RE: FTL and Endianity

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

nftl_format/nftlmount problems.

[Felix Radensky]

Hi, all

I'm using the latest CVS mtd code with 2.4.2 kernel from Monta Vista.
My platform is a custom PowerPC 405GP based board. I'm booting my
kernel from 96M DiskOnChip 2000. The technique uses M-Systems
DFORMAT utility to create so called "binary" partition and store kernel
image on it. ROM monitor reads kernel image and loads it into memory.

This works ok. However, nftl code in linux kernel has problems calculating
the correct DOC geometry (I suspect endian issues). So I tried to use
nftl_format
(which supposed to handle big endian correctly), like this:

# nftl_format /dev/mtd0 606208

(my "binary" partition occupies 37 erase units).

The kernel still boots, but nftlmount code complains about not being able
to find a valid boot record.

If I run nftl_format on the entire DOC and boot via network, everything
if fine, i.e. nftl code correctly recognizes DOC geometry.

Please advice.

Thanks in advance.

Felix.