Hi, everyone - I’m trying to figure out what I’m sure will be a pretty silly problem, but I’d like to figure it out anyway.
I’m playing around with boot options on an SD card, and occasionally I manage to screw that up badly enough that the system won’t boot. And today, like a chump, at this moment I’ve reused the other SD card I was using for something else, so here I am not booting at all. I think I got here by using the select-boot-order thing to pick “sd” without having a working SD card, alas.
My understanding of the current boot process is likely wrong, but here it is: on power on the hardware looks for the state of the switch on the SoM, and decides where to look for U-boot. U-boot reads a file saying where image it needs to boot is, goes looking for that image, and if it doesn’t find it there, the process fails. This failure is silent unless you’ve got the U-Boot console visible via the serial port.
My questions, that might not make sense if my understanding is nonsense are:
Is there a way to give U-Boot a fallback option? Or does it just commit itself and that’s it.
A while back I thought there was some work being done to make the U-Boot console visible on I think either the screen or via the HDMI port. Am I right about that, and if so how do I take advantage of it?
If I’m going to keep playing with new kernels/boot options, does it seem reasonable to you that I want to drill a hole in just the right place on the heat sink so that I can flip that switch without dismounting and remounting the whole thing every time? I think I can manage this with a 6mm bit but solving a software problem with a drill bit feels a little bit … uncivilized.
depending on the position of the dip switch, u-boot is loaded from sd-card or from emmc
independent where u-boot was loaded from, u-boot looks for extlinux.conf or boot.scr on a usb drive, on sd-card or on emmc (in that order)
the first one it finds gets loaded and executed which loads kernel and initrd
the initrd contains information where the rootfs is which it uses to start /bin/init
The handbook is still outdated concerning this so I wrote this to help improve it in the future:
I have my DIP switch set so that it loads u-boot from SD-card. This makes sense for me because I sometimes build my own custom u-boot and then i can just swap out my sd-cards to replace a possibly faulty build with a working one and don’t have to remove the heatsink all the time. If one does not tinker around with rebuilding u-boot I’d recommend to have it on emmc.
The Boundary devices u-boot fork that the Reform is using has had HDMI support for a while. If your internal display does not come on early so that you can see u-boot boot messages, then you can at least use HDMI to see them. Ideally you might want to upgrade your u-boot to the most recent version which you can find here:
you have fallback options but only for the choice of device u-boot loads extlinux.conf or boot.scr from. For the source of u-boot itself (emmc or sd-card) there is no fallback
hdmi and the internal display are working under uboot but for the latter you need the latest uboot version
depends what exactly you want to play with. Do you really want to play with u-boot directly or just with kernel and boot options?
Thank you, that’s a useful clarification. I’ve generally been sticking to the mnt-provided source and tools for updates, and I’m glad to see the version of uboot I need is in there.
Where can I download a boot image from, to recover? I thought the right answer for this was to get the build artefacts from Reform / reform-system-image · GitLab CI jobs but it looks like the recent jobs either failed or were cancelled, and the older artefacts have all expired.
The artifacts of the last successful run should never expire (it says on the right hand side “These artifacts are the latest. They will not be deleted (even if expired) until newer artifacts are available.”) and indeed they have not:
Another source for downloadable system images is:
There is also a stable link which will always point to the latest available releases:
Note, that these system images use Debian unstable. If you prefer Debian stable (Bookworm) then you can also download bootable system images from reform.debian.net
I’m a total gitlab noob and have literally never visited that page. The information on it seems very misleading. Funnily, gitlab itself seems to agree that its value is questionable as it suggests to fill out a survey about its usefulness:
Well, I appear to be making some progress, but now I’m successfully at the stage of “uboot works for the internal display, but I think uboot is either reading an extremely wrong boot script, or no boot.scr at all.” Where does boot.scr live, an what should it read?
To get to the bottom of this it would be very helpful to get any output, any error messages at all. If you do not have a USB UART serial adapter, maybe now that you have the display working you can take a photo of what u-boot is complaining about in your case?
u-boot will try to find the following files in the first partition of usb, sd-card or mmc:
/boot/extlinux/extlinux.conf
/extlinux/extlinux.conf
/boot/boot.scr.uimg
/boot/boot.scr
/boot.scr.uimg
/boot.scr
The file boot.scr is generated by the flash-kernel package and its template looks like this:
How exactly it should look like depends on the kernel you have installed because template variables like @@KERNEL_VERSION@@ have to be filled with the correct values. You can find a working boot.scr in the first partition of the system images you can download.
