Orange Pi R1 Plus LTS (RK3328) - Experiments with NetBSD ROCK64 images (round 2)

• We need to use 1500000 baud for the serial console
• It uses an old (2017.09) u-boot
• It looks for the FDT via fdtfile=rockchip/rk3328-rock64.dtb
• This is actually in /dtb/rockchip/rk3328-rock64.dtb
• The dts is now at src/sys/external/gpl2/dts/dist/arch/arm64/boot/dts/rockchip/rk3328-rock64.dts
• The boot tried BOOTP to no good end

I am seeing this as a pattern for some reason. When I have a "freshly" written SD card, it won't be willing to boot from it the first time I try it. Then if I put the card back in my card reader, examine it via my linux system, then put it back into the ARM board, it works as it should. On this system, the "fresh" card failed to boot NetBSD from the card and went into this BOOTP loop. On other systems with emmc, it would not even run u-boot from the "fresh" card but would run u-boot from the image on emmc instead.

Whatever that may be all about, it still does nothing useful, I see:

canning disk rksdmmc@ff500000.blk...
Found 2 disks
....
....
....
>> NetBSD/evbarm efiboot (arm64), Revision 1.13 (Thu Aug  4 15:30:37 UTC 2022)
Press return to boot now, any other key for boot prompt
booting netbsd - starting in 0 seconds.
5482464+2521184+2680948+1527188 [437266+711504+498085]=0xf96120

And that is it. Nothing more appears.

This screen clearing nonsense would be nice to switch off -- This could be the efi booting "middleman" if there is such a thing. Whatever it is, it is a liability, not an asset.

Plans and ideas

• Study the DTS file now that I know where it is.
• Build a new u-boot from the 2022.10 sources for arm64 (may as well target the r1+)
• Look at the NetBSD patches for U-boot circa 2022.10
• A working saveenv would be one goal (onto the SD card)
• Study the EFI booting scheme
• Study the DTS/FDT scheme
• Learn how to make a dtb from a dts
• start work on a custom DTS for the R1+