0
votes

I am working on an x86-based 64-bit system. The device in question is an eMMC controller, that has 64-bit memory-mapped regions. I am trying to access first region through the address pointed to by the BAR, but I can only read 0xffffffff's (0xffffffff_ffffffff for 64-bit read). I have tried both using /dev/mem by explicitly using the BAR and pciemem to read through /sys/devices/pcie/xxxxxx/resource0 and get same results.

If I use same logic on other PCIe devices (e.g. USB controller), I can read the memory without an issue. I have gone through the kernel source code and found out that both device drivers are using similar request_region calls, with exclusive flag = 0 (to allow user-space access to PCIe memory). Still, I have this problem only with the eMMC controller. Opening the resource0 or mmapping /dev/mem doesn't throw any error either. I need to find out why I am seeing 0xffffffff's and a way to fix this.

Another important piece of information is that I can access these registers from the bootloader. They are not accessible after Linux boots up, so my guess is that it has to do with memory access permissions, instead of HW locks to read certain registers.

1
Is the BAR enabled (usually is the lower bit)? Is the device enabled (It's a bit in the command register)? Is the device powered up? It's impossible to say what's wrong but if you can access it with a custom bootloader than it's just a configuration/PM problem.Margaret Bloom
Just as a confirmation, is your bit 0 (If memory type is IO) and bit 1 (If memory type is MEM) in Command register set? I know this can be a silly question but still worth checking once. Also you need to check the same bits in all the switches in the path to the EP.Shaibal
@Shaibal already checked. Turned out to be PM issue. Linux kernel was putting the device to sleep.Hamzahfrq
@MargaretBloom thanks for the hint!Hamzahfrq
@Hamzahfrq Just out of curiosity, which device state the kernel was putting the device into?Shaibal

1 Answers

0
votes

The issue was resolved. The devie under test was in suspended state which was confirmed by

cat /sys/devices/pcie../.../power/runtime_status

Following command brought the devie to ON state, after which the memory space was functioning normally:

cat "on" /sys/devices/pcie../.../power/runtime_status