[coreboot] GSoC 2010

Carl-Daniel Hailfinger c-d.hailfinger.devel.2006 at gmx.net
Sat Mar 6 18:55:56 CET 2010


On 06.03.2010 18:12, ron minnich wrote:
> As a project, I'd still like to see someone try the "serialice as
> bootblock" and see how it goes.
>
> Let me explain. At the meeting in 2006, we decided it would be nice to
> have an "all is lost" mode wherein we'd flash a new image from the
> serial port. I still like this idea. I think serialice would be the
> foundation of this capability.
>
> If a given mainboard could be extended to include the basic commands
> for flashing, then we could experiment with this model. Coreboot would
> need to be modified, mainly to allow it to be loaded into
> lower-than-top-64k, but we do this already: it's called the "normal"
> build.
>
> I think all the bits are there, they just need assembly. This model
> would be *ideal* for me on the Dell cluster, even better than the old
> normal/fallback model.
>
> Not well defined, I realize, but I'd be happy to mentor someone who
> wanted to give this a try.
>   

Oh, I would definitely be interested (well, it is variant 2 of my
proposal), but due to the hard requirements of flashing, the code either
has to run from CAR or from RAM. Not only the stack, but also the code
has to be outside flash. Why? Simple. During write or erase of any
Parallel/LPC/FWH chip, all reads are guaranteed to return garbage (bit 6
and 7 are reserved for JEDEC completion detection on some chips, other
chips simply return the status register instead of valid data). That
means instruction fetch from ROM has to be avoided at all costs. SPI
isn't much better, many datasheets mention that the results of reads
during erase/write are undefined. Please note that this is not the fault
of flashrom (no other flashing software would be able to cope either).

There are three points in time where the "all is lost" code can be run
in theory:
1. Without CAR or RAM. No reflashing possible (see above).
2. With CAR and without RAM. Works as long as the CPU can execute code
from CAR and at the same time have either a stack in CAR (neat) or store
a few bytes elsewhere (but it needs ROMCC for that).
3. With RAM. No limitations here.

Regards,
Carl-Daniel

-- 
"I do consider assignment statements and pointer variables to be among
computer science's most valuable treasures."
-- Donald E. Knuth





More information about the coreboot mailing list