Hi,
2010/4/3 Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com:
Brendan Trotter wrote:
1) If GRUB was using a serial port as a console device (e.g. on a
headless system) it'd be nice if the OS could continue using the same
serial port with the same configuration instead of resetting the
serial port, etc. A new tag (for 80x86, 8250/6550 compatible serial
ports) would include base I/O port, the serial line configuration
(e.g. 8 data bits, no stop bit, no parity), the baud rate (e.g. 9600),
The kernel can read data bits, stop bits, parity and divisor from
registers itself. I think it's more useful to supply a base frequency
since there are a lot of almost compatible cards which differ only in
base frequency.
You're right.
the IRQ number (if known/used by the boot loader) and the protocol
being used (ASCII, VT100, etc).
I think it's more useful to supply directly usable strings termcap
strings rather than an abstract ID
Here's an example termcap string:
ca|concept100|c100|concept|c104|concept100-4p|HDS Concept-100:\
:al=3*\E^R:am:bl=^G:cd=16*\E^C:ce=16\E^U:cl=2*^L:cm=\Ea%+ %+ :\
:co#80:.cr=9^M:db:dc=16\E^A:dl=3*\E^B:do=^J:ei=\E\200:eo:im=\E^P:in:\
:ip=16*:is=\EU\Ef\E7\E5\E8\El\ENH\EK\E\200\Eo\200\Eo\47\E:k1=\E5:\
:k2=\E6:k3=\E7:kb=^h:kd=\E:ke=\Ex:kh=\E?:kl=\E:kr=\E=:ks=\EX:\
:ku=\E;:le=^H:li#24:mb=\EC:me=\EN\200:mh=\EE:mi:mk=\EH:mp=\EI:\
:mr=\ED:nd=\E=:pb#9600:rp=0.2*\Er%.%+ :se=\Ed\Ee:sf=^J:so=\EE\ED:\
:.ta=8\t:te=\Ev\200\200\200\200\200\200\Ep\r\n:\
:ti=\EU\Ev 8p\Ep\r:ue=\Eg:ul:up=\E;:us=\EG:\
:vb=\Ek\200\200\200\200\200\200\200\200\200\200\200\200\200\200\EK:\
:ve=\Ew:vs=\EW:vt#8:xn:\
:bs:cr=^M:dC#9:dT#8:nl=^J:ta=^I:pt:
Making sense out of arbitrary termcap strings isn't easy - it would
add a large amount of mess to early OS initialisation code (which
typically doesn't even have C library functions to rely on). A single
integer saying which protocol is much easier to parse and use,
especially as only a few standard protocols (e.g. VT100) would need to
be supported.
If the boot loader doesn't know which
IRQ the serial port uses (e.g. it uses polling) then it sets the IRQ
number to 0x.
Where the serial port has a different interface
(e.g. if the serial port uses MMIO or if it's not 8250/6550
compatible) a different tag with different fields are used to
describe it.
I think it's more useful to have an I/O selector since yeeloong serial
interface is basically the same, just attached differently
An I/O selector (for 8250/6550 compatible) makes sense, and
different tags for not 8250/6550 compatible serial ports.
I think we need following fields:
1) I/O space selector (e.g. 0 = 32-bit MMIO, 1 = 64-bit MMIO, 2 = i386 I/O)
For 32-bit MMIO you could use 64-bit MMIO with the high bits of the
address in I/O space set to zero.
2) IRQ type selector (0 = None, 1 = standard platform interrupt)
3) 16-bit padding
4) address in I/O space (up to 64-bits)
5) Base frequency in Hz (32-bit)
6) IRQ (32-bit or even 64-bit since it's not excluded some platforms would
use 64-bit IRQ ids, though I'm not aware of such).
Looks good to me.
telnet+ethernet
It would need network tag first
Just an example of a different tag for a different type of console device.
2) The OS image format information should be expanded, so that the
OS can tell the boot loader if it supports 8250/6550 compatible
serial ports (and which protocols), and any other console devices (for
the same reason the OS image format already has flags, etc for
video).
Console flags tag is for this
Yes - the console flags tag needs to be expanded...
3) There should be an (optional?) critical error notification method
tag that tells the OS which method/s it can/should use to tell the
user it encountered a problem before it was able to setup it's console
output. For example, can/should the OS return to the boot loader, or
use the PC speaker to beep, or make a PS/2 keyboard's LEDs flash, or
something else.
Processing such a selector may prove as difficult as setting up a
console based on console tags. So I doubt its usefullness
I currently use PC speaker as my critical error notification
method - it's about 15 instructions that use I/O ports only and
doesn't require memory allocations or anything else. I doubt setting
keyboard LEDs (for a PS/2 keyboard) would be much larger or rely on
anything more than I/O ports.
In comparison, my video setup code is around 64 KiB of code that
starts with trying to get EDID information from the monitor, filtering
a list of video modes (from VGA and/or VBE), allocating several MiB of
RAM for video buffers and font data, scaling font data, etc. If
there's a problem setting up the memory management it's all useless
and I fall back to the critical error notification method so the
user knows the OS failed to initialise
