kernel defconfig, CONFIG_MTD_NAND_VERIFY_WRITE
gb at bsdmn.com
Fri Jan 8 14:42:16 CET 2010
В Птн, 08/01/2010 в 14:29 +0100, Christoph Mair пишет:
> On Friday 08 October 2010 15:27:21 you wrote:
> > Hi, Cristoph.
> > something still (i mean from times Werner talking about) wrong with
> > hardware ecc, I can't read/write mtdblock on 2.6.29.
> > mtd6-rd, mtd6-wt, mtdblock6-rd, mtdblock6-wt
> > original (from old test): 5.2, 4.8, 2.6, 900kb/s
> > with hw ecc + nonanddebug: 6.4, 4.9, error error
> > and got following errors while testing mtdblock (time dd
> > if=/dev/mtdblock6 of=/dev/zero bs=256k count=200)
> > [21474773.805000] end_request: I/O error, dev mtdblock6, sector 256
> > [21474773.805000] Buffer I/O error on device mtdblock6, logical block 32
> > i'll try to undertand how this happened, so wait with commit please.
> I do not have commit rights anyway, so nothing to worry about ;) I'm just
> trying random stuff to find possible bottlenecks.
I can share mine ideas what to try also, as understanding that ecc stuff
and fighting to exclude debug info and preemption can take a while:
I've saw 2 different floating point engines, fast one and pricise one,
and as we are not building plane we for sure may use fast one. My wild
guess this might help much to tangogps for example. I don't know
(yet :) ) who and how handle softfloat on arm, but this might speedup
floating operations, as this is weak point of our device.
Also, i see our kernel using HZ of 200, which extremly high in my
optinion for device there cache is flashed on each task switch. I think
decreasing it down to classic 60 which worked for ages on older kernels
will work excellent, as we not playing fps and do not do professional
but all this is just idea, may or may not work as i do not understand
this in details
More information about the openmoko-kernel