Feedback: flashing over USB works

[pktpls]

Hi friend,

I appreciate your work on this R5S Debian image! It works flawlessly so far, I was even able to flash it over USB:

> rkdeveloptool db MiniLoaderAll.bin
Downloading bootloader succeeded.

> rkdeveloptool wl 0x0 nanopi-r5_bookworm-rc3.img
Write LBA from file (100%)

> rkdeveloptool ppt
**********Partition Info(GPT)**********
NO  LBA       Name                
00  00008000  rootfs

> rkdeveloptool rd
Reset Device OK.

It boots fine just as with the other flashing methods in the Readme. This should also work with upgrade_tool I guess, it's supposed to be a precompiled version of rkdeveloptool afaiu.

Good job on boiling the device support down to the essentials, it makes it so much easier for me to try and port this neat little thing to mainline OpenWrt.

[inindev]

Not sure how much you work with u-boot, but I am having trouble getting 2023.04 to boot the pci nvme. I made a patch to get the fixed regulator working with the designware pci driver. I would also point out these two recent commits fixing u-boot gpio support:

rockchip: gpio: rk_gpio: use ROCKCHIP_GPIOS_PER_BANK as divider
u-boot/u-boot@3c45497

gpio: rockchip: Add support for RK3568 and RK3588 banks
u-boot/u-boot@88b962f

=> pci enum
pcie_dw_rockchip pcie@fe280000: PCIe Linking... LTSSM is 0x1
pcie_dw_rockchip pcie@fe280000: PCIe Link up, LTSSM is 0x130011
pcie_dw_rockchip pcie@fe280000: PCIE-0: Link up (Gen2-x1, Bus0)
PCI: Failed autoconfig bar 10
PCI: Failed autoconfig bar 14

[pktpls]

Well I have to admit that embedded stuff is not (yet) my area of expertise :-) Have never done anything directly with GPIO.

With the u-boot.img that you published my NVMe disk seems to work fine, though. It's one of those cheap Kingston NV2 pieces.

I now have Fedora Server 38 booting with minimal changes to the official arm-image-installer script: https://github.com/pktpls/arm-image-installer/compare/nanopi-r5s - the LEDs don't work yet and the network interfaces have wonky names, which I assume means I don't properly pass the device tree down into the OS. But it's a great start.

[pktpls]

With this u-boot config addition I can boot vanilla Fedora:

CONFIG_CMD_BOOTEFI=y
CONFIG_EFI_LOADER=y

sudo dd bs=1M if=Fedora-Server-38-1.6.aarch64.raw.img of=/dev/sdb status=progress
sudo dd bs=4K seek=8 if=nanopi-r5/uboot/idbloader.img of=/dev/sdb conv=notrunc
sudo dd bs=4K seek=2048 if=nanopi-r5/uboot/u-boot.itb of=/dev/sdb conv=notrunc,fsync

The network interface names are fixed by what you already do in script_rc_local.

[sarnold]

Honestly, this thing should be able to boot installer ISO in UEFI mode from USB and SDCard and install efi/grub to emmc just like you would expect. I've been trying to verify the u-boot-efi-grub boot flow on some other rockchip and marvell devices (more-or-less successfully so far) so today I will take a stab at r5c and see how far i get... One thing nobody has mentioned yet regarding uboot and ESP is that bootefi should work using grub-efi binary (as kernel) and fdtcontroladdr instead of loading a real dtb in u-boot. By that I mean:

1. ESP should contain only the grub binary installed with --removable flag
2. /boot directory on rootfs contains all the usual kernel bits with optional initramfs
3. grub.cfg includes a devicetree path similar to kernel/initrd paths

The standard grub 2.06 pkgs do understand the devicetree line if added manually, but grub-mkconfig will not populate the generated grub.cfg without the devicetree loading patches in later Fedora releases.