* [ECOS] Alpha release eCos NAND Flash, eCos YAFFS @ 2008-11-28 8:02 Rutger Hofman [not found] ` <20081130105317.GH27015@lunn.ch> 0 siblings, 1 reply; 3+ messages in thread From: Rutger Hofman @ 2008-11-28 8:02 UTC (permalink / raw) To: eCos Patches List, eCos Discuss List 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 ^ permalink raw reply [flat|nested] 3+ messages in thread
[parent not found: <20081130105317.GH27015@lunn.ch>]
[parent not found: <30c102240811300541x2c40707ck70874d3ce30820a6@mail.gmail.com>]
* Re: [ECOS] Re: Alpha release eCos NAND Flash, eCos YAFFS [not found] ` <30c102240811300541x2c40707ck70874d3ce30820a6@mail.gmail.com> @ 2008-12-01 10:07 ` Nick Garnett 0 siblings, 0 replies; 3+ messages in thread From: Nick Garnett @ 2008-12-01 10:07 UTC (permalink / raw) To: Gábor Török; +Cc: Andrew Lunn, eCos Discuss List "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 ^ permalink raw reply [flat|nested] 3+ messages in thread
* [ECOS] Re: Alpha release eCos NAND Flash, eCos YAFFS [not found] ` <20081130105317.GH27015@lunn.ch> [not found] ` <30c102240811300541x2c40707ck70874d3ce30820a6@mail.gmail.com> @ 2008-12-01 18:07 ` Rutger Hofman 1 sibling, 0 replies; 3+ messages in thread From: Rutger Hofman @ 2008-12-01 18:07 UTC (permalink / raw) To: eCos Discuss List (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 ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2008-12-01 16:23 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-11-28 8:02 [ECOS] Alpha release eCos NAND Flash, eCos YAFFS Rutger Hofman [not found] ` <20081130105317.GH27015@lunn.ch> [not found] ` <30c102240811300541x2c40707ck70874d3ce30820a6@mail.gmail.com> 2008-12-01 10:07 ` [ECOS] " Nick Garnett 2008-12-01 18:07 ` Rutger Hofman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).