From: Bjorn Helgaas <bjorn.helgaas@hp.com>
To: linux-ia64@vger.kernel.org
Subject: Re: HCDP concerns
Date: Thu, 02 Sep 2004 20:38:54 +0000 [thread overview]
Message-ID: <200409021438.54810.bjorn.helgaas@hp.com> (raw)
In-Reply-To: <4135A3A7.9000706@bull.net>
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?
next prev parent reply other threads:[~2004-09-02 20:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
2004-09-03 15:44 ` Xavier Bru
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200409021438.54810.bjorn.helgaas@hp.com \
--to=bjorn.helgaas@hp.com \
--cc=linux-ia64@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox