Question about setup_data in bootloader

[JulianKnodt]

Hi,

thanks again for the bootloader, I appreciate the work that has gone into abstracting away all this complexity.

I'm looking to implement a VirtIO block-device driver in my kernel, and for that I was doing some reading here, and it describes the setup_data in the first boot-sector, which is necessary for accessing the device-tree for getting the physical address of the device. I was wondering if this was currently exposed in the BootInfo that's passed to the main function, or if not, if it would be possible for me to add it w/ some guidance?

Thanks!

[ethindp]

I do not believe it is. However, you should not need this unless your on an architecture that doesn't have PCIe. VirtIO devices appear on the PCIe bus with a vendor ID of 0x1AF4 and a device ID of 0x1000-0x103F. The type of device can be determined by analyzing the subsystem ID field: 0x01 is a network card, 0x02 is a block device, 0x03 is a console, 0x04 is an entropy source, 0x05 is a memory balloon, 0x06 is I/O memory, 0x07 is RPMSG, 0x08 is a SCSI host, 0x09 is a 9P transport, and 0x10 is a MAC802.11 WLAN, if memory serves. But you should, when in doubt, refer to the VirtIO specification: https://docs.oasis-open.org/virtio/virtio/v1.1/virtio-v1.1.html

On 3/26/21, Julian Knodt @.***> wrote:

Hi,

thanks again for the bootloader, I appreciate the work that has gone into abstracting away all this complexity.

I'm looking to implement a VirtIO block-device driver in my kernel, and for that I was doing some reading here, and it describes the setup_data in the first boot-sector, which is necessary for accessing the device-tree for getting the physical address of the device. I was wondering if this was currently exposed in the BootInfo that's passed to the main function, or if not, if it would be possible for me to add it w/ some guidance?

Thanks!

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/rust-osdev/bootloader/issues/143

-- Signed, Ethin D. Probst

[JulianKnodt]

If there is an alternative way to access devices, that also makes sense. From what you say, it's still not clear to me how to read from the PCIe though. Is this some memory-mapped region, and if so what address is it, or is it something else?

[ethindp]

The PCIe region is an internal memory-mapped region that allows an operating system to enumerate hardware within the machine. Not all processor architectures implement it; for example, the Raspberry PI is more likely to give you what is known as a device tree blob, or DTB, which eliminates the device enumeration step entirely. However, the x86 architecture has no such system, so the firmware is free to place hardware at whatever memory addresses it pleases. PCI enumeration is the process of asking the system where devices are in memory (either in memory-mapped I/O or in port I/O) so that you may configure them and interact with them. There are three ways of doing this, all of which are explained in the OSDev article on PCI: https://wiki.osdev.org/PCI Accessing the PCIe bus (which is an extended version of PCI and which is what modern systems use) requires ACPI. The acpi crate will give you these PCIe regions; it is up to you to scan them and load them into your internal device tree, however you might do that. More here: https://wiki.osdev.org/PCI_Express

On 3/27/21, Julian Knodt @.***> wrote:

If there is an alternative way to access devices, that also makes sense. From what you say, it's still not clear to me how to read from the PCIe though. Is this some memory-mapped region, and if so what address is it, or is it something else?

-- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/rust-osdev/bootloader/issues/143#issuecomment-808656475

-- Signed, Ethin D. Probst