U-Boot on SPI flash - discussion

[Arwen]

After reading about the various issues on using the SPI flash for U-Boot, it comes down to 2 things;

 - Bricking when you write a new U-Boot that does not work as expected. But does not allow recovery.
 - Writing to the SPI flash reliably

I can't speak to the second issue directly, will have to accept what others have to say.

However, I have some thoughts on fault tolerance for the SPI flash image This is what I came up with;

 - Stage 1 code to select U-Boot image, that has recovery by looking at a special SD card
 - data to select image 1 or 2
 - U-Boot image 1
 - U-Boot image 2

So, under normal conditions, we have an old, working U-Boot, (maybe lacking a feature like NVMe boot), installed in one SPI U-Boot slot. And we want to install a new, less tested image into the second slot. We then run a program to install new U-Boot image and change the boot image selection to newest.

If the new U-Boot image fails in such a way we can't work around the problems easily, we install a SD card that has a special signature our stage 1 code recognizes. If stage 1 sees this, it changes the U-Boot image selection to the other one, (aka old U-Boot image), and proceeds to boot.

We can also have stage 1 look for a second signature on the SD card. If found, boot off the SD card. That way, we have a choice.

Since this is all open source, the exact location and data of these signatures would be well known and documented.


So, that's my solution to the SPI issue where we could "brick" our Pinebook Pros.


Discussion anyone?