iMX53: EIM access from Linux user space

[timjaacks]

Hello everyone,

I am trying to interface an external SRAM which is connected to the CS0 of the iMX53's EIM. The memory region starts at 0xF0000000. I want to access it from Linux as an MTD device using the plat-ram driver. On a previous platform running the iMX35, this worked without any problems. However, on the iMX53 there seems to be an access restriction. While I can read and write the memory from a kernel driver directly (using ioremap, __raw_writel and __raw_readl), I can only read the memory from user space (cat /dev/mtd0). Writing to the memory is not possible (echo "test" > /dev/mtd0).

I cannot find the place where to enable access from user space. There is a bit in the EIM (GCR1, b19) which should be responsible for this, but it is already cleared, i.e. user space access is allowed. There is also a write-protect bit (b27), which is cleared as well, i.e. not write-protected. I also checked the AIPS registers (OPACR) where permissions for several peripherals can be set, but these get correctly initialized with zeros. The clocks cannot be the reason either, I tested the access with all of the clocks running. I have no idea why the access does not work from the user space. Does anyone have a clue?

Best regards,

Tim

[fushi_peng]

timjaacks  is there any MTD DEBUG  log for write file .

And is you use plat-ram driver , what is your implement of platform device's set rw/ro control .

Could you check mtd->flags is MTD_WRITEABLE.

[timjaacks]

Thanks very much for your reply. I haven't implemented the rw/ro control function, since I do not want the memory to be read-only. The mtd->flags have MTD_WRITABLE set.

However, in the meantime I managed to get the memory writable. I still don't understand why this works, but it does: The function mapram_write in map_ram.c, which is responsible for executing the write-access to the MTD RAM device, uses the macro memcpy_toio for write access, which places a __force before the target address. If I replace the memcpy_toio with a simple memcpy, everything works fine. So in the end the whole problem obviously did not have anything to do with kernel/user space acccess restrictions. I don't know what this __force does, but at least it works now and that's all I wanted.