On 06/10/15 13:55, Marcel Apfelbaum wrote: > 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.
Indeed, the current initial node that is produced for the nonzero root buses is "/pci", so the "only" part you need to append to them is "@bus_nr". :) Thanks! Laszlo > I'll get to it. > > Thanks, > Marcel > >> >> Thanks >> Laszlo >> >
