SVN Coreboot-v3 with SVN OpenBIOS payload panics on boot with qemu

[Mark Cave-Ayland]

Hi everyone,

I'm been trying the latest SVN versions of coreboot-v3, OpenBIOS and 
Qemu together and I am experiencing a panic on boot when launching 
qemu-system-x86_64. I can see some hardware enumeration but before the 
OpenBIOS prompt appears, qemu puts out the following message on the console:

qemu: hardware error: register_ioport_write: invalid opaque

As far as I can tell, I don't think that it's a qemu issue since qemu 
SVN successfully boots with the pre-built coreboot-v3/OpenBIOS image 
found at http://www.coreboot.org/QEMU#coreboot_v3_.2B_OpenBIOS, which 
suggests that the bug lies somewhere between OpenBIOS and coreboot.

I've uploaded the full console output to 
http://pastebin.siriusit.co.uk/coreboot-v3-panic.txt in case other 
people may find it useful.

ATB,

Mark.

SVN Coreboot-v3 with SVN OpenBIOS payload panics on boot with qemu

[Myles Watson]

On Tue, Jan 27, 2009 at 10:35 AM, Mark Cave-Ayland
 wrote:
> Hi everyone,
>
> I'm been trying the latest SVN versions of coreboot-v3, OpenBIOS and Qemu
> together and I am experiencing a panic on boot when launching
> qemu-system-x86_64. I can see some hardware enumeration but before the
> OpenBIOS prompt appears, qemu puts out the following message on the console:
>
> qemu: hardware error: register_ioport_write: invalid opaque
>
> As far as I can tell, I don't think that it's a qemu issue since qemu SVN
> successfully boots with the pre-built coreboot-v3/OpenBIOS image found at
> http://www.coreboot.org/QEMU#coreboot_v3_.2B_OpenBIOS, which suggests that
> the bug lies somewhere between OpenBIOS and coreboot.
>
> I've uploaded the full console output to
> http://pastebin.siriusit.co.uk/coreboot-v3-panic.txt in case other people
> may find it useful.

boot eax = 0x2badb002
boot ebx = 0xf0000
boot arg = 0x2

That doesn't look good. 0x2badb002 instead of 0x100060 in the working
log.  I don't know much about OpenBIOS, but I'm happy to help if it
looks like the resource allocation is breaking it.  Have you tried it
without the printk buffer enabled?

Thanks,
Myles

SVN Coreboot-v3 with SVN OpenBIOS payload panics on boot with qemu

[Mark Cave-Ayland]

Myles Watson wrote:
> boot eax = 0x2badb002
> boot ebx = 0xf0000
> boot arg = 0x2
>
> That doesn't look good. 0x2badb002 instead of 0x100060 in the working
> log.  I don't know much about OpenBIOS, but I'm happy to help if it
> looks like the resource allocation is breaking it.  Have you tried it
> without the printk buffer enabled?
>
> Thanks,
> Myles

Hi Myles,

Possibly - I'm still quite new to both codebases at the moment. Based 
upon your advice I just tried undefining "CONSOLE_BUFFER" in "make 
menuconfig", and then did a complete "make clean; make" once again. 
Sadly after installing this coreboot/OpenBIOS, qemu SVN still fails to 
boot with exactly the same error.

ATB,

Mark.

SVN Coreboot-v3 with SVN OpenBIOS payload panics on boot with qemu

[Myles Watson]

On Tue, Jan 27, 2009 at 12:33 PM, Mark Cave-Ayland
 wrote:
> Myles Watson wrote:
> > boot eax = 0x2badb002
> > boot ebx = 0xf0000
> > boot arg = 0x2
> >
> > That doesn't look good. 0x2badb002 instead of 0x100060 in the working
> > log.  I don't know much about OpenBIOS, but I'm happy to help if it
> > looks like the resource allocation is breaking it.  Have you tried it
> > without the printk buffer enabled?
> >
> > Thanks,
> > Myles
>
> Hi Myles,
>
> Possibly - I'm still quite new to both codebases at the moment. Based upon
> your advice I just tried undefining "CONSOLE_BUFFER" in "make menuconfig",
> and then did a complete "make clean; make" once again. Sadly after
> installing this coreboot/OpenBIOS, qemu SVN still fails to boot with exactly
> the same error.

Thanks for trying it.  It was the other big change besides the
resource allocator since the working log.

I used coreboot v2 and it doesn't fail.  Buildrom makes it easy to
switch between the two.  You just have to

svn up work/openbios/svn

to get the latest instead of Rev 186, after you've configured it to
use openbios.

I still get all the

Cannot manage 'PCI host bridge' PCI device type 'pci':
 8086 1237 (6 0 0)
Cannot manage 'ISA bridge' PCI device type 'pci':
 8086 7000 (6 1 0)
Cannot manage 'IDE controller' PCI device type 'ide':
 8086 7010 (1 1 80)
Cannot manage 'misc PCI bridge' PCI device type 'pci':
 8086 7113 (6 80 0)
Cannot manage 'VGA controller' PCI device type 'display':
 1013 b8 (3 0 0)

Messages, but then I get:

Welcome to OpenBIOS v1.0RC1 built on Jan 27 2009 19:55
  Type 'help' for detailed information

[x86] Booting default not supported.

0 >

Can you enable more debugging and/or figure out what is being accessed
at the failure?  I'll help from the coreboot side if I can.

Thanks,
Myles

SVN Coreboot-v3 with SVN OpenBIOS payload panics on boot with qemu

[Mark Cave-Ayland]

Myles Watson wrote:
> Can you enable more debugging and/or figure out what is being accessed
> at the failure?  I'll help from the coreboot side if I can.
>
> Thanks,
> Myles

Hi Myles,

I have some good news; I eventually found SVN revisions of OpenBIOS and 
coreboot-v3 that worked, and found out through SVN bisection that it was 
actually a change in OpenBIOS that caused the crash. The offending 
commit appears to be r416 in the OpenBIOS codebase here:

http://tracker.coreboot.org/trac/openbios/changeset?old=416%40openbios-devel...

Does that help you at all?

ATB,

Mark.

SVN Coreboot-v3 with SVN OpenBIOS payload panics on boot with qemu

[Myles Watson]

> -----Original Message-----
> From: Mark Cave-Ayland [mailto:[e-mail]]
> Sent: Tuesday, January 27, 2009 4:43 PM
> To: Myles Watson
> Cc: [e-mail]
> Subject: Re: [coreboot] SVN Coreboot-v3 with SVN OpenBIOS payload panics
> on boot with qemu
>
> Myles Watson wrote:
> > Can you enable more debugging and/or figure out what is being accessed
> > at the failure?  I'll help from the coreboot side if I can.
> >
> > Thanks,
> > Myles
>
> Hi Myles,
>
> I have some good news; I eventually found SVN revisions of OpenBIOS and
> coreboot-v3 that worked, and found out through SVN bisection that it was
> actually a change in OpenBIOS that caused the crash. The offending
> commit appears to be r416 in the OpenBIOS codebase here:
>
> http://tracker.coreboot.org/trac/openbios/changeset?old=416%40openbios-
> devel&new=415%40openbios-devel
>
> Does that help you at all?

It definitely narrows it down.  I'll have to look more closely at the IO
space allocation differences between v2 and v3.

I may have changed the IO allocation from 0x400 to 0x1000 in qemu.  In v3 I
wanted them to all start at the same place.  In v2 it was dependent on the
board.

It looks like OpenBIOS is allocating address space for the devices and
didn't want to allocate in the legacy PCI range.  I just don't see why that
breaks anything unless they're running out of space somehow.  I wonder what
arch->io_base is before they add 0x400 to it.

Have you also asked about this change on the OpenBIOS list?

Thanks,
Myles

SVN Coreboot-v3 with SVN OpenBIOS payload panics on boot with qemu

[Mark Cave-Ayland]

Myles Watson wrote:
> It definitely narrows it down.  I'll have to look more closely at the IO
> space allocation differences between v2 and v3.
>
> I may have changed the IO allocation from 0x400 to 0x1000 in qemu.  In v3 I
> wanted them to all start at the same place.  In v2 it was dependent on the
> board.
>
> It looks like OpenBIOS is allocating address space for the devices and
> didn't want to allocate in the legacy PCI range.  I just don't see why that
> breaks anything unless they're running out of space somehow.  I wonder what
> arch->io_base is before they add 0x400 to it.
>
> Have you also asked about this change on the OpenBIOS list?

I have now. I've asked them to join onto this thread so we can all 
continue the discussion in one place.

Many thanks,

Mark.