Hello Noé,
first, welcome to the coreboot community!
Am 15.11.2011 12:07, schrieb Noé Rubinstein:
system, by putting a 'fallback' Coreboot in the high, write-blocked part
of the boot ROM, and using the fallback mechanism already implemented in
Coreboot in order to fallback in case the user-flashed firmware does not
work.
Why put the fallback in the high parts? The only reason I could find is
that you intend to use a boot block protection scheme (as these provide
protection only for some high region), but they usually cover only a
rather small area - too small for coreboot.
found with the right name. That's why the fallback mechanism has to
search for the fallback image only in the high part of the RAM. That
requires modification of walkcbfs_asm and of cbfslib to be able to find
a file after an offset.
[...]
overwrite part of another file. On the contrary, when looking for a
fallback component, the file headers before the fallback offset should
not be trusted (that's the whole point), so the beginning of the ROM
should be entirely skipped.
These two special cases can be dropped if fallback is aligned to the low
end of the image: It's always encountered first, and the CBFS alignment
data is protected, too.
I'm snipping away your other proposals for now. The reason is that there
are various projects out there that use coreboot and have safe updates
on their agenda, and I'd rather have a complete set of constraints (eg.
limitations due to flash chips that only provide boot block protection)
before planning what to do about them.
Patrick
--
coreboot mailing list: coreboot@coreboot.org
http://www.coreboot.org/mailman/listinfo/coreboot
