search

inindev / nanopi-r5

stock debian arm64 linux for the nanopi r5c & r5s
GNU General Public License v3.0
106 stars 17 forks source link

Feedback: the device is capable of booting from a USB drive #9

Open arbv opened 1 year ago

arbv commented 1 year ago

I have successfully booted unmodified Fedora Server 38 image from a USB drive. In order to accomplish that, I have flashed a small image with u-boot only into eMMC memory of the device. The u-boot (2023.04) was built with UEFI support. See #2 and #6 (in particular, this https://github.com/inindev/nanopi-r5/issues/6#issuecomment-1564912171).

arbv commented 1 year ago

I have also booted an unmodified Fedora Workstation image of the same version (also booted in UEFI mode). Works fine, GPU within GNOME is detected as using Panfrost driver.

nicolas314 commented 10 months ago

I have stupidly destroyed the SD card reader in my nanopi R5s... Good thing is: it is now running this Debian image, so all is not lost. If I want to be able to change the OS on EMMC, all I would need is the ability to boot from USB storage when detected. Question for you guys: is there any possibility we could modify the uboot script on the current device to allow for that? Any help greatly appreciated!

inindev commented 10 months ago

Removable media is preferred to non-removable. If you have a removable device, it will boot before the emmc.

If you make a removable mmc and rename /boot/extlinux to something else like /boot/extlinux.old it will not be seen as bootable and the bootloader on the mmc will then try to boot the emmc device.

Of course you can put a boot loader on the emmc device and it should just boot without mmc.

nicolas314 commented 10 months ago

Ah I don't have an mmc to try out, but I have USB storage devices. The FriendlyWRT version of u-boot accessed from the serial console has a run usb_boot option that can start from a USB thumb drive (worked for me once). Unfortunately all I have now is this repo's u-boot version without that option. I was thinking maybe there would be a way to modify extlinux to add an option to boot from USB? I don't dare touch u-boot on EMMC, it is currently my last option to boot that device.

inindev commented 10 months ago

It is the more modern Standard Boot: https://docs.u-boot.org/en/latest/develop/bootstd.html

I do not have a device in front of me to test this, but I think it should just be:

setenv boot_targets "usb"
boot
nicolas314 commented 10 months ago

Excellent, thanks! I managed to boot the board off a USB stick running the same image. I tried to persist the changes to boot_targets but could not find a way (no saveenv). All I need is re-arrange the default device boot order: usb nvme mmc1 mmc0 ... Any ways to do that without recompiling u-boot? Thanks again!

inindev commented 10 months ago

I have stupidly destroyed the SD card reader in my nanopi R5s...

Is it mechanical damage? If you are handy with a soldering iron, try this: https://www.amazon.com/gp/product/B00E6PVMU2

The bootloader is not setup with a save environment. Either do what you are doing now, or replace the boot loader. I can make a bootloader that has an environment or that boots usb, mmc0

It is not as bad as it sounds to replace it on the emmc:

sudo dd bs=4K seek=8 if=idbloader.img of=/dev/mmcblk0
sudo dd bs=4K seek=2048 if=u-boot.itb of=/dev/mmcblk0
nicolas314 commented 10 months ago

Ah, thanks for the thoughts but yes it is mechanical damage and my soldering skills are not what they used to be. I opened the box to access the motherboard and UART, forgot there was an SD card reader, and broke it in half. Should be fine as long as I can boot from other media: EMMC, USB, or even NVME. No worries I can build another boot loader with media in a different order. Thanks again for sharing such a useful project!

sarnold commented 10 months ago

I don't have access to the UART yet; can someone post the output of printenv from u-boot prompt? Thanks!

inindev commented 10 months ago 
=> printenv
arch=arm
baudrate=1500000
board=evb_rk3568
board_name=evb_rk3568
boot_targets=mmc1 mmc0 nvme scsi usb pxe dhcp spi
bootcmd=bootflow scan
bootdelay=2
cpu=armv8
cpuid#=54474e4b383400000000000000060714
eth1addr=46:37:9d:1b:c1:78
ethaddr=46:37:9d:1b:c1:79
fdt_addr_r=0x0a100000
fdtcontroladdr=edbec250
fdtfile=rockchip/rk3568-nanopi-r5c.dtb
fdtoverlay_addr_r=0x02000000
kernel_addr_r=0x02080000
kernel_comp_addr_r=0x08000000
kernel_comp_size=0x2000000
loadaddr=0xc00800
partitions=uuid_disk=${uuid_gpt_disk};name=loader1,start=32K,size=4000K,uuid=${uuid_gpt_loader1};name=loader2,start=8MB,size=4MB,uuid=${uuid_gpt_loader2};name=trust,size=4M,uuid=${uuid_gpt_atf};name=boot,size=112M,bootable,uuid=${uuid_gpt_boot};name=rootfs,size=-,uuid=B921B045-1DF0-41C3-AF44-4C6F280D3FAE;
pxefile_addr_r=0x00e00000
ramdisk_addr_r=0x0a200000
script_offset_f=0xffe000
script_size_f=0x2000
scriptaddr=0x00c00000
serial#=3ad598e2b63fdc37
soc=rk3568
stderr=serial@fe660000
stdin=serial@fe660000
stdout=serial@fe660000
vendor=rockchip

