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.
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?
Bill
---------------- William A. Mills Chief Technologist, Open Solutions, SDO Texas Instruments, Inc. 20450 Century Blvd Germantown MD 20878 240-643-0836
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
On Thu, May 31, 2018 at 06:08:09PM -0400, William Mills 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.
I think this is rather optimistic w.r.t. EDK2.
I'd have pretty serious concerns about trying to running EDK2 port from 2MB of FLASH. You'd either have to aggressively restrict the feature set, load most of the drivers from the EFI partition (which rather defeats the point of using SPI flash in the first place) or make running a DEBUG build impossible.
Daniel.
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?
Bill
William A. Mills Chief Technologist, Open Solutions, SDO Texas Instruments, Inc. 20450 Century Blvd Germantown MD 20878 240-643-0836 _______________________________________________ Arm.ebbr-discuss mailing list Arm.ebbr-discuss@arm.com
On 06/01/2018 06:08 AM, Daniel Thompson wrote:
On Thu, May 31, 2018 at 06:08:09PM -0400, William Mills 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.
I think this is rather optimistic w.r.t. EDK2.
I'd have pretty serious concerns about trying to running EDK2 port from 2MB of FLASH. You'd either have to aggressively restrict the feature set, load most of the drivers from the EFI partition (which rather defeats the point of using SPI flash in the first place) or make running a DEBUG build impossible.
Daniel.
I tend to agree. That is why I quoted 1MB and 2MB flash parts for EDKs. However for boot time I use 1MB.
I got 1MB by downloading the debian buster qemu-efi-aarch64 package: https://packages.debian.org/buster/all/qemu-efi-aarch64/download
bill@gtwmills:/usr/share/AAVMF$ hexdump AAVMF_CODE.fd 00f7520 ffac ffff ffff ffff ffff ffff ffff ffff 00f7530 ffff ffff ffff ffff ffff ffff ffff ffff * 0200000 0000 0000 0000 0000 0000 0000 0000 0000 * 4000000
So ~1MB of code, 1MB of FF's, and 62MB of 0's
(/usr/share/qemu-efi-aarch64/QEMU_EFI.fd is just the first 2MB of above)
(/usr/share/AAVMF/AAVMF_VARS.fd is 64MB of 0's)
Bill
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
boot-architecture@lists.linaro.org
-
Daniel Thompson -
Rob Herring -
William Mills