[coreboot] [RFC] Universal panic-room serial console, for x86 BIOS bootblock

Pete Batard pete at akeo.ie
Fri Jul 15 03:30:22 CEST 2011


On 2011.07.14 11:59, Andrew Goodbody wrote:
> I object
> to the use of an absolute description to refer to something that is not
> absolute.
>
> I would prefer it not be described as universal at all.

Point taken.

Believe me, I'd really like to keep you happy and change the U to 
something like "Useful" instead of "Universal" (though I guess even 
"Useful" could not be used in the absolute, since people may say UBRX 
isn't useful to them), and I almost went ahead with that... But on 
second thoughts, I really don't see why UBRX should lack the punch that 
both USB or U-boot have, through their use of "Universal", especially 
when our aspirations are exactly the same (the choice of the UBRX 
acronym was partially inspired by U-boot).

Arguably, the Universal in USB does not apply to the protocol itself, 
since a protocol is of course universal between all entities that that 
speak it (RS232 is universal too), so the scope of Universal in USB has 
to be with regards of its intended reach, just as is the case with 
U-boot. And clearly both USB and U-boot are abusing the Universal in 
their name then, since I don't see how they too can qualify as absolute 
universal (unless one acquires the right to use universal only once they 
are successful enough).

If you want to say it's a misnomer or abuse, you are of course 
technically correct, so I'm not going to dispute that. But I wouldn't 
mind having people be drawn to a project because they see that its 
aspiration is to provide something that is as universal as can be, just 
like USB and U-boot, than a project whose name is factually correct, but 
which may leave newcomers with some doubt about what its intended target 
reach is.

If people want a specific target supported, that UBRX does not support, 
then, resources permitting (and provided there is interest in UBRX, 
which remains to be seen), I'll do my best to get it supported. I'm 
currently not aware of any board that we shouldn't technically be able 
to support: Unless they are crazy fast, we should be able to disable 
watchdogs from automating the upload of a panic-room payload, so we are 
unlikely to need a special case for that. Dual BIOS is more of an issue, 
but the main problem is that we don't have data on Dual BIOS, and nobody 
seems to have reverse engineered much of it. So the only big unknown I 
have is with regards to the powering up of LDs, as well as any extra 
chipset initialization, such as the 48 MHz clock init from SB800, that I 
may have missed.
Thus, the target of being universal is more likely to be constrained by 
resources than by technical feasibility.

If U-boot can use Universal, I think I'm going to follow suit, while 
agreeing with you that the Universal from UBRX is unlikely to ever be 
absolute.

>> Finally, please remember that this is only a PoC, which is expected to
>> be incomplete or, gasp, have bugs (still working on it). Most of the
>> limitations or problems currently applying, can either be lifted or
>> worked around one way or another. However, there is only so much I can
>> test so yes, in its current instance, U(*)BRX does fall short of its
>> established goal of Universality(*). However, I'm not seeing a major
>> reason why it couldn't get there, hence the claim.
>
> And so increase complexity and reducing reliability.

Or prevent misconfiguration errors, ensure that most of the code (since 
much of it would be common/factorized) has been tested by a greater 
number of people, and increase reliability and reach.

> I was suggesting being able to
> build knowledge into a specific build of the panic room in order to
> reduce complexity and so get closer to your aim of universal support.

OK. There actually is some of that in the latest version.

>> But I do see the need for blanket detection being the main focus, if we
>> can easily perform it and it avoids being limited to only what we know.
>
> Yes, but not at the cost of excessive complexity and reduced reliability.

I'm not seeing the reliability being reduced that much. The more 
universal something is to use (i.e. the less configuration is required) 
the greater the reach and thus the greater testing and reliability.
I could talk about USB/HID vs PS/2 for reliability, for low bandwidth 
devices (keyboards/mice) but you'll likely dismiss this as a straw man.

I'm also assuming that you anticipate a series of special cases, when 
talking about "excessive complexity", where, on the other hand, I 
anticipate factorization, since I have seen a good chunk of it already 
(unless I misread the datasheet, the intel ICH/SIO init, for all ICHs, 
factorizes amazingly well).

And while I'm talking about factorization, since I went through most of 
the early_serial.c sources from coreboot, it looks like much of the code 
there could be factorized. Or at least some harmonization could benefit 
some of the SIO inits. I would even venture to say that, from not 
duplicating/factorizing existing tried and tested code, there likely 
exists reduced reliability in the coreboot early_serial sources.

> Well your plan requires two motherboards plus a development system.

Not at all.

Only one motherboard and a development system, which is what most people 
would have. I talked earlier about picking one chip from one system to 
put it onto another, but that was in a different scope.

Use flashrom to flash the BIOS, with only an UBRX bootblock, and you 
(should) now have access to a panic-room, which you can use to explore 
the hardware, test a section of your dev BIOS, reflash, etc, provided 
the relevant panic-room payloads are available, which isn't UBRX's scope...

Total investment: one null-modem cable. Especially, no need for a second 
motherboard, a second flash ROM or even a flash socket. And with USB 2.0 
debug cables being $95 a piece (at least USB 3.0 should be better in 
that aspect), even if coreboot decides on an EHCI/xHCI USB debug only 
route for its panic-room, UBRX would still have the economical edge for 
most boards.

> What if it does not work? You have no way forward.

If it does not work, then, and only then, you unsolder the chip, invest 
in an external programmer (or second mobo), and add a socket... which is 
what coreboot development, for the boards we are talking about, 
currently requires.

But at least, you have been given a fair chance to avoid having to do 
any of that...

Regards,

/Pete





More information about the coreboot mailing list