* [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).