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
