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

Andrew Goodbody andrew.goodbody at tadpole.com
Wed Jul 13 13:03:27 CEST 2011


Sorry but my replies are having problems getting to the list. 
Greylisting is not supported by the company mail system.

On 07/12/11 18:42, Pete Batard wrote:
> On 2011.07.12 07:15, Andrew Goodbody wrote:
>> Instead of attempting (and failing) to achieve universal support
>
> 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.

...

>> I would
>> rather see a framework that could easily be configured with the
>> appropriate SIO support and allow for board specific configuration if
>> necessary. This should remove a lot of the complexity that gives very
>> little advantage in trying for universal support. coreboot is built as
>> hardware specific and I see no reason why the panic room support should
>> not be the same.
>
> I guess we have different definition of a panic-room then.
>  From my dealings with Realtek SoCs, the way I see a panic-room is
> something that is as hardware agnostic as possible. In the ideal case,
> the panic-room is implemented ondie directly on a CPU that has an UART
> unit, and therefore with no possible knowledge of the hardware
> surrounding it. Such knowledge is to be provided by the user. This is
> what the RTD1283 provides for instance (8KB bootblock, with console and
> Y-modem upload in CPU ROM), and it is extremely powerful. The panic-room
> is then intended as a means for users to perform hardware initialization
> such as RAM or Flash access, as well as any other task they might
> fathom. Hence, this is the implementation of a panic-room I have been
> trying to follow, as it is the one that is most versatile and helpful to
> users IMO.

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. You would choose the SIO/UART support, possibly 
specifying IO to use. The board specific configuration, if needed, was 
only for setting GPIOs etc in order to get the RS232 port working or 
configuring programmable clocks. That's all. 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. 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.
I was not suggesting building in knowledge of anything more than how to 
reach and configure the UART in order to establish a console, so we both 
agree that more complex operations would require interaction with the user.

>
>> Choosing the SIO support to configure for the panic
>> room can be easily done from the output of superiotool.
>
> Provided superiotool knows about the chip, which may not be the case
> yet. If Nuvoton introduces a new chip tomorrow, for which we haven't
> seen a datasheet yet, I'm pretty sure UBRX will work just fine.

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.

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

>> Additionally if it was done in such a way that the serial transport
>> could be easily replaced by USB debug instead then we could really have
>> something that would be useful for new boards.
>
> Well, depending how much space EHCI/xHCI USB support would take, I don't
> see why UBRX wouldn't be able to provide both. But right now,
> considering that there is still an awful lot of modern yet legacy based
> systems out there that could benefit from coreboot support,
> concentrating on native UART doesn't seem like a bad idea.

All I was asking was that the design allowed for an alternate transport 
with minimum disruption. I did not suggest abandoning the work for UARTs.

Cheers,
Andrew

> Regards,
>
> /Pete
>






More information about the coreboot mailing list