* Re: HCDP concerns
2004-09-01 10:25 HCDP concerns Xavier Bru
@ 2004-09-01 15:14 ` Bjorn Helgaas
2004-09-01 16:36 ` Tolentino, Matthew E
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Bjorn Helgaas @ 2004-09-01 15:14 UTC (permalink / raw)
To: linux-ia64
On Wednesday 01 September 2004 4:25 am, Xavier Bru wrote:
> I have some concerns with using kernel 2.6.8.1 (and 2.6.7) with our
> platform that has a new BIOS that provides HCDP.
Great! I'm thrilled that non-HP boxes are starting to provide the HCDP!
If there's still time to change, you might consider implementing the
PCDP, as it is significantly improved.
> 1) When kernel is configured without h/pcdp support ( CONFIG_EFI_PCDP is
> not set),
> the serial console are not initialized (efi.hcdp is not NULL).
I'm not quite sure what the problem is here. Were you hoping that even
without CONFIG_EFI_PCDP, we would notice that efi_uart_console_only()
is true, and just default to a serial console? That would be nice, but
I don't think the EFI console path contains enough information to directly
locate the UART device early in boot (In general, you need PCI enumeration
or ACPI namespace access to interpret device paths.)
> A simple fix could be:
> --- linux-2.6.8.1-ori/arch/ia64/kernel/setup.c 2004-08-14
> 12:54:50.000000000 +0200
> +++ linux-2.6.8.1/arch/ia64/kernel/setup.c 2004-08-31
> 11:54:02.000000000 +0200
> @@ -351,9 +351,9 @@
> #endif
> #ifdef CONFIG_EFI_PCDP
> efi_setup_pcdp_console(*cmdline_p);
> + if (!efi.hcdp)
> #endif
> #ifdef CONFIG_SERIAL_8250_CONSOLE
> - if (!efi.hcdp)
> setup_serial_legacy();
> #endif
The "assume ports are at 0x3f8 and 0x2f8" approach is dangerous
(because we'll poke at things that might not exist), and I don't
want to do any more of that than we have to.
My expectation is that CONFIG_EFI_PCDP would always be enabled;
I'm not aware of any downside to that, even if the platform doesn't
supply an HCDP or PCDP.
> 2) Our platform has 2 serial ports (let say port 0 at address 3f8, port
> 1 at address 2f8). Usually port 0 is seen as ttyS0 & port 1 as ttyS1.
> EFI console redirection is done on port S1 (2f8) & is described through
> HCDP(port 0 is not described).
> Using the h/pcdp support ( CONFIG_EFI_PCDP=1), we get some strange
> behaviours:
> . "console=ttyS0" boot parameter, as explained in menuconfig takes the
> HCDP table entry as console, but changes the ttyS* order:
> ttyS1 for port 0 (3f8) and ttyS0 for port 1 (2f8). Console is OK, but
> the ttyS0 on port 1 is confusing compared to kernels without hcdp support.
Yes, I agree this is broken. The ttySx device names should stay the
same, regardless of whether PCDP is present, or whether we look at it.
I posted patches to fix this a long time ago, but it involved too many
changes to the serial driver. I have some ideas about how to improve
this, so your interest will prod me to pursue them.
> . due to this behaviour, there is no more possibility to have the linux
> console redirection on the port 0 at boot time.
I don't understand what this is. Can you explain further?
> . My understanding was that h/pcdp support should provide some new
> consoleïi (or serial) option to have the console defined by efi used
> by linux as console, but that this should not change the ttyS order, and
> that we should still be able to use console="ttySx" at boot time to have
> the console on port "x".
If your BIOS supplies a PCDP and you set CONFIG_EFI_PCDP, you should
not have to use a "console=" option at all.
Even if you only have an HCDP, you don't have to use a "console="
option if ConOut contains only UARTs and you're using the default
baud rate. We'll just default to the first HCDP entry.
> . specifying no "console=" provides no console as the Conout variable is
> not exported by EFI at runtime. Should it be ?
I think it makes sense that ConOut should be available for runtime access,
but I can't point to a reference in the spec. All the platforms I've seen
do make it available for runtime access.
We currently look at ConOut only when we have an HCDP. If the BIOS
supplies a PCDP, there's no need to look at ConOut.
^ permalink raw reply [flat|nested] 5+ messages in thread* RE: HCDP concerns
2004-09-01 10:25 HCDP concerns Xavier Bru
2004-09-01 15:14 ` Bjorn Helgaas
@ 2004-09-01 16:36 ` Tolentino, Matthew E
2004-09-02 20:38 ` Bjorn Helgaas
2004-09-03 15:44 ` Xavier Bru
3 siblings, 0 replies; 5+ messages in thread
From: Tolentino, Matthew E @ 2004-09-01 16:36 UTC (permalink / raw)
To: linux-ia64
>> . specifying no "console=" provides no console as the Conout
>variable is
>> not exported by EFI at runtime. Should it be ?
>
>I think it makes sense that ConOut should be available for
>runtime access,
>but I can't point to a reference in the spec. All the
>platforms I've seen
>do make it available for runtime access.
Yep, ConOut is one of the globally defined variables that has
visibility in pre-boot space as well as during runtime. Check
out the attributes for ConOut in section 3.2 of the EFI spec.
matt
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HCDP concerns
2004-09-01 10:25 HCDP concerns Xavier Bru
2004-09-01 15:14 ` Bjorn Helgaas
2004-09-01 16:36 ` Tolentino, Matthew E
@ 2004-09-02 20:38 ` Bjorn Helgaas
2004-09-03 15:44 ` Xavier Bru
3 siblings, 0 replies; 5+ messages in thread
From: Bjorn Helgaas @ 2004-09-02 20:38 UTC (permalink / raw)
To: linux-ia64
On Thursday 02 September 2004 1:09 pm, Xavier Bru wrote:
> No, I just meant that without CONFIG_EFI_PCDP, we need to fall back
> to the standart initialization calling setup_serial_legacy(). Without
> the patch, the test on efi.hcdp returns non zero, and the
> setup_serial_legacy is not called.
The only benefit of setup_serial_legacy() is that that a serial
console can start working earlier. If you don't call it, the
serial console will still work after the normal serial driver
initializes.
> In our case, the EFI has access to 1 serial line, but there are
> 2 serials in the machine, and we used to use the linux console on
> one or the other serial. Only one line is described in the HCDP
> (the one of the EFI redirection).
This sounds broken. If you have an HCDP and you want to use an
early serial console, the HCDP should describe the port you want
to use.
If one of the ports is for use by EFI only, there's no point in
describing that port in the HCDP.
> I still have some problem of understanding if HCDP should provide
> information on all potential consoles, or should provide information
> on the consoles that EFI effectively uses.
> In the first case, we need still an information on which linux will
> use (the "console= ").
> In the second case, the "console=" could allow using others possible
> consoles to linux, as linux gave this flexibility before using the
> HCDP. But it is maybe sufficient to consider that linux consoles
> are same as efi consoles.
My goal is certainly to make Linux automatically use the same console
as EFI used. That is complicated a bit by the fact that EFI can use
multiple devices simultaneously, without any concept of a "primary"
device. Linux really wants a single device. (You can use multiple
"console=" arguments to get kernel output on several devices, but
eventually init is going to open a single device.)
One of the big problems with the HCDP was that it could describe
several UARTs, but there was no indication of which was the primary.
So Linux only looks at the first entry. This is one of the things
the PCDP is intended to fix.
Let me restate this to see if I understand what you need:
I think you have ports at 0x3f8 and 0x2f8. The desired naming
is 0x3f8 = ttyS0 and 0x2f8 = ttyS1.
With CONFIG_EFI_PCDP=n, you should get the desired naming, and
"console=ttyS0" or "console=ttyS1" should both work and go to
the correct ports (but the output won't start until the serial
driver initializes).
With CONFIG_EFI_PCDP=y, the first port in the HCDP becomes ttyS0.
(This is a bug and I'll try to fix it soon.) "console=ttyS0"
should work, the output should start early, and it should go to
the first device in the HCDP. "console=ttyS1" should also work,
but the output won't start until later, and it should go to the
other port (the one that is NOT described first in the HCDP).
I think what you want is a way to
(1) get early output, and
(2) specify the port where the output should go
That's perfectly reasonable, but neither scenario above gives
you that.
Rather than using the hack of assuming ports at 0x3f8 and 0x2f8,
I'd like to use this as an excuse to get the cleaner solution
done. I'm thinking something like a "console=serial,0x3f8"
argument to specify the device. Then we don't have to bind a
name to the device, so we get rid of the renaming problem.
And the HCDP/PCDP will become just a default source of the "0x3f8"
information if it's not on the command line.
Would that solve the problem?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: HCDP concerns
2004-09-01 10:25 HCDP concerns Xavier Bru
` (2 preceding siblings ...)
2004-09-02 20:38 ` Bjorn Helgaas
@ 2004-09-03 15:44 ` Xavier Bru
3 siblings, 0 replies; 5+ messages in thread
From: Xavier Bru @ 2004-09-03 15:44 UTC (permalink / raw)
To: linux-ia64
Bjorn Helgaas wrote:
>
>
>Let me restate this to see if I understand what you need:
>
>I think you have ports at 0x3f8 and 0x2f8. The desired naming
>is 0x3f8 = ttyS0 and 0x2f8 = ttyS1.
>
>With CONFIG_EFI_PCDP=n, you should get the desired naming, and
>"console=ttyS0" or "console=ttyS1" should both work and go to
>the correct ports (but the output won't start until the serial
>driver initializes).
>
>
Yes, but I also want to be able to have the boot traces when system does
not boot, and also have an
early kdb prompt.
>With CONFIG_EFI_PCDP=y, the first port in the HCDP becomes ttyS0.
>(This is a bug and I'll try to fix it soon.) "console=ttyS0"
>should work, the output should start early, and it should go to
>the first device in the HCDP. "console=ttyS1" should also work,
>but the output won't start until later, and it should go to the
>other port (the one that is NOT described first in the HCDP).
>
>
yes, but currently our 1rst (and only one) HCDP entry is 2f8, and
console=ttyS1 gives
also the same serial (2f8). This is why I was looking for the previous
ttyS0 semantic (3f8).
>I think what you want is a way to
> (1) get early output, and
> (2) specify the port where the output should go
>That's perfectly reasonable, but neither scenario above gives
>you that.
>
>Rather than using the hack of assuming ports at 0x3f8 and 0x2f8,
>I'd like to use this as an excuse to get the cleaner solution
>done. I'm thinking something like a "console=serial,0x3f8"
>argument to specify the device. Then we don't have to bind a
>name to the device, so we get rid of the renaming problem.
>And the HCDP/PCDP will become just a default source of the "0x3f8"
>information if it's not on the command line.
>
>Would that solve the problem?
>
>
Yes, it sounds good. In our case we keep our H/PCDP describing where is
directed the EFI console, that provides the default console for linux,
and we still have the possibility to override at boot time to go to
another console.
Thanks a lot for looking in deep to my problem.
Xavier
>-
>To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
>the body of a message to majordomo@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
Sincères salutations.
_____________________________________________________________________
Xavier BRU BULL ISD/R&D/INTEL office: FREC B1-422
tel : +33 (0)4 76 29 77 45 http://www-frec.bull.fr
fax : +33 (0)4 76 29 77 70 mailto:Xavier.Bru@bull.net
addr: BULL, 1 rue de Provence, BP 208, 38432 Echirolles Cedex, FRANCE
_____________________________________________________________________
^ permalink raw reply [flat|nested] 5+ messages in thread