Hi all: Am 25.05.09 23:47 schrieb(en) Wolfram Sang:
A word or long copy of 0x0055aaff with U-Boot works fine, but a byte copy filled the whole ram with 0x0000aaaa. The reason is apparently that the chip is attached to the local bus in 16-bit mode, which is incompatible with byte accesses. However, the Local Bus doesn't provide "low byte" or "high byte" indicators in non-muxed mode. How is this supposed to work then?Hmm, as I feared... we were bitten by this, too: http://thread.gmane.org/gmane.linux.drivers.mtd/21521 There is no generic solution yet :(
At least for my case, I could completely (afaict) solve the problem, i.e. I can now access the 16-bit nv ram as mtd char and block device, the latter with jffs2. I would like to submit a patch, but I actually don't know exactly how...
The solution itself is quite simple: add a new method which works like memcpy_toio, but respects the fact that no single bytes may be written (reading through memcpy_fromio works painlessly). I think this function should go into arch/powerpc/kernel/io.c, depending upon CONFIG_PPC_MPC52xx, and the prototype into arch/powerpc/include/asm/io.h, right?
The harder part is to actually call this function properly. I now call it in include/linux/mtd/map.h, function inline_map_copy_to(), if CONFIG_PPC_MPC52xx is defined and if map->bankwidth is 2. However, is it acceptable to have a processor-type dependency in a top-level include file? Or what would be the proper way to implement it?
Thanks, Albrecht.
pgpuQKY5FoMhB.pgp
Description: PGP signature
_______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
