Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Hello all,
I'm working on OS development for my school, and I plan to integrate basic Ethernet features. I wrote a PCI driver for bus enumeration and I detect 82546EB card successfully. Now, I try to read BAR0 in order to know the address where card registers are mapped. BAR0 is MMIO (LSB is zero), and I read the value 0xF6EC0000 (depends on material). Then, I try to read a register from this address but I got a page fault exception. Maybe I missed something, in this case can you tell me please?
I already took a look at http://wiki.osdev.org/Intel_8254x and at Intel official documentation for the cards family, but my code doesn't work when reading/writing..
Could I for example change the address in BAR0 ? Maybe it could address the problem...?
If you have any additional resources, don't hesitate, give me them
Hardware always works with physical addresses (at least in a simplified view). So you need to create a mapping in your page tables that maps the physical address that you read from the BAR to a virtual address that you can use to access the registers.
Hello all,
Do you have more information about 8254x card ? I have difficulties by reading official developer manual, I don't know how to start.
Do you have additional resources?
Maksman wrote:Hello all,
Do you have more information about 8254x card ? I have difficulties by reading official developer manual, I don't know how to start.
Do you have additional resources?
Chapters 3.3, 3.4 explain in general terms, then details how transmitting works. It includes a description of the design principles on which a modern network controller is implemented. Within that portion of the document I found the necessary details to design a transmit loop, chapter 13 tells me what the values of the various constants are, so I don't see any problem.
Which is where the "required knowledge" forum rule comes into play: The physical resources we have are the same as yours: the chipset manuals, and various kernels and source trees where there are existing drivers for reference. The latter of which is only really useful for comparison with your existing work. Our real assets is the ability to properly deal with the few resources we do have. I don't expect everyone to be able to write a driver without any documentation, but it is the level you'll have to strive for:
1. Problem
2. Divide and conquer
3. Profit
Now show us what you have done and not entertain us with merely the fact that you are haven't done step 3 (that's the most boring fact ever).
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]
