Hardware shortcomings

[moonwalkers]

>and from what I understand (perhaps incorrectly), u-boot on microSD can override u-boot on eMMC if u-boot on eMMC is configured to redirect the SoC to boot from microSD first.
No, 1st uboot found (really idbloader) will be the one used
This is why "boot_targets" in uboot,,,,, nearly always a SD boot is using the emmc uboot
So you really have no idea if the uboot on SD is going to be OK if it is written to emm
Since nothing is mounted (in a file system tree) by uboot, it has to take into account both 1 & 2 partition systems
So, 6 things to look for (3 * 2,,, ie, /boot.scr,,,,,/boot/boot.scr)

You're correct, my memory wasn't serving me right, going back to the docs it is exactly as you said. Still, I have to say historically it's taken me less time to debug boot issues on original Pinebook, Pinephone, and PBP, than some of the issues I've encountered on BIOS-based or even UEFI-based systems. Perhaps I was just lucky, perhaps it was just insufficient exposure compared to x86, but for now my experience has been reasonably positive. Not perfect, but good.

Oh,, I know not so many people are still using bios firmware,, so I write bios/firmware

Gotcha.

The difference is that bios established a standard for most hardware, not the case in the arm world

BIOS became established as a de-facto standard thanks to IBM's market dominance combined with specific yet open architecture of the original IBM PC and developers that quickly started optimizing for the specific hardware. But there are plenty inconsistencies between different BIOS implementations. Even among IBM products there were some "interesting" differences in behavior between BIOSes, sufficient so that, e.g., what was booting fine on 750C wouldn't boot on the later 701C and vice versa. And then again the same between 701C and the later 755CX. Not because of the OS drivers, but because of the bootloader. With UEFI it is again the same problem - first 32-bit vs 64-bit UEFI firmware (I remember InsydeH2O giving me headache on some Acer laptop back around 2010), then just general quirks of behavior on each particular system... I have reasons to really, really hate UEFI implementation used by HP on my main work laptop for many hours of productive time wasted, not even mentioning how slow it is.

By the time ARM came to prominence writing apps to well-performing hardware abstraction layers became the norm, and it never established a single whole system architecture like PC did since they were focusing on the CPU design and not the overall system design. The closest ARM has right now to a single specification is Arm SystemReady certification program with specifications like SBBR/EBBR/LBBR. And U-boot, closest thing to the de-facto standard in ARM world for a BIOS equivalent, is already compliant with EBBR. Which includes UEFI boot method, just doesn't include ACPI tables for device description - it has to rely on DeviceTree instead. Speaking of which, that just made me realize why someone on these forums some months ago had problem trying to get their Debian installation to work - they mentioned using UEFI for booting with GRUB, and if I were to guess probably didn't have GRUB configured to use DeviceTree file... Speaking of which yet again, I think that may have also been my mistake when I failed to get GPU to work on my RPi400 when I tried booting it with TianoCore-based firmware - in ACPI mode the GPU wouldn't come up because driver lacks ACPI bindings, and in DeviceTree mode the system just wouldn't boot up altogether, most likely because I also forgot to specify the DeviceTree file in GRUB.

And as to where U-boot is installed - while EBBR specification recommends ROM, it is perfectly accepting of the first 16MiB of eMMC or microSD card model that is used on PBP.