PCI - question regarding Base Address Register in this code

[GraveMind]

Hello!

Long time lurker finally has a question . I have been reading the source for the well documented Bare Metal 64 bit OS and I have a question over the following segment:

Code: Select all

; Grab the Base I/O Address of the device
mov dl, 0x04				; BAR0
call os_pci_read_reg

from this file in Google code browser: http://code.google.com/p/baremetal/sour ... tl8169.asm

Am I correct in thinking that the 4 that gets shifted left to 16 in the PCI driver means that if I wanted say the SubsystemID (header type 00) I could use the value 11 and extract the high half of eax on its return? If so I am finally understanding the PCI!!

Cheers, J

[Combuster]

There are two ways of indexing, neither of which is a standard
- use byte offsets. This way you can fill in the addresses listed by the spec, but you have to be careful that unaligned offsets are generally not going to do what you want, or you can perform the register offsets from within the accessor instead of duplicating it in all relevant cases. I use this for legibility reasons and the fact that half of the PCI accesses are actually done to non-dword fields.
- use dword offsets. This way the input is always valid, but you have to manually shift it by 2 relative to the specification and filter the correct bytes out of the output. Based on the description, this is what the referenced implementation does.

So in your case, offset 11 is the 4th byte in dword 3, so you'd pass 3 in dl, and then shift the answer right by 24 bits to get the field in question.

[GraveMind]

So in your case, offset 11 is the 4th byte in dword 3, so you'd pass 3 in dl, and then shift the answer right by 24 bits to get the field in question.

I think my brain melted a tiny bit at this point... (may have been mistake earlier meaning 0x11h)

So by passing 3 into dl, the driver code in this index method shifts it left 2 places giving it the value of 12 or the Revision ID register. Then the return due to dword size also includes BIST, Header type and Latency Time, that's why you shift right 24 bits after. Giving Eax the final value of the Revision ID.

Also thanks for clearing up index methods, just so happened to be my first code analysis of PCI inner workings.

[Kieran]

This is the joy of PCI. Plenty of >>, << and &&.

For legabillity it could be worth creating function such as:

Code: Select all

byte ExtractByte(dword Value, unsigned Byte)

[Combuster]

Or implement b/w/d versions for PCI reads, like this.

[GraveMind]

Great, thanks for the help!

Now I can get my head around the NIC (its RTL 8139).

May then be able to actually begin work on my network bootloader ^___^

J

[shikhin]

Hi,

Now I can get my head around the NIC (its RTL 8139).

May then be able to actually begin work on my network bootloader ^___^

I'm pretty sure you're going about the wrong way handling your "network bootloader". To make remote booting easier, Intel and several other companies made a pre-boot environment, or the PXE. The PXE simply runs before boot, and runs the NBP (network bootstrap program - your bootloader), providing it with some boot-time services.

The firmware on the client tries to locate a PXE redirection service on the network (Proxy DHCP) in order to receive information about available PXE boot servers. After parsing the answer, the firmware will ask an appropriate boot server for the file path of a network bootstrap program (NBP), download it into the computer's random-access memory (RAM) using TFTP, possibly verify it, and finally execute it. If only one NBP is used among all PXE clients it could be specified using BOOTP without any need of a proxy DHCP, but a TFTP boot server is still required.

Your NBP would use the PXE and it's TFTP services to load (a) file(s) from the server, and then execute your stage 2.

Yeah, that was all very poorly worded. You might want to take a look at http://wiki.osdev.org/PXE

Regards,
Shikhin

[GraveMind]

Hi,

Now I can get my head around the NIC (its RTL 8139).

May then be able to actually begin work on my network bootloader ^___^

I'm pretty sure you're going about the wrong way handling your "network bootloader". To make remote booting easier, Intel and several other companies made a pre-boot environment, or the PXE. The PXE simply runs before boot, and runs the NBP (network bootstrap program - your bootloader), providing it with some boot-time services.

The firmware on the client tries to locate a PXE redirection service on the network (Proxy DHCP) in order to receive information about available PXE boot servers. After parsing the answer, the firmware will ask an appropriate boot server for the file path of a network bootstrap program (NBP), download it into the computer's random-access memory (RAM) using TFTP, possibly verify it, and finally execute it. If only one NBP is used among all PXE clients it could be specified using BOOTP without any need of a proxy DHCP, but a TFTP boot server is still required.

Your NBP would use the PXE and it's TFTP services to load (a) file(s) from the server, and then execute your stage 2.

Yeah, that was all very poorly worded. You might want to take a look at http://wiki.osdev.org/PXE

Regards,
Shikhin

Sounds more convenient, I will investigate, thanks!