[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