FTL and Endianity

FTL and Endianity

[Alexandr Andreev]

Hi,
It is about FTL again.
I have got a MIPS big endian machine with CFI flash. And i obliged to 
hack ftl.c
to provide correct endianity working. I mean, i must undef all 
cpu_to_le32 and the
others macros. For little endian machines these macros do nothing, but 
for my big
endian MIPS these macros are unusable too. Did anybody test FTL with big 
endian CPU?
If no, we need to throw these macros out. In any case, we have to be 
able to
configure this behaviour.

Re: FTL and Endianity

[David Woodhouse]

andreev@niisi.msk.ru said:
>  Did anybody test FTL with big  endian CPU? If no, we need to throw
> these macros out. In any case, we have to be  able to configure this
> behaviour.

I didn't test - I think others did though. FTL is defined to be 
little-endian. Why do you say the macros are unusable?

--
dwmw2

Re: FTL and Endianity

[Alexandr Andreev]

David Woodhouse wrote:

>
>I didn't test - I think others did though. FTL is defined to be 
>little-endian. Why do you say the macros are unusable?
>
As i can see, cpu_to_le32 and others macros, are usable only when FTL
reading the FTL header. But when the ftl_fromat utility creates an ftl
partition, it doesn't swap any field of the header.
So, it doesn't matter on which endianity the FTL driver and ftl_format
works, it must be the same only.
Am i wrong?

Re: FTL and Endianity

[David Woodhouse]

andreev@niisi.msk.ru said:
> But when the ftl_fromat utility creates an ftl partition, it doesn't
> swap any field of the header. So, it doesn't matter on which endianity
> the FTL driver and ftl_format works, it must be the same only. Am i
> wrong?

You're right - except that it does matter in theory. The FTL spec is 
defined as little-endian. So while it would _work_ if you do it all 
backwards, it's technically wrong. 

I'd be happier to fix ftl_format and ftl_check to do the byteswapping than 
to remove same from ftl.c.

--
dwmw2

RE: FTL and Endianity

[Siders, Keith]

So since I'm using big-endian MIPS, does this effect JFFS2? That is, 
does FTL stand for Flash Translation Layer, or some such thing? 

Keith

-> -----Original Message-----
-> From: David Woodhouse [mailto:dwmw2@infradead.org]
-> Sent: Friday, July 06, 2001 6:35 AM
-> To: Alexandr Andreev
-> Cc: linux-mtd@lists.infradead.org
-> Subject: Re: FTL and Endianity 
-> 
-> 
-> 
-> andreev@niisi.msk.ru said:
-> > But when the ftl_fromat utility creates an ftl partition, 
-> it doesn't
-> > swap any field of the header. So, it doesn't matter on 
-> which endianity
-> > the FTL driver and ftl_format works, it must be the same only. Am i
-> > wrong?
-> 
-> You're right - except that it does matter in theory. The FTL spec is 
-> defined as little-endian. So while it would _work_ if you do it all 
-> backwards, it's technically wrong. 
-> 
-> I'd be happier to fix ftl_format and ftl_check to do the 
-> byteswapping than 
-> to remove same from ftl.c.
-> 
-> --
-> dwmw2
-> 
-> 
-> 
-> ______________________________________________________
-> Linux MTD discussion mailing list
-> http://lists.infradead.org/mailman/listinfo/linux-mtd/
-> 

Re: FTL and Endianity

[David Woodhouse]

keith_siders@toshibatv.com said:
>  So since I'm using big-endian MIPS, does this effect JFFS2? That is,
> does FTL stand for Flash Translation Layer, or some such thing?  

JFFS2 is host-endian. It shouldn't affect you at all. You don't need to use 
FTL, JFFS works directly on the flash.

If you're making your JFFS2 filesystem images on a little-endian box for 
use on your target, make sure you use the appropriate arguments to 
mkfs.jffs2 to make it do the byteswapping.

--
dwmw2