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

[Rutger Hofman <rutger at cs dot vu dot nl>]

(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