From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25400 invoked by alias); 16 Dec 2014 20:11:56 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 25391 invoked by uid 89); 16 Dec 2014 20:11:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: illusory.impropriety.org.uk Received: from illusory.impropriety.org.uk (HELO illusory.impropriety.org.uk) (85.119.82.153) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Tue, 16 Dec 2014 20:11:54 +0000 Received: from 250.147.69.111.dynamic.snap.net.nz ([111.69.147.250] helo=[172.20.45.26]) by illusory.impropriety.org.uk with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1Y0yTE-000528-7o for ecos-discuss@ecos.sourceware.org; Tue, 16 Dec 2014 20:11:49 +0000 Message-ID: <549091FE.4070007@impropriety.org.uk> Date: Tue, 16 Dec 2014 20:11:00 -0000 From: Ross Younger User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0 MIME-Version: 1.0 To: ecos-discuss@ecos.sourceware.org References: <006e01d01876$c053a860$40faf920$@itrgmbh.de> <548F2A96.5070606@mindspring.com> <20141215221924.GA16860@chunk.ammanford.ecoscentric.com> <006701d01940$087c2760$19747620$@itrgmbh.de> In-Reply-To: <006701d01940$087c2760$19747620$@itrgmbh.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-illusory-Ham-score: -1.0 X-illusory-Ham-score_int: -9 X-IsSubscribed: yes Subject: Re: AW: [ECOS] General NAND Flash support? X-SW-Source: 2014-12/txt/msg00005.txt.bz2 On 17/12/14 03:53, Richard Rauch wrote: > So, as I understand, full NAND functionality is implemented inside YAFFS > only? YAFFS is implemented on top of the eCosCentric NAND layer. The eCos port patches YAFFS into the file I/O mechanism where it is available alongside FAT, jffs2 and others. The NAND layer is independent of YAFFS - you can find a recent version of its interface at http://hg-pub.ecoscentric.com/nand-ecoscentric/file/17169b710e76/packages/io/nand/current/include/nand.h > As I understand, beside user data YAFFS is writing additionally control > information to the Flash (like FAT)? That is correct. However, YAFFS has been specially designed for NAND flash - there is no file allocation table or superblock, instead it is log-structured. This is part of its strategy for avoiding wearing out individual flash cells, which can be an issue with NAND parts. > But, when we have only NAND on board, how we can boot from NAND? > ROM bootstrap loader from uController is expecting simple Binary image. This is necessarily a board-specific question, but in general terms: Some CPUs contain a ROM bootstrap that is just clever enough to load a small bootstrap from a fixed location on a NAND device. This code in turn knows how to load the next stage. You might for example choose to put RedBoot there, which you had carefully configured with YAFFS and your chosen partition geometry. Your final application image would then reside on the YAFFS filesystem and you could even script RedBoot to automatically load and execute it. Alternatively, there are some NAND parts that offer a NOR-like (i.e. direct read) interface to limited number of pages. These are intended for just this purpose -- to store a minimal bootstrapper. Regards, Ross (Full disclosure: I work for eCosCentric; I wrote their NAND layer and did the YAFFS port.) -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss