Re: NAND technical review

Rutger Hofman wrote:
> Jonathan Larmour wrote:
>> Rutger Hofman wrote:
>>> Jonathan Larmour wrote:
>>>
>>>> Does your implementation _require_ a BBT in its current 
>>>> implementation? For simpler NAND usage, it may be overkill e.g. an 
>>>> application where the number of rewrites is very small, so the 
>>>> factory bad markers may be considered sufficient.
> 
> 
> I had forgotten: there is a configuration option to bypass BBT and only 
> use factory-bad markers (and caveat emptor).

Ah. Your documentation includes:
"Before the second initialization stage, some properties of the NAND 
system can be configured. These are en/disabling of ECC generation and 
en/disabling of a Bad Block Table (BBT). By default, ECC and BBT are enabled."

I hadn't noticed that these are not in fact CDL configuration options. 
They ought to be really.

>>> This is a bit hairy in my opinion, and one reason is that there is no 
>>> Standard Layout for the spare areas. One case where a BBT is forced: 
>>> my BlackFin NFC can be used to boot from NAND, but it enforces a 
>>> spare layout that is incompatible with MTD or anybody. It is even 
>>> incompatible with most chips' specification that the first byte of 
>>> spare in the first page of the block is the Bad Block Marker. 
>>> BlackFin's boot layout uses this first byte in a way that suits it, 
>>> and it may be 0 -- which would otherwise mean Bad Block.
>>
>>
>> I infer that your layer can cope with that? I didn't see the handling 
>> for that in io_nand_chip_bad_block.c.
> 
> No (not yet).

If it doesn't sound too silly, how were you able to test your layer on the 
bfin then?

> To use the NAND controller in this way, a different spare 
> layout must be used for the chip. Although there are no obstacles to 
> selecting different spare layouts, there is no support for that yet. It 
> would require one extra parameter in the chip device struct 
> 'constructor' (e.g. with NULL for 'choose default = MTD compatible'). 

You mean CYG_NAND_DRIVER_CHIP()? Presumably some way to pass a different 
layout?

I was wondering about the extensibility of the spare layouts given how 
much stuff is sort of hard coded - sure it may fit plenty of existing 
chips but more can come along. In the chip ID table in io_nand_chip.c I 
haven't worked out what the layout field is for - I can't find where it is 
used. I also can't see how a driver in a new port can add a new chip with 
a new layout. There's talk in read_id() of being able to do a custom chip 
device (does that mean also you can do a custom spare layout?), but it's 
not clear to me how a new port can add that to the table since read_id() 
only searches the table. Obviously it's not sensible to have to keep 
changing io/nand, and may be inappropriate for custom spare layouts.

NB the chip ID table can be const can't it?

> 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.

>> Is your BBT compatible with Linux MTD? Including your use of a mirror?
> 
> 
> Yes, I read MTD, and tried to copy their BBT handling as faithfully as 
> possible without actually copying code. It is on my stack to check if 
> the BBTs are indeed identical; as you may have noticed elsethread, my 
> eCos application wants to share a YAFFS 'disk' with u-boot which has MTD.

Okay. Obviously compatibility is very important, especially for those 
using eCos/RedBoot just to load Linux.

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.

[memory use]
>> If you know what it's going to be (at most), it could just be 
>> allocated statically and just used directly surely? That's got the 
>> lowest overheads.
>>
>> E's implementation had a good idea of a CDL variable for the maximum 
>> supported block size. Then individual HALs or driver packages can use 
>> a CDL 'requires' to ensure it's >= the block size of the chips really 
>> in use.
> 
> I can follow Ross's example here. Together with a switch to constructor 
> and a cleanup of printfs, that will take some days. If it matters in the 
> decision, I will schedule this to be finished within one month.

I'll make a note about it - again I don't want you to be adjusting things 
before the decision has been made - I for one certainly haven't made up my 
mind either way. But thanks very much for your willingness to do so! I 
doubt either implementation will be checked in with zero further changes 
anyway.

[OneNAND (and things like it) fitting into R's model]
> I will take a better look at the OneNAND datasheet. You are right, it is 
> software-wise as different from NOR as from 'raw' NAND. 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.

Ross, if you're reading, I would be interested to know whether something 
with a different access model, like OneNAND, would work with E's layer, in 
your opinion. While I think the answer is yes, I had better check.

Jifl
-- 
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine