>> Fix boot-script parsing for openSUSE ppc media
>
>applied, thanks
I've applied it, as it breaks nothing and allows to use Suse, but a better fix should be:
- correctly parse the script to replace &device; by the boot device ("cd:", and not "cd:0", which is "&bootdevice;:&partition;")
- correctly manage CD partition to be able to use ":1" instead of ":0" (in fact, for the moment, we use mac partition on CD and ":0" to use the entire disk).
Regards,
Laurent
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.
--
Mark Cave-Ayland
Sirius Corporation - The Open Source Experts
http://www.siriusit.co.uk
T: +44 870 608 0063
Subject: Fix fs->vol_name handling
This patch checks wether fs->vol_name exists and handles the
case where it doesn't exist. That fixes the lockup that occurs
when trying to run qemu-system-ppc -cdrom <iso> -boot d
Signed-off-by: Stefan Assmann <sassmann(a)suse.de>
Index: modules/filesystems.c
===================================================================
--- modules/filesystems.c (revision 418)
+++ modules/filesystems.c (working copy)
@@ -145,8 +145,12 @@
if( !mi->volname )
mi->volname = malloc( VOLNAME_SIZE );
-
- ret = mi->fs->vol_name( mi->fs, mi->volname, VOLNAME_SIZE );
+ /* handle case where there is no vol_name function in fs */
+ if( !mi->fs->vol_name ) {
+ mi->volname[0] = '\0';
+ ret = mi->volname;
+ } else
+ ret = mi->fs->vol_name( mi->fs, mi->volname, VOLNAME_SIZE );
PUSH( (ucell)ret );
}
Stefan
--
Stefan Assmann | SUSE LINUX Products GmbH
Software Engineer | Maxfeldstr. 5, D-90409 Nuernberg
Mail: sassmann(a)suse.de | GF: Markus Rex, HRB 16746 (AG Nuernberg)
Author: blueswirl
Date: 2009-01-29 20:56:41 +0100 (Thu, 29 Jan 2009)
New Revision: 430
Modified:
openbios-devel/modules/filesystems.c
Log:
Fix fs->vol_name handling
This patch checks wether fs->vol_name exists and handles the
case where it doesn't exist. That fixes the lockup that occurs
when trying to run qemu-system-ppc -cdrom <iso> -boot d
Signed-off-by: Stefan Assmann <sassmann(a)suse.de>
Modified: openbios-devel/modules/filesystems.c
===================================================================
--- openbios-devel/modules/filesystems.c 2009-01-29 10:51:25 UTC (rev 429)
+++ openbios-devel/modules/filesystems.c 2009-01-29 19:56:41 UTC (rev 430)
@@ -145,8 +145,12 @@
if( !mi->volname )
mi->volname = malloc( VOLNAME_SIZE );
-
- ret = mi->fs->vol_name( mi->fs, mi->volname, VOLNAME_SIZE );
+ /* handle case where there is no vol_name function in fs */
+ if( !mi->fs->vol_name ) {
+ mi->volname[0] = '\0';
+ ret = mi->volname;
+ } else
+ ret = mi->fs->vol_name( mi->fs, mi->volname, VOLNAME_SIZE );
PUSH( (ucell)ret );
}