[LinuxBIOS] PCI IRQ routing issues with qemu

[Ed Swierk]

Hello,

I'm having some trouble getting Linux to recognize Ethernet and USB
devices when booting with LinuxBIOS on qemu 0.8.2.

During boot I see messages like:

ne2k-pci.c:v1.03 9/22/2003 D. Becker/P. Gortmaker
  http://www.scyld.com/network/ne2k-pci.html
PCI: No IRQ known for interrupt pin A of device 0000:00:03.0. Please
try using pci=biosirq.
eth0: RealTek RTL-8029 found at 0x1000, IRQ 0, 52:54:00:12:34:56.

and

USB Universal Host Controller Interface driver v3.0
PCI: No IRQ known for interrupt pin D of device 0000:00:01.2. Please
try using pci=biosirq.
uhci_hcd 0000:00:01.2: Found HC with no IRQ.  Check BIOS/PCI 0000:00:01.2 setup!
uhci_hcd 0000:00:01.2: init 0000:00:01.2 fail, -19

After groveling through the list archive for clues, I used getpir to
update irq_tables.c, since it looks like the one in
src/mainboard/emulation/qemu-i386 is pretty old. I validated the
resulting table with checkpir, and added "option HAVE_PIRQ_TABLE=1" to
Config.lb. LinuxBIOS doesn't seem to be able to use the new table,
though:

Copying IRQ routing tables to 0xf0000...done.
Verifing copy of IRQ routing tables at 0xf0000...failed

Any further clues would be appreciated. I've attached my boot log,
irq_tables.c, Config.lb, as well as the output of lspci after booting
with qemu's standard BIOS.

--Ed

[Richard Smith]

> Config.lb. LinuxBIOS doesn't seem to be able to use the new table,
> though:
>
> Copying IRQ routing tables to 0xf0000...done.
> Verifing copy of IRQ routing tables at 0xf0000...failed

What does Qemu do when the BIOS attempts to write to that area?
Normally this range of memory is write protected.

[Ronald G Minnich]

Richard Smith wrote:
> > Config.lb. LinuxBIOS doesn't seem to be able to use the new table,
> > though:
> >
> > Copying IRQ routing tables to 0xf0000...done.
> > Verifing copy of IRQ routing tables at 0xf0000...failed
>
> What does Qemu do when the BIOS attempts to write to that area?
> Normally this range of memory is write protected.

actually it is usually shadowed by that point, but not write protected.

I'm guessing turning on shadow is failing.

Build linuxbios with CONFIG_COMPRESSED=0 and see how it goes.

ron

[Richard Smith]

> > What does Qemu do when the BIOS attempts to write to that area?
> > Normally this range of memory is write protected.
>
> actually it is usually shadowed by that point, but not write protected.
> I'm guessing turning on shadow is failing.
>
> Build linuxbios with CONFIG_COMPRESSED=0 and see how it goes.

How faithfully does qemu model the hardware?

[Ed Swierk]

On 9/12/06, Richard Smith  wrote:
> What does Qemu do when the BIOS attempts to write to that area?
> Normally this range of memory is write protected.

Good question--I was scratching my head over this chunk of code in
qemu yesterday:

/* map the last 128KB of the BIOS in ISA space */
        isa_bios_size = bios_size;
        if (isa_bios_size > (128 * 1024))
            isa_bios_size = 128 * 1024;
        cpu_register_physical_memory(0xd0000, (192 * 1024) - isa_bios_size,
                                     IO_MEM_UNASSIGNED);
        cpu_register_physical_memory(0x100000 - isa_bios_size,
                                     isa_bios_size,
                                     (bios_offset + bios_size -
isa_bios_size) | IO_MEM_ROM);

Turns out that commenting out this code not only doesn't cause any
harm, it lets LinuxBIOS write the IRQ table.

The next problem I ran into was LinuxBIOS complaining about the size
and checksum of the table not matching. I solved this by adding
"option IRQ_SLOT_COUNT=6" to my Config.lb.

Now Linux happily finds IRQs and can talk to the Ethernet and USB
devices just fine.

Thanks for your help!

--Ed