On Thu, May 31, 2018 at 5:08 PM, William Mills wmills@ti.com wrote:
Hello,
My notes on "requiring" (or strongly recommending) separate storage.
A couple of times we have gone around the issue of "is it reasonable to require new platforms have separate storage for firmware".
Pros: P1) No disk partition plan etc P2) Runtime var storage is much easier
Cons: C1) Cost C2) Boot speed C3) Board becomes "state full" and brick-able C4) Need Buy-in from board makers
I hope we understand the pros so I won't go deep on those.
WRT C1 & C2: Cost & boot speed
Pocket Beagle ($25) has a 2Kx8 I2C EEPROM built into the SIP (system in package). This allows a single binary SPL to boot from uSD on multiple boards (PocketBeagle BBW, BBB, BBBlue, TI EVM, etc) as the EEPROM has board ID info.
I looked for other low cost boards with dedicated firmware storage. PINE A64-LTS ($32) and SOPINE ($30) have 16MB of SPI flash. The original PINE A64 ($15) has no on board storage.
Are there other boards I should look at?
What would this look like if we put:
- SPL & vars only into SPI flash
- SPL & U-boot & vars into SPI flash
- SPL/U-boot or EDK2 + vars into QSPI
I assume 64KB for SPL, <500KB for SPL+Uboot, and 1MB for EDK2.
How much do we need for variable storage? That will be the next problem if we have any firmware storage. IIRC, UEFI variables can be up to 32 or 64K each. We'd probably need to restrict this some if we have limited flash.
If sizes in sysfs are accurate, then this is what I get on my laptop:
$ du --apparent-size -sh /sys/firmware/efi/efivars/ 55K /sys/firmware/efi/efivars/
I'd imagine we can get by with quite a bit less.
QSPI: 1MB $0.67 2MB $0.70 16MB $1.62 (PINE A64-LTS) 133MHz == 66MB/s U-boot, 500KB in 7ms EDK2, 1MB in 14ms
SPI: 128KB $0.28 1MB $0.33 104Mhz == 13MB/s SPL only, 64KB in 5ms U-boot, 500KB in 38ms
I2C: ID only 256x8 $0.09 BBB etc 4Kx8 $0.13 32bytes @100KHz = 2.5ms
Note that on PocketBeagle the I2C cost is already baked into the SIP so you can't subtract this cost from the cost of the SPI flash. This is a legacy issue but does so that buy-in takes time to filter down.
Would a future SIP include an SPI flash? If you do then you need to fix how big.
WRT C3: State-full and brickable
As long as the SOC supports multiple bootmodes and the board adds a button or switch to select a recovery mode, this can be handled. BeagleBone black boots from eMMC (which is brickable) but holding a button at power up causes it to ignore everything in eMMC and boot form uSD. The uSD in this recovery mode need not be EBBR compliant (but I would like to allow it to be.)
PocketBeagle like board would need to add a jumper or similar.
C4: Board maker buy-in
Probably the biggest barrier. Must show value of EBBR on legacy boards before people see the value. But if legacy works OK then why change?
Can we crowdfund free SPI flashes for board makers. ;)
Rob