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

[Simon Kallweit <simon.kallweit@intefo.ch>]

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:
> http://www.cs.vu.nl/~rutger/software/ecos/nand-flash/
> 
> 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.

Simon