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: NAND technical review

Jonathan Larmour wrote:
Rutger Hofman wrote:
I was referring to the "layout" field of cyg_nand_chip_id_t. Whereas spare_scatter_fill()/extract() use the spare_layout field of the cyg_nand_chip_info_t. I haven't yet found where the "layout" field of cyg_nand_chip_id_t is used.

This represents the fourth byte of the 'regular' read_ID response. (First is manufacturer, second is device type, third is often 0, but may be defined to give further architectural details.) The specx for this layout byte:

bit   meaning               description
0..1  1KB, 2KB, 4KB, 8KB    page size
2     8, 16                 spare bytes per 512 data bytes
4..5  64KB, 128KB, 256KB,   block size (without spare)
6     x8, x16               bus width

The other bits differ across manufacturers.

Reading and parsing this byte is still insufficient to fully access the chip: its total size is unknown. It can be in the third byte, in which case the chip table needn't wouldn't need an entry for this chip because it is sufficiently self-descriptive.

For the record: MDT/Blackfin/u-boot has support for this different layout, but it is build-static. MDT cannot hot-swap layouts (at the moment).

That's reasonable given it's associated with the controller.

Well, not completely. The layout is only associated with the *boot mode*. For other use, there is no prescription of the layout, so it's typical to use the MTD layout - then one can share with Linux or u-boot. Rotten consequence: if one wants to program a new boot image into the first block(s) of the NAND, the boot-compatible layout must be used.

So I believe that means if you want to rewrite the boot program on Blackfin _and_ use a normal layout, you wouldn't be able to use R as it stands at the moment. Ack, OK.

Hot-swapping is necessary to pull this tric. It would be doable in my current svn version (which is coming up one of these days). It would imply crossing through all layers though, and it would indeed be horribly risky.

OTOH, if anything else of the NAND is going to be used, the MTD layout is required. So hot-swapping is highly desirable

Hot swapping sounds like a risky thing to do, with potentially multiple subsystems wanting access to flash, not just the application.


But also, since R does not have partitioning, won't that potentially interfere with compatibility with MTD? A Linux booted image may not be using the whole chip as a single FS.

Linux has no fixed approach to partitioning, as I learned during the discussions on this list.

Yes, but that isn't the same as not supporting partitions. Just that they aren't fixed. They're specified on the kernel boot line, and so can be configured by the user arbitrarily.... it's just that you can't change them without rebooting. So I believe anyone who is using multiple partitions with MTD would have difficulties interoperating with R.

If this is so (I am not conversant enough yet with Linux internals) then it is a very useful addition. Using multiple YAFFS devices is straightforward right now (I did this and met no problems).

[OneNAND (and things like it) fitting into R's model]

My guarded guess now is that integration into R would imply a replacement of the Common Controller code (by configuration or by 'object-oriented' indirect calls over a device struct). I will report on this later.

Thanks. Although of course adding more indirection may have its own disadvantages.

That guarded guess was correct. OneNAND is no raw NAND chip so R's common controller code won't fit. The thing to do is make a driver that comes in place of the common controller, as suggested above. Once ANC supports a pluggable controller (which I will do if it makes a difference), adding a OneNAND will take the same amount of effort as for E's implementation.

Would that not require a significant reworking and relayering of code? It seems to me that controller drivers and the chip drivers used by controller drivers under this system will still want to be able to access the infrastructure support for BBTs, ECCs and spare layout. From what I can see, preserving that without large amounts of indirection (imposing further performance and size hits) would pose quite some challenge. The result would be something really quite different to what R is like today.

The reworking would just be to replace the calls in the ANC of the controller-common API with indirect calls, and supporting this configurability in the CDL. OneNAND doesn't need ECC code because things are handled in hardware (the datasheet recommends not even checking the ECC status register for 2-bit failures because they are so rare). Maybe BBT is necessary too for OneNAND; I didn't think that through yet, but I would hope the BBT implementation would support different controllers without a lot of reworking - right now, accessing the chip already goes through controller calls. The indirections would be few: one for each top-level API call (unless the ANC must redistribute application pages to chip pages, which is only in case of heterogeneous chips).

In conclusion: a driver in R for a different class of chip than 'raw NAND' would indeed replace R's controller-common, any controller-device-specific, and any chip, because these are all code for raw NAND. I would hope that linker magic remove the code as unused from the binary.

A driver for OneNAND would still need to be written obviously, and it would share no or little code with controller-common and raw chip. My guess is that would hold for E too - although I don't really know because I have had no time to review E's code.


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