[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.


More information about the coreboot mailing list