identifying a flash file system

identifying a flash file system

[Ballymunboy]

Hello,

We have extracted the NAND flash contents from the TriMedia-based
routers from 2Wire.

We would like to re-build the router's firmware. But, as yet, the
flash file system to those devices cannot be identified.

There is a header found in the first half of page zero of the flash
device.  Fields in that header appear to reference two partitions - a
boot partition and a file system partition.  [1]

There is a hunch that the devices are using the flash translation
layer from m-Systems TrueFFS  (now part of Sandisk). [2]

The 2Wires are running an in-house flavour of BSD  (rtBSD/tm) so maybe
the file system itself is ported from elsewhere in the *BSD platform.

Has anyone here worked with TrueFFS?  What would be the best method
for mounting the volume on a Linux PC for examination?

All comments and suggestions gratefully received!

cheers,
asbokid

[1] http://hackingbtbusinesshub.wordpress.com/category/nand-flash/
[2] http://www.texim-europe.com/promotion/119/trueffs%20product%20brief.pdf

Re: identifying a flash file system

[Mike Dunn]

On 01/17/2012 07:12 PM, Ballymunboy wrote:
> Hello,
>
> We have extracted the NAND flash contents from the TriMedia-based
> routers from 2Wire.


This is a Diskonchip flash?  Which variant?  What did you use to dump the
contents?  A couple of us have developed drivers for some of these. 
Specifically, the G3 (which will probably work on the P3 with slight
modification) and the G4.


>
> We would like to re-build the router's firmware. But, as yet, the
> flash file system to those devices cannot be identified.
>
> There is a header found in the first half of page zero of the flash
> device.  Fields in that header appear to reference two partitions - a
> boot partition and a file system partition.  [1]
>
> There is a hunch that the devices are using the flash translation
> layer from m-Systems TrueFFS  (now part of Sandisk). [2]


The latest TrueFFS implementation uses the M-Sys proprietary "saftl"
formatting.  Look for ASCII 'CNAND" at the start of the first page of an erase
block.  The page that starts with this magic string contains the TrueFFS/saftl
media header, which has partitioning info, etc.  On my Palm Treo 680 with the
diskonchip G4, it's on erase block 5.  The size of an erase block varies among
the diskonchip variants.


>
> The 2Wires are running an in-house flavour of BSD  (rtBSD/tm) so maybe
> the file system itself is ported from elsewhere in the *BSD platform.


Not likely.  If it's TrueFFS, it's M-Sys proprietary. 


>
> Has anyone here worked with TrueFFS?  What would be the best method
> for mounting the volume on a Linux PC for examination?


Write an saftl implementation for linux mtd :)  I think this was done to some
degree for ntfl and inftl, the predecessors of saftl.  Header files describing
the data in the aforementioned media header were provided to developers under
NDA, and they're floating around out there.  But I don't think a full-blown
saftl filesystem is worth it unless there's a need to examine the existing
filesystem contents.  Ubifs has been working well on my diskonchip.  What would
be useful is an mtd partition parser for saftl, though.

Looks like a neat effort.  I don't recognize the data you dumped from page 0. 
I'll compare it with what is on my device when I get a chance.  From perusing
your blog, it appears you boot from a separate flash device, so the BOOTboot
string doesn't really make sense.

Thanks,
Mike

Re: identifying a flash file system

[Ballymunboy]

Hi Mike,

Thank you for taking the time to reply :-)

On Wed, Jan 18, 2012 at 2:52 PM, Mike Dunn <mikedunn@newsguy.com> wrote:
> On 01/17/2012 07:12 PM, Ballymunboy wrote:
>> Hello,
>>
>> We have extracted the NAND flash contents from the TriMedia-based
>> routers from 2Wire.
>
>
> This is a Diskonchip flash?

The flash ICs used on more recent 2Wire router boards are just
common-or-garden NAND ICs with an ONFI interface.

e.g. the Hynix HY27US08561A is found in the 2Wire 2701 router. [3]

However, much earlier 2Wire boards (circa 2003 and earlier) used an
mSys DiskOnChip for persistent storage.

For example, the 2Wire 1800HG ADSL2 modem-router relied on the
MD2811-D16-V3Q18-T, an IC from the DiskOnChip Millennium Plus
series [4]

This is what made us wonder whether 2Wire is still using the
m-Systems Flash Translation Layer from TrueFFS, but with
ONFI-standard NAND flash, such as that Hynix device.

Floating around the internet is a "TrueFFS for Tornado Programmer's Guide".
The Guide was published in 1999 by WindRiver. It documents the
use of TrueFFS with flash devices other than those from the
mSys DiskonChip family.

