[Solved/Patch Question] Weird 5200/mtd-ram problem

[Albrecht Dreß]

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20090527/5c48d239/attachment.pgp>