Broadcom MMIO base address

[kemosparc]

Hi,

I am trying to configure the Broadcom Netxtream II 57xx network card on an IBM x3650 M2.

The problem I have is in detecting the Memory base address of the card.

When I read the PCI device header I have the following:

Device ID: 0x164C
Vendor ID: 0x14E4
Header: 0x0
BAR0: 0xce0d -> 0b1100111000001101
Memory Space Indicator: I/O
Type: Anywhere in 64-bit Address (How ??)
Prefetchable: Enabled
BAR1: 0xf000ff54: 0b11110000000000001111111101010100
Memory Space Indicator: Memory
Type: Anywhere in 64-bit Address
Prefetchable: Enabled
Intr: 0xB


The values in the BAR does not work with me, the card does not respond to the drivers command when I issue them to the memory space I detected in BAR1.

I did something sneaky; I started up Linux on the same machine and issued lspci -vvv and I got the memory base address to be 0xce000000.

I hard wired this value into my code and I loaded my OS and the card started responding to the driver.

My problem is that I don't know how Linux got the 0xce000000 address.

Bar0 looks close to the address but it is 32-bit.

The same PCI header code works with the Intel e1000/e network cards with no problems, and detect the addresses correctly.

Any ideas ?

Thanks,
Karim.

[Combuster]

BAR1: 0xf000ff54: 0b11110000000000001111111101010100

This reads as if you were dereferencing a null pointer (looks like IVT contents).

[kemosparc]

I don't understand your reply !

[Combuster]

Am I now supposed to ask 100 questions to figure out why you don't understand?

[Candy]

Your results smell like you're reading regular memory space (ie, by using mov or reading from a pointer) rather than PCI config space (using port 0xCFC / 0xCF8).

Please read the Wiki on PCI and reading config space.

[iansjack]

Your results smell like you're reading regular memory space (ie, by using mov or reading from a pointer) rather than PCI config space (using port 0xCFC / 0xCF8).

Please read the Wiki on PCI and reading config space.

So how come the Vendor and Device Ids are correctly read?

[Candy]

So how come the Vendor and Device Ids are correctly read?

No idea.

Also, given that I can't see any pci config space reading code, I have no way to find out either. This leaves Combuster and myself to use only our GlassBall (tm) method of debugging that while usually quite OK, may be off in some cases.

0xF000FF54 is too familiar though - that's what my own null pointers also read.

[SpyderTL]

Double check your BAR1 code (and const values). Or you can post your code and we'll take a look.

[iansjack]

So how come the Vendor and Device Ids are correctly read?

No idea.

Also, given that I can't see any pci config space reading code, I have no way to find out either. This leaves Combuster and myself to use only our GlassBall (tm) method of debugging that while usually quite OK, may be off in some cases.

0xF000FF54 is too familiar though - that's what my own null pointers also read.

It was something of a rhetorical question. The coincidence of both Ids being correct if totally the wrong method of reading them was being used is too great to be countenanced. I don't think you need to invoke a crystal ball to see that. And the OP states that he has been successful with an E1000 driver, so it's reasonable to suppose that he has some idea of what he is doing.

I'm sure it is true that a null pointer is being read somewhere, but let's stick to the realms of the possible.