Re: NAND review

[Andrew Lunn <andrew@lunn.ch>]

> Date: Tue, 02 Jun 2009 19:17:58 +0100
> From: John Dallaway <john@dallaway.org.uk>
> To: Andrew Lunn <andrew.lunn@ascom.ch>
> CC: eCos Maintainers <ecos-maintainers@ecos.sourceware.org>
> Subject: Re: NAND & YAFFS
>
> Have you been able to form a view on the relative merits of the VU
> Amsterdam and eCosCentric implementations so far? Just wanting to ensure
> that this process is not stalled for any reason...
>
> John Dallaway

Hi John

I've spent a little time looking at the documentation and followed the
discussions on the mailling lists. I've not dug into the code at all.

From this i have my first impressions:

eCosCentric/Ross entered the game late, after starting behind closed
doors. There was no RFC about the design, APIs etc. VU/Rutger on the
other hand has been very open, posted his designs and APIs, been
involved in discussion and made changes that resulted from the
discussions. This gets lots of +ve points for Rutger and many -ve
points for Ross/eCosCentric.

I would say the current documentation of the two frameworks is about
equal and generally good. No complains here.

IMHO Ross's partitioning scheme/API is broken. I've tried to trigger
discussion about this, but there has not been much interest. This is a
shame, because to fix it will require API changes, so requiring
changes to the YAFFS glue code etc. I'm also not the only one with
reservations about this partitioning, i've had a private email from a
respected member of the community expressing reservations about the
concept.

I don't see it currently being a problem that Rutgers code does not
have a partitioning concept. It has a nice clean API to
application/filesystem code. My first impression from reading the
documentation suggests that adding partitioning to this will not
require any major API changes, it might even be totally transparent.

So a few +ve points to Rutger, many -ve points to Ross.

I would say the way forward with partitioning is to discuss the
requirements, where can the partitioning information come from, where
does it need to go to, what should the APIs look like. Then do some
design work to make draft APIs, collect comments and then do the
implementation work/modifications as necessary. 

There has been comments that Rutgers code has too many layers. Rutger
aims to allow as much code reuse between drivers as possible, which i
think is good. Simon commented that he thinks Ross's design may result
in a lot of code stuck in HALs where it is hard to reuse without copy
paste. However Ross argued that he thinks that making code reusable is
going to be hard, there is too many different configurations of chips
and controllers, etc.

With only one supported platform on Ross's code and two with Rutgers,
i think it is too early to tell the truth. However, im generally in
favour of layers.

Ross has a simple, but functional synthetic NAND driver. Simon started
on a synth driver for Rutgers library, but stopped when Ross made his
surprise announcement, wanting to see which way we go. Simon also
commented that he used quite a bit of MTD code. This got me a bit
worried about GPL issues, but there was an interesting comment from
Ross that an older version of MTD has a more eCos friendly license.

So, a few +ve points for Ross, with respect to synth drivers.

Initially i was a bit worried about Rutgers need for dynamic memory
allocation. This is needed for the bad block table and per thread
error reporting support. This could be a problem for Redboot, where
you don't normally have a "heap", malloc and free etc. However, on
second thoughts, i don't think this is too big an issue. YAFFS needs
malloc/free. UFFS can either use its own malloc/free implementation,
or use the system provided functions. So in general, redboot is going
to need malloc/free for supporting file systems, so having the NAND
library using it is not that bad.

Ross's code has the bad block table statically allocated, sized using
CDL. This removes the need for malloc/free. However, in some ways, it
reduces the flexibility. I've seen quite a few systems with the same
basic hardware, just different sized FLASH chipsets. With Rutgers
system, this should be no problem, is just asks for as much heap as
needed. Ross's system may need different eCos builds for each hardware
variant, since the size of the BBT is hard coded in the HAL, plus the
partition table is also hard coded in the HAL.

The important thing here is that the code for allocating/freeing the
memory is nicely encapsulated so that it is not too difficult to add
extra options, controlled via CDL, as to how it gets the memory it
needs. I'd need to review the code to see how well this is implemented
in both systems.

There was an email from Rutger that Televic are willing to contribute
their drivers for an AT91SAM9260 based board. If that happens, it
would mean two real implementations for Rutgers, vs one for Ross.

Rutgers API allows reading/writing less than a page, eg just a few
bytes. Ross's API is page based. I don't know if this is an advantage
or a disadvantage. 

Simon commented he preferred Ross's directory layout within the
repository. I have no strong preference here, and it should be trivial
to change Rutgers layout if we wanted to.

There was comments from Ross about excessive stack usage blowing his
target away. This might indicate the immaturity of his code? Rutgers
has been using his code in RFID guardian, and i presume Televic have
also been using the code. So i get the feeling Rutgers code is more
stable and mature.

Overall, i currently favour Rutgers implementation. However, as i said
at the beginning, i've not looked at the actual source code yet.

         Andrew