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

Torsten Duwe duwe at lst.de
Fri Jan 25 12:42:12 CET 2008

On Thursday 24 January 2008, Patrick Georgi wrote:

> ... ports at 0x400) for crucial devices.

That's the term: "cruicial device", or "essential device".

> This way a payload could have a console on COM1 and get its data via PPP
> or ZMODEM on COM2. With only a console setup, it wouldn't know about
> COM2, with only a serial ports table, it wouldn't know where to find the
> user...

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.

> The proposal is layered in two types of records:
> The first type is an I/O-device record, like the serial port record I
> wrote. These can be extended with additional information as neccessary
> (and independent from other device types!), which might include IRQs or
> enumeration (in case we ever support more than one serial port in cb
> itself, for example).

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.

> These record are specified and designed on an as-needed basis, so we
> don't fall in the trap of over-engineering.

Maybe this already is over-engineered. I still see no valid case for serial.

> Multiple devices are specified with one record (of the same type) per
> device, with some identifier (int) to tell them apart (added when we
> first use this strategy).

You'll probably stick all identical devices into an array.

> By only adding data to the record's end, they're implicitely backward
> compatible,

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.

> Payloads can figure out which information exists based on size as well,
> by ignoring any field that exceeds the size.

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

> The second type is a console type. It consists of tag and size (like
> every record), and an integer (enum) type that specifies the device type
> (eg. serial=0, vga=1, ...).

So we all agree we need something like that. Presumed we have abvove records, 
the sub-type and index would be sufficient, right.

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

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

> I'd like to go on with that, and will do so in a few days. Please don't
> wait until I have a patch ready for all that stuff, before telling me
> it's crap ;-)

There were only misunderstandings about the goal to be achieved.

Still I do not see a console use case for this split scheme. The only reason 
I'm still into this is: faster booting. 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.

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.


More information about the coreboot mailing list