From: Rutger Hofman <rutger@cs.vu.nl>
To: "ecos-devel@ecos.sourceware.org" <ecos-devel@ecos.sourceware.org>
Subject: Rutger's NAND flash now has a synth package
Date: Sun, 28 Jun 2009 11:46:00 -0000 [thread overview]
Message-ID: <4A475994.7010203@cs.vu.nl> (raw)
Good afternoon list,
in the usual work storm in my office, there was a lull last week. I took
the opportunity to make a synthetic target for my NAND flash package.
Simon Kallweit had already started work on this (but put it on hold when
eCosCentric's NAND package came up); the level of emulation in his
implementation was the NAND chip with its set of wires.
I discussed this with Simon, and we agreed that the fastest way to a
synth package would be to make an integrated NFC (NAND flash controller)
and chip(s) package. This turned out to be straightforward. The NAND
chip(s) are emulated in the same way as in the NOR flash synth targets:
by memory-mapping a file to represent a chip.
The synth target I built thus has the following properties/limitations:
- it generically supports 'regular' large-page chips; there is no
support for small-page chips; there is also no real support (yet) for
ONFI chips, which differ from 'regular' chips in the interrogation. This
didn't seem to me to be a harmful limitation because there seem to be no
ONFI chips on the market (yet);
- it supports x8 and x16 chips (8 and 16 being the chip's bus width);
- it supports multiple chips connected to one NFC;
- NAND chip size is limited to max file size and to max mappable file
size. This limit could be extended by spreading the chip over multiple
files, if the need arises;
- like the NOR flash synth target, the NAND synth target is completely
linked into the target executable. There is no host auxiliary component;
- it lives under packages/devs/nand/nfc_synth/.
I tested this synth target with an (emulated) x8 and an x16 chip, and
also with a configuration with both an x8 and an x16 chip. YAFFS
requires one chip, but my Abstract NAND Chip layer hides the presence of
multiple chips so I could run YAFFS tests that use a filesystem that
spreads over both chips. Caveat: the page/spare/block size of both
emulated chips was identical. I didn't (yet) test with chips that differ
in those respects.
A few small bugs came out, related to x16 (I erroneously divided by bus
width somewhere), and related to ANC-to-physical address calculations
for multiple chips.
Reflecting discussion on the eCos lists, I also changed the package
names from flash_nand/ to nand/, and moved NAND flash device drivers
from under devs/flash to devs/nand/.
The code is published in the same place as before:
http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/
I appreciate comments and usage.
An aside: I run Ubuntu. At first, I couldn't run synth at all.
Applications would crash, and gdb would crash on the application too!
After some list searching, I found out that this probably is
Ubuntu-specific. We need to include -fno-stack-protector in the
GLOBAL_CFLAGS configure flag. Request: cannot this be automated for
synth building? My guess is that it will not harm on systems other than
Ubuntu, and it will save Ubuntu users effort.
Rutger Hofman
VU Amsterdam
next reply other threads:[~2009-06-28 11:46 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-06-28 11:46 Rutger Hofman [this message]
2009-06-29 6:42 ` Simon Kallweit
2009-06-29 7:52 ` Sergei Gavrikov
2009-06-29 11:32 ` Rutger Hofman
2009-06-29 7:24 ` GCC stack protector with linux synthetic target John Dallaway
2009-06-29 7:50 ` Andrew Lunn
2009-06-29 9:50 ` Bart Veer
2009-06-30 8:55 ` John Dallaway
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=4A475994.7010203@cs.vu.nl \
--to=rutger@cs.vu.nl \
--cc=ecos-devel@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).