Page 1 of 1

Memory/IO addressing issue.

Posted: Tue Aug 07, 2007 9:37 pm
by 01000101
I finished dealing with my PCI configure space and read all the information I needed.

Now that I have read the IO BAR's for my network cards, I am having trouble reading from that space in memory. There for some reason is little help out there for what to do about STARTING driver development, and the few answers that are out there just point to the linux source.

How do I read from the IO address area?
say my base address is 0x6601, would I read it like this:

Code: Select all

unsigned short *IOmem;
unsigned char get_byte;
IOmem = (unsigned short *)0x6601;  
get_byte = *IOmem;
??

in my head, that lets get_byte equal the byte at memory location 'base_addr'.

Re: Memory/IO addressing issue.

Posted: Tue Aug 07, 2007 10:27 pm
by Brendan
Hi,
01000101 wrote:How do I read from the IO address area?
say my base address is 0x6601, would I read it like this:

Code: Select all

unsigned short *IOmem;
unsigned char get_byte;
IOmem = (unsigned short *)0x6601;  
get_byte = *IOmem;
No - if the lowest bit in the BAR is set, then you need to use I/O ports. For example, you'd want something like:

Code: Select all

    mov dx,0x6601 & 0xFFFC
    in eax,dx
And not something like:

Code: Select all

    mov edx,0x6601
    mov eax,[edx]
Cheers,

Brendan

Posted: Wed Aug 08, 2007 12:36 pm
by 01000101
so, if i understand that correctly, I should be able to do something along the lines of :

Code: Select all

unsigned char rtl_revision;
rtl_revision = inportb(IObase + 0x5E);   
with the assumption that my IObase is the IO base address of a PCI device space (RTL8139D), and 0x5E would then be the offset to read the revision ID.

Posted: Wed Aug 08, 2007 7:25 pm
by exkor
If port(register) = BAR+5eh of rtl8139D returns revision on reads then you are right.
If you want revision from PCI configuration space then it has offset 8h and no BARs involved.

Posted: Wed Aug 08, 2007 7:33 pm
by 01000101
yea, that is what I wanted, the non-config_space way.
I'm having a hard time getting reads from IO space provided by device BARs. Is there a sure way to see if the BAR's being read are correct?

Posted: Wed Aug 08, 2007 8:27 pm
by exkor
dont know, but you can print this hex # on the screen, last bit has to be 1 and you need to clear(=0) last byte before doing 'out' & 'in'
Most likely address has to be 16bit number not more.

You can try other offset other than 5eh, and see if reading status for instance makes sense.

Another thought: see which address(BAR) linux or windows have. Not sure how to to that. In Win you go to Device Manager -> Properties of netw adapter -> Resources Tab.
As far as I know WinXP doesn't change any addresses.

I'm not familiar with this card but maybe you need to check Command word of PCI conf space and ensure that BustMastering, IO and maybe other bits are set.

Posted: Wed Aug 08, 2007 8:48 pm
by 01000101
Thanks to all of you,
I ended up getting it working.

I was able to read a successful revision ID and other useful data and it all matched up with the datasheets on them.

yay, now on to actually writing the device driver... *googles rtl8139d*

Pe@cE
and thanks again.

Posted: Thu Aug 09, 2007 1:55 am
by 01000101
I just thought of this, but, someone should write a step-by-step tutorial on how to write network device drivers, or something similar.

I've gone to places like osdever.net, and even with their large tutorial/document sections, they hardly even touch on device driver writing, and usually when someone does, they refer to linux module coding...

Posted: Thu Aug 09, 2007 2:46 am
by pcmattman
01000101 wrote:I've gone to places like osdever.net, and even with their large tutorial/document sections, they hardly even touch on device driver writing, and usually when someone does, they refer to linux module coding...
That's because drivers are never the same on different operating systems. Each OS handles drivers differently.

If you do want to look at a very basic NE2k/rtl8139d driver, try here or here (both are the same, with some basic differences).

Ignore the 3C9xC stuff in the latter link...