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?

[pfeerick]

 - 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

Sounds very similar to the solution used on the ESP8266 and other SPI flash based MCUs. They have a bootloader (eboot IIRC) for over the air (wireless) flashing, and a dual slot system. one slot for the current firmware image, and one for the next or last, as the case may be. When a new image is written (to the non-running slot), at the end of the update, if the write was successful, swapping of the slots is scheduled, and the unit is reset. The bootloader, in looking for commands at boot up, sees that scheduled update, and marks the new slot as active, and then passes control over. If the update failed for some reason, the last working image is still present, and the slot isn't changed, so no harm done. Rinse, repeat. This model works quite well there, and has been well tested, so no reason the same wouldn't work here.

[Arwen]

Yes, it's a common technique.

My old Cisco router did something similar. It had a tiny initial boot ROM, that activated the console and performed some initialization. Then, unless told otherwise on the console, started the primary router image from a much large flash device. The large flash device could hold 2 or more router images, unless you needed all the features.

If things went badly with the router image, you could even reload the router image via initial boot ROM. Clumsy, but doable. Meaning the router was not bricked.

[zaius]

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.

Discussion anyone?

I would suggest if the stage 1 code recognizes an SD then it boots from that.  It seems more robust than looking for a special signature, and doesn't require an SD that has a special signature, or a working boot image on the SPI.

[Arwen]

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.

Discussion anyone?

I would suggest if the stage 1 code recognizes an SD then it boots from that.  It seems more robust than looking for a special signature, and doesn't require an SD that has a special signature, or a working boot image on the SPI.

We already have that, nothing to be added. Any bootable SD card installed during power on / reset will cause the eMMC U-Boot to transfer booting to the SD card. That was an update to U-Boot a few weeks ago. We would then use the SD card's OS to fix the U-Boot of the eMMC.

My thought was allow continuing to boot to the eMMC or NVMe. Fix it from there, which may have the tools and U-Boot images. Of course, if we booted from SD card, we can mount an eMMC or NVMe file system, and get access to the tools & U-Boot images.

Perhaps something simpler. If the SPI stage 1 sees a bootable SD card, boot off it. If the SPI stage 1 sees a non-bootable SD card, then try the alternate SPI U-Boot image. That gets us the simplicity you were looking for, and fault tolerance I was looking for.

[zaius]

We already have that, nothing to be added. Any bootable SD card installed during power on / reset will cause the eMMC U-Boot to transfer booting to the SD card. That was an update to U-Boot a few weeks ago. We would then use the SD card's OS to fix the U-Boot of the eMMC.

Not if the SPI is first in the boot order...

Perhaps something simpler. If the SPI stage 1 sees a bootable SD card, boot off it. If the SPI stage 1 sees a non-bootable SD card, then try the alternate SPI U-Boot image. That gets us the simplicity you were looking for, and fault tolerance I was looking for.

OK  

[Arwen]

We already have that, nothing to be added. Any bootable SD card installed during power on / reset will cause the eMMC U-Boot to transfer booting to the SD card. That was an update to U-Boot a few weeks ago. We would then use the SD card's OS to fix the U-Boot of the eMMC.

Not if the SPI is first in the boot order...
...

Actually yes. It's the payload of U-Boot installed on the SPI that would do the search for bootable SD card. That's exactly what we have for U-Boot on eMMC now.

When the Pinebook Pros first came, people could not boot off SD cards, if their eMMC had a valid boot loader. One of the first updates to the eMMC load included a U-Boot update that checked for a bootable SD card, BEFORE booting the eMMC. The same can apply to the SPI U-Boot loader.

The SPI U-Boot preferences should probably be;
 - SD card
 - NVMe SSD
 - eMMC

And eventually USB after SD cards but before NVMe SSDs or eMMC.

[zaius]

Actually yes. It's the payload of U-Boot installed on the SPI that would do the search for bootable SD card. That's exactly what we have for U-Boot on eMMC now.

Right, so SD is first in the boot order.  Unless I'm misunderstanding something, currently, the ROM goes to SPI, doesn't find boot, then goes to eMMC, which has boot, but tells it to boot from SD first.   So if the SPI has boot, then it should tell to it  to boot from SD first (which is what we have on the eMMC now.)  If it doesn't find a bootable SD, it would proceed to boot from SPI or eMMC, respectively.

Therefore, we agree having an SPI boot requires the SPI to look for a bootable SD to have that same recovery procedure.  So moving forward, since disabling or overriding the SPI is difficult, the SPI writing procedure should also "read after write" to make sure it was written correctly.

[Arwen]

...
Therefore, we agree having an SPI boot requires the SPI to look for a bootable SD to have that same recovery procedure.  So moving forward, since disabling or overriding the SPI is difficult, the SPI writing procedure should also "read after write" to make sure it was written correctly.

Yes, the SPI boot should look for a bootable SD card first.

And yes, we probably should check the program that writes the SPI, and see if it does a "read after write" verification step. If not, we can probably do so ourselves in a wrapper script.

I've not yet received my eMMC order for my ROCKPro64. Whence it arrives I can start fumbling through some of the details. It has easier SPI recovery, which is one of the first things I need to setup. Then I can look at various SPI U-Boot features.

[xalius]

You can write SPI flash from u-boot or from Linux, for emergency recovery even in the PBP, two IC test clips are probably the easiest solution...
https://www.ebay.com/itm/5-pair-Single-H...xyYu9SLrnj