| 00:02.56 | slapin | hno: will you see into zeroed oob? |
| 00:03.13 | slapin | hno: try nand read.oob is it ok this way? |
| 00:07.42 | hno | nand dump and dump.oob both gives all zeroes. |
| 00:08.43 | hno | also seems it reads much more data than there is oob in the last read. |
| 00:08.59 | hno | a full 1K read. |
| 00:10.02 | hno | nand read seem to have size specification wrong or something. Giving a size of 2000 runs "forever" |
| 00:11.12 | *** join/#arm-netbook tinti_ (~tinti@bhe201062162119.res-com.wayinternet.com.br) |
| 00:11.50 | *** join/#arm-netbook FreddyAV (~FreddyAV@ppp118-210-43-14.lns20.adl2.internode.on.net) |
| 00:12.41 | Marex | hno: 2048 + 64 , no ? |
| 00:14.53 | hno | read.oob gets the right first bytes at least. Haven't compared more than the first 5 or so. |
| 00:15.33 | hno | With ECC there is a lot more OOB than 64. |
| 00:20.53 | hno | slapin, allwinner code reads 60(dec) bytes oob per 1k data. |
| 00:21.07 | Marex | hno: not 64 ? |
| 00:21.17 | hno | no |
| 00:21.18 | Marex | hno: that'd make sense of the chips as 2048b + 128b oob |
| 00:22.12 | hno | U-boot complains about oob size on startup. "No oob scheme defined for oobsize 218" |
| 00:22.33 | hno | page size is 8192. |
| 00:22.51 | Marex | ugh |
| 00:22.54 | Marex | I see |
| 00:23.21 | Marex | hno: now it depends if the controller does the ECC already or you need to do it yourself |
| 00:23.31 | Marex | also check nand_base.c |
| 00:23.56 | hno | The controller does ECC, but we only know how to activate that when using DMA which we are not doing yet. |
| 00:26.42 | hno | On sector 7 (0-7) it seeks to 0x21e4 to read 60(dec) bytes of ECC data. |
| 00:27.34 | hno | which do not match the oobsize reported above. |
| 00:30.36 | hno | When our code reads the OOB data from the nand in one 0x400 chunk it gets 488 bytes of non-0xff data then all 0xff. |
| 00:32.19 | hno | datasheet says 448. |
| 00:33.42 | hno | Page size : 8,640 Bytes(8192+448 bytes) |
| 00:38.41 | hno | I think datasheet is wrong. 8 * 60 = 480 |
| 00:38.52 | hno | which is > 448 |
| 00:44.49 | hno | confusing. |
| 00:50.44 | *** join/#arm-netbook projectgus (~gus@spork.chainxor.org) |
| 00:51.06 | Marex | hno: I'd say check the datasheet for the NAND chip |
| 00:51.09 | Marex | that's usually right |
| 00:51.37 | *** join/#arm-netbook bfree (~niall@109.255.245.157) |
| 00:55.32 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 00:57.47 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
| 00:59.58 | slapin | hno: nand read fails because of bad block scan, just wait some time |
| 01:00.21 | slapin | hno: try nand read.oob, not dump.oob, on fresh boot. |
| 01:01.45 | hno | slapin, read.oob seems to work. |
| 01:02.34 | hno | Marex, in this case we have only found a preleminary datasheet. Says OOB size is 448, but Allwinner code is clearly using 480 bytes, and chip returns 488 bytes. |
| 01:04.06 | hno | I do not thing doing 480 bytes ECC calculcation would work if the chip actually has 448 bytes OOB as the datasheet says. |
| 01:04.30 | hno | or that the chip would return 488 bytes non-0xff data when read. |
| 01:04.55 | slapin | goes to bed |
| 01:05.01 | slapin | good night, all! |
| 01:10.00 | hno | Ah, right. No the datasheet does not say 448. It says "reserved". Missed one bit. |
| 01:12.56 | *** join/#arm-netbook stefanro1 (~stefan@p57B94083.dip.t-dialin.net) |
| 01:14.47 | Marex | huh ? |
| 01:14.52 | Marex | hno: so how much OOB is there ? |
| 01:14.59 | Marex | hno: I suspect 488 might be a typo in the software |
| 01:15.04 | Marex | 448 seems reasonable |
| 01:24.08 | *** join/#arm-netbook vinifm (~vinix@177.42.152.16) |
| 01:50.52 | hno | Marex, there is 488 bytes returned by the chip. and 480 actively used by working NAND ECC driver. |
| 01:53.14 | hno | Gah.. me no like Hynix datasheets. |
| 01:53.16 | Marex | hno: are you sure you're not reading another block of the NAND ? |
| 01:53.28 | Marex | check the jedec spec |
| 01:53.43 | Marex | hynix might be shit, but macronix is even worse |
| 01:53.56 | hno | Marex, yes I am sure. |
| 01:55.33 | hno | skipping forward to another slightly later chip with released datasheet from 2010 the oob size bits returned is still "reserved". Datasheet for that chip says it has 488 in some plavces, 448 in others.. |
| 01:58.00 | Marex | check the jedec spec |
| 01:58.05 | Marex | they're quite coherent on this |
| 02:03.07 | slapin | Marex, it returns 6-byte ID, like samsung, where to get oob size, do you understand? really? |
| 02:03.12 | slapin | back to sleep |
| 02:04.07 | slapin | wake me at 8:00 UTC, please |
| 02:10.43 | Marex | slapin: what the fuck |
| 02:11.00 | Marex | slapin: it does return some ID, but the block size is usually pretty much coherent |
| 02:11.15 | Marex | and there should be some jedec standard for it |
| 02:15.49 | slapin | Marex: you're too optimistic re flashes |
| 02:16.06 | slapin | Marex: it missed 2 relevant bytes from ID |
| 02:16.42 | slapin | Marex: I might be drunk and half asleep since 6am here, but I'm sure I'm right |
| 02:17.18 | slapin | Marex: because of that, the settings are hardcoded in u-boot code (nand_base.c near line 2700) |
| 02:18.23 | slapin | is back to sleep, will read backlog later |
| 02:18.36 | Marex | slapin: the ID is usually 8 bytes ;-) |
| 02:18.41 | Marex | slapin: and you can't depend on it |
| 02:18.50 | Marex | http://www.linux-mtd.infradead.org/nand-data/nanddata.html |
| 02:18.53 | Marex | read that |
| 02:19.00 | Marex | hno: ^ |
| 02:19.22 | Marex | hno: do you see 488 anywhere ? |
| 02:19.35 | slapin | Marex: but for these samsung and hynix chips IDs are 6byte (last 2 of 8 repeat firsdt 2_ |
| 02:22.53 | Marex | slapin: yes they do ... and there're some special cases |
| 02:23.05 | Marex | slapin: but that's completely irelevant to our discussion ! |
| 02:23.12 | Marex | slapin: the topic is the size of the block and OOB area |
| 02:23.21 | Marex | slapin: go drink, fondle boobs and sleep ;-D |
| 02:23.30 | slapin | Marex: muhahahaha - HYNIX is not supported, and Samsung is supported it seems (but dunno if really tested). |
| 02:23.42 | Marex | slapin: what ? where ? |
| 02:23.47 | Marex | slapin: I don't understand you |
| 02:23.55 | slapin | needs to just cralw to bed |
| 02:24.05 | slapin | Marex: at your link |
| 02:24.24 | Marex | slapin: I suspect that's the list of chips that are tested with Linux |
| 02:24.36 | Marex | there're some hynix chips |
| 02:24.41 | Marex | they might be weird then |
| 02:24.46 | slapin | Marex: keyword is some |
| 02:24.55 | slapin | Marex: probably almost all |
| 02:25.00 | Marex | slapin: likely |
| 02:25.04 | slapin | Marex: but not that particular package |
| 02:25.11 | Marex | slapin: what chip is that ? |
| 02:25.16 | Marex | slapin: and why dont you ask in linux-mtd ?! |
| 02:25.31 | slapin | Marex: I don't have that chip, hno has |
| 02:25.38 | slapin | Marex: I have samsubng |
| 02:26.04 | Marex | I also have samsung chip ... but on a decent (and documented) controller :p |
| 02:27.10 | slapin | Marex: this controller is also decent and shiny like a naked virgin on seashore at night, but it never seen, like that virgin, a proper touch |
| 02:27.37 | Marex | slapin: what the fuck are you babbling about again ? :O |
| 02:27.41 | slapin | Marex: hardweare requires tender caring! |
| 02:27.46 | Marex | slapin: I completely lost you ... maybe I should get drunk as well |
| 02:27.57 | rz2k | damn x.org down again |
| 02:27.59 | Marex | slapin: ah |
| 02:28.01 | rz2k | :/ |
| 02:28.04 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 02:28.20 | Marex | slapin: but if you fsck that virgin, she won't be virgin anymore ... it's irreversible process |
| 02:28.36 | Marex | slapin: and that controller in A10 seems more like a sick old whore |
| 02:28.48 | slapin | ah, sorry folks, really need to go to sleep |
| 02:28.54 | Marex | ;-) |
| 02:28.56 | Marex | slapin: good night |
| 02:29.10 | slapin | good night, all! |
| 02:37.47 | *** join/#arm-netbook QingPei (~qingpei@inet-hqmc03-o.oracle.com) |
| 02:47.42 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 02:47.48 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 03:33.01 | rz2k | who wants xf86-video-mali running on 1.13+ xorg - here is what you need https://github.com/rzk/xf86-video-mali/commit/f427d89f9683e58c952b5f6a223c9d7cc845da5e |
| 03:58.31 | *** join/#arm-netbook uwe_ (~uwe_@dslb-178-010-043-001.pools.arcor-ip.net) |
| 04:02.35 | Sv | that's pretty cool rz2k |
| 04:04.02 | *** join/#arm-netbook avernos (~avernos@221.223.234.5) |
| 04:04.03 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
| 04:32.12 | Sv | going to try it now |
| 04:39.52 | *** join/#arm-netbook Quarx (~Quarx@178.74.74.143) |
| 04:42.23 | Marex | yay |
| 04:58.04 | *** join/#arm-netbook mSquare (~selvan@122.167.66.75) |
| 05:07.00 | *** join/#arm-netbook Sv (~Sv@unaffiliated/sv) |
| 05:48.03 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 06:01.35 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 06:16.51 | *** join/#arm-netbook enigma_ (~enigma@145.100.197.111) |
| 06:46.46 | *** join/#arm-netbook Sv (~Sv@modemcable190.180-203-24.mc.videotron.ca) |
| 06:46.46 | *** join/#arm-netbook Sv (~Sv@unaffiliated/sv) |
| 06:51.21 | *** join/#arm-netbook Ershov (~Thunderbi@89.163.11.110) |
| 07:00.39 | *** join/#arm-netbook DoiX (bc1a9967@gateway/web/freenode/ip.188.26.153.103) |
| 07:01.04 | DoiX | Hello, is anyone around? |
| 07:25.44 | hno | DoiX, yes |
| 07:27.07 | DoiX | Great! |
| 07:27.24 | DoiX | I have a problem with a LY-F1 tablet |
| 07:27.32 | DoiX | is this the proper place to ask for help? |
| 07:27.58 | hno | Marex, I don's see 488 anywhere around there, but MTD is also completely void of any code detecting page size and OOB size on these chips. The code that is there DO NOT match Hynix datasheets. |
| 07:28.37 | hno | Any Hynix datasheets only says "reserved" for the OOB size bit combination this chip reports. |
| 07:29.02 | hno | And the chip is with no doubt returning 488 bytes. And allwinner driver is with no doubt using 480 bytes. |
| 07:32.10 | DoiX | hno, maybe you can aid me. i flashed a rom on my LY-F1 tablet, the room seems to have completely erased the touch controller's memory. |
| 07:33.18 | DoiX | when trying to reflash the touch firmware i encounter a CTPM ID1 = 0x00 ID2 = 0x00 and "i_ret = 2" error, and from what i gathered from the source code means that the flash memory got fully erased |
| 07:33.26 | DoiX | including the vendor and product id |
| 07:33.46 | hno | DoiX, sorry, no idea. |
| 07:34.29 | DoiX | Awh another question then, do you happen to know something about the LED + LED - contacts on the A710 PCB? |
| 07:40.14 | hno | DoiX, no. But I would guess it's the PWM for the backlight. Anything connected there? |
| 07:40.47 | DoiX | No, unfortunately while diassembling the tablet a screw fell on them and made contact, setting the backlight to minimum |
| 07:41.05 | DoiX | disassembling* |
| 07:41.11 | *** join/#arm-netbook rellla (~rellla@p5B07832B.dip0.t-ipconnect.de) |
| 07:42.02 | DoiX | I've searched for the equivalent PCB's and saw that most have cables connected to those contact points, unfortunately i can't see where the cables are connected to at the other end |
| 07:56.29 | DoiX | So, do you, or anyone else here, have an idea as to where those cables connect? |
| 08:35.59 | hno | DoiX, you disassembled with the tabled powered on? |
| 08:37.09 | hno | If a screw fell on the backlight pads then very likely a fuse or even the backlight power driver have burnt. It's a high voltage circuit not reacting well to shorts. |
| 08:38.51 | DoiX | I plugged the tablet in the usb to see if the tablet still starts (i soldered diodes under the touch buttons). Thats when the screw fell. |
| 08:39.37 | DoiX | assuming neither of those things burnt, what else could it be? |
| 08:41.29 | DoiX | http://linux-sunxi.org/images/c/c2/Lyf1back.jpg reference pic of those cables, i'd still like to know where they head |
| 08:46.20 | hno | DoiX, follow them. |
| 08:47.20 | DoiX | i can't, my tablet didn't came with cables connected to those LCD points, i've only seen them in pics of other LY-F1&clones |
| 08:47.36 | DoiX | LED points* |
| 08:49.01 | hno | What kind of backlight do your tablet have? |
| 08:51.06 | hno | DoiX, do you have cables on the other two pads? WT+/WT- |
| 08:51.22 | DoiX | No |
| 08:52.02 | hno | Any cables at all in that area? |
| 08:52.15 | hno | Where do the backlight connect on yours? |
| 08:57.31 | techn | hno: here's with newer u-boot and mem params from .fex file |
| 08:57.33 | techn | http://pastebin.com/0PZmJpWr |
| 08:58.01 | DoiX | In that area only speaker cables. |
| 08:58.21 | techn | hno: wrong dram parameters? |
| 08:59.32 | DoiX | by backlight i assume you mean the LCD connector, mine connects to the connector left of where it says Realtek http://linux-sunxi.org/images/a/a3/LY-F1_pcb_front.jpg |
| 08:59.42 | techn | One boot freezed on |
| 08:59.42 | techn | <6>Serial: 8250/16550 driver, 8 ports, IRQ sharing disabled |
| 09:00.05 | techn | other boot crahed to disp_module_init |
| 09:00.37 | focus_well | Feasibility of putting multiple nand banks to A10 - if I wanted two lots of 4GB NAND banks and switch between them, is there going to be problems? |
| 09:02.07 | focus_well | I also wanted to allow a separate USB chip to grab the nand bus and program it freeing the board from flash bricking issues |
| 09:02.19 | focus_well | Any thoughts? |
| 09:02.53 | focus_well | Ideally 3 NAND banks - one for Android, one for alternative Linux and 3rd for experimenting. |
| 09:08.16 | focus_well | I'm thinking something like a future Penpod would benefit greatly from this if they graduated to building their own tablets. |
| 09:09.46 | focus_well | Ideal if a tablet came with eSata and then you can switch to the alternative nands to use the esata instead of being stuck with limitations of android |
| 09:10.29 | focus_well | At the same time, you can sell the tablet as an android, and a simple switch will convert it to a normal linux tablet. :-) |
| 09:13.24 | hno | techn, clearly something wrong. |
| 09:22.59 | techn | anyone got precompiled "A10-meminfo" ? |
| 09:26.26 | hno | techn, what? |
| 09:26.58 | techn | hno: I broke TX pad on PCB.. so I cant run "md.w 0x42400000 0x2084" :( |
| 09:27.00 | hno | focus_well, A10 devices are unbrickable. |
| 09:28.44 | hno | techn, there is an ancroid program to read the memory controller settings. |
| 09:29.02 | techn | hno: Yep.. "A10-meminfo" :) |
| 09:30.10 | *** join/#arm-netbook cheng (~cheng@175.139.154.152) |
| 09:32.11 | hno | techn, that is available precompiled in the same git repository as it's source. |
| 09:32.55 | techn | hno: thanks.. Didn't notice :D |
| 09:36.31 | focus_well | hno: true I heard that. My interest is also to have more than one OS on a tablet and switch rapidly between them. Another motive for multiple flash banks is to get that built as a module so that if other CPUs can be made into SO-DIMM module, then they can all be programmed with one standard USB interface and software by hardware developers without having to rely on lots of different software for different chips. |
| 09:39.22 | focus_well | programming the flash should the simplest of things - and it used to be true when EPROMs could be pulled and reprogrammed - but today its soldered to the board and requires software, and this software may not work on all platforms. |
| 09:40.31 | *** join/#arm-netbook vinifm (~vinix@187.114.112.84) |
| 09:43.40 | DoiX | focus_well, maybe you know how to answer this. The EEPROM from my touchscreen controller got erased during an official firmware install (live suite) i tried reflashing it manually but the TS still doesn't work, it seems that the vendor id and product id got erased from the EEPROM, got any ideas? |
| 09:44.10 | techn | hno: dram params seems to be correct |
| 09:44.31 | techn | I gotta go.. back on sunday |
| 09:47.04 | focus_well | doix: so are you saying everything except touch screen works or that nothing works? |
| 09:47.20 | DoiX | except the touchscreen |
| 09:47.43 | hno | DoiX, didnt you just said that the backlight is also broke? |
| 09:47.56 | DoiX | thats another problem, and old one i got accustomed to |
| 09:48.48 | focus_well | that suggest the ts software is not working with the new image - may be a different chip to the original. do you have old image to trying going back? |
| 09:49.05 | DoiX | yes, i reverted to the old image |
| 09:49.25 | DoiX | still nothing, i tried most images that were compatible with my tablet model |
| 09:49.43 | DoiX | i tried manually flashing the firmware (same one as the controller is) |
| 09:50.22 | focus_well | doix: do you have more than one tablet to try swapping hardware around? |
| 09:50.31 | DoiX | i'd wish :( |
| 09:50.49 | focus_well | any chance of buying one? |
| 09:51.14 | DoiX | maybe for christmas |
| 09:51.27 | DoiX | but i doubt i'll get one compatible with my current tablet |
| 09:51.50 | DoiX | ironically i changed the touchscreen of my tablet a month ago after my nephew shattered it.. |
| 09:52.52 | DoiX | this is the error i encounter during manual firmware flashing Step 3: CTPM ID,ID1 = 0x0,ID2 = 0x0 ID1 = vendor, ID2 = product according to the sources in the kernel |
| 09:53.05 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 09:53.20 | focus_well | the only other thing I can think of is the touch itself is resistive controller built into A10, but many tablets use an external capacitive controller. Its possible all the images you are trying are resistive while what you want is capacitive - long shot! |
| 09:55.50 | DoiX | the LY-F1 original firmware is capacitive, ft5x06 controller, thats the one i flashed and messed the TS up (it wasn't the first time i flashed it, everything worked, i don't know what happened now) |
| 09:56.02 | slapin | ah, no, yet another day :( |
| 09:56.03 | DoiX | i found in the datasheet of the ts controller that it has a /reset pin |
| 09:56.41 | DoiX | but it doesn't specify what exactly it resets or how to use it, other than "external low signal" |
| 09:57.21 | slapin | Marex: H27UBG8T2BTR |
| 09:57.29 | focus_well | doix: you would reset it if you pulled the batteries, wait 10 seconds and reconnect |
| 09:58.13 | DoiX | "/RST: an external low signal reset the chip." http://www.displayfuture.com/Display/datasheet/controller/FT5x06.pdf |
| 09:59.08 | DoiX | well, the battery is soldered to the PCB so i have to try it when i get home |
| 10:01.18 | focus_well | doix: exernal reset means sending a low signal on that pin. that pin is connected to the cpu somewhere - may be a gpio pin. so finding and setting the correct gpio pin through software will force a manual reset without needing to take battery off. |
| 10:01.32 | focus_well | shame the battery is soldered - normally they are connectorized |
| 10:02.05 | DoiX | since i'll be desoldering it when i get home, i'll hook it up with connectors for future cases :) |
| 10:02.07 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 10:02.51 | focus_well | alternative - but extreme high risk!!!! - is to take a wire and quickly short the wire to the ground - but as i say it is VERY HIGH risk |
| 10:03.15 | DoiX | how would i find the gpio pin? i searched for the forsaken datasheen of the pcb board but to no avail |
| 10:04.00 | DoiX | hm, wouldn't the short option apply to /rst pin as well? |
| 10:04.08 | focus_well | doix: if you don't have a circuit diagram, it will be next to impossible on a multilayer board |
| 10:04.58 | focus_well | doix: short the reset pin to ground - but as i say VERY RISKY! - better to put connector into battery and do that thing than damage the board. |
| 10:04.59 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 10:05.22 | DoiX | you're right |
| 10:06.49 | focus_well | if you google for "CTPM ID,ID1 = 0x0" there is tons of info that comes up with similar problems - so its a well travelled bug/feature. |
| 10:07.47 | DoiX | hm, i wonder if it's possible to build some sort of programmer for the eeprom in the cotroller itself |
| 10:12.04 | focus_well | doix: probably best if software running in the CPU did that |
| 10:12.30 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 10:12.46 | DoiX | i see, well thanks for the help and info. much appreciated! i'll report back this evening if i was successful |
| 10:12.56 | DoiX | good day to all |
| 10:12.59 | focus_well | :) |
| 10:16.23 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 11:07.21 | *** join/#arm-netbook arokux (~arokux@merkur178.inf.uni-konstanz.de) |
| 11:22.04 | *** join/#arm-netbook ibrah (~chatzilla@212.49.88.96) |
| 11:27.17 | hno | 10 seconds press on the power button completely powers off the CPU exceot for RTC. |
| 11:36.05 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 11:37.53 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 11:48.05 | slapin | hno: how it is going? |
| 11:48.15 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 11:50.21 | hno | just back from the doctor. Not looking too bad, but very tired. |
| 11:51.21 | hno | and starting to get the hang of how to use the logic analyser. |
| 11:52.33 | hno | slapin, anything particular you want me to investigate now that I have our code accepting the NAND chip? |
| 11:52.43 | *** join/#arm-netbook FreddyAV (~FreddyAV@ppp118-210-43-14.lns20.adl2.internode.on.net) |
| 11:52.46 | slapin | hno: OOB |
| 11:53.00 | slapin | hno: mostly, nand dump |
| 11:53.01 | hno | I did add proper Hynix ID decoding to nand_base. It's not the same as Samsung. |
| 11:53.26 | hno | but Hynix datasheets a bit misleading as well. |
| 11:53.36 | slapin | hno: I think the data for Samsung is wrong too, which requires checking |
| 11:53.49 | slapin | hno: where have you got them? |
| 11:53.56 | slapin | hno: I mean datasheets |
| 11:54.16 | hno | Google searches. |
| 11:54.25 | FreddyAV | did someone want to download my script.bin and the output from a10-meminfo-static from my MK802v2? I don't really know how to add it to the project... |
| 11:54.33 | slapin | hno: your google-fu is better than mine |
| 11:54.50 | hno | Well, the datasheets for the chip I have I got from Olimex. |
| 11:55.00 | hno | googled some other similar chips. |
| 11:55.33 | hno | datasheet for this chip do not show up in google searches. |
| 11:56.30 | hno | but content of the datasheet is the same, just different chip id. |
| 11:57.13 | hno | Have not managed to get the randomizer to make any effect. Wonder if that is only available in DMA operations. |
| 12:06.15 | slapin | hno: lets concentrate on proper handling of OOB.As for randomizer - it might be related to flag about swapping in CMD register, NFC_DATA_SWAP_METHOD |
| 12:06.55 | slapin | hno: but without proper ground of basic support it might be too hard to achieve anything |
| 12:07.14 | slapin | hno: so lets make normal mode stable |
| 12:15.45 | slapin | hno: then we rewrite ecc functions and add ecc switching command. (even raw read wuthout ecc is "ecc function", e.g page read), this will make code a bit cleaner (but more complex might be) |
| 12:18.31 | slapin | hno: also if you find a better way to detect your chip, so to be more generic, that'd be even greater. And it'd d be cool if we could find some a10/a13 board with micron package. |
| 12:19.27 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 12:19.59 | slapin | as I see the controller now, it seems to be not hardcoded for 4GB chips, only for min 1K pages, so it might be interesting to solder 512MB SLC NAND and see how it will work. |
| 12:20.46 | *** join/#arm-netbook slash_random (~david@host106.190-136-105.telecom.net.ar) |
| 12:27.46 | hno | slapin, the cubieboard have another nand which is detected fine. But not easy to connect the logic analyzer there. |
| 12:42.35 | hno | slapin, I think we may need to go the DMA route to actually make this work. |
| 13:10.48 | *** join/#arm-netbook grimes99 (~du2@host-78-145-43-103.as13285.net) |
| 13:14.39 | vinifm | hi, I reread the code and took what was unnecessary... almost everything I had added :) |
| 13:18.09 | vinifm | what is missing 8250_sunxi.c is uart_add_one_port() |
| 13:32.42 | slapin | hno: OOB comes first |
| 13:33.20 | slapin | hno: then we rewrite code and make ECC work whatever way we can |
| 13:36.02 | slapin | hno: I don't think my Samsung chip is fully supported, too, as 218-byte ECC looks weird |
| 13:53.28 | *** join/#arm-netbook QingPei (~qingpei@124.64.127.192) |
| 13:54.25 | *** part/#arm-netbook QingPei (~qingpei@124.64.127.192) |
| 13:56.51 | *** join/#arm-netbook slash_random (~david@host106.190-136-105.telecom.net.ar) |
| 14:05.43 | *** join/#arm-netbook tzafrir (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 14:07.54 | *** join/#arm-netbook grimes99 (~du2@host-78-145-43-103.as13285.net) |
| 14:42.31 | slapin | might be kicked off from work on monday, damn wavecom stuff :( |
| 14:44.14 | *** join/#arm-netbook tzafrir (~tzafrir@bzq-218-155-146.cablep.bezeqint.net) |
| 14:48.45 | libv | toys! |
| 14:49.30 | libv | and no, olimex did not warn that something was sent |
| 14:50.21 | *** join/#arm-netbook slash_random (~david@host106.190-136-105.telecom.net.ar) |
| 14:51.51 | slapin | got non-working power bank |
| 14:52.24 | slapin | it flashes leds when powered over USB, but shows nothing when not powered to USB |
| 14:52.56 | mnemoc | loosy connector? |
| 14:53.14 | mnemoc | sometimes they forget to solder them correctyl :| |
| 14:59.02 | *** join/#arm-netbook L84Supper (~Larch@unaffiliated/l84supper) |
| 15:20.19 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 15:20.33 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 15:27.43 | *** join/#arm-netbook stefanro (~stefan@p57B94083.dip.t-dialin.net) |
| 15:30.08 | oliv3r | there, updated tons of CCM pages |
| 15:50.00 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 15:50.14 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 16:07.24 | *** join/#arm-netbook vinifm (~vini@177.19.132.23) |
| 16:07.53 | *** join/#arm-netbook t0dbld1 (~t0dbld@d192-24-12-19.try.wideopenwest.com) |
| 16:08.01 | slapin | oliv3r: where? |
| 16:11.45 | focus_well | If I wanted to put two or more A10 CPUs into a PCB and mux the video to a single LCD, is there going to be any problem? Simple glue logic for the muxing. |
| 16:13.14 | focus_well | What I want to do is have one running as android, a second one running as a normal Linux device and a third running as a minimalist server. |
| 16:13.43 | focus_well | I imagine the touch pad signals will also get muxed. |
| 16:14.30 | focus_well | The A10 is so cheap it is possible to do that. |
| 16:14.59 | focus_well | When playing games I imagine I parallel them up to boost performance. |
| 16:15.08 | L84Supper | focus_well: it can be made to work. The main concern would be floating inputs to the LCD while switching between outputs |
| 16:15.33 | focus_well | Its multi-core but not as you know it! :D |
| 16:16.55 | *** join/#arm-netbook slash_random (~david@host106.190-136-105.telecom.net.ar) |
| 16:16.56 | focus_well | L84Supper: the muxing is done electronically by mux glue logic - not physically - physical would leave floating inputs |
| 16:17.26 | L84Supper | I understand, you just need to design your glue properly |
| 16:18.17 | focus_well | A laptop size device plenty of space for 3 or more cores and mux logic |
| 16:18.45 | *** join/#arm-netbook t0dbld1 (~t0dbld@unaffiliated/t0dbld) |
| 16:19.30 | L84Supper | it's just a KVM with 3 PC's and one display |
| 16:21.50 | focus_well | Correct - so you got choice in a compact device. I love android - but that much, and I love headless servers, but again not that much, and I prefer standard linux distro for everything else. |
| 16:23.08 | focus_well | Nobody makes them because they are not commercial product - but fun for engineers :-) |
| 16:32.07 | focus_well | What to do? I just start drawing KiCAD drawings for SoM module and I find all the boards have been designed by ding dongs! Is it me? Or are all these so called electronic engineers are just following each other with copying rubbish instead of designing? |
| 16:32.15 | *** join/#arm-netbook merbzt (~benjamin@c-94-255-220-30.cust.bredband2.com) |
| 16:33.52 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 16:34.43 | focus_well | Some A10 boards put capacitors a long way from where they should be. Others have put in excessive components - probably something done to correct a problem and then endlessly copied for no reason. |
| 16:38.43 | focus_well | Weekend is here! Time to get down to some real circuit design! |
| 17:15.29 | *** join/#arm-netbook tmerle (~tmerle@bea31-1-78-226-152-136.fbx.proxad.net) |
| 17:37.55 | *** join/#arm-netbook cat_x301 (~cat@gprs-internet-fffcee00-155.dhcp.inet.fi) |
| 17:42.49 | slapin | Do anybody have K9GBG08U0A-SCB0 datasheet? |
| 17:42.52 | slapin | hno: |
| 17:47.54 | *** join/#arm-netbook galex-713 (~user@248.143.8.93.rev.sfr.net) |
| 17:48.04 | galex-713 | Hi |
| 17:51.00 | galex-713 | I have read that there are Rhombus-tech computers wich are more powerfull than the RasberryPi and wich are directly usable in the same way |
| 17:51.21 | galex-713 | Where could I find it ? |
| 17:52.07 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 17:54.21 | *** join/#arm-netbook t0dbld1 (~t0dbld@d192-24-12-19.try.wideopenwest.com) |
| 17:56.41 | galex-713 | *it? |
| 18:00.23 | Marex | slapin: its on the samsung website (but use google to search it, it's chaos) |
| 18:00.40 | Marex | galex-713: what do you expect from such device ? |
| 18:08.19 | galex-713 | Personnal server |
| 18:10.59 | galex-713 | (mail, ftp, web, sql, irc, jabber, sip, ssh on GNU/Linux) |
| 18:11.21 | slapin | Marex: nothing like that on samsung site |
| 18:12.23 | galex-713 | I expect a mini computer board like the RaspberryPi one |
| 18:18.13 | galex-713 | (Because it's tiny, low-cost, low-consume and it don't make noise) |
| 18:18.28 | galex-713 | *doesn't |
| 18:19.13 | galex-713 | Marex: Where can I found something such that ? |
| 18:25.38 | Turl | galex-713: I guess a Mele or a Cubieboard might fit your usecase |
| 18:27.46 | *** join/#arm-netbook The-Compiler (~compiler@ubuntuusers/supporter/the-compiler) |
| 18:28.48 | galex-713 | Ok |
| 18:29.18 | galex-713 | Oh… 60$… It is not so low-cost… ^^" |
| 18:32.06 | rm | galex-713, $39 for the MK802 + $7 for Ethernet adapter if you need wired network |
| 18:32.08 | Marex | Turl: it'll be too weak |
| 18:32.12 | Marex | Turl: and not enough ram |
| 18:32.24 | galex-713 | Cool… =D |
| 18:32.46 | Marex | galex-713: get yourself some Trimslice or something |
| 18:33.00 | Marex | galex-713: or nitrogen6x ... they're performant |
| 18:33.13 | Marex | or maybe panda if you're looking for cheap crap |
| 18:34.45 | mnemoc | Marex: he considers $60 with shipping expensive |
| 18:36.58 | rm | Trimslice < $199? |
| 18:36.59 | galex-713 | I've something like 80€… |
| 18:37.10 | hno | slapin, the thing is, from experiments, traces and code reading I know very well how to read a full block with ECC & randomizer using DMA. But not without DMA. |
| 18:38.11 | hno | Well, the controller do read 2KB just fine, but can't seem to access it. |
| 18:40.01 | hno | Not sure what value there is in understanding to read the raw OOB if we can't understand what is there. |
| 18:41.17 | galex-713 | Marex: rm: All of this are directly usable in the same way that the RaspberryPi? |
| 18:42.45 | rm | I'm tempted to say "If you have to ask, then no." |
| 18:43.01 | rm | but yeah, sort of - http://romanrm.ru/en/a10/mk802-server |
| 18:44.44 | vinifm | someone know which the define for /* Transmitter Holding Register */, the closest I found was #define UART_TFL 0x04 |
| 18:54.05 | *** join/#arm-netbook drachensun (~drachensu@142.196.83.182) |
| 18:58.01 | hno | vinifm, offset 0. |
| 18:58.34 | hno | The register offsets are the same as for 16550., plus some small bits. |
| 18:58.55 | vinifm | hum, so #define UART_TX0/* Out: Transmit buffer */ |
| 19:00.17 | hno | https://github.com/amery/linux-allwinner/commit/da223800ff32452d20d21d9b7677f5e2a3cf9394 |
| 19:01.19 | hno | Just remember that values are *4 compared to 16550 / 8250. |
| 19:01.29 | hno | due to how it's hooked to the CPU bus. |
| 19:06.14 | *** join/#arm-netbook slash_random (~david@host106.190-136-105.telecom.net.ar) |
| 19:07.45 | vinifm | ok, thanks |
| 19:09.57 | hno | Nice, math do add up. OLS reports NAND clock frequency as 93,727KHz and math based on clock settings says 93,750KHz. Not too far off. |
| 19:10.03 | *** join/#arm-netbook ibrah (~chatzilla@41.223.57.78) |
| 19:10.33 | hno | and no idea how exact the OLS internal clock is. |
| 19:15.49 | *** join/#arm-netbook jas-hacks (~mtx512@46-64-24-82.zone15.bethere.co.uk) |
| 19:16.12 | *** join/#arm-netbook focus_it (~focus_it@cpc2-dals6-0-0-cust1005.hari.cable.virginmedia.com) |
| 19:29.57 | *** join/#arm-netbook alcides (~alcides@177.97.36.207.dynamic.adsl.gvt.net.br) |
| 19:29.57 | *** join/#arm-netbook alcides (~alcides@unaffiliated/alcides) |
| 19:40.06 | Turl | mnemoc: I added links to the merges upstream for milestone 1 :) http://linux-sunxi.org/Mainlining_Effort |
| 19:42.54 | libv | *sigh* |
| 19:46.09 | hno | libv? |
| 19:46.23 | libv | porting to 3.9, mainlining |
| 19:46.33 | libv | all a gigantic waste of time atm |
| 19:46.38 | hno | not at all. |
| 19:46.44 | libv | oh? |
| 19:47.19 | libv | hno: we have no clue what these nasty messes are doing, and we have little insight in how they work |
| 19:47.31 | libv | porting it forward is just going to surreptitiously break more stuff |
| 19:47.31 | *** join/#arm-netbook ibrah (~chatzilla@41.223.57.76) |
| 19:47.36 | hno | the things being mainlined is well understood. |
| 19:47.39 | libv | so it is quite counterproductive |
| 19:49.08 | hno | You keep saying so. And I violently disagree. But please do not let these events distract you from what you are doing. |
| 19:50.25 | hno | Having core SoC support mainline is important, even if disp or even usb is quite far off the map of being mainlined. |
| 19:54.35 | *** join/#arm-netbook simosx (~simosx@178.128.116.24.dsl.dyn.forthnet.gr) |
| 19:54.39 | *** join/#arm-netbook simosx (~simosx@ubuntu/member/simosx) |
| 19:58.41 | libv | so we will quickly get to a point where disp and other tough bits are completely out of sync |
| 19:59.15 | *** join/#arm-netbook grimes99 (~du2@host-2-96-62-109.as13285.net) |
| 19:59.49 | RaYmAn | you said yourself that you made it in a way where it would be super easy to rebase onto a new kernel. That it pretty much didn't depend on anything outside (bar perhaps some minor gpio/pinmux stuff). |
| 20:00.02 | RaYmAn | If that's the case, it should be easy to rebase your work and others work onto mainline as it progresses. |
| 20:00.15 | RaYmAn | or rather, once it progresses sufficiently. |
| 20:00.21 | libv | i made what in a way that makes it easy to rebase? |
| 20:00.35 | libv | made as in past tense. |
| 20:00.49 | RaYmAn | s/make/are making/ |
| 20:01.12 | libv | RaYmAn: and until that point is reached? |
| 20:01.51 | RaYmAn | Not everyone needs e.g. disp |
| 20:02.05 | libv | then we better rm -rf it right now |
| 20:02.21 | RaYmAn | no, but there's no reason to hold back just because disp isn't done. |
| 20:02.31 | Turl | libv: see it this way, if we all stay at 3.0, eventually all would be nonforwardportable |
| 20:02.33 | libv | RaYmAn: in time... |
| 20:02.40 | Turl | it's better if we merge stuff as it's finished so it doesn't rot |
| 20:02.51 | libv | i will be proven right on this |
| 20:03.24 | RaYmAn | well, you're the one with the disp/mali code, so you are certainly in a position to prove whatever you want. |
| 20:03.41 | RaYmAn | code and/or knowledge. |
| 20:04.22 | RaYmAn | It's obvious that not everything in this platform is anywhere near ready for mainline. But that doesn't mean we can't put in what is and then rebase the current mess of affairs ontop. |
| 20:04.26 | RaYmAn | if so desired. |
| 20:05.21 | libv | well, first off, all of this means that the people with the already tough tasks of dealing with the most horrible code in this tree, will have an even tougher task |
| 20:05.22 | RaYmAn | I see your arguments - it will probably cause some headaches at some point, but that doesn't make it worthless at all. It's not mutually exclusive. |
| 20:05.49 | libv | nice motivator. |
| 20:06.12 | RaYmAn | but in any case, no one is forcing *you* to move to mainline. You can perfectly well stay on 3.0 and work there all you want. :) |
| 20:06.37 | libv | this is what will happen. |
| 20:06.53 | libv | and every other tree will come without disp/mali |
| 20:07.03 | libv | and other tough bits |
| 20:08.20 | libv | which will then keep a large portion of the users of this code on 3.0 |
| 20:08.21 | slapin | hno: as I understand, the controller reads data by 1k chunks even with DMA |
| 20:09.24 | libv | and then, in about a years time: http://lists.infradead.org/pipermail/linux-arm-kernel/2012-February/083088.html |
| 20:09.55 | slapin | hno: also, there's additional SRAM for OOB, might be the clue to ECC/randomizer thing. |
| 20:13.45 | RaYmAn | libv: aside from people possibly giving up maintaining it, the situation you describe is clearly what is expected. And which everyone is OK with. |
| 20:14.32 | libv | RaYmAn: ok. |
| 20:16.28 | *** join/#arm-netbook madmalkav (~Hamlet@188.86.253.69) |
| 20:17.35 | Marex | galex-713: rpi is overhyped shit |
| 20:19.36 | slapin | hno: are you here? I'd like to make clear the meanings of registers, to resume the details. so we have TIMING_CTL and TIMING_CFG of unknown meaning, ADDR_HIGH and ADDR_LOW, which are used with normal command, written at 0-th offset of CMD. SECTOR_NUM of unknown meaning, CNT, which counts bytes read or written, CMD, which contains first command and flags, RCMD_SET, with helper commands for reading, of which NFC_READ_CMD is used to read data (30 or |
| 20:21.26 | Marex | libv: you're free to do whatever you want ... do it and don't look down on other peoples' work ... it's free software, you're _free_ to do whatever you want with it (you should not forget that) |
| 20:24.13 | libv | Marex: i'd rather see people do useful things than starry-eyedly running after fetishes. |
| 20:24.43 | libv | Marex: read up on the openchrome vs unichrome fork. |
| 20:25.35 | RaYmAn | the issue is, who decides what's useful? |
| 20:26.14 | *** join/#arm-netbook focus_it (~focus_it@cpc2-dals6-0-0-cust1005.hari.cable.virginmedia.com) |
| 20:26.22 | libv | RaYmAn: the people writing code |
| 20:26.44 | slapin | Marex: I can't find my nand on samsung site - it is mentioned only in product selection guides :( |
| 20:26.45 | libv | but i'd rather see people writing real code than doing busywork that long term helps noone |
| 20:27.03 | slapin | Marex: all the rest are fine, but not this one |
| 20:27.44 | slapin | Marex: where have you found it, please give links |
| 20:34.33 | *** join/#arm-netbook specing_ (~specing@unaffiliated/specing) |
| 20:36.14 | *** join/#arm-netbook Luminary (~Luminary@176.107.248.10) |
| 20:39.19 | *** part/#arm-netbook specing_ (~specing@unaffiliated/specing) |
| 20:40.04 | Luminary | Hello, I have one question about SoC Allwinner A10: |
| 20:43.38 | Marex | libv: so you decide what is useful ? |
| 20:43.50 | Marex | libv: good ... please turn around and go do what is useful, thank you |
| 20:44.08 | slapin | hno: samsung tells us 8KB + 640 bytes |
| 20:44.10 | Marex | slapin: dang :/ |
| 20:44.33 | Marex | slapin: they usually released datasheets ... try trimming down the name a bit, something usually surfaces |
| 20:46.00 | galex-713 | Srry I'm went away to eat. Where can I find hardware characteristics of all those mini-computer to compare them? |
| 20:46.08 | Luminary | Hello, I have one question about SoC Allwinner A10: |
| 20:46.08 | Luminary | I have tablet on this SoC with mali 400 GPU, when i build xf86-video-mali driver i see in glxinfo the following: |
| 20:46.08 | Luminary | direct rendering: Yes |
| 20:46.08 | Luminary | renderer : Software Rasterizing |
| 20:46.08 | Luminary | OS: Ubuntu 12.04 |
| 20:46.10 | Luminary | I would like to know how to make it work.. |
| 20:46.32 | slapin | Marex: do you remember, how to properly hardcode pages/oob sizes for NANDs in u-boot? |
| 20:47.01 | slapin | Marex: I can't beleive it is assumed to be done in that mess at nand_base.c:27xx |
| 20:47.45 | Marex | slapin: ain't there some table for these ? |
| 20:47.52 | Marex | slapin: lemme take a look |
| 20:48.10 | slapin | Marex: while it is easy to be done there, but that plase would easily turn into mess |
| 20:48.27 | Marex | slapin: that stuff is only to decode samsung flashes |
| 20:48.30 | Turl | Luminary: http://linux-sunxi.org/Mali400 would be a good start |
| 20:49.01 | Luminary | Turl, this not work |
| 20:49.13 | Luminary | Can anyone worked on this, and can tell me about this :) |
| 20:50.26 | slapin | Marex: weird, since 6-byte IDs seems to be not only from Samsung, but also from Hynix |
| 20:50.49 | Marex | slapin: patch is welcome ... doesn't it explicitly check for the sammy id ? |
| 20:50.55 | hno | slapin, the controller reads 2 * 1KB as told by the CNT register. It does this in 1KB chunks for ECC processing. |
| 20:50.56 | Luminary | I would describe everything in detail but do not know English |
| 20:50.57 | Marex | 2692 id_data[0] == NAND_MFR_SAMSUNG && |
| 20:51.24 | Marex | hno: so your ECC is split into 8 1k blocks with something inbetween ? |
| 20:51.28 | Marex | (something ... OOB) |
| 20:52.11 | hno | Marex, read 1KB data, seek to OOB, read 60B OOB, seek back to 0x200, read 1K data, seek to OOB+60B read, 60B OOB. |
| 20:52.12 | Marex | depending on the OOB algo, you can compute how many OOB data are needed to do BBM on 1k block |
| 20:52.23 | Marex | hno: yum |
| 20:52.30 | Marex | slapin: what signal analyzer do oyu use ? |
| 20:52.40 | hno | There is multiple ECC modes. This is how it behaves in the ECC mode selected for my Hynix chip. |
| 20:53.08 | hno | slapin uses some HP signal analyser. I use an OLS. |
| 20:53.09 | Marex | hno: huh ? |
| 20:53.15 | slapin | Marex: HP 16500C chassis, HP 16555A analyser |
| 20:53.15 | Marex | hno: there're usually only two possible ECC modes |
| 20:53.21 | Marex | BCH and Reed-Solomon |
| 20:53.24 | Marex | if I'm not mistaken |
| 20:54.12 | Marex | slapin: quite old one, right ? |
| 20:55.33 | slapin | hno: algorythm is not selected for NAND, it doesn't care much for NAND, it just uses that algorithm hardcoded in driver. and it is not ECC algorithm, it is ECC layout algorithm for this particular driver on this particular CPU. |
| 20:55.40 | slapin | Marex: yes |
| 20:55.48 | slapin | Marex: circa 1993 |
| 20:57.26 | Marex | slapin: I still believe there is a hardware to do the ECC |
| 20:57.35 | hno | slapin, Allwinner driver selects ECC mode depending on the detected chip. Exactly what the different ECC modes means is unclear. |
| 20:58.07 | *** join/#arm-netbook myfluxi (myfluxi@dslb-088-077-213-183.pools.arcor-ip.net) |
| 20:58.18 | Marex | hno: I'd say it's the size of ECC blocks and size of OOB data used for such block |
| 20:58.27 | Marex | hno: read up on BCH |
| 20:58.59 | *** join/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 21:00.39 | Luminary | http://pastebin.com/4ap3aNAb |
| 21:01.27 | Luminary | [ 283.009] (EE) AIGLX error: Mali DRI2 exports no extensions (/usr/lib/arm-linux-gnueabihf/dri/Mali DRI2_dri.so: undefined symbol: __driDriverExtensions) |
| 21:01.28 | Luminary | [ 283.010] (EE) AIGLX: reverting to software rendering |
| 21:01.54 | hno | Marex, probably correct. |
| 21:03.13 | hno | Seen ECC modes are 0 (majority), 1, 2, 3, 4. |
| 21:04.34 | hno | datasheet says BHC correcting up to 64 bit errors per 512 or 1024 bytes. |
| 21:04.39 | Luminary | How to fix it? I was so tired that don't know how it fix. |
| 21:05.59 | hno | Luminary, did you follow http://linux-sunxi.org/Mali400#Mali-400_X11_DRI2_drivers |
| 21:07.46 | Luminary | hno, yes. All modules loaded, all source compiled in host arm with no error, but linux distrib is ubuntu 12.04 |
| 21:08.57 | Luminary | libs - r3p1 armhf |
| 21:10.35 | hno | Luminary, did you get the right r3p1 libs? There is two r3p1 builds, one with X11 one without. |
| 21:11.16 | Luminary | I do not know much xorg so the problem may be on the surface. |
| 21:11.29 | Luminary | hno, with x11 |
| 21:12.46 | *** part/#arm-netbook jas-hacks (~mtx512@46-64-24-82.zone15.bethere.co.uk) |
| 21:13.09 | hno | I don't know which Linaro release these was tested on. |
| 21:13.17 | Luminary | hno, es2gears, glcompbench and glmark2-es2 working on X11. Others crash. |
| 21:16.41 | *** join/#arm-netbook tuliom (~tuliom@177.133.170.242) |
| 21:18.48 | *** part/#arm-netbook SouL_ (~SouL_@95.211.10.204) |
| 21:31.01 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 21:35.22 | *** join/#arm-netbook fluxi (myfluxi@dslb-088-077-213-183.pools.arcor-ip.net) |
| 21:36.05 | *** join/#arm-netbook slash_random (~david@host106.190-136-105.telecom.net.ar) |
| 21:36.29 | slapin | thinks gles is useless under normal Linux distro since little to no applications use it |
| 21:36.58 | slapin | hno: I think it is not exactly mode, but layout. |
| 21:37.46 | slapin | woorks on adding samsung chip to u-boot |
| 21:39.10 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 21:54.04 | *** join/#arm-netbook jlj (~jlj@109-104-24-9.customers.ownit.se) |
| 21:58.07 | Marex | slapin: good luck ... #u-boot might be a better place to discuss this shit |
| 22:06.25 | slapin | Marex: ah, I know the reason everything is so fucked up |
| 22:07.28 | slapin | Marex: http://paste.ubuntu.com/1380624/ this is funny, hahahahaha |
| 22:08.04 | slapin | it seems there will be some mtd patches over there... |
| 22:13.57 | slapin | Marex: this is somehow working: http://paste.ubuntu.com/1380641/ |
| 22:14.37 | slapin | Marex: interesting, if such chabge will break anything for anyone |
| 22:16.17 | Marex | slapin: does it work in linux ? |
| 22:16.32 | Marex | slapin: the mtd stack in u-boot is basically the same thing as is in linux |
| 22:17.55 | slapin | Marex: dunno |
| 22:19.13 | slapin | Marex: whatever, i found chip->init_size thingy not noticed before, and can move this stuff there to leave crap out of mtd core |
| 22:20.43 | slapin | hno: lets use chip->init_size for NAND init, which allows us setup page size properly for our controller, so it is really neat function, like sunshine after long polar winter... |
| 22:21.16 | slapin | hno: ping |
| 22:21.45 | slapin | hno: I can do it if you have your changes pushed |
| 22:21.51 | Marex | sunshine sunshine ... |
| 22:22.48 | slapin | Marex: or girl's boobs after long work rush, if that's better for you |
| 22:23.26 | *** join/#arm-netbook LK (~lk@host-78-147-118-225.as13285.net) |
| 22:23.32 | *** part/#arm-netbook LK (~lk@host-78-147-118-225.as13285.net) |
| 23:02.38 | *** join/#arm-netbook kamals (~kamals@5.43.203.151) |
| 23:20.05 | *** join/#arm-netbook CaCtus491 (~Kent@123-243-197-152.static.tpgi.com.au) |
| 23:25.45 | slapin | Marex: weird thing |
| 23:26.10 | slapin | Marex: my NAND reports ID different from what provided in datasheet |
| 23:26.20 | *** join/#arm-netbook FreddyAV (~FreddyAV@ppp118-210-43-14.lns20.adl2.internode.on.net) |
| 23:26.59 | slapin | first 3 matches, but 4th is 7a instead of 76, hence reserved code for OOB size |
| 23:27.15 | slapin | damn |
| 23:27.34 | slapin | samsung is not any better than hynix |
| 23:39.18 | Marex | slapin: that's probably a different bus width |
| 23:39.31 | Marex | it's some minor difference on the chip |
| 23:40.32 | slapin | Marex: no, the only difference is OOB size |
| 23:41.34 | slapin | I fail to find proper datasheet - does samsung makes any NAND chips yet? I can't find samsung flash chips on neither mouser nor digikey |
| 23:42.25 | slapin | probably these are special chips made for China, or made in China, and just marked as Samsung |
| 23:42.40 | slapin | but not really related to Samsung |
| 23:45.38 | Marex | yes ... samsung does nand chips for quite a while |
| 23:45.48 | Marex | slapin: btw don't speak about boobs, I'm depressed from girls today |
| 23:46.21 | Marex | slapin: SAMSUNG_NAND_IDs.pdf |
| 23:46.25 | Marex | google that file |
| 23:57.04 | slapin | Marex: http://lists.infradead.org/pipermail/linux-mtd/2012-September/044147.html |
| 23:58.00 | slapin | Marex: and hynix was added too, so just u-boot's mtd needs to be updated, for now init_size os ok, I think. |
| 23:58.47 | slapin | Marex: any way to politely ask people to update mtd in u-boot or at least add these patch series? |
| 23:59.14 | slapin | hno: http://lists.infradead.org/pipermail/linux-mtd/2012-September/044147.html and hynix is there, too |
