You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
virtio is described to the system via FDT as plain old virtio nodes, which need to be probed for their types. inetboot currently rewrites a few of these based on what it knows, rather than discovering anything.
One of two/three/four things needs to happen:
inetboot rewrites things based on probing and knowledge of what compatible strings are needed (still yucky, doesn't solve the ACPI case)
We create a virtio nexus driver which probes the firmware for virtio devices, does the necessary discovery and fires up appropriate sub-devices, or...
Each virtio device gets a nexus driver (instantiated via FDT/ACPI), which probes the device and has a (single?) child device implementing the desired functionality (this is probably the best approach, but I don't know that it will definitely work)
Assuming ACPI also just exposes virtio nodes with nothing helpful in the _CID list (need to check this), then approach 3 is by far the cleanest way for us to do this. In ACPI the HID for these should be LNRO0005. They should have ACPI_RESOURCE_TYPE_FIXED_MEMORY32 and ACPI_RESOURCE_TYPE_EXTENDED_IRQ resources. This should give enough information to figure out the device type.
The text was updated successfully, but these errors were encountered:
virtio
is described to the system via FDT as plain oldvirtio
nodes, which need to be probed for their types.inetboot
currently rewrites a few of these based on what it knows, rather than discovering anything.One of two/three/four things needs to happen:
inetboot
rewrites things based on probing and knowledge of what compatible strings are needed (still yucky, doesn't solve the ACPI case)virtio
nexus driver which probes the firmware forvirtio
devices, does the necessary discovery and fires up appropriate sub-devices, or...virtio
device gets a nexus driver (instantiated via FDT/ACPI), which probes the device and has a (single?) child device implementing the desired functionality (this is probably the best approach, but I don't know that it will definitely work)Assuming ACPI also just exposes
virtio
nodes with nothing helpful in the _CID list (need to check this), then approach 3 is by far the cleanest way for us to do this. In ACPI the HID for these should beLNRO0005
. They should haveACPI_RESOURCE_TYPE_FIXED_MEMORY32
andACPI_RESOURCE_TYPE_EXTENDED_IRQ
resources. This should give enough information to figure out the device type.The text was updated successfully, but these errors were encountered: