On 1/29/09, Mark Cave-Ayland <[email protected]> wrote: > Myles Watson wrote: > > > > Yes. qemu 0.9.1 works with v2+OpenBIOS and v3+OpenBIOS, but the latest > qemu > > doesn't. The latest qemu works with v2 or v3 +OpenBIOS r186, so it looks > > like an interaction between OpenBIOS and qemu. > > > > HTH, > > Myles > > > > Okay, I think I found out what is happening. With coreboot-v3 and OpenBIOS > SVN then the base address for I/O devices is set to 0x400 which causes > subsequent hardware to be mapped higher. The backtrace on the hw_error() > line shows this: > > > Breakpoint 1, register_ioport_write (start=1296, length=1, size=1, > func=0x42b105 <ne2000_asic_ioport_write>, opaque=0xc9abb8) > at /home/build/src/qemu/trunk/vl.c:392 > 392 hw_error("register_ioport_write: > invalid opaque: (start 0x%x, length 0x%x, address 0x%x)", start, length, i); > (gdb) print/x start > $1 = 0x510 > (gdb) bt > #0 register_ioport_write (start=1296, length=1, size=1, func=0x42b105 > <ne2000_asic_ioport_write>, opaque=0xc9abb8) > at /home/build/src/qemu/trunk/vl.c:392 > #1 0x000000000042bc6b in ne2000_map (pci_dev=0xc9a990, region_num=0, > addr=1280, size=256, type=1) > at /home/build/src/qemu/trunk/hw/ne2000.c:771 > #2 0x0000000000414548 in pci_update_mappings (d=0xc9a990) at > /home/build/src/qemu/trunk/hw/pci.c:301 > #3 0x0000000000414706 in pci_default_write_config (d=0xc9a990, address=16, > val=1281, len=4) at /home/build/src/qemu/trunk/hw/pci.c:362 > #4 0x00000000004148d7 in pci_data_write (opaque=0xc281c0, addr=2147489808, > val=1281, len=4) at /home/build/src/qemu/trunk/hw/pci.c:467 > #5 0x0000000000483e31 in pci_host_data_writel (opaque=0xc281a0, addr=3324, > val=1281) at /home/build/src/qemu/trunk/hw/pci_host.h:74 > #6 0x0000000000406818 in ioport_write (index=2, address=3324, data=1281) > at /home/build/src/qemu/trunk/vl.c:298 > #7 0x0000000000406c0d in cpu_outl (env=0xc10650, addr=3324, val=1281) at > /home/build/src/qemu/trunk/vl.c:438 > #8 0x00000000005248fe in helper_outl (port=3324, data=1281) at > /home/build/src/qemu/trunk/target-i386/op_helper.c:582 > #9 0x0000000040e5d11c in ?? () > #10 0x00000000000000f4 in ?? () > #11 0x0000000006e64a20 in ?? () > #12 0x0000000006f687ab in ?? () > #13 0x0000000040e5ce30 in ?? () > #14 0x0000000040e603c8 in ?? () > #15 0x0000000008000000 in ?? () > #16 0x00007fff4ef701b0 in ?? () > #17 0x00000000004fcd9c in tb_set_jmp_target (tb=0x406670, n=0, > addr=2361183241434822607) at ../exec-all.h:240 > #18 0x000000000040c64f in main_loop () at > /home/build/src/qemu/trunk/vl.c:3737 > #19 0x000000000040f772 in main (argc=6, argv=0x7fff4ef70bf8, > envp=0x7fff4ef70c30) at > /home/build/src/qemu/trunk/vl.c:5712 > > > So in other words, with current OpenBIOS SVN the I/O space for the network > card requires more than 0x110 bytes from 0x400 and hence when qemu tries to > map I/O address 0x510 (which is already mapped to the BIOS I/O port), qemu > reports the error and panics. > > My quick fix was to apply the following patch to openbios in order to raise > the io_base further from 0x400 to 0x520 so that no devices appear below the > BIOS_IO_PORT address of 0x510: > > > --- drivers/pci.c (revision 428) > +++ drivers/pci.c (working copy) > @@ -762,7 +762,7 @@ > mem_base = arch->mem_base; > /* I/O ports under 0x400 are used by devices mapped at fixed > location. */ > - io_base = arch->io_base + 0x400; > + io_base = arch->io_base + 0x520; > path = strdup(""); > for (bus = 0; bus<0x100; bus++) { > ob_scan_pci_bus(bus, &mem_base, &io_base, &path); > > > With this patch applied, I am pleased to report that qemu can successfully > boot openbios once again. Can anyone with more knowledge comment on whether > this is an adequate solution or not?
Would this patch fix the problem?
fix_x86_pci.diff
Description: plain/text
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
