| 00:00.02 | *** join/#arm-netbook xenoxaos (~xenoxaos@developers.archlinuxarm.org) |
| 00:56.49 | *** join/#arm-netbook zewelor (~x@89-78-93-36.dynamic.chello.pl) |
| 01:52.24 | *** join/#arm-netbook Hexxeh (u1532@gateway/web/irccloud.com/x-fmkixslykoclzxdz) |
| 01:52.37 | *** join/#arm-netbook steev (u1383@gentoo/developer/steev) |
| 02:46.53 | *** join/#arm-netbook tekzilla (~jon@hmbg-4d06d437.pool.mediaWays.net) |
| 04:10.25 | *** join/#arm-netbook calris (~calris@d110-32-174-6.sbr801.nsw.optusnet.com.au) |
| 04:50.21 | *** join/#arm-netbook newbie (~kvirc@220-136-76-173.dynamic.hinet.net) |
| 04:52.33 | *** join/#arm-netbook Quarx (~Quarx@94.137.56.184) |
| 05:54.17 | *** join/#arm-netbook steev (u1383@gentoo/developer/steev) |
| 06:30.48 | *** join/#arm-netbook jlj (~jlj@109-104-24-9.customers.ownit.se) |
| 06:44.44 | *** join/#arm-netbook robws (~robws1@38.99.170.111) |
| 07:07.40 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 07:46.30 | *** join/#arm-netbook mSquare (~selvan@122.178.254.228) |
| 08:06.08 | *** join/#arm-netbook rvalles (~rvalles@unaffiliated/rvalles) |
| 08:08.39 | *** join/#arm-netbook rellla (~Thunderbi@p5B078046.dip0.t-ipconnect.de) |
| 08:19.59 | techn_ | WarheadsSE: chmod your /dev/ump |
| 08:21.59 | techn_ | or if you have done so.. try with that buf2 patch |
| 08:33.10 | *** join/#arm-netbook jlj (~jlj@109-104-24-9.customers.ownit.se) |
| 08:41.03 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 08:48.22 | *** join/#arm-netbook MMlosh (~MMlosh@2001:470:6f:23:99fc:20ff:5a87:7724) |
| 09:25.25 | *** join/#arm-netbook rellla (~Thunderbi@p4FE5606E.dip0.t-ipconnect.de) |
| 09:45.28 | *** join/#arm-netbook lkcl (~lkcl@host86-131-170-4.range86-131.btcentralplus.com) |
| 09:47.41 | *** join/#arm-netbook rvalles (~rvalles@unaffiliated/rvalles) |
| 09:53.33 | *** join/#arm-netbook cheng (~cheng@175.137.64.110) |
| 10:04.43 | *** join/#arm-netbook plan_b (~plan_b@ip-80-226-24-3.vodafone-net.de) |
| 10:09.00 | techn_ | mnemoc: this can be removed? wip/allwinner-v2.6.36-android/disp :) |
| 10:11.50 | mnemoc | techn_: ok |
| 10:12.19 | techn_ | what I noticed that there is only one hack to supress crash |
| 10:12.47 | mnemoc | yes |
| 10:12.50 | mnemoc | done |
| 10:14.37 | techn_ | how about these? /allwinner/amery/lichee-v2.6.36-dev, /amery/linux-2.6.36-sun4i ? |
| 10:15.12 | mnemoc | techn_: we still need the 2.6.36 ref for sun3i |
| 10:15.47 | techn_ | ok |
| 10:15.51 | RaYmAn | it also really doesn't matter much whether you delete the branch or not (Except for the github ui) |
| 10:15.58 | mnemoc | but I can rename them if the "amery" prefix bothers you |
| 10:16.24 | mnemoc | RaYmAn: eventually orphan heads get removed |
| 10:16.52 | mnemoc | and that implies losing data |
| 10:17.01 | techn_ | mnemoc: no.. I'm just cleaning my own repo.. and trying to find out valid branches |
| 10:18.18 | techn_ | RaYmAn: you can force compress which removes dead head's |
| 10:18.48 | RaYmAn | sure |
| 10:18.50 | techn_ | mnemoc: how about 3.3 branches? :) |
| 10:19.22 | mnemoc | techn_: there is work from steev there |
| 10:19.38 | mnemoc | techn_: which i don't want to trash until it's ported to 3.4 |
| 10:20.09 | mnemoc | but they are also part of our "attic" |
| 10:23.07 | RaYmAn | perhaps it's time to consider making a github "organisation" to put the "official repos" on, e.g. u-boot and kernel? then the more experimental can stay at amery and hno repos? |
| 10:24.09 | mnemoc | i would love too... but I fear about broken links |
| 10:24.41 | mnemoc | I still get people forking my uboot repo regarless the big warnings asking them to use hno's |
| 10:24.55 | RaYmAn | so clean it out? :P |
| 10:25.05 | mnemoc | hno's is a fork of mine |
| 10:25.13 | mnemoc | no clue how will github react |
| 10:25.26 | RaYmAn | it won't affect anything |
| 10:25.35 | RaYmAn | you can delete your repo and hno's will be unaffected. |
| 10:25.51 | mnemoc | i thought they were linked |
| 10:26.14 | RaYmAn | mm ,probably behind the scenes - but I'm 100% that github does the right thing |
| 10:27.57 | RaYmAn | it would be chaos if all forks went haywire if original repo was broken |
| 10:28.42 | mnemoc | fair point |
| 10:29.21 | RaYmAn | but rather than deleting, it would probably be better to remove all content and and make sure to link on to the proper repo |
| 10:29.32 | RaYmAn | so you don't break http links to it :) |
| 10:29.44 | mnemoc | that sounds like a good idea |
| 10:34.35 | cat1 | is it only me who gets this error http://sprunge.us/IXPP while compiling recent linux-sunxi-3.4? note that CONFIG_RTL8192CU_SW=m is used instead of mainstream driver. |
| 10:36.01 | mnemoc | cat1: yes, the driver is bound to android stuff deprecated in their 3.4 branch |
| 10:36.15 | mnemoc | we can either fix the driver, or trash it |
| 10:37.04 | cat1 | mnemoc: yeah, once we get rtlwifi working with fw :) |
| 10:37.24 | cat1 | actually i do not really remember, maybe that was working with 3.4.. |
| 10:37.28 | cat1 | but i doubt.. |
| 10:37.35 | mnemoc | we should move the usb_wifi_para handling into proper power management |
| 10:37.45 | mnemoc | cat1: try it ;-) |
| 10:38.01 | cat1 | mnemoc: but the problem i have seems not to be realted to pm |
| 10:38.41 | techn_ | mnemoc: could there be used kernel's own usb suspend logic? |
| 10:40.11 | mnemoc | cat1: it's not |
| 10:40.34 | mnemoc | cat1: but the reason for that driver to exist and be used instead of mainline is [usb_wifi_para] support |
| 10:40.50 | mnemoc | which enable/disable the usbc if the wifi module is loaded/unloaded |
| 10:41.00 | mnemoc | to save power |
| 10:41.56 | cat1 | mnemoc: ok, marked for the future :) anyway, the thing is that i am really annoyed by the fact that network connectivity is missing to the target.. |
| 10:42.24 | mnemoc | disable CONFIG_RTL8192CU_SW |
| 10:42.45 | cat1 | mnemoc: it is not fun :) |
| 10:42.57 | mnemoc | :) |
| 10:43.31 | cat1 | the real fun is to get mainline stuff working. |
| 10:44.28 | mnemoc | but fixing the fw problem on the mainline driver in 3.6 doesn't add value to sunxi =) |
| 10:45.00 | cat1 | mnemoc: actually it does as i suspect it does not work in 3.4 too! |
| 10:45.18 | cat1 | will figure it out soon as i am preparing 3.4 for testing |
| 10:46.53 | mnemoc | :) |
| 10:47.31 | cat1 | btw, yesterday took 4g modem for trial, results are good so far http://speedtest.net/result/2208940981.png |
| 10:48.12 | techn_ | cat1: nice.. looks good alternative for adsl |
| 10:50.10 | techn_ | http://www.speedtest.net/result/2209808481.png <= 20/1 adsl result |
| 10:50.22 | cat1 | techn_: aha, the only problem is that my house is located on the coverage boundary, so only 2bars on strength indicator :) dunno if it will cause any connection stability issues. |
| 10:50.59 | cat1 | techn_: yeah, i still have nokia paid adsl line -- restults are proximately in the same range as yours. |
| 10:51.31 | cat1 | techn_: but soon it will be terminated so i am looking for alternatives. |
| 10:51.41 | techn_ | cat1: external antenna would help? |
| 10:52.08 | cat1 | techn_: maybe, but i wont bother unless i experience real problems. |
| 10:52.49 | techn_ | repo size went from 800MB to 600MB with aggressive gc :) |
| 11:06.20 | *** join/#arm-netbook aaribaud (~aaribaud@2a01:e35:2eb9:20:250:43ff:fe01:dc73) |
| 11:06.39 | rz2k | techn_: could you please write step-by-step manual about how you got es2gears working, I've tested clean install on r2p4 with latest buf2 patch, I have same errors and black screens. tested both in-kernel and modules for hdmi/lcd/disp stuff. |
| 11:07.00 | rz2k | we have same config.h |
| 11:07.03 | *** join/#arm-netbook silentaa (~silentaa@2a01:e35:2eb9:20:250:43ff:fe01:dc73) |
| 11:08.30 | techn_ | rz2k: I compiled everythink like in the wiki.. except I didn't run autoreconf -vi command.. if I remember correctly |
| 11:09.22 | rz2k | yes, autoreconf fails r2p4 setup because ARM guys was too lazy to write working configuration, so they've supplied output from autoconf in package. |
| 11:10.20 | mnemoc | instead of "instructions" we should provide patch |
| 11:12.08 | techn_ | I have to leave.. back in 2 hours :( |
| 11:12.20 | rz2k | techn_: could you try clean install of r2p4 with kernel from -v2 + your buf2 patch and everything like in wiki? I believe you've did something that I miss. |
| 11:13.24 | rz2k | + using your default script.bin, for instance, script.bin from mele-vga package from dl.linux-sunxi.org has different clock_div than my default one. |
| 11:16.55 | *** join/#arm-netbook RITRedbeard (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
| 11:18.50 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 11:19.18 | *** join/#arm-netbook strong (~strong@86.108.10.58) |
| 11:35.23 | *** part/#arm-netbook strong (~strong@86.108.10.58) |
| 11:39.49 | *** join/#arm-netbook jlj (~jlj@109-104-24-9.customers.ownit.se) |
| 11:56.40 | *** join/#arm-netbook penguin42 (~dg@tu006.demon.co.uk) |
| 12:02.28 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 12:11.19 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 12:26.17 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 12:46.14 | *** join/#arm-netbook chz_ (~chz@27.26.47.156) |
| 12:58.42 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 13:06.59 | *** join/#arm-netbook Quarx (~Quarx@94.137.56.184) |
| 13:19.08 | techn_ | back |
| 13:24.44 | captainigloo | i'm trying to use nand-part of sunxi-tools |
| 13:24.55 | captainigloo | but i'm not able to get my nand back :( |
| 13:25.07 | captainigloo | somebody already uses it ? |
| 13:26.50 | mnemoc | after repartitioning you might need to reboot |
| 13:26.59 | mnemoc | i doubt the changes are taken immediately |
| 13:27.21 | captainigloo | yeah but they seems not to be taken at all |
| 13:27.35 | mnemoc | you have /dev/nand, right? |
| 13:27.40 | captainigloo | yes |
| 13:27.57 | mnemoc | uhm |
| 13:27.59 | captainigloo | http://pastebin.ca/2229559 |
| 13:28.33 | captainigloo | i'm trying to create a 16MB partitions, and a nand2 as 128MB |
| 13:28.48 | captainigloo | i put size in bytes |
| 13:29.45 | mnemoc | the tool itself skips nanda |
| 13:29.58 | mnemoc | you might need to patch it to let you modify it |
| 13:31.51 | captainigloo | hum |
| 13:32.57 | captainigloo | nandA is the first partition |
| 13:33.05 | captainigloo | and contains the "mbr" ? |
| 13:34.11 | plan_b | just enter: nand-part /dev/nand 'nand2 134217728' |
| 13:34.36 | captainigloo | same error |
| 13:34.55 | captainigloo | http://pastebin.ca/2229560 |
| 13:35.16 | captainigloo | if someone give the first 1024 bytes of nand , i could maybe recover the mbr ? |
| 13:35.36 | captainigloo | with dd |
| 13:42.16 | *** join/#arm-netbook hipboi (~hipboi@27.42.88.119) |
| 13:48.20 | *** join/#arm-netbook RITRedbeard (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
| 14:05.10 | *** join/#arm-netbook plan_b (~plan_b@ip-80-226-24-13.vodafone-net.de) |
| 14:07.00 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 14:09.17 | mnemoc | captainigloo: nanda is the boot partition, 16MB vfat. the partitions table comes before |
| 14:09.59 | captainigloo | mnemoc: plan_b send me the first 2048 bytes of the /dev/nand device |
| 14:10.20 | mnemoc | captainigloo: fixed the problem? |
| 14:10.20 | captainigloo | it seems that partition 0 which is actually nandA begin at offset 2048 |
| 14:10.29 | captainigloo | mnemoc: i'm waiting for the file :) |
| 14:11.17 | plan_b | just a moment .. my internet connections is unstable at the moment |
| 14:12.06 | mnemoc | plan_b: try https://filetea.me .... it's anonimous and not-storing |
| 14:14.04 | plan_b | 44% done |
| 14:14.04 | plan_b | so sloooowwww at the moment |
| 14:14.18 | captainigloo | for 2048 bytes ?! |
| 14:14.45 | plan_b | 65% |
| 14:15.01 | mnemoc | come one |
| 14:15.04 | mnemoc | on |
| 14:15.08 | captainigloo | it's less thant 2 ip packets :) |
| 14:15.08 | mnemoc | 2k?? |
| 14:15.32 | plan_b | I'm not at home at the moment ... no dsl |
| 14:15.33 | mnemoc | plan_b: dd if=/dev/nand of=head.bin bs=2048 count=1 |
| 14:16.00 | plan_b | 96% |
| 14:16.09 | *** join/#arm-netbook QingPei (~qingpei@114.241.177.202) |
| 14:16.31 | mnemoc | plan_b: you are uploading something wrong |
| 14:16.47 | mnemoc | plan_b: it's impossible it takes you over 2 seconds to upload such file |
| 14:17.00 | mnemoc | even if you connect to the internet using a cotton thread |
| 14:17.49 | RaYmAn | maybe if it's by carrier pidgeon :D |
| 14:18.07 | RaYmAn | rfc1149 as it were |
| 14:18.08 | RaYmAn | :P |
| 14:18.12 | Turl | this is how I repartitioned my tablet |
| 14:18.14 | Turl | /sbin/yes | /tmp/nand-part /dev/block/nand 'env 4096' 'boot 65536' 'system 716800' 'data 2265088' 'misc 2048' 'recovery 65536' 'cache 262144' 'UDISK 27713536' |
| 14:18.32 | Turl | ymmv |
| 14:18.33 | mnemoc | Turl: captainigloo corrupted his nanda |
| 14:18.42 | mnemoc | nand-part doesn't touch that one |
| 14:19.21 | Turl | if it's corrupted, it's livesuit time :P |
| 14:19.21 | plan_b | https://filetea.me/t1se9c1f |
| 14:19.36 | Turl | unless you wanna boot with an sdcard with a minimal linux and fix it |
| 14:19.49 | plan_b | mk5sum bd089df81f028767bd1a9994ce1ab36e |
| 14:19.52 | Turl | you'd need a nanda backup for that though |
| 14:22.04 | captainigloo | http://pastebin.ca/2229572 |
| 14:22.07 | captainigloo | seems better ! |
| 14:22.11 | captainigloo | plan_b: thanks :) |
| 14:22.44 | plan_b | but your nanda will be empty ... do you have a backup |
| 14:23.05 | captainigloo | there is one on amery's github repo |
| 14:23.11 | plan_b | ok |
| 14:23.30 | Turl | captainigloo: the 'stock' nanda won't boot anything with that partition disposition though |
| 14:23.45 | captainigloo | ah and after a reboot i get /dev/nanda and /dev/nandb |
| 14:23.49 | captainigloo | Turl: why ? |
| 14:24.22 | Turl | captainigloo: because it's configured to boot an android boot.img from a boot partition which you clearly lack |
| 14:24.43 | captainigloo | what's configured ? |
| 14:24.49 | Turl | the uboot on it |
| 14:25.01 | captainigloo | hum |
| 14:25.32 | plan_b | captainigloo, what happens if you "mount /dev/nanda /mnt" |
| 14:25.52 | plan_b | without a reboot |
| 14:26.40 | captainigloo | /dev/nanda is not formated |
| 14:26.49 | plan_b | ok |
| 14:27.17 | plan_b | I could upload my nanda backup ... will be online in about 2 weeks |
| 14:27.21 | plan_b | ;) |
| 14:27.23 | captainigloo | lol |
| 14:29.16 | captainigloo | rh i don't have mkfs on my system ! |
| 14:30.42 | Turl | what are you using to format this stuff captainigloo? |
| 14:31.03 | captainigloo | i think about using mkfs.vfat to format /dev/nanda |
| 14:31.10 | captainigloo | and put the boot files on it |
| 14:31.24 | Turl | yeah that should be ok |
| 14:31.35 | Turl | but you say you don't have mkfs.vfat? |
| 14:32.11 | captainigloo | yeaj i'm building it |
| 14:34.10 | Turl | CWM has probably everything you'd ever need and more, might come in handy to have a sdcard with it to do these kind of things captainigloo |
| 14:34.18 | Turl | http://linux-sunxi.org/CWM_on_a_SDCard |
| 14:37.37 | mnemoc | :o |
| 14:42.37 | captainigloo | Turl: i don't know what CWM is, but it's what i try to do |
| 14:43.03 | captainigloo | a bootable sdcard to recovery my mele if it crashes or something goes wrong |
| 14:43.27 | captainigloo | but i'm using a minimal linux distro |
| 15:06.27 | *** join/#arm-netbook revident (~scott@fw.ss.org) |
| 15:19.37 | *** part/#arm-netbook hipboi (~hipboi@27.42.88.119) |
| 15:21.55 | *** join/#arm-netbook QingPei (~qingpei@114.241.177.202) |
| 15:26.27 | captainigloo | ok it works |
| 15:26.50 | captainigloo | my nand works again |
| 15:26.58 | Turl | captainigloo: CWM means ClockworkMod Recovery |
| 15:27.26 | Turl | it's an android recovery |
| 15:27.40 | Turl | it's main use is flashing android roms, but you can use adb shell on it |
| 15:27.48 | captainigloo | ah ok, i already use it to flash my htc desire |
| 15:27.49 | techn_ | new mali libs here http://linux-sunxi.org/Mali400 |
| 15:27.53 | Turl | and it has a crapton of useful tools |
| 15:28.08 | captainigloo | ok |
| 15:28.22 | Turl | techn_: r3p1 for android? :P |
| 15:28.31 | techn_ | rz2k: I need to go now.. sorry could manage to get things running with r2p4.. Some other linking problems |
| 15:29.00 | techn_ | Turl: mali400-gles20-gles11-linux-x11-ump-no_monolithic |
| 15:30.15 | techn_ | r3p0 |
| 15:30.16 | rz2k | I will try that right now, thanks techn_ |
| 15:30.33 | cat1 | techn_: second, what is kernel part for it? |
| 15:30.36 | captainigloo | armhf ? |
| 15:31.00 | rz2k | captainigloo: TARGET_SYSTEM=gcc-arm-linux-gnueabihf |
| 15:31.33 | rz2k | cat1: https://github.com/amery/linux-allwinner/tree/wip/linux-sunxi-3.0/next_mali |
| 15:31.36 | techn_ | cat1: next_mali |
| 15:31.44 | cat1 | techn_: ah, ok, tnx! |
| 15:32.00 | techn_ | thank Tom :) |
| 15:32.12 | cat1 | techn_: thanks, Tom! ;D |
| 15:32.44 | captainigloo | there is no way to have a softfp version ? |
| 15:32.59 | techn_ | but gotta go to party :D |
| 15:33.26 | captainigloo | have a nice party :) |
| 15:41.31 | *** join/#arm-netbook vgrade2 (~martinbro@cpc2-nrte22-2-0-cust128.8-4.cable.virginmedia.com) |
| 15:41.58 | *** join/#arm-netbook drachensun (~drachensu@142.196.83.182) |
| 15:43.37 | mnemoc | techn_: please send a mail to linux-sunxi announcing it :) |
| 15:44.59 | *** join/#arm-netbook vgrade (~martinbro@cpc2-nrte22-2-0-cust128.8-4.cable.virginmedia.com) |
| 15:48.12 | Turl | http://marcin.juszkiewicz.com.pl/2012/09/28/lets-take-a-look-at-arm-boards-again/ |
| 15:51.30 | Turl | 69USD i.MX6 boards :p |
| 15:51.47 | mnemoc | made from the buggy chips |
| 15:52.08 | Turl | possibly |
| 15:52.32 | Turl | wasn't the bug power management only though? |
| 15:52.39 | mnemoc | the fixed chips just started selling last month |
| 15:52.45 | mnemoc | yes |
| 15:53.07 | captainigloo | there is a i.MX6 board at only 69$ ? |
| 15:53.21 | mnemoc | dev boards is a nice way of getting rid of those buggy chips |
| 15:53.56 | Turl | shipment starts end of nov 2012 mnemoc |
| 15:53.57 | Turl | so it might as well have the fixed ones |
| 15:53.58 | Turl | captainigloo: http://www.wandboard.org/ |
| 15:54.42 | rm | wangboard |
| 15:54.52 | captainigloo | interresting |
| 16:00.25 | plan_b | $89 for two cores |
| 16:02.12 | captainigloo | i bet on 109$ for 4 cores when it will be out :) |
| 16:04.01 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 16:15.54 | L84Supper | the price difference between the single and four core imx was only around $15 |
| 16:17.20 | L84Supper | MCIMX6S5DVM10AA i.MX 6Solo Consumer - 1GHz w/ VPU&GPU ~$11 |
| 16:17.45 | L84Supper | MCIMX6D5EYM12AB i.MX 6Dual Consumer Ext. Temp 1.2GHz w/ VPU&GPU ~$23 |
| 16:18.07 | L84Supper | MCIMX6Q5EYM12AB i.MX 6Quad Consumer Ext. Temp 1.2GHz w/ VPU&GPU ~$29 |
| 16:18.28 | L84Supper | MCIMX6Q5EYM10AB i.MX 6Quad Consumer Ext. Temp - 1GHz w/ VPU&GPU ~$26 |
| 16:18.55 | plan_b | Quad 1.2 GHz would be nice |
| 16:19.14 | penguin42 | http://boundarydevices.com/products/sabre-lite-imx6-sbc/ is neat |
| 16:20.04 | penguin42 | more expensive (note the $199 from November) but nice stuff; 1GB, PCIe, SATA, GBe |
| 16:26.42 | rz2k | I was thinking about making imx6q board for self education or university paper, but didnt find any data about when imx6q will go out for minor customers and when documents like reference designs will be available. |
| 16:27.12 | rz2k | "q4 2012" doesnt say anything because it is already q4 2012. |
| 16:27.45 | penguin42 | not until Monday it isn't! |
| 16:43.32 | penguin42 | Turl: What's interesting about the wandboard is it's modular with the CPU/RAM etc on a separate board; with a creative commons defined interface (EDM) |
| 17:06.01 | *** join/#arm-netbook RITRedbeard (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
| 17:07.41 | *** join/#arm-netbook gimli_ (~gimli@xbmc/staff/gimli) |
| 17:12.37 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 17:26.28 | *** join/#arm-netbook mikey_w (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
| 17:26.46 | *** join/#arm-netbook n6pfk (~mike@c-71-63-115-202.hsd1.va.comcast.net) |
| 17:28.59 | *** join/#arm-netbook ssvb (~ssvb@212.16.98.80) |
| 17:38.56 | *** join/#arm-netbook ceo16 (~asus@host153-22-dynamic.4-87-r.retail.telecomitalia.it) |
| 17:53.40 | drachensun | has anyone tried to get a tablet camera working? |
| 17:54.02 | drachensun | I can load the camera driver but I'm not sure whats needed after that |
| 18:13.45 | lkcl | penguin42: yeah... it looks great, until you realise that it's designed for purely factory-install purposes *only*. just like the qseven-standard. you can't do anything with an EDM module, without a matching breakout PCB. |
| 18:18.57 | Turl | lkcl: same with EOMA-68 too? |
| 18:19.25 | Turl | drachensun: it uses video4linux from what I recall |
| 18:22.02 | *** join/#arm-netbook RITRedbeard (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
| 18:22.40 | lkcl | Turl: no. EOMA-68 re-purposes PCMCIA. you can stick an EOMA-68 CPU Card in your top pocket without damage. |
| 18:23.09 | lkcl | ok, that's assuming it's inside a PCMCIA metal shield of course, rather than being straight off an engineer's R&D lab desk |
| 18:23.46 | lkcl | EOMA-68 is designed for mass-volume end-user purposes [with a case on] as well as for factory-install purposes [with the case off] |
| 18:24.09 | Turl | ah, I see what you mean now |
| 18:24.23 | lkcl | yeah. |
| 18:24.29 | Turl | you could stick some shielding on top of EDM too I guess |
| 18:24.33 | Turl | or make a carrying case |
| 18:24.45 | lkcl | plus, unfortunately, just like in the q-seven standard, many of the interfaces are "optional". |
| 18:24.56 | lkcl | did i ever tell you the story about the development of the X-25 standard? |
| 18:25.10 | lkcl | it's quite a simple one. |
| 18:25.13 | Turl | I don't think you did :) |
| 18:25.17 | lkcl | :) |
| 18:25.21 | lkcl | ahh, allow me :) |
| 18:25.27 | Turl | X-25 reminds me of X-28, any relation? |
| 18:25.33 | Turl | (alarm system) |
| 18:25.44 | lkcl | the X-25 standard is similar to RS-232 - it was what the JANET network ran on. |
| 18:26.14 | lkcl | it's 9 pins, and it has (had) a hardware line dedicated to "interrupt", and it had a "Tx" clock line. |
| 18:26.28 | *** join/#arm-netbook revident (~scott@76.10.173.74) |
| 18:26.49 | lkcl | but, *just in case* someone forgot to honour the hardware "interrupt" line, they put "software interrupt" into the serial data stream |
| 18:26.57 | lkcl | no, sorry - it only had a "Rx" clock line. |
| 18:27.22 | lkcl | anyway - because it had both hardware and software interrupt, *everyone* had to support software interrupt |
| 18:27.35 | lkcl | thus, the hardware interrupt line was *utterly* useless. |
| 18:27.37 | *** join/#arm-netbook jlj (~jlj@109-104-24-9.customers.ownit.se) |
| 18:27.45 | Turl | heh |
| 18:27.54 | lkcl | which is a total waste of a pin, esp. when it could have been used as a "Tx" clock line |
| 18:28.34 | drachensun | Turl: yeah I figured out the drivers needed from looking at the android but I'm getting crashes in videobuf_core now |
| 18:28.47 | lkcl | so instead of a $2 cable like in RS232, you had to have a $7 box generating a Tx clock to *both* parties, with a $3 power supply! |
| 18:28.58 | drachensun | I'm looking for 'low hanging fruit' features to fix up right now |
| 18:29.13 | lkcl | you see the point i'm making - which is that you must NOT have "optional features" in a hardware standard? |
| 18:29.54 | lkcl | if you do have options, they must be negotiable over the bus lines. |
| 18:30.06 | lkcl | e.g. USB2 has speed-negotiation... but done in hardware. |
| 18:30.29 | lkcl | SATA has speed-negotiation... all the way from 150mbits/sec up to 3gbits/sec... but that's done over the *same* 4 wires |
| 18:30.36 | lkcl | ethernet as well. |
| 18:30.56 | lkcl | EDM, unfortunately, makes many of its interfaces optional |
| 18:31.06 | Turl | drachensun: on kernel? |
| 18:31.11 | lkcl | that immediately to me is a red flag |
| 18:31.48 | Turl | lkcl: any optional features on EOMA-68? :) |
| 18:32.27 | drachensun | Turl: when I used fswebcam to try to read from the camera the kernel driver videobuf_core is crashing |
| 18:33.13 | drachensun | I'm installing another v4l program now to see if maybe thats all it is |
| 18:33.49 | Turl | it shouldn't crash even if it's a bad v4l program :) |
| 18:34.59 | lkcl | Turl: nnnope :) |
| 18:35.10 | lkcl | i learned the lesson of X-25 :) |
| 18:35.33 | drachensun | heh yeah I guess not |
| 18:35.40 | drachensun | it was checking for working resolutions |
| 18:35.57 | drachensun | and I'm thinking maybe the first resolutions just aren't supported |
| 18:38.03 | *** join/#arm-netbook RITRedbeard (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
| 18:41.51 | penguin42 | lkcl: How 'factory only' is EDM? What makes it any worse than a so-dimm? |
| 18:43.39 | lkcl | penguin42: it's exactly the same factory-only usefulness for all those form-factors. MXM, SO-DIMM, EDM, Q-Seven. |
| 18:43.54 | penguin42 | lkcl: In that case, I don't see the problem |
| 18:44.09 | penguin42 | lkcl: Plenty of people carry SO-DIMMs around, fit them in their own laptops etc |
| 18:44.20 | lkcl | you only have to think, "would a module of standard X survive my grandma putting it in the top pocket of her best nylon-polyester dress?" |
| 18:44.38 | penguin42 | lkcl: But why is that important for EOMA? |
| 18:44.46 | lkcl | penguin42: think "grandma". does grandma carry around SO-DIMMs and fit them into her laptop? |
| 18:45.08 | penguin42 | lkcl: No, grandma carries around a system with an HDMI port on |
| 18:45.11 | lkcl | penguin42: because we're expecting the volumes to be somewhere around a million a month or greater |
| 18:45.20 | penguin42 | lkcl: That's way less than SO-DIMM |
| 18:45.26 | lkcl | penguin42: exactly. an EOMA-68 CPU Card has an HDMI port. |
| 18:45.45 | penguin42 | lkcl: No, my point is what is granny going to do with her EOMA? |
| 18:45.56 | penguin42 | lkcl: Why wouldn't she just carry her tablet around? |
| 18:46.07 | lkcl | penguin42: i was underestimating. GW's capacity is... even into numbers bigger than i can appreciate |
| 18:46.44 | penguin42 | lkcl: Seriously, that EDM stuff looks like exactly what is needed |
| 18:47.15 | lkcl | penguin42: yes. good question. granny's tablet breaks. little johnny (her 8-year-old tech support) tells her to take the EOMA-68 CPU Card out and bring it over to his mum's house. |
| 18:47.34 | penguin42 | lkcl: No he doesn't, little jonny tells her to bring her tablet over |
| 18:47.41 | rm | rz2k, what am I missing? mali_exa.h:27:21: fatal error: ump/ump.h: No such file or directory |
| 18:47.59 | lkcl | or, granny takes it back to the store when it's broken, takes the EOMA-68 CPU Card out and she puts it in her handbag. |
| 18:48.10 | penguin42 | lkcl: No, Granny takes the tablet back |
| 18:48.30 | penguin42 | lkcl: The differential between the card and the object it's part enough has to be large enough to justify the difference |
| 18:48.41 | lkcl | penguin42: sorry, you don't get it. if you don't get it, i'm not going to spend a lot of time explaining. |
| 18:49.31 | penguin42 | lkcl: Sorry, I don't; I see the point in making stuff modular, I don't get the reason to make it more robust for that type of app |
| 18:49.42 | *** join/#arm-netbook RITRedbeard (~redbeard@c-68-37-165-37.hsd1.nj.comcast.net) |
| 18:52.19 | lkcl | penguin42: if you're going to argue with the envisaged scenarios without listening, there's no point in me trying to explain, is there. |
| 18:53.01 | penguin42 | lkcl: Apologies, I seriously don't mean to be like that; I don't see what I haven't listened to |
| 18:53.51 | lkcl | penguin42: the point is that anything that's removable *will* be hit or damaged by the average person. |
| 18:54.41 | lkcl | penguin42: if there's even a 1% returns rate on items that are sold in quantities of 100 million, that's still a loss of a million units. |
| 18:55.07 | lkcl | in the mass-volume retail sector, typically the profits are below 1%. |
| 18:55.10 | penguin42 | lkcl: OK, so I'm trying to understand why the SO-DIMM doesn't hit that problem? |
| 18:55.39 | lkcl | it does hit that problem. it's not protected from damage through static, is it? |
| 18:55.46 | lkcl | or from being dropped |
| 18:55.54 | lkcl | or poked at with a sharp implement |
| 18:56.11 | lkcl | or peoples' fingers pressing against the connector and getting oil on it |
| 18:56.14 | penguin42 | lkcl: Yep, so laptops are still mostly sold with SO-DIMMs in - so why do they survive? |
| 18:56.35 | lkcl | because the average person DOES NOT DO THE INSTALL, do they? |
| 18:57.02 | lkcl | what's the average lifecycle on removal and insertion of an SO-DIMM memory module? |
| 18:57.09 | penguin42 | lkcl: I'd guess 10 |
| 18:57.16 | lkcl | it'll be about once every.... 5 years. |
| 18:57.53 | lkcl | whereas we're anticipating EOMA-68 modules to be inserted/removed on a similar order as USB |
| 18:58.05 | penguin42 | lkcl: OK, but why do you want EOMA to be installed/removed more often - I want to understand why granny would want to do this |
| 18:58.14 | lkcl | SO-DIMM sockets have a lifecycle of about .... something like 25 cycles *total*. |
| 18:58.19 | lkcl | because they can. |
| 18:58.25 | lkcl | granny might not |
| 18:58.50 | lkcl | but a professional who has an EOMA-68-compliant Digital SLR Camera, as well as an EOMA-68-compliant smartphone |
| 18:58.52 | lkcl | and tablet |
| 18:58.54 | lkcl | and laptop |
| 18:59.00 | lkcl | and 30in LCD monitor at work |
| 18:59.05 | lkcl | and a games console at home |
| 18:59.26 | lkcl | they might end up inserting/removing their EOMA-68 CPU Cards up to 10 times a *day* |
| 18:59.36 | penguin42 | lkcl: OK, I hadn't seen that use of it |
| 19:00.14 | lkcl | yeah - it's like... the potential here is *huge*. it covers virtually every mass-volume electronics system you can think of, in the world. |
| 19:00.38 | lkcl | with the exception of the hard-core gaming industry, the high-end server market, high-end / real-time video editing industry |
| 19:01.19 | lkcl | and ... err... i run out of examples where EOMA-68 could not be used. oh yeah: portable watches :) |
| 19:01.33 | penguin42 | and music players |
| 19:01.36 | lkcl | i'm not going to wear a device of 86x54 mm on my wrist :) |
| 19:02.16 | lkcl | true. yes. music players... well..... you think, we used to have walkmans and so on.... 86x54 is credit-card-sized... but... yeah |
| 19:02.22 | lkcl | people now expect them to be usb-stick-sized |
| 19:02.29 | penguin42 | lkcl: and I think mobiles are now probably below it |
| 19:02.51 | lkcl | just about, yes. although some smartphones have to have larger screens. |
| 19:02.59 | drachensun | people still buy ipods, how big are those now? |
| 19:03.02 | lkcl | and esp. the smartphones with keyboards |
| 19:03.05 | drachensun | still phone sized I think |
| 19:03.17 | lkcl | ipods? ooo, they're about the size of Compact Flash. |
| 19:03.25 | lkcl | which is why i drew up EOMA-CF as well |
| 19:03.34 | lkcl | but, we'll get to that later |
| 19:04.08 | penguin42 | lkcl: Right, so I hadn't seen your vision of that before which is why I couldn't see that before - the challenge then which I'm not too sure of is whether the market is really there; people carry the SD card between there tablet/tv/camera/laptop, or use their mobile as the module |
| 19:04.42 | lkcl | penguin42: sorry! |
| 19:05.23 | drachensun | cost cost cost, I think consumers would see the benefit of "I want the latest camera with 2123123 MP but this one is less because it uses my old cameras processor board" |
| 19:05.24 | lkcl | penguin42: yeah, some people aren't going to "grok" the various combinations |
| 19:05.50 | penguin42 | lkcl: That argument is much better than 'servicing' argument; because 8 year old jonny probably can change an SO-DIMM |
| 19:05.57 | Turl | drachensun: you're likely to need a new processor to process the extra MPs anyway |
| 19:06.04 | lkcl | but that's ok - there are benefits for the factories, SoC vendors etc. etc. as well which gives them some incentive to make them |
| 19:06.31 | lkcl | penguin42: there's an article coming out in a couple of weeks |
| 19:07.55 | drachensun | Turl: maybe not a perfect example, but in a lot of consumer electronics pieces don't change generation to generation, except the processing |
| 19:09.13 | penguin42 | lkcl: It's interesting though how uses change; the SD card and the mobile are now to some extent getting used as the module; people can carry their data around between all their devices; and I think on iphone 5 Apple have put a high bandwidth interface which I expect them to push that idea further (wtf they didn't use the thunderbolt or USB-3 I don't get, or is it actually a thunderbolt derivative) |
| 19:10.09 | Turl | drachensun: I really can't think of a single example :| |
| 19:11.13 | *** join/#arm-netbook techn (~quassel@a91-152-35-60.elisa-laajakaista.fi) |
| 19:13.35 | drachensun | well I just noticed there is a videobuf2-core driver |
| 19:13.38 | drachensun | maybe that is what I need |
| 19:15.49 | lkcl | penguin42: apple have a different kind of agenda. compliance with e.g. EU regulations on industry standards such as the USB charger/audio connector standard ain't high on their list.... |
| 19:16.22 | penguin42 | lkcl: Right, but their move to higher bandwidth interfaces I suspect is the interesting one to watch |
| 19:18.02 | captainigloo | I build my own kernel, git://github.com/amery/linux-allwinner.git branch allwinner-v3.0-android-v2 with arch/arm/config/sun4i_defconfig |
| 19:18.16 | hno | captainigloo, good. |
| 19:18.16 | captainigloo | but it freezez just after loading kernel in uboot |
| 19:18.30 | hno | that's not good. |
| 19:18.34 | captainigloo | :) |
| 19:18.43 | lkcl | penguin42: yeahhh, they have the funds to create entire eco-systems, amortising the R&D and tooling across the cost of the devices, but still pushing up the overall unit price |
| 19:18.56 | hno | captainigloo, what device do you have? |
| 19:19.08 | captainigloo | i compare mine with the one in nightly build hw pack |
| 19:19.11 | captainigloo | mele a2000 |
| 19:19.37 | lkcl | whereas we're re-using stuff that's just borderline obselete, using decade-old lowest common denominator interfaces. radically different approach! |
| 19:19.43 | hno | the nightly build should be a sun4i_defconfig build as well. |
| 19:19.59 | captainigloo | it seems there is a diff in load adress and entry point of the uboot format |
| 19:20.06 | captainigloo | file uImage |
| 19:20.07 | captainigloo | uImage: u-boot legacy uImage, Angstrom/3.0.42/allwinner-a10, Linux/ARM, OS Kernel Image (Not compressed), 4018700 bytes, Sat Sep 29 10:40:32 2012, Load Address: 0x20008000, Entry Point: 0x20008000, Header CRC: 0x18E011A8, Data CRC: 0x3424C34B |
| 19:20.17 | hno | that do not look right. |
| 19:20.24 | penguin42 | lkcl: Yeh I worry about that |
| 19:20.26 | captainigloo | this one is mine |
| 19:20.50 | captainigloo | ram begins at 0x4000000 right ? |
| 19:20.54 | hno | yes |
| 19:21.22 | captainigloo | i can't find where this value is used |
| 19:21.33 | hno | and kernel load & entry point should be 0x40008000, |
| 19:21.51 | captainigloo | it should be passed during the mkimage step |
| 19:21.58 | hno | ram begins at 0x40000000 (one zero more) |
| 19:22.13 | captainigloo | yeah sorry 0x4000 0000 |
| 19:23.10 | hno | It's set in arch/arm/mach-sun4i/Makefile.boot |
| 19:23.22 | hno | no idea where your build got 0x20008000 from. |
| 19:24.38 | captainigloo | zreladdr-$(CONFIG_ARCH_SUN4I):= 0x40008000 |
| 19:24.49 | captainigloo | it's the content of my Makefile.boot |
| 19:25.08 | captainigloo | ls |
| 19:25.10 | captainigloo | ouch sorry |
| 19:26.07 | hno | Is that uImage from the kernel build process, or created separately by your build environment= |
| 19:26.09 | hno | ? |
| 19:26.38 | captainigloo | my build environment use the stanadrt kernel build process |
| 19:27.10 | captainigloo | i'm using openembedded btw |
| 19:27.19 | hno | What's in arch/arm/boot/? |
| 19:27.51 | captainigloo | bootp compressed Image install.sh Makefile uImage zImage |
| 19:28.06 | hno | and the uImage there has 0x20008000 as address? |
| 19:28.14 | captainigloo | and file uImage shows Entry Point at 0x20008000 |
| 19:28.22 | captainigloo | yes |
| 19:28.25 | hno | strange |
| 19:29.41 | captainigloo | ah , the script which generate the uImage has fixed ENTRYPOINT at 20008000 |
| 19:29.54 | captainigloo | it's in openembedded |
| 19:30.10 | captainigloo | dinally it's maybe not following the kernel build process |
| 19:30.17 | captainigloo | :) |
| 19:31.45 | hno | obviously not entirely following process. |
| 19:35.42 | captainigloo | it seems i need to declare UBOOT_ENTRYPOINT and UBOOT_LOADADDRESS into my hardware configuration file ... |
| 19:35.51 | captainigloo | make sense |
| 19:36.28 | mnemoc | hno: I can't get wip/unified-aw to tell anything in the uart :< |
| 19:36.44 | hno | Nothing? |
| 19:36.56 | mnemoc | nothing at all |
| 19:37.52 | hno | ok. Thanks for trying. Will dig into it in detail. |
| 19:39.37 | mnemoc | hno: would it make sense to try sunxi again? |
| 19:39.47 | mnemoc | will the generated dram_para |
| 19:39.52 | mnemoc | with* |
| 19:42.08 | hno | mnemoc, sunxi do not have dram_para for sun4i, only sun5i. |
| 19:42.56 | mnemoc | ok |
| 19:44.18 | captainigloo | huhu, i finally get my squashfs image running on nand ! |
| 19:44.21 | hno | do it work on the A13? |
| 19:44.30 | captainigloo | thanks guys :D |
| 19:45.18 | rm | http://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-everyone/ |
| 19:52.12 | mnemoc | hno: I might have another problem.... sunxi used to greet and halt, now it doesn't show anything either |
| 19:55.36 | hno | ok |
| 19:58.07 | mnemoc | meh, powercycling the board instead of playing with the button worked. sunxi now greets again |
| 19:58.15 | mnemoc | back to unified-aw |
| 19:59.35 | mnemoc | very strange thing. on reboot it skips the uSD |
| 20:00.37 | mnemoc | hno: same, no greeting from a fresh unified-aw on my cubie |
| 20:00.42 | hno | ok |
| 20:00.46 | mnemoc | will try the a13 |
| 20:00.57 | hno | would be great. |
| 20:04.44 | mnemoc | hno: btw, this was my intention http://sprunge.us/IeLe?diff |
| 20:07.31 | mnemoc | and was going to add an equivalent call to init the PMU when called |
| 20:07.41 | mnemoc | with [target] values |
| 20:07.48 | hno | Ok. |
| 20:08.02 | hno | The SUN5I values are for Olinuxino A13. |
| 20:08.13 | hno | And the original SUN4I ones are Mele. |
| 20:08.59 | mnemoc | ok |
| 20:08.59 | hno | Ah, density on the 1GB cubieboard should be 4096, not 2048. |
| 20:09.20 | hno | and size 1024. |
| 20:09.40 | mnemoc | but might that cause it to not greet at all? |
| 20:09.49 | hno | unlikely. |
| 20:10.10 | hno | should run fine with too small density & size. |
| 20:45.43 | mnemoc | hno: it seems to be PMU related, in both (a13 olinuxino and cubieboard) with plugging the board with a card made of unified-aw there is no reaction in uart AND the power button does nothing at all |
| 20:46.10 | mnemoc | after pressing reset, boots fine from NAND |
| 20:49.17 | mnemoc | with the uSD still connected |
| 20:49.35 | captainigloo | did you already get this kind of error with nand driver : |
| 20:49.38 | captainigloo | http://pastebin.ca/2231521 |
| 20:50.56 | captainigloo | this log is better, i launch nand-part, and i get error, the second time it's ok |
| 20:51.00 | captainigloo | http://pastebin.ca/2231532 |
| 20:51.27 | mnemoc | uh |
| 20:52.32 | mnemoc | captainigloo: you should really reflash it |
| 20:52.52 | captainigloo | yep but i need windows ? |
| 20:53.16 | mnemoc | unfortunatelly yes |
| 20:53.31 | captainigloo | i try to launch LiveSuit with wine but it doens't work |
| 20:53.46 | captainigloo | i have macos, linux, android |
| 20:53.51 | captainigloo | but no windows :( |
| 20:54.17 | hno | phoenixcard might work better, but probably not. |
| 20:55.09 | captainigloo | where could i find the phonix card ? |
| 20:55.14 | Turl | I cannot see the logs :< |
| 20:55.24 | Turl | captainigloo: it's generated with a windows software |
| 20:55.30 | captainigloo | :'( |
| 20:55.52 | Turl | captainigloo: can you paste your logs somewhere else? :< pastebin.ca doesn't work for me |
| 20:56.14 | captainigloo | .com is ok ? |
| 20:56.38 | captainigloo | http://pastebin.com/xh6snxMp |
| 20:57.01 | mnemoc | http://sprunge.us/ rules |
| 20:57.23 | Turl | yeah .com is ok as long as it doesn't show me a captcha :P |
| 20:59.44 | Turl | weird stuff captainigloo, never seen anything like that :/ |
| 21:00.04 | captainigloo | o:/ |
| 21:00.42 | captainigloo | that's really strange |
| 21:00.54 | captainigloo | i relaunch again, an now there is no problem |
| 21:01.02 | captainigloo | at least when i launch nand-part |
| 21:02.33 | captainigloo | ok now my mele is completely instable |
| 21:03.04 | captainigloo | ouach |
| 21:04.43 | Turl | ah, you have a mele? |
| 21:04.49 | Turl | there's a dd-able phoenixcard somewhere |
| 21:05.51 | captainigloo | about the nand partitions |
| 21:06.02 | captainigloo | i need to align the partitions ? |
| 21:07.56 | hno | mnemoc, A13 Olinuxuni should not differ between sunxi and wip/unified-aw. Ifthere is a difference then I goofed up something. |
| 21:08.21 | Turl | captainigloo: http://lundman.net/ftp/mele/Mele_HTPC_Android_4.0_V1.ddimg.bin.bz2 |
| 21:08.31 | Turl | download, uncompress and dd to a sdcard, then boot your mele with it |
| 21:08.32 | captainigloo | Turl: hehe, i just find this linnk ! |
| 21:09.10 | Turl | if you have uart you should be able to follow the install process there |
| 21:09.23 | captainigloo | yep, thanks ! |
| 21:09.42 | mnemoc | hno: i'll test pristine sunxi on the a13 olinuxino now |
| 21:10.16 | *** join/#arm-netbook avernos (~avernos@111.194.214.45) |
| 21:10.17 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
| 21:16.12 | mnemoc | hno: sunxi/sun5i booted just fine |
| 21:18.26 | hno | Yes.. unified-aw seems dead. |
| 21:18.34 | hno | lets see where. |
| 21:32.28 | captainigloo | Turl: ok ICS is booting now;), and nand seems to be ok |
| 21:33.16 | Turl | :) |
| 21:33.51 | mnemoc | captainigloo: and now nand-part works fine? |
| 21:36.45 | *** join/#arm-netbook pwhalen (~paul@CPE001310360dac-CM78cd8ec9e405.cpe.net.cable.rogers.com) |
| 21:39.54 | *** join/#arm-netbook cat1 (~cat_x301@a91-152-66-200.elisa-laajakaista.fi) |
| 21:40.19 | hno | mnemoc, ok, found one copy-paste bug which caused internal dram bus clock to not enable.. guess that may have some impact. |
| 21:41.11 | mnemoc | :) |
| 21:47.51 | hno | U-Boot SPL 2012.10-rc1-00830-gb88d9f5-dirty (Sep 29 2012 - 23:42:18) |
| 21:47.52 | hno | MMC: |
| 21:48.13 | hno | looks better. |
| 21:48.18 | mnemoc | :) |
| 21:48.28 | mnemoc | push the fix please |
| 21:48.45 | rm | what's with that problem where U-boot SPL refuses to see MMC on one MK802 |
| 21:48.56 | mnemoc | techn: there is a thread about edid in the cubieboard list which desperately needs you :) |
| 21:49.05 | rm | any hope it's been fixed by something recently? should I retry? |
| 21:49.25 | mnemoc | isn't that fixed with a clock factor change? |
| 21:50.30 | rm | I thought clock factor was fixing something else, i.e. that instability and kernel crashes |
| 21:50.48 | mnemoc | ah, ok. never mind |
| 21:51.03 | hno | mnemoc, pushed. |
| 21:51.05 | *** join/#arm-netbook ssvb (~ssvb@212.16.98.80) |
| 21:52.10 | hno | rm, there is reports about u-boot-mmc not liking some SD cards, probably a timeout issue where it doesn't wait long enought for the card to come online. |
| 21:52.22 | mnemoc | rootwait ? |
| 21:52.38 | mnemoc | meh. need to sleep |
| 21:52.39 | hno | no, earlier when u-boot tries to access the mmc. |
| 21:53.23 | rm | I mean this http://permalink.gmane.org/gmane.comp.hardware.netbook.arm/4203 |
| 21:53.45 | hno | not planning to look into MMC issues until PMU support is implemented. |
| 21:53.52 | *** join/#arm-netbook calris (~calris@d110-32-174-6.sbr801.nsw.optusnet.com.au) |
| 21:54.16 | hno | rm, yes that. |
| 21:55.08 | rm | also this is with 3 or 4 different cards, but consistently on one MK802 out of three |
| 21:55.38 | mnemoc | hno: `fexc -O uboot` now makes an struct pmu_para made out of [target] |
| 21:56.19 | hno | rm, could also be the PMU issue, if it's a newer MK802 with PMU. Running the CPU under voltage gives all kinds of wierd errors. |
| 21:56.27 | mnemoc | still only a proof of concept obviusly, output needs to match uboot needs |
| 21:57.01 | hno | mnemoc, plus that more and more boards will come with empty parameters. |
| 21:57.47 | hno | luckily rand, bus, io, density and size can all be determined by visually inspecting the board. |
| 21:58.10 | mnemoc | livesuit uses sys_config, so there must be "good defaults" we can adopt |
| 21:58.11 | hno | s/rand/rank/ |
| 21:58.39 | hno | mnemoc, livesuit is said to autodetect memory layout these days. |
| 21:58.55 | mnemoc | doesn't believe in magic |
| 21:59.18 | mnemoc | it could trial and error |
| 21:59.35 | hno | It's supposedly one of the big things with the A13 push as it makes the same image run on many different boards. |
| 21:59.54 | hno | ofcourse it's trial and error. |
| 22:00.06 | mnemoc | so NULL fields would mean "detect"? |
| 22:00.08 | hno | but some educated trial & error. |
| 22:00.11 | hno | yes. |
| 22:00.34 | mnemoc | do I turn those into... 0xffffffff ? |
| 22:00.40 | hno | no idea what phoenixcard does. |
| 22:00.58 | hno | the code I have do not do any autodetection. |
| 22:01.40 | mnemoc | yet :) |
| 22:02.06 | hno | have not planned to implement any autodetection. |
| 22:02.45 | mnemoc | :) |
| 22:03.20 | hno | but guess we will need to deal with this one way or another as information is unavailable. |
| 22:03.29 | hno | to users- |
| 22:04.13 | mnemoc | thinking in "the users" if we can't trust script.bin, and "good defaults" are not possible... a fel tool to dump the boot1 header? |
| 22:04.30 | mnemoc | kind of sucks :| |
| 22:05.09 | mnemoc | another way is to keep an archive of trustworthy $board.fex files |
| 22:06.48 | mnemoc | like the chips thing in the SDK, but corrected to not assume livesuit will do it's thing |
| 22:06.49 | hno | Well. there isn't really that many different DRAM configurations. So a little guide based on number of chips, type of chips and cpu model helps filling in the gaps. |
| 22:07.49 | hno | but having corrected fex files helps a lot. |
| 22:08.54 | mnemoc | hno: cubieboard + unified-aw (with board_cubieboard.c) worked :) |
| 22:08.58 | hno | livesuit misdetects the A13 Olinuxino configuration btw. |
| 22:09.18 | mnemoc | but... DRAM: 1 KiB |
| 22:09.33 | hno | Eh. Right. Wrong scale ther. |
| 22:10.03 | mnemoc | http://sprunge.us/OYQB?diff |
| 22:11.34 | hno | is missing mele. |
| 22:12.02 | hno | the sun4i config you deleted. |
| 22:12.28 | mnemoc | yes |
| 22:12.49 | mnemoc | but without a CONFIG_ ruling this I can't really start making a collection yet |
| 22:14.19 | hno | Memory size fix pushed. |
| 22:14.49 | mnemoc | http://sprunge.us/YEaI <--- now with mele |
| 22:15.12 | hno | but don't try that meminfo with MALI enabled. |
| 22:16.06 | hno | mnemoc, better. |
| 22:17.41 | hno | I also have another dram.c based on toms code, but much more work to merge that and rewrite to seinsible parameterized code than to switch to the allwinner code. |
| 22:18.14 | mnemoc | btw, that board_mele.c is made from the stock script.bin, not from the code I deleted |
| 22:18.54 | hno | should not differ. Does it? |
| 22:19.03 | mnemoc | didn't check :p |
| 22:19.41 | mnemoc | DRAM: 1 GiB |
| 22:19.45 | mnemoc | \o/ |
| 22:20.15 | hno | Yes, but clock speed probably isn't very good. |
| 22:20.58 | mnemoc | i'll start playing with the kernel here tomorrow... with mali disabled |
| 22:21.46 | hno | maybe possible to use cpufreq to switch to better speeds, that do reprogram the PMU. But don't know. There is more voltage settings than just the core. |
| 22:22.02 | mnemoc | :( |
| 22:22.45 | mnemoc | maybe setting the default governor to performance can make an early reclocking? |
| 22:23.41 | hno | you can try. But I would prefer to get the PMU under control before trying higher clocks. |
| 22:23.58 | mnemoc | fair enough |
| 22:24.43 | hno | but on the other hand most A10 devices seem fine with default voltages for some strange reason. |
| 22:25.49 | hno | I do have PMU TWI traces, but then realized the trace is a warm trace with the PMU already configured. Need to redo the trace at cold boot. |
| 22:26.39 | hno | The third access is reading a non-default value of a user defined register (4 bytes of user defined usage, preserved by PMU as long as there is at least backup power) |
| 22:34.11 | captainigloo | mnemoc: nand-part works again |
| 22:34.28 | mnemoc | \o/ |
| 22:34.33 | captainigloo | :) |
| 22:34.45 | captainigloo | but i don't understand what it says |
| 22:35.15 | captainigloo | http://pastebin.com/2tjFFXhU |
| 22:35.25 | captainigloo | partition1, i guess it's nanda |
| 22:35.36 | captainigloo | sorry partition0 |
| 22:35.45 | captainigloo | partition size is 32768 |
| 22:35.49 | hno | yes. |
| 22:35.52 | captainigloo | but 32768 what ? |
| 22:36.12 | hno | kb IIRC. nanda is very small. |
| 22:36.21 | captainigloo | ah ! |
| 22:36.22 | hno | or is it blocks? |
| 22:36.26 | captainigloo | no |
| 22:36.41 | captainigloo | mount /dev/nanda /mnt/nanda |
| 22:36.45 | captainigloo | df -h |
| 22:37.00 | captainigloo | /dev/nanda 16.0M 6.5M 9.5M 41% /mnt/nanda |
| 22:37.05 | captainigloo | it's 16MB |
| 22:37.48 | mnemoc | yes, 512b blocks |
| 22:37.54 | mnemoc | B |
| 22:38.19 | captainigloo | ah ok |
| 22:38.50 | captainigloo | it's maybe why i fucked up my partition table earlier ;) |
| 22:39.05 | captainigloo | i was sure it's in bytes :D |
| 22:41.28 | mnemoc | :) |
| 22:41.32 | mnemoc | going to sleep |
| 22:41.34 | mnemoc | good night |
| 22:41.38 | captainigloo | gn |
| 23:15.52 | *** join/#arm-netbook Thomas42 (~Thomas42@static.105.236.9.5.clients.your-server.de) |
