This is the mail archive of the mailing list for the eCos project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Rutger's NAND flash now has a synth package

Rutger Hofman wrote:
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:

I appreciate comments and usage.

That sounds like good news. Soon I'll have to do a little studies on flash filesystems for our platform, so I think I'll port the UFFS filesystem to eCos and write the necessary device drivers for the STM32 family. I think your framework just got a little more attractive with the recent changes.

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.

I observed the same bug. But I started using eCosCentrics i386 toolchain for my synth builds which works fine with standard configuration. It will also make sure that I don't run into GCC specifics from time to time, as the distro's toolchain is updated quite often.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]