On 06/10/2015 02:04 PM, Laszlo Ersek wrote: > On 06/10/15 11:09, Marcel Apfelbaum wrote: >> On 06/06/2015 02:45 AM, Laszlo Ersek wrote: > >>> (7) At least one issue remains to be solved (designed) in QEMU, for both >>> SeaBIOS's and OVMF's sake: booting off devices that are located on >>> the PXB. The problem is with the "bootorder" fw_cfg file. Consider >>> the following example: >>> >>> /pci@i0cf8/scsi@3/channel@0/disk@0,0 >>> /pci/pci-bridge@0/ethernet@2/ethernet-phy@0 >>> >>> which is generated for the options >>> >>> -device virtio-scsi-pci,id=scsi0 \ >>> -device scsi-cd,bus=scsi0.0,drive=cdrom,bootindex=0 \ >>> \ >>> -device pxb,id=bridge1,bus_nr=4 \ >>> -device >>> e1000,netdev=netdev0,bus=bridge1,addr=2,romfile=,bootindex=1 >>> >>> While the first entry is recognized by both SeaBIOS and OVMF, the >>> second entry (generated for the NIC hanging off the PXB, see above) >>> is recognized by neither. (I tested OVMF, and investigated the >>> SeaBIOS source, for this claim.) >>> >>> For the SeaBIOS explanation, grep the source code for FW_PCI_DOMAIN. >> Thanks for bringing it to my attention. >> >>> >>> The OVMF explanation is that OVMF simply rejects the initial >>> OpenFirmware device path node "/pci" with a controlled parse error >>> (as opposed to the "/pci@i0cf8" node, which it recognizes and >>> translates to UEFI in combination with the rest of that OFW device >>> path). >>> >>> The "/pci" node comes from QEMU's sysbus_get_fw_dev_path() function, >>> file "hw/core/sysbus.c", where *neither* of the (s->num_mmio) and >>> (s->num_pio) branches apply. (The (s->num_pio) branch applies for >>> the first entry, ie. "/pci@i0cf8".) >>> >>> Something has to be invented here to clue in both firmwares as to >>> the root bus number (here bus_nr=4), in a format that is compliant >>> with the "OpenFirmware unit address" concept. (Note that >>> "/pci-bridge@0" only gives away the slot number *on* the extra root >>> bus, not the number of the root bus itself.) For example: >>> >>> /pci@rootbus4/pci-bridge@0/ethernet@2/ethernet-phy@0 >>> >>> would be acceptable. However, I don't know how to implement this in >>> sysbus_get_fw_dev_path(). >> I'll look into it. What is the OpenFirmware unit address" concept ? :) > > Okay, I looked it up again (also rechecked the OVMF parser code) -- in > fact the example I gave would not be preferable. > > * Background: > > For the specification, please see "3.2.1.1 Node names" in > > IEEE Standard for Boot (Initialization Configuration) > Firmware: Core Requirements and Practices > > The notation is > > driver-name@unit-address:device-arguments > > It says (excerpt): > > The /driver name/ field is a sequence of between one and 31 letters, > digits, and punctuation characters from the set “, . _ + - ”. > Uppercase and lowercase characters are distinct. [...] > > [...] > > The /unit address/ field is the text representation of the physical > address of the device within the address space defined by its parent > node. The form of the text representation is bus-dependent. > > Please see the TranslatePciOfwNodes() function in OVMF, for the > "PCI-like" OFW device paths that OVMF currently recognizes -- just > scroll through the function to see the comments: > > https://github.com/tianocore/edk2/blob/master/OvmfPkg/Library/QemuBootOrderLib/QemuBootOrderLib.c#L582 > > * Therefore, the only kind of /unit address/ that OVMF has faced, > exposed by QEMU, is "comma separated list of hexadecimal integers". OVMF > uses the helper function ParseUnitAddressHexList() to parse them. (It is > defined in the same file linked above.) > > It would be preferable to stick with this assumption. Therefore, let me > revise my earlier recommendation, and ask for: > > /pxb@4/pci-bridge@0/ethernet@2/ethernet-phy@0 > ^ > bus_nr (hex, without 0x prefix) > > instead. Providing "pxb" as /driver name/ in the very first OFW node > would be sufficient for OVMF (and I guess for SeaBIOS too) to recognize > the extra root bus. The single hex integer in the /unit address/ of the > first node would identify bus_nr. The rest of the nodes in the OFW > devpath are already recognized by OVMF. > > An alternative would be simply > > /pci@4 > > (quoting just the first node), because I can still tell apart the > numeric ("4") /unit address/ from the "i0cf8" one that identifies the > main root bus. > > Summary: either of the following would be okay: > > /pxb@4 > /pci@4 Thanks a lot for the pointer. I prefer the latest. I'll get to it.
Thanks, Marcel > > Thanks > Laszlo > ------------------------------------------------------------------------------ _______________________________________________ edk2-devel mailing list edk2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/edk2-devel
