Yesterday I worked on the support for the serial GRUB console.
For some target machines at home I needed it again and I try
to collect experience in this stuff.
For the use here at home, I reprogrammed a solution using
a macro to decide in compile time the use of serial or pc
console. By this I realised, that there is code for serial
support included in the etherboot package. I reused this and
rewrited this in C to have the possibility to have the possibility
to do runtime configuration (port, baud rate, etc) for the
final implementation in GRUB (not per compile macro). The
serial driver code works.
I aslo began with a test implementation of the configurable
version of the console in GRUB including the possibility of
autodetection (if configured), from which console the first input
occurs.
Some experience:
On using *not* a dump termial, but a terminal program
which is able to handle cursor sets and courser queries,
etc (like a terminal program running in xterm), then there
is a good possibility to use the GRUB as is, inclusive the
menus, etc.
Routines to be console dependent:
putchar ()
getxy ()
gotoxy ()
getkey ()
checkkey ()
cls ()
set_line ()
print_frame ()
The 'set_attr' is not console-dependent, as set_line and
print_frame d not call set_attr () in my implementation.
Print_frame draws the frame with '+' and '-', '|' and
does not fill up the whole area with a color (By the way,
this was the task which takes that long time, because
every gotoxy () result in about 8 Byte transfer and this
for 73 * 14 positions !).
The set_line draws a '>' on x=2 and a '<' on x=74. So the
user can use the menu as is, but the highlighted line is
not inverted but marked (and quite fast and convinient
to use).
The only thing, I have not tried yet, was the implementation of
the console configuration itself.
Another topic is the use of the terminal type. In the company we
often use the terminal program inside the 'emacs' editor. This
editor does the line editing local and sends the result string to
the GRUB (command line mode). This does not work with my idea
of implementation. There is no possibility to use the menu nor
the command-interpreter, as it queries the length of the line
typed in by querying the cursor position. This is very difficult
in emacs to handle.
A dump serial support for the command line interpreter is a possible
solution, but only as another configurable option, not as the only
implementation. In this case, the command line interpreter should have
the possibility to have the menu included. For example:
After the welcome text of GRUB the display shows the
options in following form:
0 .. Linux XXXX
1 .. HURD yyyy
2 .. Windows XXX
And the command interpreter has additional builtins like
the command '0', '1', etc.....
Also the automatic is possible....
The other possibility is that the menu page, as implemented yet, is
used with a prompt line on the bottom getting commands like '0', '1',
'c' for the command interpreter and so on. All of this commands
have to be terminated by 'enter' (dump mode !).
But in the menu implementation I see the problem in drawing frames
without setting any cursor position. The only way is to 'produce'
the text lines for frame plus menu line before writing them line
for line on the dump terminal.
Those are some thoughts to the serial stuff topic.
With friendly regards
Christoph Plattner
