Re: [Qemu-devel] Machine specific option ROMs
On Tue, 20 Aug 2019, Gerd Hoffmann wrote: Yes, how the guest treats those roms is another issue. bios/efi combo roms on x86 are not that uncommon. But I'm not sure how widespread bios/openfirmare combo roms are used (have been used) in practice. If I haven't heard about such BIOS/OF ROMs (which does not mean much as I don't know much about this) but I think it's probably not widespread if used at all. I think ROM size on cards were limited for cost reasons so instead of trying to fit more images in one limited space vendors usually produced separate versions for x86 and Macs with different ROM image. At least there's a lot of info on how to convert PC cards to Mac by reflashing ROM which would not be needed if these had support in ROM. guests can't deal with it (and try to run a x86 emulator on the bios image instead) it might not be the best plan to go that route. Some clients do have BIOS emulation while also can use OF ROM like pegasos2's SmartFirmware but I don't know how that would handle multiplatform ROMs so it's better go the simpler way which seems to have less problems and just set the ROM the clients are most likely to support by machine emulation. Multiplatform ROMs are an interesting possibility but looks like more trouble in practice than it could bring. just not the QEMU vgabios due to not emulating i386 specific opcodes that gcc puts in real mode code What does sam460ex use? Some x86emu fork? If so upgrading might help. Xorg uses x86emu too and older versions have problems with the gcc-generated real mode code too. It has x86emu in roms/u-boot-sam460ex/board/ACube/bios_emulator and is likely old version because this is from 2010/2011. (I think I've also tried enabling the option in vgabios for x86emu fixups before but that did not help or maybe that was with pegasos2 which does not even have firmware sources to update, yet it's useful to test with original firmware so I'd like to get that working eventually.) For sam460ex there's a newer, updated firmware version from 2015 the sources of which are available from the vendor here: http://acube-systems.biz/index.php?page=hardware&pid=5 but I don't know if that has newer x86emu and haven't tested if it works with QEMU. I also had to fix bugs in the previous version to compile and work so unless there's a good reason I don't want to spend time trying to update sam460ex firmware. The current version works enough to boot OSes and I don't want to start maintaining and fixing a commercial vendor's firmware. They can support it if they want. Regards, BALATON Zoltan
Re: [Qemu-devel] Machine specific option ROMs
Hi, > Plus I don't know if other firmwares such as sam460ex U-Boot can handle such > multiplatform ROMs, especially because it can use x86 ROM Yes, how the guest treats those roms is another issue. bios/efi combo roms on x86 are not that uncommon. But I'm not sure how widespread bios/openfirmare combo roms are used (have been used) in practice. If guests can't deal with it (and try to run a x86 emulator on the bios image instead) it might not be the best plan to go that route. > just not the QEMU > vgabios due to not emulating i386 specific opcodes that gcc puts in real > mode code What does sam460ex use? Some x86emu fork? If so upgrading might help. Xorg uses x86emu too and older versions have problems with the gcc-generated real mode code too. cheers, Gerd
Re: [Qemu-devel] Machine specific option ROMs
On Tue, 20 Aug 2019, Gerd Hoffmann wrote:
For example in qemu 1.5 the nic roms got EFI support and there is a
compat property which switches the pc-i440fx-1.4 (and older) machine
types to the non-efi versions. Grep for pxe-e1000.rom to find the code.
Note that roms with a pci firmware standard header[1] can be chained
together, then placed in the pci rom bar. This is how the efi-*.rom
files are created, they are three-in-one images (bios, efi ia32, efi
x64).
# file pc-bios/qemu_vga.ndrv
pc-bios/qemu_vga.ndrv: header for PowerPC PEF executable
Hmm, so that is probably not going to work.
+static GlobalProperty compat[] = {
+{ "VGA", "romfile", NDRV_VGA_FILENAME },
+};
+compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
I wouldn't name the variable compat (in this specific case it's not for
backward compatibility), but yes, this is the idea.
manually. (In the future this same way can also be used to pass proper
FCode ROMs to OpenBIOS.)
The image type (pci rom header) can be:
Type Description
0 Intel x86, PC-AT compatible
1 Open Firmware standard for PCI
2 Hewlett-Packard PA RISC
3 Extensible Firmware Interface (EFI)
4-FF Reserved
So having a single pci rom image with both classic vgabios (type 0) and
open firmware fcode (type 1) should be possible.
cheers,
Gerd
[1] http://read.pudn.com/downloads211/doc/comm/994029/pcifw_r3_0_updated.pdf,
section 5.1
Thanks for investigating it. However there are at least two problems with
that idea:
1. OpenBIOS does not yet understand standard PCI ROM headers, it can only
handle NDRV and PEF ROMs yet so first support for that (and FCode ROMs)
should be added to OpenBIOS.
2. Building rom images from different sources (in this case your vgabios
and QemuMacDrivers for the NDRV) might not be straightforward (maybe some
clever make rules would take care of these without too much hassle but I'm
not sure, this would mean rebuilding binary if any of the two sources
change).
Plus I don't know if other firmwares such as sam460ex U-Boot can handle
such multiplatform ROMs, especially because it can use x86 ROM just not
the QEMU vgabios due to not emulating i386 specific opcodes that gcc puts
in real mode code so it needs something compiled with bcc such as
Plex86/Bochs VGABios so then we can't put those in one binary because we
had two x86 images in it. Therefore I think setting this based on machine
like above is probably the easiest way for now.
I'll wait for Mark's comments before going further with this.
Regards,
BALATON Zoltan
Re: [Qemu-devel] Machine specific option ROMs
Hi,
> > For example in qemu 1.5 the nic roms got EFI support and there is a
> > compat property which switches the pc-i440fx-1.4 (and older) machine
> > types to the non-efi versions. Grep for pxe-e1000.rom to find the code.
Note that roms with a pci firmware standard header[1] can be chained
together, then placed in the pci rom bar. This is how the efi-*.rom
files are created, they are three-in-one images (bios, efi ia32, efi
x64).
# file pc-bios/qemu_vga.ndrv
pc-bios/qemu_vga.ndrv: header for PowerPC PEF executable
Hmm, so that is probably not going to work.
> +static GlobalProperty compat[] = {
> +{ "VGA", "romfile", NDRV_VGA_FILENAME },
> +};
> +compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
I wouldn't name the variable compat (in this specific case it's not for
backward compatibility), but yes, this is the idea.
> manually. (In the future this same way can also be used to pass proper
> FCode ROMs to OpenBIOS.)
The image type (pci rom header) can be:
Type Description
0 Intel x86, PC-AT compatible
1 Open Firmware standard for PCI
2 Hewlett-Packard PA RISC
3 Extensible Firmware Interface (EFI)
4-FF Reserved
So having a single pci rom image with both classic vgabios (type 0) and
open firmware fcode (type 1) should be possible.
cheers,
Gerd
[1] http://read.pudn.com/downloads211/doc/comm/994029/pcifw_r3_0_updated.pdf,
section 5.1
Re: [Qemu-devel] Machine specific option ROMs
On Mon, 19 Aug 2019, Gerd Hoffmann wrote:
> On Mon, Aug 19, 2019 at 02:38:09AM +0200, BALATON Zoltan wrote:
>> I know about the possibility to set the option ROM of a PCIDevice with the
>> romfile property (that we can set on command line or in a device's init
>> method) but is there a way to set it depending on the machine that uses the
>> device? If this is not currently possible what would be needed to allow
>> this?
>
> Should work with compat properties. That is a list of device, property
> and value which a specific machine type should use. Typically they are
> used to make versioned machine types behave simliar to older qemu
> versions (this is where the name comes from). Using them to use
> non-default properties on ppc platform should work too.
>
> For example in qemu 1.5 the nic roms got EFI support and there is a
> compat property which switches the pc-i440fx-1.4 (and older) machine
> types to the non-efi versions. Grep for pxe-e1000.rom to find the code.
OK thanks, looks like something like this works:
diff --git a/hw/ppc/mac_newworld.c b/hw/ppc/mac_newworld.c
index c5bbcc7433..8ee937e3ce 100644
--- a/hw/ppc/mac_newworld.c
+++ b/hw/ppc/mac_newworld.c
@@ -569,6 +572,10 @@ static int core99_kvm_type(MachineState *machine, const
char *arg)
return 2;
}
+static GlobalProperty compat[] = {
+{ "VGA", "romfile", NDRV_VGA_FILENAME },
+};
+
static void core99_machine_class_init(ObjectClass *oc, void *data)
{
MachineClass *mc = MACHINE_CLASS(oc);
@@ -587,6 +594,7 @@ static void core99_machine_class_init(ObjectClass *oc, void
*data)
mc->default_cpu_type = POWERPC_CPU_TYPE_NAME("7400_v2.9");
#endif
mc->ignore_boot_device_suffixes = true;
+compat_props_add(mc->compat_props, compat, G_N_ELEMENTS(compat));
fwc->get_dev_path = core99_fw_dev_path;
}
Mark, do you think this could replace the current way of passing this
driver via fw_cfg and would you accept patches to OpenBIOS to revert the
ndrv patching to replace that with this solution? (The vga_config_cb
already adds the driver from the ROM when set as above so no further hacks
are necessary. If we want we can keep the vga-ndrv? option to control this
adding NDRV from ROM after the current use of this setting is no longer
needed.) I think this would allow some simplification and also avoids
patching ati-vga with this driver without needing to add vga-ndrv?=false
manually. (In the future this same way can also be used to pass proper
FCode ROMs to OpenBIOS.)
Regards,
BALATON Zoltan
Re: [Qemu-devel] Machine specific option ROMs
On Mon, Aug 19, 2019 at 02:38:09AM +0200, BALATON Zoltan wrote: > Hello, > > I know about the possibility to set the option ROM of a PCIDevice with the > romfile property (that we can set on command line or in a device's init > method) but is there a way to set it depending on the machine that uses the > device? If this is not currently possible what would be needed to allow > this? Should work with compat properties. That is a list of device, property and value which a specific machine type should use. Typically they are used to make versioned machine types behave simliar to older qemu versions (this is where the name comes from). Using them to use non-default properties on ppc platform should work too. For example in qemu 1.5 the nic roms got EFI support and there is a compat property which switches the pc-i440fx-1.4 (and older) machine types to the non-efi versions. Grep for pxe-e1000.rom to find the code. HTH, Gerd
