What does it mean when a PCI device's BARs are all 0 despite device supporting MMIO?

[Theodoros]

Hi,
I am trying to develop on real hardware. I am in real mode and reading from device 27AC-8086 (it has header type 0). When I read from it, it has all its BARs to 0. The value in the COMMAND field (register 0x4) is 0x0006, which indicates its MMIO. Why are they 0? should I define them myself? The way I do it after I get the bus/device/function value in eax is:

Code: Select all

mov al,010h  ; first BAR but same happens for up to BAR 5, 0x24
mov dx,0CF8h
out dx,eax
mov dx,0CFCh
in eax,dx      ; I get 0 here

Regards,

[Octocontrabass]

I am in real mode

Why are you doing this in real mode?

Why are they 0?

That device doesn't use BARs for its MMIO. It can do that because it's part of the chipset. The firmware knows how to deal with it.

should I define them myself?

You can't. Since it doesn't use BARs, they're read-only.

[Theodoros]

Thanks for the reply.

Why are you doing this in real mode?

It's before I load my kernel, I get the memory map and mmio addresses so I know where (not) to load kernel.

That device doesn't use BARs for its MMIO. It can do that because it's part of the chipset. The firmware knows how to deal with it.

Is there a way to know where it is mapped to? Thanks.

[Octocontrabass]

It's before I load my kernel, I get the memory map and mmio addresses so I know where (not) to load kernel.

You only need the INT 0x15 EAX=0xE820 memory map to load your kernel. Everything else you can do after your kernel is running.

Is there a way to know where it is mapped to?

Its MMIO addresses will be reserved in either the INT 0x15 EAX=0xE820 memory map or in ACPI. You might not know which device the reserved addresses belong to, but it doesn't matter since you won't be accessing it anyway.