[daneel_w]

For the Pine family of SBCs I highly recommend installing Tow-Boot - https://tow-boot.org/ - on the SPI flash memory to allow yourself much better boot options, including booting directly from NVMe so you don't need to keep the MicroSD card plugged-in.

[fellowmartian]

Alternatively one could go for Barebox, it’s neat and standardized like Tow-boot, but it’s not phone-focused and works on many more boards.

[Timon3]

Does this have a mechanism for automatic redundant OS upgrades? I just built a Yocto-based distribution for a board based on rk3399, but the currently integrated U-Boot is not in the best state. This could be a great alternative if it really is a bit easier to integrate/build upon.

[daneel_w]

It's just a bootloader, with a few tricks up its sleeve. All it does is letting you boot from any storage medium you want (most notably NVMe) instead of being restricted to the hardcoded sequence of the boot ROM.

[Timon3]

I understand that part. What I'm talking about specifically is part of a bootloader, see for example this page in the documentation of SWUpdate: https://sbabic.github.io/swupdate/bootloader_interface.html

By adding communication between the OS and the bootloader it's possible to implement redundant updates for whole partitions (specifically A/B-updates with a boot counter). U-Boot supports this (depending on the state of the vendor-provided fork better or worse), and Tow-Boot seems to be based on U-Boot.

[megous]

One problem with opinionated builds of U-Boot is that you'll have more work figuring out what's enabled in its config. Configure and build your own if you want this kind of control.

[irusensei]

The tow-boot software devs goes out of the way to say they are offering a boring PC boot loader experience so I wouldn’t expect any advanced features other than booting from devices.

[yencabulator]

PC boot loaders have been able to fall back to previous configurations on boot failure ("automatic redundant OS upgrades") for a long time[1], so that's not a valid excuse.

https://systemd.io/AUTOMATIC_BOOT_ASSESSMENT/

https://www.gnu.org/software/grub/manual/grub/html_node/fall...

https://www.gnu.org/software/grub/manual/legacy/Booting-fall...

[1]: Minimum about 23 years, from personal use in creating a product with A/B-root partitions.

[daneel_w]

I don't know if it retained swupdate functionality, or if it's drop-in compatible with u-boot's such.

[rjsw]

It is a bootloader bundled with the ARM64 firmware. That means you don't need to add the firmware to each OS that you might want to use so it is easier to switch between them.

[jforberg]

Yes, I considered that and agree that it would have been nicer! I didn't pursue it for this project because my jury-rigged SD boot was working fine and I wanted to move on to other parts of the system.

[throwaway173738]

SD cards are pretty unreliable so it might be good to take it out of the loop at some point. Most field failures I’ve seen for products I develop have been related to SD cards dying during power loss or falling out due to vibration.

[throwaway173738]

Does the U-boot in the SPI-NOR not support booting from NVMe? It might also be possible to patch that in from mainline if it exists. You can also often provide a “boot script” in the vfat partition that overrides the boot config in non volatile memory. This was something Freescale did with the i.MX6 that became a relatively standard thing for vendor-supplied U-boot.

[daneel_w]

The default setup does not support it for any Rockchip SoC up to and including the RK3399, which is why everyone goes for tow-boot on SPI for their Pine devices. The SoCs have a hardcoded boot sequence which includes SPI, SD, USB and eMMC, but not PCIe. It is however available since the RK3588 - e.g. the Radxa Rock5B boots from NVMe right off the bat.