[ECOS] Alpha release eCos NAND Flash, eCos YAFFS

[ECOS] Alpha release eCos NAND Flash, eCos YAFFS

[Rutger Hofman]

Last time I visited a conference, everybody spoke about 'Release early, 
release often'.

Here comes an alpha release of the eCos NAND Flash library and the eCos 
YAFFS wrapper library (r536 of our repository).

To note:
- documentation in packages/io/flash_nand/current/doc/ and 
packages/fs/yaffs/current/doc/
- it has been tested on a BlackFin with on-board NAND Flash controller, 
and one ST-Micro chip;
- it has survived some long tests on the YAFFS file system;
- if you want to use it, you will need to implement the device-specific 
code for your NAND Flash controller. I bundle a template for such a 
device that uses GPIO pins (packages/devs/flash/nfc_gpio); you will also 
need to generate a little bit of NAND chip-specific code;
- a recent YAFFS checkout is bundled too in the tar; if this is 
converted into a regular eCos package, the YAFFS code proper will go so 
users must download YAFFS code separately. Cause: licensing issues;
- the code still has many debug prints (diag_printf) which will have to 
go in beta or stable releases

Download:
ecos.db append:
    http://www.cs.vu.nl/~rutger/software/nand-flash/ecos.db-append
NAND flash package:
    http://www.cs.vu.nl/~rutger/software/nand-flash/nand-flash.r536.tbz2
YAFFS wrappers and YAFFS source:
    http://www.cs.vu.nl/~rutger/software/nand-flash/yaffs.r536.tbz2

Any feedback will be appreciated.

Rutger Hofman
VU Amsterdam

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] Re: Alpha release eCos NAND Flash, eCos YAFFS

[Nick Garnett]

"Gábor Török" <tgabor84@gmail.com> writes:

> On Sun, Nov 30, 2008 at 11:53 AM, Andrew Lunn <andrew@lunn.ch> wrote:
> > On Fri, Nov 28, 2008 at 01:30:23AM +0100, Rutger Hofman wrote:
> >> Last time I visited a conference, everybody spoke about 'Release early,
> >> release often'.
> >>
> >> Here comes an alpha release of the eCos NAND Flash library and the eCos
> >> YAFFS wrapper library (r536 of our repository).
> >
> > Thanks for showing us the code at this early state. I just started
> > browsing through it.
> >
> > ... ...
> >
> >
> > The idea of generic GPIO functions needs to be discussed in the bigger
> > context. More likely these need to be HAL macros, CYG_HAL_GPIO_SET().
> > We want these to be fast as generally they are just two or three
> > assembly instructions. Doing a function call is too expensive in most
> > cases. You also need a generic way to address pins. The AT91 var hal
> > has some ideas here.
> >
> 
> I think also that generic GPIO woukld be a good idea. This would
> simplify writing generic drivers, etc.

I've looked at this several times and decided that it does not make
sense.  The problem with a generic API is that GPIO pins have a large
number of properties. Different manufacturers have wildy different
ways of configuring GPIO lines, from setting a overall mode to large
numbers of registers to control each property. 

Even generating a generic abstract API for something as straighforward
as the AT91 would result in a very large number of functions. Just
look at how complicated the AT91 code is already, when no attempt is
made at abstracting the concepts. This would also place yet another
large burden on the implementor of a new microcontroller port: to try
and map the GPIO abstractions onto the actual hardware.

I can think of very few device drivers that need to control GPIO pins
that would not be target specific. Any truly generic driver needs some
sort of customization to the target, such as register base addresses
and interrupt vector numbers; GPIO setup and control macros can be
provided from the same source.

There may be an argument for having generic macros to set the output
and read the input of a given GPIO pin. But such macros don't really
address the real issue of getting the GPIO pin into the correct mode
in the first place.

In general, I think the current approach of having microcontroller
specific macros for GPIO is the best we can do for now.


-- 
Nick Garnett                                      eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com      The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.     Tel: +44 1223 245571
Registered in England and Wales:                        Reg No: 4422071


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] Re: Alpha release eCos NAND Flash, eCos YAFFS

[Rutger Hofman]

(Limited the reply to the discuss list)

Andrew Lunn wrote:
> ecos-nand-flash-api-err.html: 
> 
> If a function fails, a global variable is set that indicates where the
> error occurred and for what reason
> 
> I don't like this. How do you protect against race conditions with
> multiple threads doing accesses? It either needs to be a variable
> passed with each function call, or at least in thread local storage.

I also prefer thread-local. However, if each thread needs to allocate a 
struct for error handling, there must be some memory allocator. And it 
cannot be the one that is passed to cyg_nand_init() because that is too 
late (and it is nand-struct-specific). Is there a kernel allocator (in 
the vein of kmalloc) that I could use?

> ecos-nand-flash-api-anc.html:
> 
> cyg_flash_get_info() -> cyg_nand_get_info() 

Thanks, fixed.

> ecos-nand-flash-api-anc.html:
> 
> "use_cache is a boolean". eCos has a boolean type, cyg_bool. 
> 
> Checks the BBT (Bad Block Table) if this block is good, worn bad,
> reserved, or factory-bad. If no BBT is used, attempts to check the
> chip for factory-bad marks.
> 
> The last sentence makes no sense.

However, it makes sense. A chip can have a BBT put onto it by the NAND 
library (at its first ever access), or it can be initialized without BBT 
at the option of the application. If a chip has a BBT, then that is 
queried. If it has no BBT, checking the factory-bad marks is the best 
the NAND library can do.

> I'm not so happy with cyg_hal_gpio_*. 
> 
> The idea of generic GPIO functions needs to be discussed in the bigger
> context. More likely these need to be HAL macros, CYG_HAL_GPIO_SET().
> We want these to be fast as generally they are just two or three
> assembly instructions. Doing a function call is too expensive in most
> cases. You also need a generic way to address pins. The AT91 var hal
> has some ideas here.

I'd prefer to await the outcome of the ensuing discussion. Another 
factor is that it is only a template that is not for real use.

> You can submit your NOR driver for the blackfin board anytime. It is
> separate for NAND.

I would much like to submit all of the BlackFin code (once I am 
convinced that it is stable enough). But most of that code is not by me, 
but by Andre Liesk who did the port for his Master's in Chemnitz. I 
should contact him to see if he is willing to transfer the IP to eCos.

Rutger

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss