U-Boot on SPI flash - discussion
#1
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?
--
Arwen Evenstar
Princess of Rivendale
#2
(11-29-2019, 04:18 PM)Arwen Wrote:  - 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.
#3
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.
--
Arwen Evenstar
Princess of Rivendale
#4
(11-29-2019, 04:18 PM)Arwen Wrote: 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.
#5
(11-30-2019, 04:07 PM)zaius Wrote:
(11-29-2019, 04:18 PM)Arwen Wrote: 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.
--
Arwen Evenstar
Princess of Rivendale
#6
(11-29-2019, 04:18 PM)Arwen Wrote: 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...

(11-29-2019, 04:18 PM)Arwen Wrote: 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   Smile
#7
(12-01-2019, 11:21 AM)zaius Wrote:
(11-29-2019, 04:18 PM)Arwen Wrote: 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.
--
Arwen Evenstar
Princess of Rivendale
#8
(12-01-2019, 11:51 AM)Arwen Wrote: 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.
#9
(12-02-2019, 06:26 AM)zaius Wrote: ...
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.
--
Arwen Evenstar
Princess of Rivendale
#10
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
Come have a chat in the Pine IRC channel >>


Possibly Related Threads…
Thread Author Replies Views Last Post
  Cant boot into an OS trashtendenz 3 584 10-23-2024, 03:49 AM
Last Post: chaylengordon
  3 days in, slow/stuck or no boot. lgmpbp2 30 3,322 09-05-2024, 08:49 AM
Last Post: lgmpbp2
  Unable to boot? YossiS 4 295 09-04-2024, 10:35 AM
Last Post: wdt
  upgrading u-boot--what version? where to get it? bsammon 11 2,403 05-22-2024, 09:33 AM
Last Post: wdt
  uboot wont boot to SD card after upgrade jbradley419 7 2,120 01-19-2024, 02:29 PM
Last Post: wdt
  Video Flashing/adjusting on boot and reboot jbradley419 0 603 01-16-2024, 09:17 AM
Last Post: jbradley419
  Brand new Pinebook Pro doesn't boot after Manjaro update johnboiles 8 3,595 12-15-2023, 02:11 PM
Last Post: wdt
  PBP won't boot after trying to reinstall Manjaro ARM soupgirl 3 1,389 12-13-2023, 08:17 PM
Last Post: trillobite
  Various freezes during boot & while running several Linux distros - hardware error? donuts 1 1,014 11-22-2023, 11:47 AM
Last Post: fxc
  Cannot boot to Kali SD card after uboot upgrade jbradley419 4 1,875 09-19-2023, 08:48 AM
Last Post: dachalife

Forum Jump:


Users browsing this thread: 2 Guest(s)