[coreboot] [RFC] Improve very early boot

Patrick Georgi patrick at georgi-clan.de
Thu Mar 15 18:41:48 CET 2012


Am 15.03.2012 15:00, schrieb Kyösti Mälkki:
> On selected boards, some hardware initialisation is placed in the
> bootblock. The source files and directories are currently hard-coded in
> Kconfigs, which is sort of ugly.
> 
> A few months ago I put together changeset [1], which hasn't drawn much
> review or interest.
Thank you for that contribution - I'm really sorry that it fell through
the cracks. This was partly due to timing (slow development back then),
partly because it's a rather involved patch, doing similar things at once.

It's not a very conscious decision on my part, but I sometimes look at
changes, and quickly close them because they overwhelm me, and I don't
always have the time and concentration to dive into it very deeply -
this one, I looked at several times, with no real results :-(

I hereby pledge to resist that urge in the future and at least give some
hints on how I'd like to see things split up to simplify a review.

Things that could be separated out:
- removing the AMD no-op bootblocks could be a separate change - that
probably would be committed in a day or two.

- renaming the functions - I explicitely added the bootblock_ prefix so
the context in which this code is used is clear. It can be argued that
the filenames are enough of a clue, so that would probably go through as
well, after talking about this aspect.

- the rest. It's a rather involved change. It doesn't turn coreboot
upside down, but I think it's much easier to consider the consequences
if we don't have to fear some side effect hidden in the "noise" of the
two changes above.

> One benefit of my changeset is that it can be
> extended to move superio and console initialisation to bootblock. 
> Serial-line IO can then be used to switch between fallback/normal
> romstage and early POSTs could go to serial too.
We can consider doing so (It adds complexity to something we tried to
keep small, but I think it's worth it). But we should also aim at moving
all chipsets to behave that way.

You can't do that alone (of course), but a discussion on that on the
list (like what's going on now) goes a long way to make sure we all know
what to expect from the change, and to enlist support in making it
happen everywhere.


Thanks,
Patrick




More information about the coreboot mailing list