Weird 5200/mtd-ram problem

Weird 5200/mtd-ram problem

[Albrecht Dreß]

Hi all,

I ran into a weird problem when I tried to access a static (NV) ram attache=
d to the localbus of a '5200 using Wolfram's mtd-ram OF driver (on a stock =
2.6.29.1 kernel).  The 512k ram chip is connected in 16-bit mode to cs1.  t=
he of entry reads

nvram@1,0 {
=09compatible =3D "mtd-ram";
=09reg =3D <1 0x0 0x00080000>;      // 512 kB
=09bank-width =3D <2>;
=09device-width =3D <2>;
=09#size-cells =3D <1>;
=09#address-cells =3D <1>;
=09};

For the test I created a "pattern file" which is filled with the unsigned l=
ong 0x0055aaff.  Using the Abatron BDI3000, I can write the pattern file to=
 the ram and re-read it without problems.  The same applies to u-boot (writ=
e ram via tftp, dump contents).

In Linux, when I write the file to /dev/mtdx, the last dword of each block =
is broken, e.g. when running "dd if=3Dpattern of=3D/dev/mtd5 bs=3D512" the =
dword's at offset 0x1fc, 0x3fc, ... are 0x0000aaaa (instead of 0x0055aaff),=
 if I use bs=3D1024 the dwords at 0x3fc, 0x7fc, ... show this value, if I u=
se bs=3D4096 the dword at 0xffc shows this value, etc.  I looked at the CS/=
WR lines with a scope, and I couldn't see anything special.  The timing sho=
uld be fine, as u-boot uses the same as Linux.

Any idea what goes wrong here?  I guessed I missed something in the LPB set=
up...

Thanks in advance,
Albrecht.

Arcor.de Gaming Area - kostenfrei daddeln bis der Arzt kommt!
Jetzt checken und aus =FCber 80 Spielen w=E4hlen!
http://www.arcor.de/footer-gaming/

Re: Weird 5200/mtd-ram problem

[Gary Thomas]

Albrecht Dreß wrote:
> Hi all,
> 
> I ran into a weird problem when I tried to access a static (NV) ram attached to the localbus of a '5200 using Wolfram's mtd-ram OF driver (on a stock 2.6.29.1 kernel).  The 512k ram chip is connected in 16-bit mode to cs1.  the of entry reads
> 
> nvram@1,0 {
> 	compatible = "mtd-ram";
> 	reg = <1 0x0 0x00080000>;      // 512 kB
> 	bank-width = <2>;
> 	device-width = <2>;
> 	#size-cells = <1>;
> 	#address-cells = <1>;
> 	};
> 
> For the test I created a "pattern file" which is filled with the unsigned long 0x0055aaff.  Using the Abatron BDI3000, I can write the pattern file to the ram and re-read it without problems.  The same applies to u-boot (write ram via tftp, dump contents).
> 
> In Linux, when I write the file to /dev/mtdx, the last dword of each block is broken, e.g. when running "dd if=pattern of=/dev/mtd5 bs=512" the dword's at offset 0x1fc, 0x3fc, ... are 0x0000aaaa (instead of 0x0055aaff), if I use bs=1024 the dwords at 0x3fc, 0x7fc, ... show this value, if I use bs=4096 the dword at 0xffc shows this value, etc.  I looked at the CS/WR lines with a scope, and I couldn't see anything special.  The timing should be fine, as u-boot uses the same as Linux.
> 
> Any idea what goes wrong here?  I guessed I missed something in the LPB setup...

Check your cache setup - the BDI is most certainly not accessing
this via the Data cache whereas Linux probably will be.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Weird 5200/mtd-ram problem

[Albrecht Dreß]

