Hardware shortcomings

[moonwalkers]

Err, modern motherboards make it a LOT harder to brick by writing wrong bios/firmware
(with a backup bios)
One can legitimately complain about somewhat defective uboots that are only tested
with one distro and can somewhat brick the device when booting something else
(because the pbp has a battery, it can 'remember' a bad setup, requiring a hard reset & a uboot change)
(and it is a bit of a pain when the emmc must be disabled/removed or defective switches
to short the SPI clock if you are so brave as to write to SPI)

Modern motherboards DO NOT use BIOS, they use UEFI with CSM module (that nowadays usually turned off out of the box) for backwards compatibility with bootloaders and OSes that don't understand UEFI specification.

U-boot compatibility issues are not so much with the distros, as much as with the individual kernels - switch around the kernel while keeping the rest of the distro the same and you can indeed get an issue, swap around the whole distro while keeping the kernel and you'll only get userland-specific issues. But also swap your kernel for a wrong one on an x86 system, one that lacks particular binary blob for the hardware present, and you can also get a system that fails to get basic functionality working. If you never ran into that situation - you're very lucky you never had to just work with whatever junk gets thrown your way.

Maybe I never did anything wrong on PBP (pretty sure that's not the case, though I have been pretty conservative about u-boot changes), but I never ran into boot issues because of the battery and it "remembering" anything. 4 seconds holding power button and then brief press - system is booting fresh. Problem is that there are two locations (if SPI is empty) where it reads u-boot, 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.

Disabling eMMC (that has a simple switch on the mobo) is order of magnitude simpler than what we had to do back in 2005 with BIOS on a mobo - my roommate in uni had a bad flash. Luckily, a friend of ours had exactly the same mobo. We borrowed his BIOS chip, inserted it into my roommate's mobo, booted up the system, then on a live system pulled the BIOS ROM chip from the mobo, replaced it with the bad one, and re-flashed it. That's an order of magnitude more hassle than having to boot PBP from microSD with eMMC disabled, enabling eMMC, and replacing u-boot there. But yes, you're correct - modern x86 motherboards (which, again, about a decade since no longer use BIOS) have all kinds of protections against bad updates.

[wdt]

>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 emmc
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)
Oh,, I know not so many people are still using bios firmware,, so I write bios/firmware
The difference is that bios established a standard for most hardware, not the case in the arm world

[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.

[commiecam]

I'll apologise if I've managed to open an off-topic can of worms, for that was not my intent. But this conversation has been well worth while, even if it has gone far afield. All that I'm asking is that someone, preferably an experienced mechanical engineer, have a critical look at the hardware, preferably doing a few dumb things in an effort to make it break, BEFORE you go to the expense of committing even to beta test production. It's bound to drastically reduce your headaches and later redesign expenses while doing wonders for your reputation. This is a good little box and it can have a bright future. I just want to see that future come true so I can finally put X86 and AMD64 in the circular file for good. And as to going off-topic, I don't think that you can actually claim to have an O/S distro on Pinebook Pro if that system does not have within it the means to either run from SD card or install to emmc or other disk and run from first boot attempt. Much like what Linus did when releasing Linux, i.e. "It ain't Linux until I sez so!", Pine64 really ought to consider not allowing a distro onto their website's list of same until the author has demonstrated that it will do just that on a stock, factory fresh Pinebook Pro. Sorry for all the wind, but these are GOOD products and this is my two cents opinion on how to make them succeed as they so much deserve to.

[moonwalkers]

I'll apologise if I've managed to open an off-topic can of worms, for that was not my intent.  But this conversation has been well worth while, even if it has gone far afield.  All that I'm asking is that someone, preferably an experienced mechanical engineer, have a critical look at the hardware, preferably doing a few dumb things in an effort to make it break, BEFORE you go to the expense of committing even to beta test production.  It's bound to  drastically reduce your headaches and later redesign expenses while doing wonders for your reputation.  This is a good little box and it can have a bright future.  I just want to see that future come true so I can finally put X86 and AMD64 in the circular file for good.

Agree, in general.

And as to going off-topic, I don't think that you can actually claim to have an O/S distro on Pinebook Pro if that system does not have within it the means to either run from SD card or install to emmc or other disk and run from first boot attempt.  Much like what Linus did when releasing Linux, i.e. "It ain't Linux until I sez so!",  Pine64 really ought to consider not allowing a distro onto their website's list of same until the author has demonstrated that it will do just that on a stock, factory fresh Pinebook Pro.  Sorry for all the wind, but these are GOOD products and this is my two cents opinion on how to make them succeed as they so much deserve to.

So... Are you asking for distros to run on the firmware that's installed of factory-fresh PBP (Das U-Boot built with binary blobs), or you're asking that they work regardless of firmware shipped with PBP, if they ship their own firmware? Are you asking that users are blocked from editing the OS section of the PBP's wiki page until the OS passes some sort of Pine64's certification? Something else? Pine64 clearly advertises the product as "just the hardware", the rest is clearly intended to be a community effort - hence the OS list in the wiki, and the cornucopia of different U-boot builds and everything else.

Oh, and BTW something like Debian nowadays works on PBP just fine, including using fully open source U-Boot build in its repos. Well, there are minor issues like lack of deep sleep support, but that was the case for factory-installed U-Boot with blobs too, at least when I originally got my PBP in January 2020. The only problem with getting Debian to work there is that you have to manually partition, leaving enough space for U-Boot, manually install the appropriate U-Boot package using chroot (u-boot-rockchip is the package name, IIRC), and manually get U-Boot to actually be written onto eMMC or wherever you want it to be written. That is something that could benefit from either some automation, or at least better and more clear documentation, and I've been just too lazy to update the wiki pages, so feel free to blame the lack of docs me.