[coreboot] [RFC] consoles, serial ports and all that for v2 and v3 payloads

[Patrick Georgi]

Am Freitag, den 25.01.2008, 12:42 +0100 schrieb Torsten Duwe:
> IMHO this case is artificial. Zmodem can be muxed with the console, and with a 
> second port or PPP, you'll need basic multitasking or at least a working 
> interrupt subsystem.
It wasn't me with that requirement. Yet, the current implementation
isn't complete enough for this setup, but it is extensible to the point
that whoever implements that setup can extend the lbtable in a
compatible way to contain any data necessary.

> I'm not sure I understand you correctly. I would think about LB_TAG_DEVICE, 
> which, after the obligatory length, first has a type field , for e.g. 8250, 
> IDE, AHCI and so on. The problem is that beyond serial ports, things quickly 
> become hierarchical and thus complicate (bloat) the code.
That's why there's a record per device type. A serial port doesn't need
a vgatext memory area, and a trivial vgatext device doesn't need an
ioport.


> Maybe this already is over-engineered. I still see no valid case for serial.
Want a simple one? "PCBIOS provides such data" - it was you who argued
with "We're behind because we lack an int0x10-alike", or not?
I do the same with the 0x400 memory region of PCBIOS. (and I do have a
use case for it, too: the serial module of grub2)

> You'll probably stick all identical devices into an array.
That's not extensible: as soon as the size of an individual device
record changes, the array is pretty much unreadable (beyond the first
entry) to the payload.

> NO. record types and version info have proven valuable countless times in the 
> past, but maybe I'm over-engineering now. At least the record sub-type should 
> impose limits on the length.
sub type? We need no limits without sub types.

> Payloads should check for device records with known sub-type.
... with known record type.

> > Later, this record can be extended to also carry a device number (if
> > there are multiple serial ports) 
> 
> I thought this was your original motivation? So let's add an index right away, 
> to prevent backward-compatibility problems later.
No, I merely know that some people want this, but we're not in a position where
we can make use of it right now (there is no support for >1 serial or >1 vgatext).
There won't be compatibility problems, either - and more importantly: no
pre-planned junk that ends up unused because it doesn't fit the future's actual
requirements.

> > and maybe priorities or markers that 
> > consoles should be used in parallel (serial + vgatext).
> > Multiple consoles would again be done by adding one record for each
> > console.
> 
> Now you are definitely over-engineering. 
I'm merely stating that such extensions are possible. And Uwe mentioned
he'd like to see the possibility of multiple output devices.

I'm not over-engineering, I'm carving out the design space so that such
changes don't require incompatible changes when/if they're done.

> My proposal for alternate/auxiliary 
> consoles was meant as _replacement_ for a full device list. If CB logs to 
> VGA, but the payload only has a serial driver (or vice versa) things 
> shouldn't stay totally in the dark. With all serial ports listed, the payload 
> can arbitrarily pick one, if the CB console isn't on any of them and the log 
> device will change anyway.
That's another, different requirement (console fallback). If you need
it, implement it. It can be easily done on-top of what I'm proposing.

> Still I do not see a console use case for this split scheme. The only reason 
> I'm still into this is: faster booting.
Extensibility. Planning today what might be neccessary won't work

> Extending/splitting the info about 
> the console in use into a config and a device part allows extensions for 
> those devs that are slow to probe, IDE disks in particular.
See above: device part != config (in this case: console) part.

> If we agree that probing slow devices only once is a desireable goal, let's go 
> for it. Otherwise I would just change your serial port info into a console / 
> aux console info; the change is minimal.
And impossible to maintain in a forward compatible way.


Regards,
Patrick Georgi