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

Pete Batard pete at akeo.ie
Wed Jul 13 23:25:32 CEST 2011


On 2011.07.13 12:03, Andrew Goodbody wrote:
>> I'll start with the aside, that if "failing" means instantly supporting
>> more than 90% of Intel based motherboards produced in the last 10 years
>
> Yes, universal means everything. If you do not support everything then
> it is not universal. The use of universal sets false expectations.

In that case, "unlimited broadband" means truly unlimited, and fair 
expectations are not supposed to be applied to the claim.
I guess if you would prefer an asterisk after the Universal in UBRX, 
with a "Terms and Conditions apply", this can be arranged... ;)

This being said, the 90% with regards to Intel chipsets applies to the 
*PoC* (guesstimate obviously, but I think I'm probably pessimistic when 
only those weird ITE init and non PnP Super I/Os are expected to fail 
detection, which I doubt many of the ICH motherboard from the last 10 
years would have). The final version could be a lot closer to the 100% 
mark, especially if we attempt detect both native UART and USB 3.0 
debug, as legacy free hardware, which I suppose is expected to have 
PCI-E, would just need an xHCI PCI-E card we can detect to get going.

I also don't think the idea of dropping support for non PnP SIO chips 
detracts from the claim of Universality(*) that much. A comparison would 
be to claim that Windows software released in 2011 does not actually 
qualify as being "Windows compatible" or put Windows on the box if it 
doesn't support Windows 98 (And, just like Windows software comes with a 
"minimum system requirements", our Readme comes with about the same 
thing in the form of current UBRX limitations). My understanding is that 
most manufacturers would have switched to PnP SIOs around '98 as well, 
so the Windows 98 comparison seems appropriate.

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.

At least I am hoping that it is OK to come to this list, with something 
that is still incomplete, to see if there is interest, and not being 
requested to come back with a solution that is feature complete and 
spotless.

> Yes we see different priorities for a panic room, but I think you
> misunderstood how much knowledge of the platform I was suggesting needed
> to be configured.

OK, that's probably fair.

> To me a panic room should
> be as simple and bullet proof as possible and if that means
> pre-configuring the build then so be it.

The problem I have with pre-configured is you need to have prior 
knowledge. So in effect, your panic room would be restricted to only 
platforms that coreboot already supports, which, to mirror your 
"unnecessary complication" below, I would see as an "unnecessary 
limitation".

> Being 'hardware agnostic' helps
> in putting it on a new platform, assuming that platform conforms to the
> restrictions, but it does not help in actual operation of the panic
> room. So to me that would be an unnecessary complication.
> Your example of a panic room ondie with a UART is not hardware agnostic
> at all, you have pre-knowledge of the critical elements for establishing
> a console.

Call me confrontational, but I am going to dispute the "not hardware 
agnostic at all".

If AMD and Intel agreed tomorrow to provide an UART ondie, accessed in 
the same fashion, on all of their future x86 chips, should we consider 
that this knowledge should be out of bounds?
Or how about FPUs? Older x86 CPUs did not have an FPU unit ondie. Should 
we then consider that a program that just uses the FPU, since it has 
been for about the past 20 years, and no external hardware, can not be 
considered hardware agnostic and should have performed FPU detection?

To me there is such thing as internal hardware, which is 100% fair game 
to use as soon as it is introduced, as, in the worst case scenario, it 
can easily be detected from the public CPU specs, and external hardware, 
which, and this is the critical point, may include elements that have 
not even been designed yet. So I would say that a panic room ondie with 
an UART, if all CPUs from the same line have this feature, is hardware 
agnostic. But then again, whether hardware agnosticism applies to a CPU 
that is irrelevant to coreboot doesn't bring much to the discussion.

> OK, well how about the SIO support from UBRX being one of the SIO
> modules that can be chosen. My main concern is allowing a simple method
> of getting panic room support to work on boards that do not meet your
> restrictions.

That's one of my concerns too.

As I indicated above, I am not planning to spend much time on getting 
non PnP SIOs, or PnP SIOs that require some weird init to be supported 
by UBRX.

This being said, UBRX does support the VMWare virtual SIO, which is not 
PnP, and I think your idea about trying to be modular in UBRX is a good 
one. I can probably create a separate module for the VMWare non PnP SIO, 
which could be used as a template for other SIOs that people want to see 
supported, and that may not be detected in UBRX main. Such modules could 
then be selected and included conditionally at buildtime.
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.

With this, unconditional universality may actually apply to UBRX after 
all (though some may claim that if everything isn't supported at the 
same time, it's still not universal)... ;)

>> Superiotool, not so much... Also picking a coreboot BIOS from one
>> machine and soldering it into another, with the expectation that even if
>> the motherboards have nothing in common but the flash they use,
>> panic-room access will be available, can have its advantages, be it only
>> for ghetto-style budget-constrained tinkerers.
>
> Shudders! Do we really want to encourage that?

I most certainly see some merit in that for the following reasons: One 
is the consideration that people who may have a lot of time on their end 
may not be the ones with the highest means of income, and coreboot could 
probably use people with a time on their hand to support new 
motherboards. The second reason is that there are an awful lot of 
proprietary systems out there with soldered (non SPI) flash chips (Dell, 
Compaq, etc...), that could really benefit from coreboot. Past their 
prime, these systems can be obtained fairly cheaply, from corporate 
sales, etc., and therefore are a good target for coreboot development.
However, when the first step of coreboot development is to install a 
BIOS socket as well as get an external flasher, this is likely to put 
potential contributors off. On the other hand, while there is obviously 
a risk that the U(*)BRX panic-room may not work, there's a good chance 
that it will and thus provide developers with both the possibility to 
explore their hardware and test a coreboot development payload.

So I guess the question is: do we want a panic-room that only applies to 
systems that coreboot already support? Or do we want it to also be used 
as a tool for the adding of new systems.
If only the former, then U(*)BRX is likely an overkill. But even a 
panic-room seems a bit of an overkill to me, as all you probably want 
from it is flash recovery...

Regards,

/Pete


(*) Terms and Conditions apply




More information about the coreboot mailing list