public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Ross Younger <ecos@impropriety.org.uk>
To: ecos-discuss@ecos.sourceware.org
Subject: Re: AW: [ECOS] General NAND Flash support?
Date: Tue, 16 Dec 2014 20:11:00 -0000	[thread overview]
Message-ID: <549091FE.4070007@impropriety.org.uk> (raw)
In-Reply-To: <006701d01940$087c2760$19747620$@itrgmbh.de>

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

      reply	other threads:[~2014-12-16 20:11 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-15 14:52 Richard Rauch
2014-12-15 18:38 ` Frank Pagliughi
2014-12-15 22:19   ` Daniel Morris
2014-12-16 14:53     ` AW: " Richard Rauch
2014-12-16 20:11       ` Ross Younger [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=549091FE.4070007@impropriety.org.uk \
    --to=ecos@impropriety.org.uk \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).