* [Qemu-devel] Machine specific option ROMs
@ 2019-08-19 0:38 BALATON Zoltan
2019-08-19 6:15 ` Gerd Hoffmann
0 siblings, 1 reply; 7+ messages in thread
From: BALATON Zoltan @ 2019-08-19 0:38 UTC (permalink / raw)
To: qemu-devel; +Cc: Mark Cave-Ayland, Gerd Hoffmann
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?
I'm asking because some cards may have different option ROMs on different
platforms: e.g. gfx cards need different ROM on Mac than on PC due to
using different firmware (and CPU arch). For Mac machines emulated by QEMU
OpenBIOS now patches in a driver that it downloads via FW_CFG but it could
use an FCode ROM (or the driver directly passed as the ROM image) instead
which would be a simpler solution and more like how real hardware works.
Also sam460ex firmware has a BIOS emulator for using PC option ROMs but
that can't run QEMU vgabios binaries (as these are i386 real mode and it
can only run x86 real mode) so we may need a way to specify a different
ROM if the card is used in sam460ex.
So I'm looking for a way for board code to set romfile when the device is
added to the board. Should the normal way of setting a property work for
this or is that too late by then to change ROM of the device? (Also this
may need to work together with the -vga option to ensure card has the
right ROM on different machines even if added by -vga.)
Regards,
BALATON Zoltan
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Machine specific option ROMs
2019-08-19 0:38 [Qemu-devel] Machine specific option ROMs BALATON Zoltan
@ 2019-08-19 6:15 ` Gerd Hoffmann
2019-08-19 23:42 ` BALATON Zoltan
0 siblings, 1 reply; 7+ messages in thread
From: Gerd Hoffmann @ 2019-08-19 6:15 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Machine specific option ROMs
2019-08-19 6:15 ` Gerd Hoffmann
@ 2019-08-19 23:42 ` BALATON Zoltan
2019-08-20 6:25 ` Gerd Hoffmann
0 siblings, 1 reply; 7+ messages in thread
From: BALATON Zoltan @ 2019-08-19 23:42 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Mark Cave-Ayland, qemu-devel
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
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Machine specific option ROMs
2019-08-19 23:42 ` BALATON Zoltan
@ 2019-08-20 6:25 ` Gerd Hoffmann
2019-08-20 10:46 ` BALATON Zoltan
0 siblings, 1 reply; 7+ messages in thread
From: Gerd Hoffmann @ 2019-08-20 6:25 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Machine specific option ROMs
2019-08-20 6:25 ` Gerd Hoffmann
@ 2019-08-20 10:46 ` BALATON Zoltan
2019-08-20 12:28 ` Gerd Hoffmann
0 siblings, 1 reply; 7+ messages in thread
From: BALATON Zoltan @ 2019-08-20 10:46 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Mark Cave-Ayland, qemu-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Machine specific option ROMs
2019-08-20 10:46 ` BALATON Zoltan
@ 2019-08-20 12:28 ` Gerd Hoffmann
2019-08-20 14:01 ` BALATON Zoltan
0 siblings, 1 reply; 7+ messages in thread
From: Gerd Hoffmann @ 2019-08-20 12:28 UTC (permalink / raw)
To: BALATON Zoltan; +Cc: Mark Cave-Ayland, qemu-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [Qemu-devel] Machine specific option ROMs
2019-08-20 12:28 ` Gerd Hoffmann
@ 2019-08-20 14:01 ` BALATON Zoltan
0 siblings, 0 replies; 7+ messages in thread
From: BALATON Zoltan @ 2019-08-20 14:01 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: Mark Cave-Ayland, qemu-devel
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2019-08-20 14:02 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-08-19 0:38 [Qemu-devel] Machine specific option ROMs BALATON Zoltan
2019-08-19 6:15 ` Gerd Hoffmann
2019-08-19 23:42 ` BALATON Zoltan
2019-08-20 6:25 ` Gerd Hoffmann
2019-08-20 10:46 ` BALATON Zoltan
2019-08-20 12:28 ` Gerd Hoffmann
2019-08-20 14:01 ` BALATON Zoltan
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).