Re: [RPX Classic/Lite and byte ordering]

Re: [RPX Classic/Lite and byte ordering]

[Eric]

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

E

Tim Bowman <tbowman@emware.com> wrote:
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


____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1


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

Re: [RPX Classic/Lite and byte ordering]

[Eric]

Tim Bowman <tbowman@emware.com> wrote:

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

Yes, in any case they should be using the __raw equivalents to force
untranslated byte ordering.  This allows the ENDIAN defines to work
appropriately.  I can't say if this is your problem, but you should
go 'raw' at the very least to be idiomatic with the other drivers.

E



____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1


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

Re: [RPX Classic/Lite and byte ordering]

[Tim Bowman]

Tim Bowman <tbowman@emware.com> wrote:

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

Yes, in any case they should be using the __raw equivalents to force
untranslated byte ordering.  This allows the ENDIAN defines to work
appropriately.  I can't say if this is your problem, but you should
go 'raw' at the very least to be idiomatic with the other drivers.

-----------------

Ta-Da.... I fixed the problem in include/asm-ppc/io.h:
...
#define readb(addr) in_8((volatile u8 *)(addr))
#define writeb(b,addr) out_8((volatile u8 *)(addr), (b))
#if defined(CONFIG_APUS) || defined(RPXCLASSIC)
#define readw(addr) (*(volatile u16 *) (addr))
#define readl(addr) (*(volatile u32 *) (addr))
#define writew(b,addr) ((*(volatile u16 *) (addr)) = (b))
#define writel(b,addr) ((*(volatile u32 *) (addr)) = (b))
#else
#define readw(addr) in_le16((volatile u16 *)(addr))
#define readl(addr) in_le32((volatile u32 *)(addr))
#define writew(b,addr) out_le16((volatile u16 *)(addr),(b))
#define writel(b,addr) out_le32((volatile u32 *)(addr),(b))
#endif
...

Everything works great now, in fact so great that I blew away the RPX
utility with a jffs file system and rendered my board useless.  Has
anyone re-programmed the flash via BDM on these boards?  I wonder what
hardware and software works the best.

This solution doesn't explain why some of you haven't had this problem. 
Maybe the flash really is wired up two different ways on RPX boards...

Thanks a lot for everybody's help.  -T


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