I take this as a challenge, maybe you just shoot the idea down of extending use of CBMEM IDs to pre-ram? You only need an index at fixed CAR location?

We have about 100 bytes available in _car_relocatable before sandy/ivy MRC blob starts to interfere. It would not be the first case when static allocations are just fine for a long time, but eventually it starts to be inconvenient or fall apart. (Like !DYNAMIC_CBMEM).

I wouldn't really say that anything is "falling apart" right now. Do you have a use case where this is really a problem? For Chrome OS' use of vboot it never really has been (we'd do that branching anyway for overall product stability, not just for this), and I'd be surprised if other people who pick it up wouldn't come to the same conclusion. Trying to make two very diverged versions of coreboot come together as RO and RW would probably be a bad idea for more reasons than this (and I don't think we'd want to introduce a general mandate that all changes will have to be backwards compatible to old verstages in the future, or at least make a big deal out of it every time).

I'm generally wary of introducing complexity without good cause (especially in early stages), which this sounds like it might do. One of the strengths of memlayout is that it is dead simple to reason about, dynamic allocation frameworks maybe not so much. You don't want firmware that just occasionally runs out of memory in the bootblock because the allocator acts slightly different in certain edge cases. (Also, remember that if you'd want to unify this across all architectures, there are some Arm boards so close to bursting that we already have to count pretty much every byte in SRAM.)

View Change

To view, visit change 31174. To unsubscribe, or for help writing mail filters, visit settings.