OSDev.org

OK found it in the dev guide for broadcom, we have to set command register to enable i/o or memory access

Thanks

aloktiagi wrote:OK found it in the dev guide for broadcom, we have to set command register to enable i/o or memory access

Thanks

yep, that's what I mean with bit 0 and bit 1 of the command register.
You should also note that, when trying to figure out the io base and memory base, you will first have to distinguish whether the address in BARn is the io base or memory base. In my OS, im looping through BAR0 - BAR5 and check the first bit of the BAR. If it is set to 1 its an io base, otherwise its a memory base.

It's actually described quite good in the wiki, but here's still a code snipped how I'm discovering the bases in my os: Note that the code snipped above does not check if the memory base is 32-bit or 64-bit. Neither does it work very well when a device has more than one io base or memory base. So you should also check for that if you want a proper implementation.

Hi

I got the BAR0 as F8000004. So my memory base address is F8000000. So using this address can i now access NICs registers by adding offsets to this memory base address, for eg

not quite.. you have to use the io base instead of the memory base
but aside of that its correct to use inb(iobase+offset)

Hi,

Ok but i found only a memory base address i.e BAR[0] there was no other address in the other BAR registers. So where is the I/O base register value?

oops, sorry I thought we're talking about a realtek nic here.
According to broadcom's specs, the registers are located in the memory address space (offset 0x400 - 0x8000 [see page 32 of the manual]), so membase+offset is correct.

I got the BAR0 as F8000004. So my memory base address is F8000000.

Now when i do something like this
Here all that i get for register vlaues are FFFF and don't see any MAC addresses which should be present at offset ox410!!

aloktiagi wrote:

Code: Select all

        addr = F8000000;

Doesn't this cause a compiler error?
Try 0xf8000000 instead.

I've just had a look at the manual and the offset you're using isn't correct. According to the manual the device id registers are located at offset 0x2 (see page 152, NetXtreme II Programmer's Reference Guide)

@aloktiagi
You can't use IO instructions on memory. They're two completely independent address spaces; you just use a normal pointer at (membase + offset). So you can dereference it at whatever address you want, use memcpy or whatever to transfer buffers, etc. etc. That ease of use, along with the fact that memory accesses are faster and have a larger address space, is why you're unlikely to find IO ports used for non-legacy purposes.

@selenic
Yes thats what i thought,but then mkruk told using inb for memory addresses was ok .
So i'll use something like void *memcpy(void *dest, const void *src, size_t n); to transfer register data at F8000000

aloktiagi wrote:@selenic
Yes thats what i thought,but then mkruk told using inb for memory addresses was ok .
So i'll use something like void *memcpy(void *dest, const void *src, size_t n); to transfer register data at F8000000

This is enough: If you replace char with short or int, you get all register sizes .

@eddyb

I used your method

char reg_value = *((char*)0xF8000000);

So i should get the value of the register at 0xF8000000 in reg_value?

But i'm getting a seg fault . Any idea why?

Could someone comment on the previous post!!

Of course nobody has a clue. The intel processor doesn't do segfaults. It's a unix thing.

So if I have to trust your description, you're trying to access hardware from an existing OS. Which is just stupid because the kernel won't allow it.

And it is stupid to not have anticipated this from my previous posts