[-- Attachment #1: Type: text/plain, Size: 1150 bytes --]

Am 20.05.09 16:23 schrieb(en) Gary Thomas:
> > In Linux, when I write the file to /dev/mtdx, the last dword of  
> each block is broken, e.g. when running "dd if=pattern of=/dev/mtd5  
> bs=512" the dword's at offset 0x1fc, 0x3fc, ... are 0x0000aaaa  
> (instead of 0x0055aaff), if I use bs=1024 the dwords at 0x3fc, 0x7fc,  
> ... show this value, if I use bs=4096 the dword at 0xffc shows this  
> value, etc.  I looked at the CS/WR lines with a scope, and I couldn't  
> see anything special.  The timing should be fine, as u-boot uses the  
> same as Linux.
> >
> > Any idea what goes wrong here?  I guessed I missed something in the  
> LPB setup...
> 
> Check your cache setup - the BDI is most certainly not accessing this  
> via the Data cache whereas Linux probably will be.

Hmm, yes - I didn't touch the vanilla Lite5200B Linux setup there,  
which has a flash chip at cs1...

If it is really a cache problem (I'm away now from my test board) -  
isn't a sync sufficient after doing the copy to the external ram  
(lpb/cs1)?  What is the proper approach for devices attached to the  
localbus?

Thanks, Albrecht.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Weird 5200/mtd-ram problem

[Gary Thomas]

Albrecht Dreß wrote:
> Am 20.05.09 16:23 schrieb(en) Gary Thomas:
>> > In Linux, when I write the file to /dev/mtdx, the last dword of each
>> block is broken, e.g. when running "dd if=pattern of=/dev/mtd5 bs=512"
>> the dword's at offset 0x1fc, 0x3fc, ... are 0x0000aaaa (instead of
>> 0x0055aaff), if I use bs=1024 the dwords at 0x3fc, 0x7fc, ... show
>> this value, if I use bs=4096 the dword at 0xffc shows this value,
>> etc.  I looked at the CS/WR lines with a scope, and I couldn't see
>> anything special.  The timing should be fine, as u-boot uses the same
>> as Linux.
>> >
>> > Any idea what goes wrong here?  I guessed I missed something in the
>> LPB setup...
>>
>> Check your cache setup - the BDI is most certainly not accessing this
>> via the Data cache whereas Linux probably will be.
> 
> Hmm, yes - I didn't touch the vanilla Lite5200B Linux setup there, which
> has a flash chip at cs1...
> 
> If it is really a cache problem (I'm away now from my test board) -
> isn't a sync sufficient after doing the copy to the external ram
> (lpb/cs1)?  What is the proper approach for devices attached to the
> localbus?

Based on the behaviour, it's probably a timing problem with
multi-beat transfers.  When the PowerPC does cache flushes,
the chip activity is very different than the single beat accesses
used by the BDI.

Try to access this without using the cache.  If it works properly
then you'll need to look at the timing setup (the local bus registers)
to see why it fails with the multi-beat accesses.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Weird 5200/mtd-ram problem

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

> For the test I created a "pattern file" which is filled with the unsigned
> long 0x0055aaff.  Using the Abatron BDI3000, I can write the pattern file to
> the ram and re-read it without problems.  The same applies to u-boot (write
> ram via tftp, dump contents).

Does it work with byte, word and long accesses?

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: Weird 5200/mtd-ram problem

[Albrecht Dreß]

[-- Attachment #1: Type: text/plain, Size: 1333 bytes --]

Hi Gary & Wolfram:

Thanks for youre help, and sorry for the late reply - I've been on  
vacation...

Am 20.05.09 21:59 schrieb(en) Gary Thomas:
> Try to access this without using the cache.

Unfortunately, this is not cache related - I switched the dcache off  
completely - same results.

Am 20.05.09 22:01 schrieb(en) Wolfram Sang:
> Does it work with byte, word and long accesses?

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?

For the mtd driver, I tracked down the problem via mapram_write() (in  
drivers/mtd/chips/map_ram.c) down to the call of map_copy_to() which is  
actually inline_map_copy_to(), which in turn calls memcpy_toio().  I  
*think* this is _memcpy_toio() in arch/powerpc/kernel/io.c, which  
copies all data in long (4-byte) moves, except for the last 4 bytes.  I  
guess I have to write my own copy function which respects the fact that  
byte writes actually must be a read word - modify - write word  
sequence, right?

Thanks, Albrecht.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: Weird 5200/mtd-ram problem

[Wolfgang Denk]

Dear Albrecht =?iso-8859-1?b?RHJl3w==?=,

In message <1243273283.3328.0@antares> you wrote:
>
> Thanks for youre help, and sorry for the late reply - I've been on  
> vacation...

Hally you...

> For the mtd driver, I tracked down the problem via mapram_write() (in  
> drivers/mtd/chips/map_ram.c) down to the call of map_copy_to() which is  
> actually inline_map_copy_to(), which in turn calls memcpy_toio().  I  
> *think* this is _memcpy_toio() in arch/powerpc/kernel/io.c, which  
> copies all data in long (4-byte) moves, except for the last 4 bytes.  I  
> guess I have to write my own copy function which respects the fact that  
> byte writes actually must be a read word - modify - write word  
> sequence, right?

I remember some nasty problems with memcpy*(),  especially  with  un-
aligned  accesses  over the LocalPlus Bus. I'm not sure if fixes ever
made it into 2.6; the only commit that might be related is 6989f5122f
"fec: do not use memcpy on physical addresses", but this doesn't  got
into details about the casue.

Please see here for an old (2.4.25) patch for this problem - maybe
it's worth a try on your system:

http://git.denx.de/?p=linuxppc_2_4_devel.git;a=commit;h=222bd702a59efb22bf66937f6ac844ed7327fd1a

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If you're not part of the solution, you're part of the problem.

Re: Weird 5200/mtd-ram problem

[Wolfram Sang]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]


> 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 :(

-- 
Pengutronix e.K.                           | Wolfram Sang                |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

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

[Albrecht Dreß]

[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]

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.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

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

[Jon Smirl]

On Wed, May 27, 2009 at 3:54 PM, Albrecht Dre=DF <albrecht.dress@arcor.de> =
wrote:
> 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 co=
py
>>> filled the whole ram with 0x0000aaaa. =A0The reason is apparently that =
the
>>> chip is attached to the local bus in 16-bit mode, which is incompatible=
 with
>>> byte accesses. =A0However, the Local Bus doesn't provide "low byte" or =
"high
>>> byte" indicators in non-muxed mode. =A0How is this supposed to work the=
n?
>>
>> 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. =A0I 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). =A0I think this functio=
n
> should go into arch/powerpc/kernel/io.c, depending upon CONFIG_PPC_MPC52x=
x,
> and the prototype into arch/powerpc/include/asm/io.h, right?
>
> The harder part is to actually call this function properly. =A0I 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. =A0However, is =
it
> acceptable to have a processor-type dependency in a top-level include fil=
e?
> =A0Or what would be the proper way to implement it?

This is an old jffs2 patch that was addressing this same problem.

diff --git a/fs/jffs2/scan.c b/fs/jffs2/scan.c
index 272872d..c982adc 100644
--- a/fs/jffs2/scan.c
+++ b/fs/jffs2/scan.c
@@ -16,6 +16,7 @@
 #include <linux/pagemap.h>
 #include <linux/crc32.h>
 #include <linux/compiler.h>
+#include <asm/io.h>
 #include "nodelist.h"
 #include "summary.h"
 #include "debug.h"
@@ -505,7 +506,7 @@ static int jffs2_scan_eraseblock (struct
jffs2_sb_info *c, struct jffs2_eraseblo
 					sumptr =3D kmalloc(sumlen, GFP_KERNEL);
 					if (!sumptr)
 						return -ENOMEM;
-					memcpy(sumptr + sumlen - buf_len, buf + buf_size - buf_len, buf_len);
+					memcpy_fromio(sumptr + sumlen - buf_len, buf + buf_size -
buf_len, buf_len);
 				}
 				if (buf_len < sumlen) {
 					/* Need to read more so that the entire summary node is present */
@@ -1035,7 +1036,7 @@ static int jffs2_scan_dirent_node(struct
jffs2_sb_info *c, struct jffs2_eraseblo
 	if (!fd) {
 		return -ENOMEM;
 	}
-	memcpy(&fd->name, rd->name, checkedlen);
+	memcpy_fromio(&fd->name, rd->name, checkedlen);
 	fd->name[checkedlen] =3D 0;

 	crc =3D crc32(0, fd->name, rd->nsize);



>
> Thanks, Albrecht.
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>



--=20
Jon Smirl
jonsmirl@gmail.com