Reading 0's from memory after mmap

Running on a Xilinx Zynq SOC with ARM Cortex. The application I am supporting communicates with the peripherals such as SPI via direct register access with dev/mem, mmap etc...rather than drivers. I know this is not the preferred way to control the peripherals but this is how it is done in the application. I am upgrading from an older Linux kernel V3.x to a later Linux kernel V4.x. When I run the new kernel the mmap operation succeeds but when I read the contents of any device registers I read all 0's. If I run the older kernel I read the expected non-zero values.
If I get to a u-boot prompt and use the md command to read the memory I can see that the register values are correct and non-zero, but if I boot to Linux I read all 0's.
I use the busybox devmem and I get the same zero results. Busybox also does an mmap so that makes sense. Any ideas why mmap/devmem would read 0's?

Kernel 3.x.x --> 4.x.x implies a compatibility break. The way to sort that is painful. You're in for a bit of compiling.
First, have a look at the ChangeLogs to see if you spot a change affecting this. If you can spot one, test it by compiling a kernel before the break, and after it, and test them. You can apply and remove patches with 'patch'(man patch), so you won't have to grab the whole source every time.

If you can't spot it from that, go to the last 3,x kernel, and the 1st 4.x release and test those. Then go forward or back accordingly, testing as you go.

Either way, you'll eventually come to the bit that affects you. Then grok the patch source, look for an option to skirt around it, or halt there. If you have a working kernel, I'd stop updating it, unless you see clear benefits. I wouldn't start patching kernel source with your own code if at all possible. That would be a maintainance nightmare. It's safer to backport drivers. When you have moved on, pity some poor bugger asked to tidy up your code!

Thank you for your reply. Interestingly I can use devmem to query some addresses, so it seems that the functionality is not broken. It's just when I try to use it to address the registers of some peripherals, e.g. IC2, SPI. Would that still be a kernel compatibility thing?

Originally Posted by business_kid Kernel 3.x.x --> 4.x.x implies a compatibility break. The way to sort that is painful. You're in for a bit of compiling. First, have a look at the ChangeLogs to see if you spot a change affecting this. If you can spot one, test it by compiling a kernel before the break, and after it, and test them. You can apply and remove patches with 'patch'(man patch), so you won't have to grab the whole source every time. If you can't spot it from that, go to the last 3,x kernel, and the 1st 4.x release and test those. Then go forward or back accordingly, testing as you go. Either way, you'll eventually come to the bit that affects you. Then grok the patch source, look for an option to skirt around it, or halt there. If you have a working kernel, I'd stop updating it, unless you see clear benefits. I wouldn't start patching kernel source with your own code if at all possible. That would be a maintainance nightmare. It's safer to backport drivers. When you have moved on, pity some poor bugger asked to tidy up your code!

So you replaced the kernel, but not the OS? what about libc.so ? Probably you need to rebuild your app (if that possible).

Originally Posted by pan64 So you replaced the kernel, but not the OS? what about libc.so ? Probably you need to rebuild your app (if that possible).

Thank you for the reply, the OS has been replaced as well as all libraries. The application is running well except for the ability to read from these device registers after mmap.

I still think you need to recompile that app (if possible). From the other hand you may try to use strace to get more info.

Originally Posted by mashman Thank you for your reply. Interestingly I can use devmem to query some addresses, so it seems that the functionality is not broken. It's just when I try to use it to address the registers of some peripherals, e.g. IC2, SPI. Would that still be a kernel compatibility thing?

It depends on if what's malfunctioning matters. If changing up the kernel and nothing else caused it, yes it's a kernel compatibility thing. The procedure to follow is in post #2.

The Linux Runtime Power Management was causing my problem. I disable that and I can communicate with the SPI. Linux was putting the device into a suspended state.
It looks like the power management was added or enhanced in kernel 3.10 so that makes sense.
Thank you

Originally Posted by business_kid Kernel 3.x.x --> 4.x.x implies a compatibility break. The way to sort that is painful. You're in for a bit of compiling. First, have a look at the ChangeLogs to see if you spot a change affecting this. If you can spot one, test it by compiling a kernel before the break, and after it, and test them. You can apply and remove patches with 'patch'(man patch), so you won't have to grab the whole source every time. If you can't spot it from that, go to the last 3,x kernel, and the 1st 4.x release and test those. Then go forward or back accordingly, testing as you go. Either way, you'll eventually come to the bit that affects you. Then grok the patch source, look for an option to skirt around it, or halt there. If you have a working kernel, I'd stop updating it, unless you see clear benefits. I wouldn't start patching kernel source with your own code if at all possible. That would be a maintainance nightmare. It's safer to backport drivers. When you have moved on, pity some poor bugger asked to tidy up your code!