Black_Horseman has quit [Ping timeout: 265 seconds]
<rellla>
plaes: np. was just some c&p work :p
gianMOD has joined #linux-sunxi
gianMOD has quit [Remote host closed the connection]
_massi has joined #linux-sunxi
Netlynx has joined #linux-sunxi
Netlynx has joined #linux-sunxi
domidumont has joined #linux-sunxi
domidumont has quit [Remote host closed the connection]
sehraf has joined #linux-sunxi
domidumont has joined #linux-sunxi
sehraf has quit [Client Quit]
popolon has quit [Read error: Connection reset by peer]
paulk-collins has joined #linux-sunxi
popolon has joined #linux-sunxi
philippe_fouquet has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
bonbons has joined #linux-sunxi
gianMOD_ has joined #linux-sunxi
sehraf has joined #linux-sunxi
<RSpliet>
bbrezillon: a 4-bit ECC means it actually uses 4 bits for parity? or does that mean "it can correct errors of up to 4 bits"?
awe00 has joined #linux-sunxi
viccuad has joined #linux-sunxi
philippe_fouquet has quit [Remote host closed the connection]
philippe_fouquet has joined #linux-sunxi
prz has joined #linux-sunxi
philippe_fouquet has quit [Remote host closed the connection]
aballier_ has quit [Quit: leaving]
aballier has joined #linux-sunxi
book` has quit [Ping timeout: 248 seconds]
<RSpliet>
bbrezillon: where this question comes from: the datasheet of a particular type of SLC flash that we wish to experiment with defines a requirement of "4-bit ECC per 512B page"
<RSpliet>
I'm assuming this means they require a minimum of 4-bit parity (which... to the best of my understanding doesn't buy us a lot of resilience)
<bbrezillon>
RSpliet: it's the strength requirement not the size ECC byte will take
<RSpliet>
oh...
sunxi_fan has joined #linux-sunxi
<bbrezillon>
s/byte/bytes/
<RSpliet>
ok... is there some simple formula to calculate the size of the resulting data word?
<bbrezillon>
yep, there is
<bbrezillon>
it depends on the algorithm you want to use
<bbrezillon>
whether you want to use HW ECC or not
<RSpliet>
preferrably, but AllWinner seems to support 20-bit minimum
<bbrezillon>
note that the sunxi NAND controller provides a min strength of 16 bits/1024 bytes
<RSpliet>
while I only have 16B oob per 512B page
<RSpliet>
oh you're right, 16, my bad
<bbrezillon>
hm, indeed, that won't fit
book` has joined #linux-sunxi
<RSpliet>
could you show me the formula for the Allwinner HW ECC? bits of ECC code for given strength+data-length?
<bbrezillon>
the formula for BCH is : eccbytes = DIV_ROUNDUP((strength * fls(8 * stepsize)), 8)
<bbrezillon>
so => (4 * 12) / 8 = 6 bytes
<RSpliet>
stepsize is the 2log of page size I assume? :-)
Black_Horseman has joined #linux-sunxi
<bbrezillon>
RSpliet: hey, actually the bytes generated by allwinner's HW ECC should fit into the OOB area :-)
<bbrezillon>
RSpliet: actually, fls is the 2log operation
<bbrezillon>
which means stepsize is still expressed in bytes
<bbrezillon>
the multiply by 8 operation is here to transform bytes into bits
<bbrezillon>
RSpliet: regarding the HW ECC and your NAND chip, you'll have to modify a bit the logic deciding the appropriate ECC config
<bbrezillon>
4bits/512B is equivalent to 8bits/1024B
<bbrezillon>
(actually it's even a bit stronger)
<bbrezillon>
so 16bits/1024 bytes is even better
<bbrezillon>
I did the calculation and, it takes 23 bytes to have a 16b/1024B strength
<bbrezillon>
you'll have to add 4 extra bytes (space reserved by the controller to store protected OOB data)
<bbrezillon>
(actually it's not 23 it's 26)
<bbrezillon>
and 26 + 4 = 40 < (16 * 2)
<wens>
mripard: i haven't looked closely at the audio-clk dt patches
<bbrezillon>
RSpliet: yep, and that's the reason I proposed the per partition ECC thing a while ago ;-)
<RSpliet>
ah... oh, ok, is that by any chance 64-bit ECC?
<RSpliet>
because if it is... then I doubt we can find a SLC with sufficient OOB space to store it :-(
Renard has joined #linux-sunxi
<bbrezillon>
RSpliet: oh, I'm probably wrong, because I was able to read the first (and you too, if I'm correct) without passing and a specific ECC strength
<bbrezillon>
I guess the ROM code adapt the ECC strength depending on the detected NAND
<bbrezillon>
what you'll have to verify though, is whether the ROM code will accept (recognize) your SLC chip.
<bbrezillon>
and what it'll select for the ECC config
<RSpliet>
if any... for all I know it might just ignore ECC data altogether
<bbrezillon>
to know that you can either disassemble the ROM code
<bbrezillon>
or test it
<RSpliet>
hehe, well, we're in the process of figuring out whether we should place an order right now, so testing is going to be tricky right now :-)
sunxi_fan1 has joined #linux-sunxi
sunxi_fan has quit [Ping timeout: 252 seconds]
<bbrezillon>
then disassembling the ROM code is your only option ;-)
<bbrezillon>
I know it have been done for A10
naobsd has quit [Quit: naobsd]
<RSpliet>
are you farmiliar with the overhead of the software ECC methods in Linux? for smaller ECCs (like 4-bit strength, 7 bytes), is that going to be noticable?
<bbrezillon>
it depends on your NAND usage
<bbrezillon>
the FS cache should help
<bbrezillon>
but if you're writing a lot of things you might have a noticeable perf penalty
<bbrezillon>
(never measured it though)
<bbrezillon>
RSpliet: what's the problem with the HW ECC approach ?
<RSpliet>
in short: 64B OOB for 2048B pages sounds like it is too small for the minimum strength that the Allwinner HW supports
<RSpliet>
and this seems to be the typical (n=2 statistics... so don't take my word on it) OOB area for SLC-NAND chips
<bbrezillon>
RSpliet: why is it too small
<bbrezillon>
I just proove the opposite
<RSpliet>
sorry, I'm equally tired
<RSpliet>
well, it fits provided I can use 16b strength per 1024B ECC step size, even though HW spec sheets seem to mandate a 512B step size
<bbrezillon>
you can
<bbrezillon>
as I said, 16b/1024B is far more stronger than 8b/512B
<bbrezillon>
and the requirement you see in the datasheet is a minimum requirement, which means you can use stronger ECC if you want
gianMOD_ has quit []
<RSpliet>
ok, so for 16/1024 I'll need (16*14)/8 = 28 bytes per step, two steps per page, so 56B plus the OOB protected data 4B... eraseblock data too?
<RSpliet>
anyway, sounds like it can be squeezed in
<RSpliet>
barely, but that's good enough :-)
<oliv3r>
bbrezillon: would we also need OBB data for any filesystem? Or does ubifs for example not require any? I recall that we couldn't use JFFS2 because of OBB issues, but this is from long ago any my memory is weak!
leviathancn has joined #linux-sunxi
<bbrezillon>
UBI/UBIFS do not require any
<oliv3r>
awesome :)
<bbrezillon>
RSpliet: and yes, my calculation was wrong => it's 28 + 4
<bbrezillon>
not 26 + 4
<oliv3r>
bbrezillon: so that SLC chip should work :D
<bbrezillon>
yes it should
<oliv3r>
bbrezillon: ok i'll get our EE guy to order some of those SLC chips; once we have them, would you be interested in a re-solderd board for dev purpouses?
<bbrezillon>
but you'll have to check if it is properly recognized/supported by the BROM
<bbrezillon>
oliv3r: maybe, but even if you send me one, don't expect me to work on it in a near future (I don't have much time to work on NAND related stuff lately)
<oliv3r>
bbrezillon: i'm not expecting anything :)
<oliv3r>
bbrezillon: and as discussed earlier, we may hire Free-Electrons to pick up rspliets work when he leaves (or I have to pick it up) ;)
<oliv3r>
bbrezillon: speaking off, i'll reply to thomas his e-mail hopefully later today/weekend (if he's waiting for a reply)
sunxi_fan1 has left #linux-sunxi [#linux-sunxi]
sunxi_fan1 has joined #linux-sunxi
<bbrezillon>
oliv3r: no problem, I just wanted to make it clear ;-)
sdschulze has joined #linux-sunxi
sdschulze has quit [Ping timeout: 264 seconds]
leviathancn has quit [Ping timeout: 258 seconds]
leviathancn has joined #linux-sunxi
mawe242 has quit [Quit: Leaving]
cubeast has quit [Ping timeout: 252 seconds]
kaspter has quit [Ping timeout: 258 seconds]
awe00 has quit [Ping timeout: 256 seconds]
leviathancn has quit [Ping timeout: 246 seconds]
leviathancn has joined #linux-sunxi
leviathancn has quit [Ping timeout: 246 seconds]
ricardocrudo has quit [Ping timeout: 250 seconds]
Nyuutwo has joined #linux-sunxi
Black_Horseman has quit [Remote host closed the connection]
premoboss has joined #linux-sunxi
ricardocrudo has joined #linux-sunxi
awe00 has joined #linux-sunxi
awe00 has quit [Ping timeout: 256 seconds]
physis has joined #linux-sunxi
physis has quit [Remote host closed the connection]
physis has joined #linux-sunxi
linkmauve1 has quit [Ping timeout: 272 seconds]
nicksydney_ has quit [Remote host closed the connection]
nicksydney has joined #linux-sunxi
linkmauve1 has joined #linux-sunxi
awe00 has joined #linux-sunxi
paulk-collins has quit [Remote host closed the connection]
JohnDoe_71Rus has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org]
afaerber has quit [Quit: Verlassend]
philippe_fouquet has joined #linux-sunxi
lemonzest has quit [Remote host closed the connection]
philippe_fouquet has quit [Client Quit]
afaerber has joined #linux-sunxi
dack has joined #linux-sunxi
domidumont has quit [Ping timeout: 246 seconds]
pacopad has joined #linux-sunxi
Playdo has joined #linux-sunxi
reinforce has quit [Quit: Leaving.]
RzR has quit [Excess Flood]
RzR has joined #linux-sunxi
<RSpliet>
bbrezillon: don't take my word on it just yet, but from what I can tell BROM always expects HW ECC at 64-bit strength
<bbrezillon>
RSpliet: how did you manage to read the content of the eGON partition then ?
<bbrezillon>
in raw mode ?
<RSpliet>
just... dd
<RSpliet>
idk, I'm still figuring out the details
physis has quit [Remote host closed the connection]
<bbrezillon>
RSpliet: use nanddump
<bbrezillon>
with that tool you're guaranteed to access the NAND using the proper page alignment
premoboss has quit [Remote host closed the connection]
<bbrezillon>
+ you can enable/disable the ECC engine
<bbrezillon>
and dump the OOB data
<bbrezillon>
RSpliet: what makes you think it's using 64bit ECC ?
<bbrezillon>
(that might well be the case, I did some tests a while ago, but I don't remember what was the conclusion :-))
firnsy has quit [Ping timeout: 244 seconds]
diego_r has quit [Quit: Konversation terminated!]
reinforce has joined #linux-sunxi
firnsy has joined #linux-sunxi
_massi has quit [Remote host closed the connection]