This is the mail archive of the
mailing list for the eCos project.
Re: NAND "FIS" in RedBoot proposal
- From: Ross Younger <wry at ecoscentric dot com>
- To: Jonathan Larmour <jifl at jifvik dot org>
- Cc: ecos-devel <ecos-devel at ecos dot sourceware dot org>
- Date: Sat, 04 Jul 2009 10:00:46 +0100
- Subject: Re: NAND "FIS" in RedBoot proposal
- References: <4A4DDABA.email@example.com> <4A4EB8D5.firstname.lastname@example.org>
Jonathan Larmour wrote:
The tag is a packed byte array, in processor-local endian, with the
* Magic number - 2 bytes, 0xEF15. (This is a compile-time constant
and demonstrates that the block is one of ours. It's a corruption
of "eCos FIS".)
* Logical block number - 2 bytes.
* Master serial number - 4 bytes (see below).
Given you say processor-local endian, I assume you mean there are two
16-bit words and a 32-bit word here.
Given you are assuming partial-page writes, I think you can do something
more intelligent here [...]
When you write a new revision of a block, you mark
the previous one dead by overwriting it with a partial write (without
I think there are too many overwrite-forbidding chips around for this to be
a goer (including, inter alia, the one on my desk).
When I talked about partial-page reads and writes, I meant only that the
NAND library would cope with being asked to read or write a non-integral
number of pages; that it would do the right thing in terms of how many bytes
it actually sent to the chip and computing/checking ECC.
> I should note though that multiple writes are not supported on newer MLC
> NAND flash. This could be an issue as this class of NAND may become more
> common. Perhaps in that case an obsoleted block can just be erased
We could indeed have a two-bit serial number per logical block and use that
as a distinguisher, erasing the old copy immediately (hence the older serial
number wins). However, dropping the master serial number means we can no
longer detect which was the last block to be written (to the device as a
whole), which I was relying on in order to set up my next-write-here pointer.
- That frees up space which we can use for potential optimisations. In
particular, the common use-case we are envisaging is wholly sequential
reads of fairly large images. So we could use 2 bytes to point to the
next block in the logical block chain. This is very useful if most use
I'm not sure whether this gets us much. NAND blocks are commonly so large
that I think that many applications will only ever be using a small number
at a time?
eCosCentric Ltd, Barnwell House, Barnwell Drive, Cambridge CB5 8UU, UK
Registered in England no. 4422071. www.ecoscentric.com