In code accompanying that Guide, a number of examples are given.
These illustrate the use of TrueFFS with a fairly wide range of flash
devices, most (if not all) of which are now obsolete.

>> We would like to re-build the router's firmware. But, as yet, the
>> flash file system to those devices cannot be identified.
>>
>> There is a header found in the first half of page zero of the flash
>> device.  Fields in that header appear to reference two partitions - a
>> boot partition and a file system partition.  [1]
>>
>> There is a hunch that the devices are using the flash translation
>> layer from m-Systems TrueFFS  (now part of Sandisk). [2]
>
>
> The latest TrueFFS implementation uses the M-Sys proprietary "saftl"
> formatting.  Look for ASCII 'CNAND" at the start of the first page of an erase
> block.  The page that starts with this magic string contains the TrueFFS/saftl
> media header, which has partitioning info, etc.  On my Palm Treo 680 with the
> diskonchip G4, it's on erase block 5.  The size of an erase block varies among
> the diskonchip variants.

Aha! Thank you for the advice.

So the magic string, at least in recent versions of TrueFFS is found in
the main part of the flash page rather than in the out-of-band extra bytes
to the page?

>> The 2Wires are running an in-house flavour of BSD  (rtBSD/tm) so maybe
>> the file system itself is ported from elsewhere in the *BSD platform.
>
> Not likely.  If it's TrueFFS, it's M-Sys proprietary.
>

TrueFFS has got me really confused. It's still not clear to me what it
actually does.

In an ancient message from 2005 posted by Dan Brown to this list, Dan
described TrueFFS as a "block-remapping pseudo-file system".. that sits
on top of the MTD layer and provides an API for the higher-level file system
such as FAT [5]

That's why we wondered whether a regular file system from elsewhere in the
BSD platform may have been borrowed for the TriMedia port of BSD.  That file
system would sit on top of the TrueFFS layer, interfacing with it
through the API.
TrueFFS would invoke the MTD-layer functions, which 2Wire wrote for the
TriMedia, to perform the wear-leveling, garbage collection and fault recovery.

That header we found in block 0 of the NAND flash image from a 2Wire 2701
has a content that is uncannily similar to the mSys flash header
discussed in 2004
by a poster to the TriMedia Users Support Group forum.  [6]


>>
>> Has anyone here worked with TrueFFS?  What would be the best method
>> for mounting the volume on a Linux PC for examination?
>
>
> Write an saftl implementation for linux mtd :)  I think this was done to some
> degree for ntfl and inftl, the predecessors of saftl.  Header files describing
> the data in the aforementioned media header were provided to developers under
> NDA, and they're floating around out there.  But I don't think a full-blown
> saftl filesystem is worth it unless there's a need to examine the existing
> filesystem contents.  Ubifs has been working well on my diskonchip.  What would
> be useful is an mtd partition parser for saftl, though.

> Looks like a neat effort.  I don't recognize the data you dumped from page 0.
> I'll compare it with what is on my device when I get a chance.  From perusing
> your blog, it appears you boot from a separate flash device, so the BOOTboot
> string doesn't really make sense.

The bootstrap sequence is unusual for TriMedia-based board.  The sequence has at
least three stages to it.

A boot ROM loads a minimal NAND driver into RAM. That bootloader reads
the contents
of the flash header to find the offset and size of the next stage of
the boot process.

Using those parameters read from the header, the object code for the
next stage is
copied from NAND into memory. That code is typically an OS bootloader or maybe
the BSD kernel itself.

> Thanks,
> Mike

Thanks Mike. Your time and wisdom is much appreciated :-)

Cheers, a

[1] http://hackingbtbusinesshub.wordpress.com/category/nand-flash/
[2] http://www.texim-europe.com/promotion/119/trueffs%20product%20brief.pdf
[3] https://docs.google.com/open?id=0B6wW18mYskvBY2M4Njk0YTEtYjI4ZC00NWUwLWFjZmEtNjA1NmUwZWQ2ZTY3
[4] http://hackingbtbusinesshub.wordpress.com/2011/09/02/pcb-photos-of-the-2wire-1800hg-medusa-cpu-trimedia-vliw-core/
[5] http://lists.infradead.org/pipermail/linux-mtd/2005-October/014131.html
[6] http://tech.groups.yahoo.com/group/trimedia/message/6367?source=1&var=0&l=1

Re: identifying a flash file system

[Mike Dunn]

