| 00:05.03 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 00:37.34 | *** join/#arm-netbook stefanro1 (~stefan@pD9FFA140.dip0.t-ipconnect.de) |
| 03:05.22 | *** join/#arm-netbook hipboi (~hipboi@119.132.103.21) |
| 03:34.13 | *** join/#arm-netbook KoH__ (~kane@trir-5d800751.pool.mediaWays.net) |
| 04:44.08 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 05:48.29 | *** join/#arm-netbook dfletcher (~fletch@108-196-222-251.lightspeed.sntcca.sbcglobal.net) |
| 06:42.28 | *** join/#arm-netbook discopig (~discopig@modemcable140.167-130-66.mc.videotron.ca) |
| 06:42.29 | *** join/#arm-netbook discopig (~discopig@unaffiliated/discopig) |
| 06:56.06 | *** join/#arm-netbook de (~de@167-19-112-92.pool.ukrtel.net) |
| 07:38.06 | *** join/#arm-netbook herdingcat (~huli@222.128.169.75) |
| 07:44.12 | *** join/#arm-netbook stamina (~stamina@140-074-128-083.dynamic.caiway.nl) |
| 07:48.49 | *** join/#arm-netbook rellla (~rellla@p4FE1DCCD.dip0.t-ipconnect.de) |
| 07:51.23 | *** join/#arm-netbook rellla (~quassel@p4FE1DCCD.dip0.t-ipconnect.de) |
| 09:16.51 | *** join/#arm-netbook Gumboot (~sh1@rev.bovine.muck.net.nz) |
| 09:46.29 | *** join/#arm-netbook Dessimat0r (~Dessimat0@host-2-103-118-35.as13285.net) |
| 10:27.02 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 11:14.18 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 11:50.27 | rm | http://www.cnx-software.com/2013/05/18/n70-a-and-n70-b-allwinner-a20-and-a31-based-android-netbooks-with-13-3-display/ |
| 11:50.29 | rm | oh wow |
| 11:52.59 | penguin42 | ah, those look pretty nice |
| 11:53.49 | penguin42 | what's the story with the flash drivers on the A31 ? |
| 11:55.22 | penguin42 | rm: 2GB RAM ain't too bad on the A31 version (although I'm still a believer in at least 1GB/core) |
| 12:10.46 | *** join/#arm-netbook wingrime (~wingrime@78.109.115.103) |
| 12:19.58 | *** join/#arm-netbook Dessimat0r (~Dessimat0@host-2-102-42-137.as13285.net) |
| 12:27.04 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 12:30.18 | specing | I will be getting a haswell "ultrabook" instead, ARM is just too great of a hassle for me wrt. getting things working. |
| 12:30.32 | specing | :3 Intel iGPU |
| 12:50.34 | lkcl | penguin42: same as with the A20 - a proprietary application which runs in userspace (!) that communicates with a memory-mapping kernel driver. |
| 12:52.36 | penguin42 | lkcl: Yeuch |
| 12:53.25 | lkcl | yeah. basstud |
| 12:54.22 | penguin42 | wth is it with flash drivers - the rk's are similarly screwed up |
| 12:58.01 | penguin42 | will the A31's boot off SD so you can avoid using flash at all? |
| 13:33.25 | *** join/#arm-netbook Dessimat0r (~Dessimat0@host-2-102-41-125.as13285.net) |
| 13:38.25 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 13:53.24 | *** join/#arm-netbook Dessimat0r (~Dessimat0@host-2-103-118-61.as13285.net) |
| 14:05.13 | *** join/#arm-netbook Dessimat0r (~Dessimat0@host-2-103-118-61.as13285.net) |
| 14:06.13 | lkcl | penguin42: don't know yet. |
| 14:07.33 | penguin42 | (says he still having a bricked rk device) |
| 14:09.58 | SPG | lkcl master 83fa027 rhombus allwinner_a10/debian_netboot.mdwn * add telnet startup * http://git.hands.com/?p=rhombus.git;a=commitdiff;h=83fa027 |
| 14:23.31 | *** join/#arm-netbook L84Supper (~TheLarch@unaffiliated/l84supper) |
| 14:39.10 | *** join/#arm-netbook Dessimat0r (~Dessimat0@host-2-103-118-61.as13285.net) |
| 14:44.14 | SPG | lkcl master 2e4d112 rhombus allwinner_a10/debian_netboot.mdwn * use gzip not lzop * http://git.hands.com/?p=rhombus.git;a=commitdiff;h=2e4d112 |
| 14:44.56 | *** join/#arm-netbook L84Supper (~TheLarch@unaffiliated/l84supper) |
| 14:59.26 | *** join/#arm-netbook hramrach_ (~hramrach@gateway/tor-sasl/hramrach) |
| 15:28.29 | *** join/#arm-netbook fragmint (~fragmint@108-77-196-171.lightspeed.tukrga.sbcglobal.net) |
| 15:39.19 | *** join/#arm-netbook ganbold_ (~Ganbold@173.244.215.173) |
| 15:56.02 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 16:20.24 | *** join/#arm-netbook L84Supper (~TheLarch@unaffiliated/l84supper) |
| 16:26.34 | *** join/#arm-netbook Dessimat0r (~Dessimat0@host-2-103-118-61.as13285.net) |
| 16:47.59 | *** join/#arm-netbook Undertasker (~meister@p5099d479.dip0.t-ipconnect.de) |
| 16:50.10 | *** join/#arm-netbook rz2k (~rz2k@128-69-81-21.broadband.corbina.ru) |
| 17:20.54 | *** join/#arm-netbook fredy (~fredy@snf-8914.vm.okeanos.grnet.gr) |
| 17:49.07 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 18:23.41 | *** join/#arm-netbook Undertasker (~meister@p5099d479.dip0.t-ipconnect.de) |
| 18:46.44 | *** join/#arm-netbook Undertasker (~meister@p5099d479.dip0.t-ipconnect.de) |
| 18:47.11 | 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) |
| 18:47.33 | hno | or are we not talking about the NAND driver? |
| 18:48.51 | hno | The A31 can boot of SD if the board is configured to boot from SD or if you use the UBOOT/FEL button. |
| 18:49.27 | hno | but apparently the allwinner bootloader do not handle UBOOT/FEL induced SD boot very well. |
| 18:56.23 | *** join/#arm-netbook Undertasker (~meister@p5099d479.dip0.t-ipconnect.de) |
| 19:21.59 | *** join/#arm-netbook Undertasker (~meister@89.204.137.24) |
| 19:26.21 | lkcl | hno: ok. right. not userspace then. that's good. definite gpl violation. yes we're talking about the nand driver |
| 19:35.12 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 19:35.28 | mnemoc | they even made some wrapping for this gpl violating |
| 19:35.57 | mnemoc | they used to just include a .ko or .a ... but not they were straight into the violation |
| 19:36.02 | mnemoc | s/not/now/ |
| 19:36.11 | mnemoc | went* |
| 19:38.28 | penguin42 | I just don't get it; you'd think flash would be easy |
| 19:39.05 | hno | penguin42, it |
| 19:39.16 | hno | penguin42, it's not at all easy these days. |
| 19:39.47 | penguin42 | but isn't most of the logic for driving flash somewhere in the kernel ? |
| 19:40.16 | hno | not really for a good block device type flash no. |
| 19:40.33 | penguin42 | oh, interesting - what's missing and why? |
| 19:42.47 | 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. |
| 19:43.04 | hno | - don't read too often |
| 19:43.12 | hno | - don't write certain patterns |
| 19:43.29 | penguin42 | oh, I didn't realise there was any restriction on reading; that is erm odd |
| 19:43.57 | hno | - be very careful with how you write |
| 19:44.21 | penguin42 | yeh but that's always been the case with Flash hasn't it? |
| 19:44.22 | hno | When you have read N times from the same block you need to relocate it, or the stored data wears out. |
| 19:44.40 | penguin42 | oh, heck ok makes sense I guess |
| 19:45.15 | hno | And when writing you need to make sure there is no large islands of the same value or things fucks up. |
| 19:45.36 | penguin42 | wth do you do if it is the same value? |
| 19:46.07 | hno | An easy solution is to randomize the data with a known seed. |
| 19:46.11 | penguin42 | yeh |
| 19:46.55 | penguin42 | are the requirements publicly documented? |
| 19:47.03 | hno | Yes. |
| 19:47.36 | penguin42 | do things like f2fs help at all or are they still built on top of the assumption of a block device? |
| 19:47.44 | hno | But the big thing is a reliable FTL layer. |
| 19:47.49 | hno | f2fs is a block filesystem. |
| 19:47.49 | *** join/#arm-netbook rellla (~quassel@p4FE1DCCD.dip0.t-ipconnect.de) |
| 19:48.04 | penguin42 | FTL? |
| 19:49.11 | 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. |
| 19:49.28 | penguin42 | nod |
| 19:50.21 | 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? |
| 19:51.10 | hno | The alternative to using and FTL is to use a filesystem designed for NAND, such as ubifs or jffs2. |
| 19:51.41 | penguin42 | they can do write levelling I think but can they do anything about those read constraints? |
| 19:51.51 | hno | penguin42, it's not that complicated really. You relocate the block when the error rate is too high. |
| 19:52.28 | 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? |
| 20:07.53 | hno | penguin42, the ECC circuit (or software). The NAND chip is plain dumb. |
| 20:08.21 | hno | penguin42, the allwinner NAND controller have built in harfware randomizer & ECC. |
| 20:09.51 | penguin42 | ah right, hence why it's different on all the vendors hardware |
| 20:19.48 | *** join/#arm-netbook Dessimat0r (~Dessimat0@46.233.72.80) |
| 20:30.10 | hno | penguin42, yes. |
| 20:30.37 | penguin42 | unless they're buying in an IP module from someone under NDA? |
| 20:31.30 | 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. |
| 20:32.07 | penguin42 | yeh |
| 20:32.10 | hno | The NAND controller as such is not very complex. |
| 20:33.08 | 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? |
| 20:33.37 | hno | that's almost standardised. Done by software querying the NAND chip. |
| 20:34.32 | hno | there is a quite large set of commands used to communicating with NAND chips. |
| 20:34.37 | 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 |
| 20:35.46 | 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. |
| 20:35.58 | penguin42 | yeh |
| 20:36.25 | penguin42 | very early stuff - probably about '96 |
| 20:36.53 | hno | Some people still do that. |
| 20:37.53 | hno | but do not perform so well as the CPU needs to go to quite lengths to get the sequence right. |
| 20:37.58 | penguin42 | yeh |
| 20:39.04 | penguin42 | I guess with having encrypted like that to get rid of constant areas it's more of a pita to jtag |
| 20:40.07 | hno | JTAG do not do NAND |
| 20:40.18 | hno | so not really. |
| 20:40.20 | *** join/#arm-netbook drachensun (~drachensu@142.196.78.82) |
| 20:40.33 | penguin42 | yeh but you've always been able to hand drive the pins on the CPU or other part that does JTAG |
| 20:41.33 | hno | Sure. But you nearly always upload code to the CPU for doing the NAND flash. |
| 20:42.16 | hno | direct driving via JTAG like that only works for NAND connected directly on the address lines. |
| 20:42.28 | penguin42 | yeh |
| 20:42.55 | hno | and it's still very CPU & board specific. so the jump to use some code uploaded to the CPU isn't large. |
| 20:43.12 | penguin42 | yeh |
| 20:43.34 | penguin42 | are they using the same key on every chip or using the serial number or the like ? |
| 20:47.35 | hno | It's not encrypted. Only randomized. |
| 20:47.55 | hno | same on every chip. |
| 20:47.57 | penguin42 | ok |
| 21:50.07 | *** join/#arm-netbook Undertasker (~meister@p5099d479.dip0.t-ipconnect.de) |
| 21:51.16 | *** join/#arm-netbook Undertasker1 (~meister@82.113.99.20) |
| 22:08.53 | *** part/#arm-netbook Undertasker1 (~meister@82.113.99.20) |
| 22:11.05 | *** join/#arm-netbook DEAT_ (~heh@14-201-99-152.tpgi.com.au) |
| 23:23.37 | *** join/#arm-netbook Dessimat0r (~Dessimat0@cpc1-birk8-2-0-cust884.1-3.cable.virginmedia.com) |