c-d.hailfinger.devel.2006 at gmx.net
Sat Jun 20 00:32:19 CEST 2009
On 19.06.2009 19:41, Stefan Reinauer wrote:
> Carl-Daniel Hailfinger wrote:
>>> I never got this done, I only got the "AP post code"
>>> working. But overall I think my SMP startup prototype was much cleaner
>>> than what is in v2 today.
>> I don't understand v2 startup anyway (well, except for your new code).
> Then please go ahead and learn to read it... It's important that we
> understand what's going on before changing it.
I tried multiple times and gave up after it became obvious that v3
startup did similar stuff, but was a lot more understandable. I suck at
understanding linker scripts. Lots of linker symbols and scripts and
other funky trickery combined with code includes made the code
unnecessarily hard to read. I know you understand early startup very
well and I admire that.
Anyway, given two code versions A and B which seem to be functionally
identical, but only one of them is easily understood, I'll always opt
for replacing the complicated version with the easy version unless there
are technical reasons not to do so (broken functionality etc.).
> The new code just duplicates what was there, but it adds a couple of new
> breakages. It doesn't even add any conceptional differences.
Even if the differences are only conceptual, the coding style (and the
IMHO over-usage of linker magic) is so radically different that I dread
the current v2 code (well, not the brand new stuff from Ron).
Once I know what's broken with the new code, I actually have a chance to
understand and fix it.
Firmware is magic. Early CPU startup is even more magic. (I mean this in
the best possible way.) We are magicians, but some of us are more
advanced than others. I'm still learning. Having code which is
understood by more than one magician is good. Don't get me wrong, I'm
not advocating dumbing down the code, but if we have functionally
equivalent code variants, the more readable/debuggable variant should be
> Please, please, don't get fancy. There's no real problem, we've just
> been doing too much cut and paste in the past without testing the new
> code. This made us end up with different versions of printk, some with
> locking, some without.
The v3 printk has some neat features over what I can see in v2, at least
from what I remember offhand:
- detection of NULL dereference (helped find a bug)
- detection of near-NULL dereference (same)
- detection of non-ASCII characters in case of corruption (same)
- reuse of vtxprintf for sprintf and printk
- printk buffer
- multiple output devices: USBDebug, Serial, Buffer
Since my intention is to keep v3 alive and to improve v2, I want to make
very sure that we find out what the best variant of printk is (this may
well be a fusion of v2 and v3 functionality), then have both versions
use identical code. If there are technical reasons not to do so, I'd
like to hear about them.
> And, no, porting the code from v3 over is not an option at this point.
> It does too much different stuff. Let's rather start dropping unneeded
> implementations in v2 until things look sane again and then we can
> decide what implementation we want.
I had assumed the v3 printk was universally better than all of the v2
variants. Unifying all v2 printk would indeed be a huge step forward,
but as long as I don't know which features we want, I risk eliminating
the wrong variants.
One thing v3 seems to handle better is multiple output modes (USB Debug,
Serial, Buffer), where v2 seems to have sprouted a printk variant for each.
> What would
> lock auto-busting gain us? We'd be debugging printk, but nothing more?
Sorry, it was a bad idea to bring up, mostly addressed at worries that
printk may hang. Though if that happens, we have much more pressing
problems than locking.
Please forget I brought up lock-busting. Thanks.
More information about the coreboot