hramrach_ has quit [Remote host closed the connection]
hramrach_ has joined #arm-netbook
fragmint has joined #arm-netbook
ganbold_ has joined #arm-netbook
ganbold__ has quit [Ping timeout: 256 seconds]
hg_5 has joined #arm-netbook
L84Supper has quit [Remote host closed the connection]
L84Supper has joined #arm-netbook
Dessimat0r has quit [Quit: Computer has gone to sleep.]
Dessimat0r has joined #arm-netbook
Undertasker has joined #arm-netbook
rz2k has joined #arm-netbook
eebrah|away is now known as eebrah
fredy has quit [Ping timeout: 256 seconds]
fredy has joined #arm-netbook
herdingcat has quit [Remote host closed the connection]
ganbold_ has quit [Remote host closed the connection]
popolon has quit [Quit: Quitte]
tinti has quit [Read error: Connection reset by peer]
tinti has joined #arm-netbook
wingrime has quit [Ping timeout: 248 seconds]
tinti has quit [Remote host closed the connection]
eebrah is now known as eebrah|away
Undertasker has quit [Read error: Connection reset by peer]
Undertasker has joined #arm-netbook
Undertasker has quit [Ping timeout: 256 seconds]
Undertasker has joined #arm-netbook
<hno>
penguin42, lkcl what? The A31 flash driver is a "normal" binary blob kernel driver with a thin GPL shim. No userspace loop, just plain GPL violation (at least when it's a built-in module which it always is)
<hno>
or are we not talking about the NAND driver?
rellla has quit [Remote host closed the connection]
<hno>
The A31 can boot of SD if the board is configured to boot from SD or if you use the UBOOT/FEL button.
<hno>
but apparently the allwinner bootloader do not handle UBOOT/FEL induced SD boot very well.
Undertasker has quit [Ping timeout: 256 seconds]
Undertasker has joined #arm-netbook
Undertasker has quit [Read error: Operation timed out]
MMlosh has quit [Quit: Bye...]
Dessimat0r has quit [Quit: Computer has gone to sleep.]
Undertasker has joined #arm-netbook
<lkcl>
hno: ok. right. not userspace then. that's good. definite gpl violation. yes we're talking about the nand driver
eFfeM has joined #arm-netbook
<mnemoc>
they even made some wrapping for this gpl violating
<mnemoc>
they used to just include a .ko or .a ... but not they were straight into the violation
<mnemoc>
s/not/now/
<ibot>
mnemoc meant: they used to just include a .ko or .a ... but now they were straight into the violation
<mnemoc>
went*
<penguin42>
I just don't get it; you'd think flash would be easy
<hno>
penguin42, it
<hno>
penguin42, it's not at all easy these days.
<penguin42>
but isn't most of the logic for driving flash somewhere in the kernel ?
<hno>
not really for a good block device type flash no.
<penguin42>
oh, interesting - what's missing and why?
<hno>
First of all NAND flash is not a block device. Second, todays NAND memories are generally MLC type and there is a number of rather scary properties you need to account for with those.
<hno>
- don't read too often
<hno>
- don't write certain patterns
<penguin42>
oh, I didn't realise there was any restriction on reading; that is erm odd
<hno>
- be very careful with how you write
<penguin42>
yeh but that's always been the case with Flash hasn't it?
<hno>
When you have read N times from the same block you need to relocate it, or the stored data wears out.
<penguin42>
oh, heck ok makes sense I guess
<hno>
And when writing you need to make sure there is no large islands of the same value or things fucks up.
<penguin42>
wth do you do if it is the same value?
<hno>
An easy solution is to randomize the data with a known seed.
<penguin42>
yeh
<penguin42>
are the requirements publicly documented?
<hno>
Yes.
<penguin42>
do things like f2fs help at all or are they still built on top of the assumption of a block device?
<hno>
But the big thing is a reliable FTL layer.
<hno>
f2fs is a block filesystem.
rellla has joined #arm-netbook
<penguin42>
FTL?
<hno>
flash translation layer, what you need to be able to emulate a block device ontop of NAND. Exposes the NAND as a block device and hides all the grumpy details you don't want to know about.
<penguin42>
nod
<penguin42>
the multiple read one sounds tricky; that suggests you need to do a write that's a result of doing reads which is somewhat odd feeling, and thus a read could be dangerous if interrupted, and wth do you do with boot data that primarily just gets read?
<hno>
The alternative to using and FTL is to use a filesystem designed for NAND, such as ubifs or jffs2.
<penguin42>
they can do write levelling I think but can they do anything about those read constraints?
<hno>
penguin42, it's not that complicated really. You relocate the block when the error rate is too high.
<penguin42>
ah ok, so you don't need to hold state on read counts - but who does the error counting/correction - the host or the flash itself?
eFfeM is now known as eFfeM_away
<hno>
penguin42, the ECC circuit (or software). The NAND chip is plain dumb.
<hno>
penguin42, the allwinner NAND controller have built in harfware randomizer & ECC.
<penguin42>
ah right, hence why it's different on all the vendors hardware
Dessimat0r has joined #arm-netbook
<hno>
penguin42, yes.
<penguin42>
unless they're buying in an IP module from someone under NDA?
<hno>
plus that there is no industry standard for what the register interface to a NAND flash controller looks like, like there is for USB & SATA.
<penguin42>
yeh
<hno>
The NAND controller as such is not very complex.
<penguin42>
does the controller do stuff like identifying the model/block size/timing/width of the flash - or is that all a load of stuff you have to programme it with for each board?
<hno>
that's almost standardised. Done by software querying the NAND chip.
<hno>
there is a quite large set of commands used to communicating with NAND chips.
<penguin42>
but can the software talk to the nand chip directly - or does it still have to go through the controller; I remember erm heck when NAND 1st came out it was special write accesses
<hno>
You have to go via the controller, but the controller exposes these things raw. What you rememer is a controller-less setup where the NAND control lines are wired to the address bus directly.
<penguin42>
yeh
<penguin42>
very early stuff - probably about '96
<hno>
Some people still do that.
<hno>
but do not perform so well as the CPU needs to go to quite lengths to get the sequence right.
<penguin42>
yeh
rz2k has quit []
<penguin42>
I guess with having encrypted like that to get rid of constant areas it's more of a pita to jtag
<hno>
JTAG do not do NAND
<hno>
so not really.
drachensun has joined #arm-netbook
<penguin42>
yeh but you've always been able to hand drive the pins on the CPU or other part that does JTAG
<hno>
Sure. But you nearly always upload code to the CPU for doing the NAND flash.
<hno>
direct driving via JTAG like that only works for NAND connected directly on the address lines.
<penguin42>
yeh
<hno>
and it's still very CPU & board specific. so the jump to use some code uploaded to the CPU isn't large.
<penguin42>
yeh
<penguin42>
are they using the same key on every chip or using the serial number or the like ?
<hno>
It's not encrypted. Only randomized.
<hno>
same on every chip.
<penguin42>
ok
de has quit [Ping timeout: 256 seconds]
Undertasker has quit [Ping timeout: 260 seconds]
gimli has quit [Ping timeout: 256 seconds]
Undertasker has joined #arm-netbook
Undertasker1 has joined #arm-netbook
Dessimat0r has quit [Quit: Computer has gone to sleep.]