Re: NAND technical review

[Rutger Hofman <rutger@cs.vu.nl>]

Jonathan Larmour wrote:
> Rutger Hofman wrote:
>> Jonathan Larmour wrote:
>>
>>> Rutger Hofman wrote:
[on adding support for other NAND chips than raw NAND]
> 
>> I guess that this refactoring will take something like one or a few 
>> days' work, including having ANC call the controller over a dispatch 
>> table. I'll be glad to do it (ETA: somewhere in the next 1 to 1.5 
>> months).
> 
> I would be very surprised by a day!

Yesterday, there was an unexpected lull in the usual storm of work. 
Basically, the refactoring is done so R can support hardware other than 
raw NAND. I must still update the documentation, though. The structure 
is a bit different than I first thought; there is a package IO_NAND for 
the general stuff (anc, ecc, bbt), and a package IO_NAND_RAW for the raw 
NAND. So, if somebody wants NAND but not raw NAND, that package isn't 
included so no raw NAND code.

I will put up a next release when the documentation is done. I am aware 
that changing the code while you are reviewing it is not very polite; 
maybe you prefer to stick with the code that you have right now, and 
just acknowledge any updates/refactoring I did.

An unusual problem has cropped up in my synth build. After having run my 
tests on the BlackFin, I built for synth and I am now meeting weird 
alignment behaviour in the HAL_TABLE device tabs. My gcc (gcc-4.2.real 
(GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)) for synth generates a directive 
.align 32 in the declaration of a device struct in the appropriate 
section, but the HAL_TABLE array has align=4. In consequence, the 
pointer to traverse the device table has the wrong stride. 'Proof': if I 
hand-align the device struct to be a multiple of 32, things work 
correctly in synth. Anybody any idea what I should do? Put in an 
align(32) directive on the device struct definitions? That is a hack to 
work around a compiler bug just for one platform, I'd say; OTOH it's bad 
that it might just bite *any* synth device driver table, not only mine.

> Finally, are there any questions about E's layer that you think I should 
> ask about which I haven't?

I am sorry, I have had no time to review E's layer. My boss tells me 
loudly that doing so is not on the critical path of our project...

Rutger