OSDev.org

Hello,
Is there any good documentation about ne2000 ?

I have found some but every seem to be different
The ralf brown's ports list doesn't match either

I read this : http://www.osdev.org/osfaq2/index.php/ne2000
But you don't even know how and where to access these registers ?

I have also read the doc made by national semiconductors but in their code snippet they just send some numbers to some ports without any other kind of explanation about the meaning of the numbers

Following some links from the OS DEV FAQ I got to this:

http://www.nondot.org/sabre/os/articles/NetworkingDevices/

yep. The NE2000 is one of the best-documented chip. the PCI clones are basically working like the ISA card except you must use BARs to detect I/O and IRQs involved rather than relying on user input.

I've never heard of "BARs" (except to get drunk, heh) before Pype. Would you mind elaborating a bit on that?

Hi,

Rob wrote:I've never heard of "BARs" (except to get drunk, heh) before Pype. Would you mind elaborating a bit on that?

For auto-configuration, PCI has has a special space called "PCI Configuration Space". This space is accessed using I/O ports. There's 2 different configuration space access mechanisms, but for the most common one you set the address in one I/O port (the bus, device, function and offset) and read or write the data in another I/O port.

Anyway, in each PCI device's configuration space there's normally one or more BARs (or "Base Address Registers"), which can be used to set or find the address (in physical memory or in I/O space) for each resource the card uses.

The BARs could be used for memory mapped I/O, I/O port ranges and/or a boot ROM.

They aren't used for IRQs though - there's different fields in PCI configuration space for that, one for the interrupt line the card uses (which is a fixed/static flag) and another for which IRQ it is routed to (which is set by the BIOS during boot, and only exists as a means to pass this information to operating systems - the hardware itself ignores it).


Cheers,

Brendan

nicely said, Brendan. If you don't mind, i'll paste it into the FAQ page on PCI

Pype.Clicker wrote: nicely said, Brendan.

I second that one! Nicely done.

Brendan wrote: Anyway, in each PCI device's configuration space there's normally one or more BARs (or "Base Address Registers"), which can be used to set or find the address (in physical memory or in I/O space) for each resource the card uses.

The BARs could be used for memory mapped I/O, I/O port ranges and/or a boot ROM.

Technically speaking, that's almost entirely correct. You can't use a BAR for a boot rom, but they are in the configuration space. It isn't officially a BAR though. There are 6 BAR locations that can be used, either set to memory, cached memory or port access. Memory can require only 20 bits to be used (<1M iirc, could be 24bit/16M), 32 bits (<4G) or 64 bits (<16E). A boot rom is a single location that indicates its size and that can be mapped just like a BAR, but that isn't actually a BAR.

Functionally speaking though, you're spot on. I also think that a boot rom read will be honored when the access to the bus is limited but that the BAR's will not respond. This is also not sure, you'd have to check the PCI spec (ch6 of v3 iirc).

Thank you very much
I have just an other question...
In "Writing Drivers for the DP83902 & DP83902" (a pdf) they write during the ISR : These are arguments for the "NICtoPC" function which transfers from the NIC to the memory

I presume "recv_pc_buff" is the buffer where it is going to write data.
But "next_packet" and "packet_length" are unknown

Does somebody know how to detect this ?

NB: as I am not mastering the english langage, I didn't really understand the documentation (which is a different pdf), so I just translated from asm to C

iirc, those informations are stored ahead of the packet itself in the "packet descriptor". And if english is a concern here, i suggest you grab a good dictionnary, print out the documents and take it as an opportunity to improve your language skills by translating it into your native language (that's what i did for several section of the Intel Manuals ) . To what i've seen, NE2K documents are among the bestly written technical guides one might found for a given hardware (really!).

As for the "packet descriptor" format, have a look at page 11 in DP8390Details.pdf

If you eat source code for breakfast, bochs implementations of components can clarify bits which arent made clear by the documents. Also, drivers for existing OS's are good to look at as long as someone has bothered commenting and documenting what they did (this varies wildly across developers even in the same project).

My reference is usually the BSDs (OpenBSD for anything security-related and NetBSD for anything portability related). Its nice to have 3 different approaches to the same OS to compare between each other, and if the license in one is too much to stomach, try the others .

paulbarker wrote: If you eat source code for breakfast, bochs implementations of components can clarify bits which arent made clear by the documents. Also, drivers for existing OS's are good to look at as long as someone has bothered commenting and documenting what they did (this varies wildly across developers even in the same project).

I tend to prefer a mix of bread and code for breakfast with pure code for the rest.