Hi Kevin --
Thanks for the patch. I haven't had a chance to study the code yet
(holiday weekend) but a suggestion:
How about using "xenconsole=" and "xencom2=" to differentiate
from the dom0 xenlinux command line parameters? Then there
won't be an ordering constraint (which as you point out could
lead to a common problem).
Dan
> Hi, Dan
> Attached is the patch to make serial port re-work on VTI on
> Tiger4 box, which actually has a 16550 port. Keir's clean simply removed
> some hardcode parameter used by IA64, so serial doesn't work then.
> Attached patch makes boot parameter 'really' working, and then removed
> unnecessary bad hardcode. Now user can use "com2=57600,8n1 console=com2"
> to steer xen.
>
> Signed-off-by Kevin Tian <Kevin.tian@xxxxxxxxx>
>
> The patch is made upon latest xeno-unstable tree, and please
> check in after you sync with it. It should also benefit ski or zx
> machine, though another serial object (uart_driver) still required to be
> defined as Keir suggested.
>
> BTW, a special note should be cared by normal users (maybe
> should go into README. :-)
> If user want to include multiple consoles into
> elili.conf, "console=com*" must be the last one. E.g.
> "console=ttyS0,57600 console=tty console=com2" is legible. That example
> is possible because nowadays Elilo only supports one cmdline, which
> means we have to merge boot parameters for xen and for guest kernel into
> one line. Then the problem occurs due to different style to define
> multiple consoles. Linux kernel support by "console= console= ...",
> while xen use "console=vga,com2" style. So the last one is the one that
> xen will really use, or else people may see no output from serial port
> though already add string there.
>
> Later this problem will be solved when we begin to patch elilo,
> for supporting multiple modules load. But people have to be aware of
> this caution. :)
>
> Thanks,
> Kevin
>
>>-----Original Message-----
>>From: xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx
>>[mailto:xen-ia64-devel-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of
>>Magenheimer, Dan (HP Labs Fort Collins)
>>Sent: Tuesday, May 31, 2005 2:25 AM
>>To: Greg Edwards; xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>Subject: [Xen-ia64-devel] FW: IA-64 serial driver
>>
>>FYI. I'll take a look at this tomorrow as xeno-unstable
>>will undoubtedly be broken for ia64.
>>
>>Greg, I hope this doesn't throw a wrench into your work.
>>(Hopefully it will make it easier.)
>>
>>> -----Original Message-----
>>> From: Keir Fraser [mailto:Keir.Fraser@xxxxxxxxxxxx]
>>> Sent: Saturday, May 28, 2005 3:19 PM
>>> To: Magenheimer, Dan (HP Labs Fort Collins)
>>> Cc: Keir Fraser; Arun Sharma
>>> Subject: IA-64 serial driver
>>>
>>> Dan, Arun,
>>>
>>> I've just checked in a big cleanup of the serial driver which has
>>> certainly broken IA-64 serial output in cases where you do not use a
>>> 16550 uart (e.g., your simulator package).
>>>
>>> I've separated out the guts of 16550 driver code from the generic
>>> 'serial framework'. Each architecture calls a set of initialisation
>>> functions for the specific uarts that it supports, before calling the
>>> generic serial_init_preirq() function.
>>>
>>> So far I have added ns16550_init() to arch/ia64, but you will need to
>>> add a new uart_driver type for each other type of 'serial device' you
>>> have. The driver can be *really* simple: just supporting putc, for
>>> example.
>>>
>>> To define a simple driver:
>>> static void hp_skiing_putc(struct serial_port *port, char c) { ... }
>>> static struct uart_driver hp_skiing = { .putc = hp_skiing_putc };
>>>
>>> Then, at the same point we do ns16550_init() in arch/ia64/xensetup.c:
>>> serial_register_uart(0, &hp_skiing, NULL);
>>>
>>> -- Keir
>>>
>>>
>>
>>_______________________________________________
>>Xen-ia64-devel mailing list
>>Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>>http://lists.xensource.com/xen-ia64-devel
>
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home