RPX Classic/Lite and byte ordering

RPX Classic/Lite and byte ordering

[Tim Bowman]

I am having trouble with an Embeddded Planet RPX board.  The mtd layer
seems to be reversing the data by double words.  If I write (then cat)
some text, every double word is reversed.  I can use a cramfs file
system, but I have to reverse the dwords myself before writing it to
flash, then everything works fine.  JFFS and other file systems
obviously don't work, since the data is written by mtd in the wrong
order.  I am doing everything on big-endian machines (PowerPC).

If someone can point me to the right code I would be glad to work on
this.

-TDB


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

AW: RPX Classic/Lite and byte ordering

[Florian Schirmer / TayTron]

Hi!

>I am having trouble with an Embeddded Planet RPX board.  The mtd layer
>seems to be reversing the data by double words.  If I write (then cat)
>some text, every double word is reversed.  I can use a cramfs file
>system, but I have to reverse the dwords myself before writing it to
>flash, then everything works fine.  JFFS and other file systems
>obviously don't work, since the data is written by mtd in the wrong
>order.  I am doing everything on big-endian machines (PowerPC).
>
>If someone can point me to the right code I would be glad to work on
>this.

Did you upgrade to the latest cvs code? If not try this first. If you
already have the latest code then play with the endian options under the cfi
advanced settings in the kernel config.

PPC works very here.

Hope that helps
  Florian Schirmer



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RPX Classic/Lite and byte ordering

[Tim Bowman]

Original message:

> I am having trouble with an Embeddded Planet RPX board.  The mtd layer
> seems to be reversing the data by double words.  If I write (then cat)
> some text, every double word is reversed.  I can use a cramfs file
> system, but I have to reverse the dwords myself before writing it to
> flash, then everything works fine.  JFFS and other file systems
> obviously don't work, since the data is written by mtd in the wrong
> order.  I am doing everything on big-endian machines (PowerPC).

I have tried all of the query ordering options in the kernel config, and
even tried changing just the read, and then just the write in
cfi-endian.h to order words and double words, to no avail.  I have the
latest code for both the bk kernel and the cvs mtd.

Eric B. suggested:
"You might want to take a look at .../include/mtd/cfi_endian.h and
be sure you are using __raw_writeb and friends. "

The rpxlite layer seems to be using memcpy_fromio, writeb, writew, etc,
not __raw_writeb.  Should these be replaced with the raw versions?

Finally, could this have something to do with flash interleave?  I am
relatively new at this low-level stuff, but if the interleave is 4 for
the RPX, then I could see how every 4 bytes might be reversed.  The
specific board I am using is a CLCC_E with 8M flash.

Thanks


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

RPX Classic/Lite and byte ordering

[Tim Bowman]

One more possibilty: 

Would cross-compiling the kernel on an x86 produce different ordering
than compiling natively on a PowerPC (which is how I am building it)? 
Maybe I need to build it on an x86?


Original message:

> I am having trouble with an Embeddded Planet RPX board.  The mtd layer
> seems to be reversing the data by double words.  If I write (then cat)
> some text, every double word is reversed.  I can use a cramfs file
> system, but I have to reverse the dwords myself before writing it to
> flash, then everything works fine.  JFFS and other file systems
> obviously don't work, since the data is written by mtd in the wrong
> order.  I am doing everything on big-endian machines (PowerPC).

I have tried all of the query ordering options in the kernel config, and
even tried changing just the read, and then just the write in
cfi-endian.h to order words and double words, to no avail.  I have the
latest code for both the bk kernel and the cvs mtd.

Eric B. suggested:
"You might want to take a look at .../include/mtd/cfi_endian.h and
be sure you are using __raw_writeb and friends. "

The rpxlite layer seems to be using memcpy_fromio, writeb, writew, etc,
not __raw_writeb.  Should these be replaced with the raw versions?

Finally, could this have something to do with flash interleave?  I am
relatively new at this low-level stuff, but if the interleave is 4 for
the RPX, then I could see how every 4 bytes might be reversed.  The
specific board I am using is a CLCC_E with 8M flash.

Thanks


To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: RPX Classic/Lite and byte ordering

[Brendan J Simon]

Nope.  A powerpc cross compiler *should* produce *exactly* the same code 
as a naitive compiler.  This assumes you are using exactly the same 
version of gcc, gas and glibc.  Having said that, I just remembered that 
the PowerPC architecture can be big endian or little endian.  There must 
be a configuration option when building the compilers that sets the 
default.  You should be able to specify which you want, either in the 
spec file or on the command line.

I've had a look at my spec file.  Try the -mbig-endian (or -mbig) for 
big endian.  Try -mlittle-endian (or -mlittle) for little endian.  I 
prefer -mbig-endian or -mlittle-endian because they are a lot clearer 
than -mbig or -mlittle.

My spec file has the following:

*multilib_defaults:
mbig mcall-linux

*cpp_endian_default:
%(cpp_endian_big)

*cc1_endian_default:
%(cc1_endian_big_spec)


Regards,
Brendan Simon.



Tim Bowman wrote:

> Would cross-compiling the kernel on an x86 produce different ordering
> than compiling natively on a PowerPC (which is how I am building it)? 
> Maybe I need to build it on an x86?





To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: RPX Classic/Lite and byte ordering

[mferrell]

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

I was talking with some people who work with the Embeded Planet RPX stuff and
apparently a couple of chips on the system are wired backwards.  The
developers could remember "exacly" which models they ran across that where
wired this way, but he remembered that it only showed up when dealing with
double words.  Dunno if that helps.

As far as the PPC stuff, a few can be little endian, but under linux they are
all big endian so far.


On Tue, Apr 03, 2001 at 11:16:11AM +1000, Brendan J Simon wrote:
> Nope.  A powerpc cross compiler *should* produce *exactly* the same code 
> as a naitive compiler.  This assumes you are using exactly the same 
> version of gcc, gas and glibc.  Having said that, I just remembered that 
> the PowerPC architecture can be big endian or little endian.  There must 
> be a configuration option when building the compilers that sets the 
> default.  You should be able to specify which you want, either in the 
> spec file or on the command line.
> 
> I've had a look at my spec file.  Try the -mbig-endian (or -mbig) for 
> big endian.  Try -mlittle-endian (or -mlittle) for little endian.  I 
> prefer -mbig-endian or -mlittle-endian because they are a lot clearer 
> than -mbig or -mlittle.
> 
> My spec file has the following:
> 
> *multilib_defaults:
> mbig mcall-linux
> 
> *cpp_endian_default:
> %(cpp_endian_big)
> 
> *cc1_endian_default:
> %(cc1_endian_big_spec)
> 
> 
> Regards,
> Brendan Simon.
> 
> 
> 
> Tim Bowman wrote:
> 
> > Would cross-compiling the kernel on an x86 produce different ordering
> > than compiling natively on a PowerPC (which is how I am building it)? 
> > Maybe I need to build it on an x86?
> 
> 
> 
> 
> 
> To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

-- 
Mark Ferrell <mferrell@mvista.com>
Monta Vista Software Inc. <http://www.mvista.com>

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