Re: [OpenBIOS] [coreboot] OpenBIOS SVN r416 breaks coreboot-v3

[Mark Cave-Ayland]

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?

ATB,

Mark.

[coreboot] OpenBIOS SVN r416 breaks coreboot-v3

[Blue Swirl]

On 1/29/09, Mark Cave-Ayland  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?

For PPC, 0x520 is not what real HW uses, it should be 0x400. The
pci_arch_t structure could be extended with an IO offset parameter, or
that could be passed from XML configuration.

The device that uses port 0x510 is the firmware configuration device
for Qemu, so another solution is to move the I/O port used by the
device below 0x400. The port is already used by x86 Bochs BIOS, so
moving the port would require some coordination between a few parties.