On 01/18/2012 03:56 PM, Ballymunboy wrote:
> The flash ICs used on more recent 2Wire router boards are just
> common-or-garden NAND ICs with an ONFI interface.
>
> e.g. the Hynix HY27US08561A is found in the 2Wire 2701 router. [3]
>
> However, much earlier 2Wire boards (circa 2003 and earlier) used an
> mSys DiskOnChip for persistent storage.


Ah, I see.  More of a family of products having different BOMs.  You picked a
tough nut to crack.


>
> For example, the 2Wire 1800HG ADSL2 modem-router relied on the
> MD2811-D16-V3Q18-T, an IC from the DiskOnChip Millennium Plus
> series [4]


The Millenium Plus has inftl formatting.


>
> This is what made us wonder whether 2Wire is still using the
> m-Systems Flash Translation Layer from TrueFFS, but with
> ONFI-standard NAND flash, such as that Hynix device.


Makes sense.  Companies are likely to take the path of least resistance when it
comes to development.


>
> Floating around the internet is a "TrueFFS for Tornado Programmer's Guide".
> The Guide was published in 1999 by WindRiver. It documents the
> use of TrueFFS with flash devices other than those from the
> mSys DiskonChip family.
>
> In code accompanying that Guide, a number of examples are given.
> These illustrate the use of TrueFFS with a fairly wide range of flash
> devices, most (if not all) of which are now obsolete.


This is news to me (which should give you an idea of the extent of my
knowledge).  I didn't realize M-Sys made TrueFFS a separate product for generic
flash devices.


>>
>> So the magic string, at least in recent versions of TrueFFS is found in
>> the main part of the flash page rather than in the out-of-band extra bytes
>> to the page?


Correct, 'CNAND' resides in the first bytes of the page data, on the first page
of the block that contains the saftl volume header.  The rest of the volume
header structure data follows it on that page.  This applies to the saftl.  I
have little knowledge of inftl, but it has already been reverse-engineered, so
refer to the relevant code in the linux kernel.  I notice that inftl's magic
string is 'ANAND' or 'BNAND'; see find_media_headers() in
drivers/mtd/nand/diskonchip.c.

BTW, I see that inftl uses oob data.  saftl does not.  The "sa" stands for
"serial access", and was developed for MLC nand, where pages must be written
sequentially within a block, which is different from the earlier *ftl's.  I
guess by this point TrueFFS became strictly in-house to M-Sys, though I'm not sure.


> TrueFFS has got me really confused. It's still not clear to me what it
> actually does.
>
> In an ancient message from 2005 posted by Dan Brown to this list, Dan
> described TrueFFS as a "block-remapping pseudo-file system".. that sits
> on top of the MTD layer and provides an API for the higher-level file system
> such as FAT [5]


It is equivalent to UBI, which sits between mtd and ubifs.  There is a good
explanation of this on the linux-mtd site. 

What confused me is the relationship between nftl / inftl / saftl and TrueFFS. 
Esentially they are one and the same.  As TrueFFS evolved to support newer flash
technologies, the *ftl names and definitions changed.  They define the control
structures used by the FTL.  But the *ftl definitions (and the TrueFFS sdk) also
include stuff like boot methods and partitioning / volume headers, which are
technically outside the scope of what an FTL does (e.g., mtd now handles
partitioning, not UBI).


>
> That's why we wondered whether a regular file system from elsewhere in the
> BSD platform may have been borrowed for the TriMedia port of BSD.  That file
> system would sit on top of the TrueFFS layer, interfacing with it
> through the API.


Also makes sense.  I didn't think through my earlier reaction to this.


> The bootstrap sequence is unusual for TriMedia-based board.  The sequence has at
> least three stages to it.
>
> A boot ROM loads a minimal NAND driver into RAM.


FYI, this step is not included in the G4 device I've been working with.  These
devices have a 2K region that interfaces to the system bus at the reset vector
like a NOR flash, and this contains code which can read the rest of the flash.


>  That bootloader reads
> the contents
> of the flash header to find the offset and size of the next stage of
> the boot process.


This next stage of the bootloader is sometimes called the IPL (initial program
loader).


>
> Using those parameters read from the header, the object code for the
> next stage is
> copied from NAND into memory. That code is typically an OS bootloader or maybe
> the BSD kernel itself.


If it's the next stage of the bootloader, it's sometimes called the SPL
(secondary program loader).  There is a reference to a MDOC_LoadSPL() function
in the yahoo groups post.

I suspect the inftl kernel code will have a lot of useful info for you.  Good
luck and have fun.

Mike