Hi,
as promised a short proposal on how to give the payload a chance to make use of the console(s) established by coreboot.
There's an ACK for my serial patch, but I'll wait for responses on this one, as the patch is a first step for this strategy.
The proposal is about a setup which would implement both console management (Torsten wrote about int0x10) and resource tables (eg. serial ports at 0x400) for crucial devices. 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...
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).
These record are specified and designed on an as-needed basis, so we don't fall in the trap of over-engineering. 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).
By only adding data to the record's end, they're implicitely backward compatible, as the growing size is taken care of with the size attribute that is standard to all records. Payloads can figure out which information exists based on size as well, by ignoring any field that exceeds the size.
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, ...). Later, this record can be extended to also carry a device number (if there are multiple serial ports) 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. Again, these additions will be made when there's an actual use case, thereby reducing the problem space right now.
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 ;-)
So... Comments? :-)
Regards, Patrick Georgi
On Thu, Jan 24, 2008 at 09:36:51PM +0100, Patrick Georgi wrote:
as promised a short proposal on how to give the payload a chance to make use of the console(s) established by coreboot.
..
So... Comments? :-)
I think this is the next logical step after the serial port patch. Thumbs up.
//Peter
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.
Torsten
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
-
Patrick Georgi -
Peter Stuge -
Torsten Duwe