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

[Andrew Goodbody]

On 07/13/11 22:25, Pete Batard wrote:
> 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.

But that is the point. Your support is not universal and unlimited 
broadband is not unlimited and should not be described as such. I object 
to the use of an absolute description to refer to something that is not 
absolute.

> I guess if you would prefer an asterisk after the Universal in UBRX,
> with a "Terms and Conditions apply", this can be arranged... ;)

I would prefer it not be described as universal at all.

> 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 will not argue over made up statistics.

>...

Nor will I argue a strawman.

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

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

!!! Of course you are welcome to come to this list with incomplete 
ideas. I was trying to work with you to improve it. I object to your 
claim of universal support, not your aim of supporting as much as 
possible. I do not want your description to set up false expectations. I 
see no request in that to go away until your support is complete and 
spotless. That comes only from your desire to make your idea live up to 
the description you chose.

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

Not at all. The pre-knowledge of the hardware required is just how to 
get to the UART. It is very, very far from requiring existing coreboot 
support. You do not need to know how to set up memory, you do not need 
to know how the interrupts are configured, you do not need to know what 
PCI/PCIe devices there are, etc. etc. which are all things needed for 
coreboot. So no you are not limited to platforms that coreboot already 
supports.

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

You are confrontational and you are arguing points that I do not hold 
and this I think is due to a misunderstanding of 'hardware agnostic'.

All I was saying is that use of internal hardware implies pre-knowledge 
of that hardware and that is included into the build. My suggestion of 
being able to configure the use of a different SIO or allowing easy 
insertion of motherboard specific GPIO settings is on the same level of 
pre-knowledge as is required to use internal hardware. I never suggested 
that any knowledge was out of bounds. 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, 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.

I did not ask for support for these to be implemented by you, merely a 
framework that would allow them to be supported without having to make 
in depth changes to the core support.

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

I think we may even both be able to agree that this is a good idea.

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

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

Well your plan requires two motherboards plus a development system. The 
first with an existing coreboot image with working panic room. The 
second using a compatible BIOS flash chip. You start by removing the 
BIOS chip, containing the coreboot image with panic room, from a working 
board, rendering it useless. Then you swap in that BIOS flash chip onto 
the second board and hope that the panic room still works and will give 
you a console accessible from your development system. What if it does 
not work? You have no way forward.

However if you allow the soldering of a socket (the same soldering skill 
needed as swapping a chip) you can do the following.
One motherboard can act as your development system and as your flashing 
tool by doing a hot flash for the other. You do not need an existing 
coreboot support for either and you are not left with a useless 
motherboard. The cost of two sockets should be a lot less than another 
motherboard and no external flasher is needed.

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

You guess wrong. The question is how much complexity do we want for 
little or no discernible gain? Of course using it for new systems would 
be a good thing and my suggestions in no way prevent that.

Andrew