Hello list,
the system from which I'm talking about is a Menlow XL (Intel Atom Z510PT and SCH US15WPT) platform with 512 megabyte RAM.
There is one PCIe-switch (PI7C9X20404SL) attached to each of both PCIe-ports of the US15WPT (see attached 2.6.30-lspci.txt for details).
With both switches enabled, all Kernel versions (vanilla) above 2.6.30 refuse to boot. With only one switch active
(the other one with no supply voltage ), all Kernel versions boot properly. It does not matter which switch is removed, it
is sufficient just to remove one of the two.
There is an UART (FPGA IP Core) in that system located at address 1900h using interrupt 3. In order to get Kernel messages at boot time,
I changed file arch/x86/include/asm/serial.h as follows:
- { 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, /* ttyS0 */ \
+ { 0, BASE_BAUD, 0x1900, 3, STD_COM_FLAGS }, /* ttyS0 */ \
that is the only change I made to the kernel sources.
The build process has been the same for all kernel versions (Host: Ubuntu 10.04 LTS gcc version 4.4.3):
$ sudo make i386_defconfig
$ sudo make menuconfig (enabled PCI debugging)
$ sudo make-kpkg clean
$ sudo make-kpkg --initrd kernel_image --revision KernelRebuild.01
The target system is a voyage 0.6.5 (Debian Lenny based). On the target I did the following in order to install the new kernels:
# dpkg -i linux-image-2.6.38.6_KernelRebuild.01_i386.deb
# dpkg -i linux-image-2.6.30_KernelRebuild.01_i386.deb
# update-initramfs -c -k 2.6.38.6
# update-initramfs -c -k 2.6.30
# update-grub
To the grub command line I added the following:
debug console=tty0 console=ttyS0,115200
I attached the kernel boot messages from Kernel versions 2.6.30 (2.6.30.log) and 2.6.38.6 (2.6.38.6.log) both were dumped from
the serial line.
While looking at the kernel messages on the attached monitor, the kernel output seems to stop always on different positions.
Looking at the serial line, the kernel output always stops after the following message:
pci 0000:00:1c.0: enabling device (0006 -> 0007)
The monitor shows a few lines more than the serial line, before the output stops as well.
Any hints what I'm doing wrong?
Thank you very much in advance.
With best regards
Michael Hornung
------------------------------------------------------------
Michael Hornung
Hardware
Mobile Telematic and Fare Collection Systems
E-Mail [email protected]
INIT Innovative Informatikanwendungen
in Transport-, Verkehrs- und Leitsystemen GmbH
K?ppelestrasse 4-6
76131 Karlsruhe
Germany
http://www.init-ka.de
Gesch?ftsf?hrer:
Dr.-Ing. Gottfried Greschner, Dipl.-Inform. Achim Becker, Dipl.-Ing. (FH) Wolfgang Degen, Dipl.-Kfm. Dr. J?rgen Greschner
Amtsgericht Mannheim HRB 103679 . Internationale Registrierungen: 988055689MVA (Norwegen), FC027220 (UK)
Vertraulichkeitshinweis:
Der Inhalt dieser E-Mail ist vertraulich zu behandeln. Das Schreiben ist nur zur Kenntnis des oben genannten Empf?ngers bestimmt. Wenn Sie nicht der richtige Adressat sind, informieren Sie bitte sofort den Absender und vernichten diese Nachricht. Unerlaubte Kopien sowie unbefugte Weitergabe sind nicht gestattet.
Bitte beachten Sie, dass durch diese E-Mail keine rechtsverbindlichen Willenserkl?rungen abgegeben werden.
Privacy Notice:
Content of this e-mail must be treated as strictly confidential. This writing is intended only for the knowledge of the above-mentioned addressee. If you are not the correct recipient please inform the sender immediately and permanently erase this message. Illegal copies as well as unauthorized passing is not permitted and strictly forbidden.
Please note that by sending this mail INIT does not make any commitment and is under no obligation.
[added linux-pci]
On Tue, May 17, 2011 at 1:01 AM, Hornung, Michael <[email protected]> wrote:
> the system from which I'm talking about is a Menlow XL (Intel Atom Z510PT and SCH US15WPT) platform with 512 megabyte RAM.
> There is one PCIe-switch (PI7C9X20404SL) attached to each of both PCIe-ports of the US15WPT (see attached 2.6.30-lspci.txt for details).
I think you forgot to attach the lspci.
> With both switches enabled, all Kernel versions (vanilla) above 2.6.30 refuse to boot. With only one switch active
> (the other one with no supply voltage ), all Kernel versions boot properly. It does not matter which switch is removed, it
> is sufficient just to remove one of the two.
>
> There is an UART (FPGA IP Core) in that system located at address 1900h using interrupt 3. In order to get Kernel messages at boot time,
> I changed file arch/x86/include/asm/serial.h as follows:
>
> - ? ? ? ?{ 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, ? ? ?/* ttyS0 */ ? ? \
> + ? ? ? ?{ 0, BASE_BAUD, 0x1900, 3, STD_COM_FLAGS }, ? ? /* ttyS0 */ ? ?\
>
> that is the only change I made to the kernel sources.
Is this UART connected via PCI? I don't think so, because I don't see
any I/O BARs that include 0x1900. However, I don't see any ACPI
devices that mention that address either (none of the "pnp 00:xx"
devices include that range).
Since there's no PCI-enumerable device that uses 0x1900, and ACPI
doesn't mention it, we think it's available, and I notice the 2.6.38.6
kernel does assign the [io 0x1000-0x1fff] range to the 00:1c.1 bridge
I/O window. Now we probably have two devices claiming accesses to
0x1900 (the bridge and the UART). I don't know whether this is
causing the problem, but it can't be good.
I think the best way to fix this would be to change your BIOS to
include a PNP0501 ACPI device with the appropriate _CRS to tell us
what resources it uses (then you could drop your serial.h change,
too).
If changing the BIOS is impossible, you could at least find out if
this is the problem by adding a quirk in drivers/pnp/quirks.c to
reserve the 0x1900 region by adding an I/O resource to the PNP0c02
device.
Bjorn
Hello Bjorn,
>[added linux-pci]
>> On Tue, May 17, 2011 at 1:01 AM, Hornung, Michael <[email protected]> wrote:
>> the system from which I'm talking about is a Menlow XL (Intel Atom Z510PT and SCH US15WPT) platform with 512 megabyte RAM.
>> There is one PCIe-switch (PI7C9X20404SL) attached to each of both PCIe-ports of the US15WPT (see attached 2.6.30-lspci.txt for details).
>I think you forgot to attach the lspci.
Sorry for that, I attached it to this mail.
>> With both switches enabled, all Kernel versions (vanilla) above 2.6.30 refuse to boot. With only one switch active
>> (the other one with no supply voltage ), all Kernel versions boot properly. It does not matter which switch is removed, it
>> is sufficient just to remove one of the two.
>>
>> There is an UART (FPGA IP Core) in that system located at address 1900h using interrupt 3. In order to get Kernel messages at boot time,
>> I changed file arch/x86/include/asm/serial.h as follows:
>>
>> - ? ? ? ?{ 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, ? ? ?/* ttyS0 */ ? ? \
>> + ? ? ? ?{ 0, BASE_BAUD, 0x1900, 3, STD_COM_FLAGS }, ? ? /* ttyS0 */ ? ?\
>>
>> that is the only change I made to the kernel sources.
> Is this UART connected via PCI? I don't think so, because I don't see
> any I/O BARs that include 0x1900.
The UART is connected via LPC bus.
> However, I don't see any ACPI
> devices that mention that address either (none of the "pnp 00:xx"
> devices include that range).
> Since there's no PCI-enumerable device that uses 0x1900, and ACPI
> doesn't mention it, we think it's available, and I notice the 2.6.38.6
> kernel does assign the [io 0x1000-0x1fff] range to the 00:1c.1 bridge
> I/O window. Now we probably have two devices claiming accesses to
> 0x1900 (the bridge and the UART). I don't know whether this is
> causing the problem, but it can't be good.
> I think the best way to fix this would be to change your BIOS to
> include a PNP0501 ACPI device with the appropriate _CRS to tell us
> what resources it uses (then you could drop your serial.h change,
> too).
I do have the BIOS sources so I'll try do to it that way, thank you very
much!
> If changing the BIOS is impossible, you could at least find out if
> this is the problem by adding a quirk in drivers/pnp/quirks.c to
> reserve the 0x1900 region by adding an I/O resource to the PNP0c02
> device.
> Bjorn
Thank you very much again for your help!
With best regards
Michael Hornung
------------------------------------------------------------
Michael Hornung
Hardware
Mobile Telematic and Fare Collection Systems
Phone +49-(0)721-6100-305
Fax +49-(0)721-6100-399
E-Mail [email protected]
INIT Innovative Informatikanwendungen
in Transport-, Verkehrs- und Leitsystemen GmbH
K?ppelestrasse 4-6
76131 Karlsruhe
Germany
http://www.init-ka.de
Gesch?ftsf?hrer:
Dr.-Ing. Gottfried Greschner, Dipl.-Inform. Achim Becker, Dipl.-Ing. (FH) Wolfgang Degen, Dipl.-Kfm. Dr. J?rgen Greschner
Amtsgericht Mannheim HRB 103679 . Internationale Registrierungen: 988055689MVA (Norwegen), FC027220 (UK)
Vertraulichkeitshinweis:
Der Inhalt dieser E-Mail ist vertraulich zu behandeln. Das Schreiben ist nur zur Kenntnis des oben genannten Empf?ngers bestimmt. Wenn Sie nicht der richtige Adressat sind, informieren Sie bitte sofort den Absender und vernichten diese Nachricht. Unerlaubte Kopien sowie unbefugte Weitergabe sind nicht gestattet.
Bitte beachten Sie, dass durch diese E-Mail keine rechtsverbindlichen Willenserkl?rungen abgegeben werden.
Privacy Notice:
Content of this e-mail must be treated as strictly confidential. This writing is intended only for the knowledge of the above-mentioned addressee. If you are not the correct recipient please inform the sender immediately and permanently erase this message. Illegal copies as well as unauthorized passing is not permitted and strictly forbidden.
Please note that by sending this mail INIT does not make any commitment and is under no obligation.
On Wed, May 18, 2011 at 1:44 AM, Hornung, Michael <[email protected]> wrote:
>>> There is an UART (FPGA IP Core) in that system located at address 1900h using interrupt 3. In order to get Kernel messages at boot time,
>>> I changed file arch/x86/include/asm/serial.h as follows:
>>>
>>> - ? ? ? ?{ 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, ? ? ?/* ttyS0 */ ? ? \
>>> + ? ? ? ?{ 0, BASE_BAUD, 0x1900, 3, STD_COM_FLAGS }, ? ? /* ttyS0 */ ? ?\
>>>
>>> that is the only change I made to the kernel sources.
>
>> Is this UART connected via PCI? ?I don't think so, because I don't see
>> any I/O BARs that include 0x1900.
>
> The UART is connected via LPC bus.
Makes sense; that's a common way for attaching UARTs, and they are
normally described via ACPI. When you do that, I think it will show
up as ttyS4 (be sure you build with CONFIG_SERIAL_8250_PNP=y), so
you'll have to use "console=ttyS4" when you boot. ttyS0-ttyS3 are
taken by the hard-coded ports in serial.h, even though they may not
exist on your platform.
Bjorn
On Wed, May 18, 2011 at 7:56 AM, Bjorn Helgaas <[email protected]> wrote:
> On Wed, May 18, 2011 at 1:44 AM, Hornung, Michael <[email protected]> wrote:
>>>> There is an UART (FPGA IP Core) in that system located at address 1900h using interrupt 3. In order to get Kernel messages at boot time,
>>>> I changed file arch/x86/include/asm/serial.h as follows:
>>>>
>>>> - ? ? ? ?{ 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, ? ? ?/* ttyS0 */ ? ? \
>>>> + ? ? ? ?{ 0, BASE_BAUD, 0x1900, 3, STD_COM_FLAGS }, ? ? /* ttyS0 */ ? ?\
>>>>
>>>> that is the only change I made to the kernel sources.
>>
>>> Is this UART connected via PCI? ?I don't think so, because I don't see
>>> any I/O BARs that include 0x1900.
>>
>> The UART is connected via LPC bus.
>
> Makes sense; that's a common way for attaching UARTs, and they are
> normally described via ACPI. ?When you do that, I think it will show
> up as ttyS4 (be sure you build with CONFIG_SERIAL_8250_PNP=y), so
> you'll have to use "console=ttyS4" when you boot. ?ttyS0-ttyS3 are
> taken by the hard-coded ports in serial.h, even though they may not
> exist on your platform.
Hi Michael,
Any update on this problem? Did it make any difference to put the
UART in the ACPI namespace?
Bjorn
>>>>> There is an UART (FPGA IP Core) in that system located at address 1900h using interrupt 3. In order to get Kernel messages at boot time,
>>>>> I changed file arch/x86/include/asm/serial.h as follows:
>>>>>
>>>>> - ? ? ? ?{ 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, ? ? ?/* ttyS0 */ ? ? \
>>>>> + ? ? ? ?{ 0, BASE_BAUD, 0x1900, 3, STD_COM_FLAGS }, ? ? /* ttyS0 */ ? ?\
>>>>>
>>>>> that is the only change I made to the kernel sources.
>>>
>>>> Is this UART connected via PCI? ?I don't think so, because I don't see
>>>> any I/O BARs that include 0x1900.
>>>
>>> The UART is connected via LPC bus.
>>
>> Makes sense; that's a common way for attaching UARTs, and they are
>> normally described via ACPI. ?When you do that, I think it will show
>> up as ttyS4 (be sure you build with CONFIG_SERIAL_8250_PNP=y), so
>> you'll have to use "console=ttyS4" when you boot. ?ttyS0-ttyS3 are
>> taken by the hard-coded ports in serial.h, even though they may not
>> exist on your platform.
>
> Hi Michael,
>
> Any update on this problem? Did it make any difference to put the
> UART in the ACPI namespace?
>
> Bjorn
Hi Bjorn,
thank you very much for your support. Unfortunately I'm not able to get it to work. I changed
the BIOS and added PNP0500 device nodes for all 21 UARTS (all located in the FPGA, all connected
via LPC, all located at addresses between 0x1900 and 0x19a7h and all using IRQ3), but the kernel does not care about
that nodes. CONFIG_SERIAL_8250_PNP is set to "y" (see attached config.txt) but the kernel output does not show
up any differences (2.6.38.6.log).
In my defense I have to say that I'm a hardware guy and really new to BIOS and Linux adaption. I'm trying to get better
at the moment.
Once again, thanks a lot for your support.
With best regards
Michael Hornung
------------------------------------------------------------
Michael Hornung
Hardware
Mobile Telematic and Fare Collection Systems
Phone +49-(0)721-6100-305
Fax +49-(0)721-6100-399
E-Mail [email protected]
INIT Innovative Informatikanwendungen
in Transport-, Verkehrs- und Leitsystemen GmbH
K?ppelestrasse 4-6
76131 Karlsruhe
Germany
http://www.init-ka.de
Gesch?ftsf?hrer:
Dr.-Ing. Gottfried Greschner, Dipl.-Inform. Achim Becker, Dipl.-Ing. (FH) Wolfgang Degen, Dipl.-Kfm. Dr. J?rgen Greschner
Amtsgericht Mannheim HRB 103679 . Internationale Registrierungen: 988055689MVA (Norwegen), FC027220 (UK)
Vertraulichkeitshinweis:
Der Inhalt dieser E-Mail ist vertraulich zu behandeln. Das Schreiben ist nur zur Kenntnis des oben genannten Empf?ngers bestimmt. Wenn Sie nicht der richtige Adressat sind, informieren Sie bitte sofort den Absender und vernichten diese Nachricht. Unerlaubte Kopien sowie unbefugte Weitergabe sind nicht gestattet.
Bitte beachten Sie, dass durch diese E-Mail keine rechtsverbindlichen Willenserkl?rungen abgegeben werden.
Privacy Notice:
Content of this e-mail must be treated as strictly confidential. This writing is intended only for the knowledge of the above-mentioned addressee. If you are not the correct recipient please inform the sender immediately and permanently erase this message. Illegal copies as well as unauthorized passing is not permitted and strictly forbidden.
Please note that by sending this mail INIT does not make any commitment and is under no obligation.
On Wed, May 25, 2011 at 6:28 AM, Hornung, Michael <[email protected]> wrote:
>>>>>> There is an UART (FPGA IP Core) in that system located at address 1900h using interrupt 3. In order to get Kernel messages at boot time,
>>>>>> I changed file arch/x86/include/asm/serial.h as follows:
>>>>>>
>>>>>> - ? ? ? ?{ 0, BASE_BAUD, 0x3F8, 4, STD_COM_FLAGS }, ? ? ?/* ttyS0 */ ? ? \
>>>>>> + ? ? ? ?{ 0, BASE_BAUD, 0x1900, 3, STD_COM_FLAGS }, ? ? /* ttyS0 */ ? ?\
>>>>>>
>>>>>> that is the only change I made to the kernel sources.
>>>>
>>>>> Is this UART connected via PCI? ?I don't think so, because I don't see
>>>>> any I/O BARs that include 0x1900.
>>>>
>>>> The UART is connected via LPC bus.
>>>
>>> Makes sense; that's a common way for attaching UARTs, and they are
>>> normally described via ACPI. ?When you do that, I think it will show
>>> up as ttyS4 (be sure you build with CONFIG_SERIAL_8250_PNP=y), so
>>> you'll have to use "console=ttyS4" when you boot. ?ttyS0-ttyS3 are
>>> taken by the hard-coded ports in serial.h, even though they may not
>>> exist on your platform.
>>
>> Hi Michael,
>>
>> Any update on this problem? ?Did it make any difference to put the
>> UART in the ACPI namespace?
>
> thank you very much for your support. Unfortunately I'm not able to get it to work. I changed
> the BIOS and added PNP0500 device nodes for all 21 UARTS (all located in the FPGA, all connected
> via LPC, all located at addresses between 0x1900 and 0x19a7h and all using IRQ3), but the kernel does not care about
> that nodes. CONFIG_SERIAL_8250_PNP is set to "y" (see attached config.txt) but the kernel output does not show
> up any differences (2.6.38.6.log).
Hmm, let's see... It's been a while since I really worked in this area.
I think there are two problems here:
1) Something must be wrong with your PNP0500 devices because we only
found seven PNP/ACPI devices, the same as we found in the original
boot. Your most recent boot didn't have "debug" on the command line;
that should show us the PNP devices we did find. Can you post the
DSDT? Maybe it will have a clue about why we didn't find 28 (the
original 7 + the new 21 UARTs) devices.
2) Even if the PNP0500 devices were all there, Linux has a
long-standing problem that we don't actually *do* anything with PNP
resources until a driver claims the device. This PCI assignment is
happening before the serial driver would claim the devices, so I'm
afraid it won't help with the problem you're seeing. Ugh. I've been
wanting to fix this for years, but haven't had a chance to dig into
it.
It does seem unnecessary to assign I/O resources to the 00:1c.1 bridge
at all, since there's no device below the bridge that needs I/O
resources. But changing that is a bigger project, too.
There *is* an exception to the "Linux ignores PNP resources" rule,
though -- maybe we could take advantage of that. We do reserve
"motherboard" resources (PNP0C01 and PNP0C02 devices), and there's
even a comment in drivers/pnp/system.c about doing it early, before
PCI assigns resources. So if you change your new PNP0500 devices to
PNP0C02 (and fix whatever is preventing PNPACPI from finding them),
that might fix the PCI bridge assignment. Then you'd have to keep the
serial.h hack, since the serial driver wouldn't be able to claim the
UARTs.
Ugh. I'm really sorry you're tripping over this ugliness in Linux.
The way this is *supposed* to work is that first, ACPI tells us where
all the fixed hardware is. The UARTs and PCI host bridges are
examples of this fixed hardware. Then we're supposed to enumerate
things below the host bridges and assign unused space when necessary.
But Linux has always discovered PCI stuff first, mostly ignoring ACPI,
so keep tripping over problems like this.
Bjorn
Hi Bjorn,
>>> Hi Michael,
>>>
>>> Any update on this problem? ?Did it make any difference to put the
>>> UART in the ACPI namespace?
>>
>> thank you very much for your support. Unfortunately I'm not able to get it to work. I changed
>> the BIOS and added PNP0500 device nodes for all 21 UARTS (all located in the FPGA, all connected
>> via LPC, all located at addresses between 0x1900 and 0x19a7h and all using IRQ3), but the kernel does not care about
>> that nodes. CONFIG_SERIAL_8250_PNP is set to "y" (see attached config.txt) but the kernel output does not show
>> up any differences (2.6.38.6.log).
>
> Hmm, let's see... It's been a while since I really worked in this area.
>
> I think there are two problems here:
>
> 1) Something must be wrong with your PNP0500 devices because we only
> found seven PNP/ACPI devices, the same as we found in the original
> boot.Your most recent boot didn't have "debug" on the command line;
> that should show us the PNP devices we did find. Can you post the
> DSDT? Maybe it will have a clue about why we didn't find 28 (the
> original 7 + the new 21 UARTs) devices.
The BIOS sources were a little bit confusing at that point, but finally
I am able to add PNP device nodes.
> 2) Even if the PNP0500 devices were all there, Linux has a
> long-standing problem that we don't actually *do* anything with PNP
> resources until a driver claims the device. This PCI assignment is
> happening before the serial driver would claim the devices, so I'm
> afraid it won't help with the problem you're seeing. Ugh. I've been
> wanting to fix this for years, but haven't had a chance to dig into
> it.
> It does seem unnecessary to assign I/O resources to the 00:1c.1 bridge
> at all, since there's no device below the bridge that needs I/O
> resources. But changing that is a bigger project, too.
> There *is* an exception to the "Linux ignores PNP resources" rule,
> though -- maybe we could take advantage of that. We do reserve
> "motherboard" resources (PNP0C01 and PNP0C02 devices), and there's
> even a comment in drivers/pnp/system.c about doing it early, before
> PCI assigns resources. So if you change your new PNP0500 devices to
> PNP0C02 (and fix whatever is preventing PNPACPI from finding them),
> that might fix the PCI bridge assignment. Then you'd have to keep the
> serial.h hack, since the serial driver wouldn't be able to claim the
> UARTs.
Thank you so much, that actually did the trick. I got it done to add a
PNP0C02 device with a memory region from 0x1900 to 0x1947 and that is
sufficient to get the kernel booting.
> Ugh. I'm really sorry you're tripping over this ugliness in Linux.
Don't mind, 21 UARTs, all starting at address 0x1900 is a little bit "special".
> The way this is *supposed* to work is that first, ACPI tells us where
> all the fixed hardware is. The UARTs and PCI host bridges are
> examples of this fixed hardware. Then we're supposed to enumerate
> things below the host bridges and assign unused space when necessary.
> But Linux has always discovered PCI stuff first, mostly ignoring ACPI,
> so keep tripping over problems like this.
> Bjorn
Again Bjorn, thank you very very much!
With best regards
Michael Hornung
------------------------------------------------------------
Michael Hornung
Hardware
Mobile Telematic and Fare Collection Systems
Phone +49-(0)721-6100-305
Fax +49-(0)721-6100-399
E-Mail [email protected]
INIT Innovative Informatikanwendungen
in Transport-, Verkehrs- und Leitsystemen GmbH
K?ppelestrasse 4-6
76131 Karlsruhe
Germany
http://www.init-ka.de
Gesch?ftsf?hrer:
Dr.-Ing. Gottfried Greschner, Dipl.-Inform. Achim Becker, Dipl.-Ing. (FH) Wolfgang Degen, Dipl.-Kfm. Dr. J?rgen Greschner
Amtsgericht Mannheim HRB 103679 . Internationale Registrierungen: 988055689MVA (Norwegen), FC027220 (UK)
Vertraulichkeitshinweis:
Der Inhalt dieser E-Mail ist vertraulich zu behandeln. Das Schreiben ist nur zur Kenntnis des oben genannten Empf?ngers bestimmt. Wenn Sie nicht der richtige Adressat sind, informieren Sie bitte sofort den Absender und vernichten diese Nachricht. Unerlaubte Kopien sowie unbefugte Weitergabe sind nicht gestattet.
Bitte beachten Sie, dass durch diese E-Mail keine rechtsverbindlichen Willenserkl?rungen abgegeben werden.
Privacy Notice:
Content of this e-mail must be treated as strictly confidential. This writing is intended only for the knowledge of the above-mentioned addressee. If you are not the correct recipient please inform the sender immediately and permanently erase this message. Illegal copies as well as unauthorized passing is not permitted and strictly forbidden.
Please note that by sending this mail INIT does not make any commitment and is under no obligation.
On Fri, May 27, 2011 at 12:48 AM, Hornung, Michael <[email protected]> wrote:
> Hi Bjorn,
>
>>>> Hi Michael,
>>>>
>>>> Any update on this problem? ?Did it make any difference to put the
>>>> UART in the ACPI namespace?
>>>
>>> thank you very much for your support. Unfortunately I'm not able to get it to work. I changed
>>> the BIOS and added PNP0500 device nodes for all 21 UARTS (all located in the FPGA, all connected
>>> via LPC, all located at addresses between 0x1900 and 0x19a7h and all using IRQ3), but the kernel does not care about
>>> that nodes. CONFIG_SERIAL_8250_PNP is set to "y" (see attached config.txt) but the kernel output does not show
>>> up any differences (2.6.38.6.log).
>>
>> Hmm, let's see... ?It's been a while since I really worked in this area.
>>
>> I think there are two problems here:
>>
>> 1) Something must be wrong with your PNP0500 devices because we only
>> found seven PNP/ACPI devices, the same as we found in the original
>> boot.Your most recent boot didn't have "debug" on the command line;
>> that should show us the PNP devices we did find. ?Can you post the
>> DSDT? ?Maybe it will have a clue about why we didn't find 28 (the
>> original 7 + the new 21 UARTs) devices.
>
> The BIOS sources were a little bit confusing at that point, but finally
> I am able to add PNP device nodes.
>
>> 2) Even if the PNP0500 devices were all there, Linux has a
>> long-standing problem that we don't actually *do* anything with PNP
>> resources until a driver claims the device. ?This PCI assignment is
>> happening before the serial driver would claim the devices, so I'm
>> afraid it won't help with the problem you're seeing. ?Ugh. ?I've been
>> wanting to fix this for years, but haven't had a chance to dig into
>> it.
>
>> It does seem unnecessary to assign I/O resources to the 00:1c.1 bridge
>> at all, since there's no device below the bridge that needs I/O
>> resources. ?But changing that is a bigger project, too.
>
>> There *is* an exception to the "Linux ignores PNP resources" rule,
>> though -- maybe we could take advantage of that. ?We do reserve
>> "motherboard" resources (PNP0C01 and PNP0C02 devices), and there's
>> even a comment in drivers/pnp/system.c about doing it early, before
>> PCI assigns resources. ?So if you change your new PNP0500 devices to
>> PNP0C02 (and fix whatever is preventing PNPACPI from finding them),
>> that might fix the PCI bridge assignment. ?Then you'd have to keep the
>> serial.h hack, since the serial driver wouldn't be able to claim the
>> UARTs.
>
> Thank you so much, that actually did the trick. I got it done to add a
> PNP0C02 device with a memory region from 0x1900 to 0x1947 and that is
> sufficient to get the kernel booting.
>
>> Ugh. ?I'm really sorry you're tripping over this ugliness in Linux.
>
> Don't mind, 21 UARTs, all starting at address 0x1900 is a little bit "special".
>
>> The way this is *supposed* to work is that first, ACPI tells us where
>> all the fixed hardware is. ?The UARTs and PCI host bridges are
>> examples of this fixed hardware. ?Then we're supposed to enumerate
>> things below the host bridges and assign unused space when necessary.
>> But Linux has always discovered PCI stuff first, mostly ignoring ACPI,
>> so keep tripping over problems like this.
I opened this bug report to make sure we don't lose this. I don't
know when or if this will be addressed, but your system is valuable as
a real live test case that shows what we're doing wrong.
https://bugzilla.kernel.org/show_bug.cgi?id=36462
Bjorn
>>> I opened this bug report to make sure we don't lose this. I don't
>>> know when or if this will be addressed, but your system is valuable as
>>> a real live test case that shows what we're doing wrong.
>>>
>>> https://bugzilla.kernel.org/show_bug.cgi?id=36462
>>> Bjorn
Hi Bjorn,
just for the record, the BIOS hack does only work for kernels obove 2.6.33 (2.6.33.14). Those below seem not to care about the PNP device nodes.
With best regards
Michael Hornung
------------------------------------------------------------
Michael Hornung
Hardware
Mobile Telematic and Fare Collection Systems
Phone +49-(0)721-6100-305
Fax +49-(0)721-6100-399
E-Mail [email protected]
INIT Innovative Informatikanwendungen
in Transport-, Verkehrs- und Leitsystemen GmbH
K?ppelestrasse 4-6
76131 Karlsruhe
Germany
http://www.init-ka.de
Gesch?ftsf?hrer:
Dr.-Ing. Gottfried Greschner, Dipl.-Inform. Achim Becker, Dipl.-Ing. (FH) Wolfgang Degen, Dipl.-Kfm. Dr. J?rgen Greschner
Amtsgericht Mannheim HRB 103679 . Internationale Registrierungen: 988055689MVA (Norwegen), FC027220 (UK)
Vertraulichkeitshinweis:
Der Inhalt dieser E-Mail ist vertraulich zu behandeln. Das Schreiben ist nur zur Kenntnis des oben genannten Empf?ngers bestimmt. Wenn Sie nicht der richtige Adressat sind, informieren Sie bitte sofort den Absender und vernichten diese Nachricht. Unerlaubte Kopien sowie unbefugte Weitergabe sind nicht gestattet.
Bitte beachten Sie, dass durch diese E-Mail keine rechtsverbindlichen Willenserkl?rungen abgegeben werden.
Privacy Notice:
Content of this e-mail must be treated as strictly confidential. This writing is intended only for the knowledge of the above-mentioned addressee. If you are not the correct recipient please inform the sender immediately and permanently erase this message. Illegal copies as well as unauthorized passing is not permitted and strictly forbidden.
Please note that by sending this mail INIT does not make any commitment and is under no obligation.