Re: NAND technical review

Ross Younger wrote:
> Jonathan Larmour wrote:
> 
>>To double check, you mean reading was slowest, programming was faster
>>and erasing was fastest, even apparently faster than what may be the
>>theoretical fastest time? (I use the term "fast" advisedly, mark).
>>
>>Are you sure there isn't a problem with your driver to cause such
>>figures? :-)
> 
> 
> Those are the raw numbers. Yes, I agree that they don't appear to make
> sense. As I said, profiling - which will include figuring out what's going
> on here - is languishing on the todo list ...

Ok, although I think I may have to take those particular figures with a 
pinch of salt, given they are.... unexpected.

>>I wonder if Rutger has the ability to compare with his YAFFS throughput.
>>OTOH, as you say, the controller plays a large part, and there's no
>>common ground with R so it's entirely possible no comparison can be fair
>>for either implementation.
> 
> 
> The YAFFS benchmarking is done by our yaffs5 test, which IIRC goes only
> through fileio so ought to be trivially portable. It doesn't appear in my
> last drop on the bz ticket, but will when I get round to freshening it.

Ok. Although I'm not sure how long these discussions will continue for. 
Although not ideal, running it on both the synth targets may be the only 
way to compare.

> To be clear: hwecc _is_ working well, on this customer port, and getting it
> going on the STM3210E is on the cards so I have something I can usefully
> share publicly.

Can you at least shed light on the API changes (by cut'n'pasting relevant 
sections of headers/code even if not the whole thing)? I feel this is a 
key thing to get clarity on since I don't have a view on that yet and it's 
an important feature. I know doc etc. will want updating, but in reality 
we can probably get a good idea from an overview of the code, even if it's 
not a complete self-contained package drop. It may also save you time. I 
don't doubt it works on your port, but I think I need to get a view on how 
well it would fit with other hardware ECC systems which I know about and 
those which R goes to pains to support.

I also realise people have busy lives so no worries if you can't do it for 
a few days if there's more than a little effort involved; although I'd 
have thought it wouldn't be much.

>>Just as an aside, you may find that improving eCos more generally to
>>have e.g. assembler optimised implementation of memcpy/memmove/memset
>>(and possibly others) may improve performance of these and other things
>>across the board. GCC's intrinsics can only do so much. (FAOD actual
>>implementations to use (at least to start with) can be found in newlib.
> 
> 
> The speedups in my NAND driver on this board came from a straightforward
> Duff's device 8-way-unroll of what had been HAL_{READ,WRITE}_UINT8_VECTOR;
> 16-way and 32-way unrolls seemed to add a smidgen more performance but
> increased code size perhaps disproportionately. (Using the existing VECTOR
> macro but with -funroll-loops gave a similar speed-up but more noticeable
> code bloat across the board.)

OOI you could add it to the per-package CFLAGS (unless you meant you 
already did and the bloat was noticeable even just there).

> The word copies in newlib's memcpy et al look like they would boost
> performance generally, but I have attempted to avoid copying data around as
> far as possible in my layer.

I was mostly thinking of YAFFS in fact (and fileio on top), although I 
haven't really looked at the extent they depend on bulk memory moves.

> To try and fit with the eCos philosophy, I've left the localised unroll as a
> CDL option in this driver, defaulting to off. I expect similar unrolls would
> be profitable in other NAND drivers, but a more generalised solution might
> be preferable: something like HAL_READ_UINT8_VECTOR_UNROLL, with options to
> configure whether and how far it was unrolled?

Possible, although there are probably bigger fish to fry.

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