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

Pete Batard pete at akeo.ie
Tue Jul 12 19:42:10 CEST 2011


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 
(if you have an ICH# or a 440BX controller, you should be good, as you 
only have one clock for Super I/O, that isn't programmable), as well as 
a large chunk of AMD motherboards (once the SB clock programming issue 
is solved, which I'm pretty sure can be done), then I wonder how the 
rate of support that coreboot has with regards to motherboards produced 
in the last few years would qualify...
Please do not misconstrue this as criticism of coreboot, as it isn't. 
It's just that, if I were to start coreboot development, I sure wouldn't 
mind if someone else had already sorted some kind of bare metal console 
access for my platform, even if that applied "only" to 3/4th of all x86 
motherboards produced in the last 10 years...

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

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

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

Regards,

/Pete




More information about the coreboot mailing list