Environment size: 1014/126972 bytes
sarnold commented 10 months ago

Hmm, except for the bootcmd value that ^^ looks almost identical to rk3328 renegade with mainline u-boot. The latter didn't like booting from sdcard using efi/grub but nanopi-r5c booted up right away with the same sdcard image and u-boot defconfig. Simple config is:

Note u-boot was built with the latest rkbin files:

Rambling references from testing:

sarnold commented 10 months ago 
[    0.000000] Booting Linux on physical CPU 0x0000000000 [0x412fd050]
[    0.000000] Linux version 6.6.8-gentoo-dist (root@jiji.arm.dev.gentoo.org) (aarch64-unknown-linux-gnu-gcc (Gentoo 13.2.1_p20230826 p7) 13.2.1 20230826, GNU ld (Gentoo 2.40 p5) 2.40.0) #1 SMP PREEMPT_DYNAMIC Wed Dec 20 17:39:34 -00 2023
[    0.000000] KASLR disabled due to lack of seed
[    0.000000] Machine model: FriendlyElec NanoPi R5C
[    0.000000] earlycon: uart8250 at MMIO32 0x00000000fe660000 (options '')
[    0.000000] printk: bootconsole [uart8250] enabled
[    0.000000] efi: EFI v2.10 by Das U-Boot
[    0.000000] efi: RTPROP=0xecbd3040 SMBIOS=0xecbd2000 MEMRESERVE=0xacee1040 
[    0.000000] NUMA: No NUMA configuration found
[    0.000000] NUMA: Faking a node at [mem 0x0000000000200000-0x00000000efffffff]
[    0.000000] NUMA: NODE_DATA [mem 0xef5bd2c0-0xef5d3fff]
[    0.000000] Zone ranges:
[    0.000000]   DMA      [mem 0x0000000000200000-0x00000000efffffff]
[    0.000000]   DMA32    empty
[    0.000000]   Normal   empty
[    0.000000]   Device   empty
[    0.000000] Movable zone start for each node
[    0.000000] Early memory node ranges
[    0.000000]   node   0: [mem 0x0000000000200000-0x00000000ecbd1fff]
[    0.000000]   node   0: [mem 0x00000000ecbd2000-0x00000000ecbd3fff]
[    0.000000]   node   0: [mem 0x00000000ecbd4000-0x00000000ecbd4fff]
[    0.000000]   node   0: [mem 0x00000000ecbd5000-0x00000000ecbd6fff]
[    0.000000]   node   0: [mem 0x00000000ecbd7000-0x00000000ecbd7fff]
[    0.000000]   node   0: [mem 0x00000000ecbd8000-0x00000000ecbdbfff]
[    0.000000]   node   0: [mem 0x00000000ecbdc000-0x00000000eff0ffff]
[    0.000000]   node   0: [mem 0x00000000eff10000-0x00000000eff1ffff]
[    0.000000]   node   0: [mem 0x00000000eff20000-0x00000000efffffff]
[    0.000000] Initmem setup node 0 [mem 0x0000000000200000-0x00000000efffffff]
[    0.000000] On node 0, zone DMA: 512 pages in unavailable ranges
[    0.000000] cma: Reserved 64 MiB at 0x00000000e4e00000 on node -1
[    0.000000] psci: probing for conduit method from DT.
[    0.000000] psci: PSCIv1.1 detected in firmware.
[    0.000000] psci: Using standard PSCI v0.2 function IDs
[    0.000000] psci: MIGRATE_INFO_TYPE not supported.
[    0.000000] psci: SMC Calling Convention v1.2
[    0.000000] percpu: Embedded 32 pages/cpu s92840 r8192 d30040 u131072
sarnold commented 10 months ago

Also, again, thanks! this really does help with the bootstrapping as someone else mentioned...