| 00:00.54 | lundman | so, there is a difference in the kernel somewhere |
| 00:01.29 | *** join/#arm-netbook leszcz (~marek@host-89-167-63-165.nplay.net.pl) |
| 00:02.29 | mnemoc | i wouldn't care much considering sonner than later we need to replace that nand driver with one mtd compatible |
| 00:03.48 | *** join/#arm-netbook L84Supper (~ly@unaffiliated/l84supper) |
| 00:04.26 | lundman | their nand is init very late, compared to our kernel |
| 00:05.13 | lundman | [ 3.901589] [NAND] nand driver version: 0x2, 0x10, data: 20120718 |
| 00:05.15 | lundman | [ 0.870000] [NAND] nand driver version: 0x2 0x9 |
| 00:05.23 | lundman | so theirs is newer at that |
| 00:05.33 | mnemoc | versions |
| 00:05.36 | mnemoc | 0x10 |
| 00:05.45 | mnemoc | lovely |
| 00:06.00 | mnemoc | got homework ;-) |
| 00:06.23 | lundman | they broke something though |
| 00:06.27 | lundman | The 0 disk name = bootloader, class name = DISK, disk size = d93da424 |
| 00:06.30 | lundman | The 0 disk name = bootloader, class name = DISK, disk size = 32768 |
| 00:07.10 | lundman | bootloader,env,boot,system,data,misc,recovery,cache,private,sysrecovery,UDISK |
| 00:07.28 | lundman | bootloader,envboot,misc,recovery,private,sysrecovery,UDISK |
| 00:07.34 | lundman | yeah, so where is that defined |
| 00:11.53 | mnemoc | look at the source of the tool to repartition |
| 00:12.34 | mnemoc | we will need to act differently is the version of the partition table is 0x10 instead of 0x9 |
| 00:13.19 | lundman | 0x10 is the nand source version. |
| 00:13.32 | lundman | so my guess is they moved the mbr to some other block |
| 00:13.44 | mnemoc | lovely |
| 00:13.52 | mnemoc | hunt it down :) |
| 00:14.06 | mnemoc | once the tool can read the new partition table, we can adapt the kernel driver to support both |
| 00:14.39 | lundman | why cant they just share the updated version |
| 00:15.02 | mnemoc | try |
| 00:19.23 | lundman | ok, none of my source tree has a newer version of NAND_VERSION_1 |
| 00:25.34 | lundman | I'd better go take a look at the mbr |
| 00:59.19 | lundman | well, its not from nanda |
| 01:00.06 | mnemoc | ? |
| 01:00.21 | lundman | just wondering where this mbr is stored |
| 01:00.27 | mnemoc | /dev/nand |
| 01:00.30 | mnemoc | before nanda |
| 01:00.54 | lundman | no such device |
| 01:01.07 | mnemoc | in our kernel it does |
| 01:01.49 | mnemoc | it was added to be able to repartition from linux |
| 01:02.03 | lundman | in miniand with nand, but no raw device |
| 01:03.07 | mnemoc | no idea what kernel "miniand" uses |
| 01:03.20 | mnemoc | going to sleep now |
| 01:03.23 | mnemoc | good night |
| 01:03.28 | lundman | 3.0.36+ at the moment |
| 01:06.15 | mnemoc | no idea. i've never seen anyone from that company asking or collaborating with us. no idea what's source they use, what changes they do or what troubles they have |
| 01:06.36 | mnemoc | now good night for real |
| 01:31.08 | lundman | not even android boot gives a "nand" device |
| 01:32.39 | Turl | "nand" is a kernel thing |
| 01:32.51 | Turl | you need the lastestestest sunxi-3.0 |
| 01:33.32 | lundman | i might have that, but since I can't boot it, it gets awkward :) |
| 01:36.51 | Turl | and on android it'd usually be /dev/*block*/nand |
| 01:54.50 | lundman | yes, and it has no top-level |
| 01:58.03 | *** join/#arm-netbook itamar_ (~itamar@189-015-124-078.xd-dynamic.ctbcnetsuper.com.br) |
| 01:58.19 | lundman | ah yes, I see.. i need the newer kernel |
| 02:07.04 | *** join/#arm-netbook cheng (~cheng@219.92.77.39) |
| 02:24.12 | *** join/#arm-netbook mSquare (~selvan@122.178.208.87) |
| 03:08.53 | *** join/#arm-netbook tekzilla (~jon@hmbg-5f763e0f.pool.mediaWays.net) |
| 03:31.58 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@212.179.75.202) |
| 03:50.41 | lundman | ok, /dev/nand does have MBR |
| 04:34.52 | *** join/#arm-netbook cheng (~cheng@219.92.77.39) |
| 04:53.32 | lundman | mbr has no surprises. 'our' layout x4 |
| 04:56.54 | lundman | I take that back, mbr is like their layout, not our |
| 05:05.54 | *** join/#arm-netbook ol1ver (~Thunderbi@7of9.schinagl.nl) |
| 05:12.08 | lundman | ok there is no reason our kernel should return this weird mbr |
| 06:26.23 | *** join/#arm-netbook ZaEarl (~malmrose@014136144056.ctinets.com) |
| 06:39.50 | *** join/#arm-netbook pawel5870 (~pkarpins@pc.193147149.ip.amg.net.pl) |
| 06:46.04 | *** join/#arm-netbook Svet (~Sv@unaffiliated/sv) |
| 06:47.30 | *** join/#arm-netbook ol1ver (~Thunderbi@7of9.schinagl.nl) |
| 06:52.27 | mnemoc | lundman: there must be something... |
| 06:52.57 | mnemoc | lundman: the repartition tool is based in kernel code.. you can play from there |
| 06:53.36 | lundman | yeah I think I have found it |
| 06:53.43 | lundman | just waiting for compile so I can boot and try |
| 06:53.56 | mnemoc | userspace is simpler :p |
| 06:54.54 | lundman | the fix was in the kernel :) |
| 06:57.36 | lundman | ah ok, lets try then |
| 07:00.23 | lundman | ok this time I will dd it to nandc, then reboot |
| 07:01.15 | mnemoc | /dev/nand gives you free access to the mbr, and the partitioning tool mutated over kernel code |
| 07:01.33 | mnemoc | there is zero need to experiment with this on kernel space |
| 07:02.27 | lundman | box uname -a |
| 07:02.28 | lundman | Linux localhost 3.0.42+ #9 PREEMPT Tue Oct 16 06:55:29 UTC 2012 armv7l GNU/Linux |
| 07:02.32 | lundman | that did indeed fix it |
| 07:02.59 | mnemoc | in a way that keeps compatibility? |
| 07:03.08 | lundman | we should discuss that |
| 07:03.18 | mnemoc | :) |
| 07:03.20 | lundman | the line in question is: |
| 07:03.48 | lundman | drivers/block/sunxi_nand/nfd/mbr.c |
| 07:03.57 | mnemoc | show a patch |
| 07:03.59 | lundman | if((mbr->array[part_cnt].user_type == 2) || (mbr->array[part_cnt].user_type == 0)) |
| 07:04.09 | mnemoc | then I can test it here |
| 07:04.12 | lundman | want me to just make a github pull requests and discuss in there? |
| 07:04.19 | mnemoc | no... |
| 07:04.26 | mnemoc | git diff | sprunge |
| 07:04.48 | mnemoc | curl -F 'sprunge=<-' http://sprunge.us <---- sprunge |
| 07:05.23 | *** join/#arm-netbook leszcz (~marek@193.138.208.6) |
| 07:06.14 | ZaEarl | remind me again why patch discussion goes on the mailing list and now github? |
| 07:06.28 | ZaEarl | s/now/not/ |
| 07:06.29 | mnemoc | github doesn't give proper threading |
| 07:06.42 | mnemoc | also limits the audience |
| 07:07.13 | lundman | http://pastebin.com/a8ABeJqm |
| 07:07.28 | lundman | anyway. melev-1.3 MBR block, only has type 0 and type 1. |
| 07:07.40 | mnemoc | and gives the chance for people to learn before we get mainline |
| 07:07.44 | lundman | but I do not know about legacy. did older MBRs have 2, or is it a mistake |
| 07:07.59 | lundman | so the safe option is to add "1", as opposed to replace "2" |
| 07:08.12 | mnemoc | lundman: you had to use the worst pastbin service ever :< |
| 07:08.18 | ZaEarl | but then looking through patches on github won't include the discussions |
| 07:08.43 | mnemoc | lundman: the crap truncates long lines! http://pastebin.com/raw.php?i=a8ABeJqm |
| 07:09.04 | lundman | woo, i win! |
| 07:09.27 | mnemoc | ZaEarl: discussions on pull requests or issues don't get bound to commits on github either |
| 07:09.44 | lundman | ah its uart |
| 07:10.23 | mnemoc | lundman: git diff | acivilisedpaster |
| 07:10.32 | mnemoc | sprunge been the cleanes |
| 07:10.32 | mnemoc | t |
| 07:11.14 | lundman | http://pastebin.com/xHLSSSy3 |
| 07:11.19 | mnemoc | :< |
| 07:11.30 | lundman | even retained the chinese |
| 07:11.42 | *** join/#arm-netbook Quarx (~Quarx@94.137.58.58) |
| 07:13.08 | mnemoc | curl http://pastebin.com/raw.php?i=xHLSSSy3 | git apply |
| 07:13.14 | mnemoc | fatal: corrupt patch at line 12 |
| 07:13.29 | mnemoc | lundman: ok. what's the 2 and what the 1? |
| 07:13.31 | lundman | so, the question would be, are the older MBRs using "2" |
| 07:13.37 | lundman | or was that introduced incorrectly somewhere |
| 07:14.05 | lundman | alas, all references to "user_type" uses raw ints :( |
| 07:14.49 | lundman | bootloader, env, boot, recovery, private, systecoverya nd UDISK are 0 |
| 07:14.55 | lundman | system, data and cache are 1. |
| 07:14.58 | mnemoc | git grep user_type drivers/block/sunxi_nand shows only 2 references :< |
| 07:15.04 | lundman | i have not seen any 2s |
| 07:15.19 | mnemoc | let me look at my mele |
| 07:15.24 | mnemoc | that's old enough |
| 07:15.57 | lundman | <PROTECTED> |
| 07:16.28 | lundman | "Flag letter belongs" |
| 07:17.15 | *** join/#arm-netbook ZaEarl (~malmrose@014136144056.ctinets.com) |
| 07:17.28 | mnemoc | lundman: keep your local change and send a mail to the list CCed to Tom asking if he knows something |
| 07:17.42 | mnemoc | in the mean time I'll try to see if I have any 2s |
| 07:18.31 | ZaEarl | mnemoc, I don't understand. When I look at github, I see discussions in pull requests and comments in commits. Seems nice and organized like that. |
| 07:18.45 | lundman | yeah I mean, the safe option is to just add "1", and keep 2. but it sort of feels like the 2 is a misstake |
| 07:19.25 | lundman | I could also IDA their kernel and see what values they test for |
| 07:19.55 | mnemoc | ZaEarl: things get rebased, links get broken |
| 07:20.11 | ZaEarl | bummer |
| 07:20.14 | mnemoc | ZaEarl: in the ML you have proper interleaved discussion over the actual patch |
| 07:20.17 | mnemoc | in plain text |
| 07:20.42 | lundman | dang |
| 07:21.00 | lundman | kernel changed too much, can't load 3.0.8 modules in 3.0.42 without hanging :) |
| 07:21.14 | mnemoc | expectable... |
| 07:21.27 | lundman | so, a dead end |
| 07:21.36 | lundman | guess it is time to move onto some other project |
| 07:22.45 | *** join/#arm-netbook sspiff (~quassel@103.4-78-194.adsl-static.isp.belgacom.be) |
| 07:22.46 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 07:23.38 | mnemoc | lundman: what that doesn't evolve and move forward? |
| 07:24.12 | lundman | hmm? |
| 07:24.26 | mnemoc | "guess it is time to move onto some other project" |
| 07:24.30 | mnemoc | you lost me there |
| 07:25.24 | lundman | we dont have "their" sources for android 3.0.8 kernel. and I can't boot our 3.0.42 kernel |
| 07:25.42 | mnemoc | tried from uSD? |
| 07:25.56 | lundman | never managed to boot android from SD actually |
| 07:26.13 | lundman | but I suppose I could add 42 modules to nandX somewhere |
| 07:26.17 | mnemoc | android... :| |
| 07:36.01 | hno | mnemoc, I have not been able to test the reboot issue in depth. |
| 07:37.14 | mnemoc | hno: but at least reproduce one? |
| 07:37.31 | mnemoc | i'm starting to wonder if i've burned out my cards |
| 07:37.38 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 07:37.49 | mnemoc | s/one/once/ |
| 07:38.51 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 07:39.18 | *** join/#arm-netbook mid7tester (55bbd88a@gateway/web/freenode/ip.85.187.216.138) |
| 07:46.18 | lundman | dang, loading the .42+ modules on android makes it panic, after loading UMP |
| 08:04.37 | mnemoc | gosh. the code of this nand-part is horrible |
| 08:13.39 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 08:17.12 | mnemoc | lundman: in my mele I have type 0 and 2 |
| 08:17.56 | mnemoc | lundman: http://dpaste.com/814191/plain/ |
| 08:19.23 | mnemoc | so I guess we need to accept the 3 values |
| 08:26.46 | mnemoc | does that really solve your nand detection problem? |
| 08:28.07 | *** join/#arm-netbook popolon (~popolon@82.225.234.108) |
| 08:35.01 | lundman | yep it did |
| 08:35.08 | lundman | ok, so the real answer is to handle 3 |
| 08:35.51 | lundman | if you boot .42 kernel, it will not "show you" system, data and cache, as it skips type==1 |
| 08:35.55 | lundman | so I would say we need it |
| 08:36.43 | *** join/#arm-netbook silentaa (znc@aribaud.fr) |
| 08:50.31 | mnemoc | want to send a patch yourself? It's your fix after all |
| 08:53.41 | *** join/#arm-netbook ZaEarl (~malmrose@014136144056.ctinets.com) |
| 08:59.20 | *** join/#arm-netbook ZaEarl_ (~malmrose@014136144056.ctinets.com) |
| 09:08.40 | *** join/#arm-netbook oliv3r (~oliver@7of9.schinagl.nl) |
| 09:11.38 | *** join/#arm-netbook cat_n9 (~communi@a91-152-66-200.elisa-laajakaista.fi) |
| 09:24.44 | *** join/#arm-netbook avernos (~avernos@222.128.157.156) |
| 09:24.45 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
| 09:57.48 | *** join/#arm-netbook newbie (~kvirc@118-168-194-44.dynamic.hinet.net) |
| 09:59.09 | *** join/#arm-netbook rellla (~Thunderbi@p5B0789F5.dip0.t-ipconnect.de) |
| 10:14.16 | libv | .fex is not as funny as the fermi microcode (fuc) the nouveau guys keep talking about, but gets bonus points for the father ted reference :) |
| 10:17.16 | mnemoc | o_O |
| 10:25.55 | *** join/#arm-netbook jeremb (u2617@gateway/web/irccloud.com/x-ikswyjlxsjliiyds) |
| 10:28.10 | jeremb | hi everyone, I have a question, are phoenixcard images and livesuit the exact same thing or does the phonixcard image contains more things? |
| 10:29.12 | mnemoc | phonixcard turns a livesuit image into an installer card with phonixcard image format |
| 10:29.24 | *** join/#arm-netbook ZaEarl_ (~malmrose@014136144056.ctinets.com) |
| 10:30.13 | jeremb | because I am trying to build a custom image for the MK802 II but it's never flashed correctly when I burn it with PhoenixCard |
| 10:30.57 | jeremb | so normally the same .img file can be both used in LiveSuit and Phoenix card ? |
| 10:31.12 | mnemoc | afaik, yes. I've never used either |
| 10:32.15 | mnemoc | in sunxi-tools there is a tool that parses phoenixcard images (already on card, or dd-able) |
| 10:32.32 | mnemoc | it might show you what's on yours |
| 10:32.57 | jeremb | so it's strange because I take the official MK802II rom, I unpack/repack it with unimg.exe then burn it with PhoenixCard and it never get flashed on my device... |
| 10:33.50 | mnemoc | test without repacking it |
| 10:33.56 | jeremb | it works |
| 10:34.16 | mnemoc | then the repacking is broken |
| 10:34.40 | jeremb | phoenix_info tells me that both the original img and the repacked one are not valid phoenixcard images |
| 10:35.16 | mnemoc | maybe different format version |
| 10:35.28 | mnemoc | not supported by the other tools yet |
| 10:36.16 | mnemoc | pretty common when dealing with obscure proprietary formats/tools |
| 10:36.41 | jeremb | so any advice how I can repack the image? maybe another tool? or method? |
| 10:39.07 | ZaEarl_ | try LiveSuit |
| 10:40.06 | jeremb | unfortunately it's not easy to to switch the device to LiveSuit mode as there is no hardware button to do it |
| 10:40.50 | ZaEarl_ | that's interesting. what device? |
| 10:40.56 | mnemoc | you can make a bootable card jumping you directly to FEL mode |
| 10:41.11 | ZaEarl_ | that's a good idea |
| 10:41.14 | jeremb | MK802II |
| 10:41.47 | jeremb | yep I'll try that but I would like to make a PhoenixCard compatible img to easily share my ROM with others |
| 10:43.05 | mnemoc | https://github.com/linux-sunxi/sunxi-tools/blob/master/fel-boot.c would let you boot directly to FEL from a uSD card |
| 10:43.05 | ZaEarl_ | so they took the reset button off II? Lame. |
| 10:43.17 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 10:44.06 | jeremb | there is a recovery button, but it boot the device in recovery mode, not in FEL mode |
| 10:44.11 | jeremb | @mmemoc thanks |
| 10:55.54 | mnemoc | jeremb: unfortunatelly for your problem most people here focuses in the open source side of sunxi (A10/A10s/A12/A13/...), CM in the case of android, and not really into modifying closed images. |
| 11:00.34 | jeremb | mnemoc: ok I understand! |
| 11:03.03 | mnemoc | but in the cubieboard branch of https://github.com/matson-hall/allwinner-pack-tools you might find newer tools |
| 11:04.17 | *** join/#arm-netbook ZaEarl_ (~malmrose@014136144056.ctinets.com) |
| 11:19.01 | *** join/#arm-netbook techn_ (~quassel@a91-152-35-60.elisa-laajakaista.fi) |
| 11:36.48 | libv | hrm, with "Building_Debian_From_Source_Code_for_Mele" adjusted for linux-sunxi github stuff and with a linaro rootfs, i managed to get something booting |
| 11:36.55 | libv | but this is far from smooth |
| 11:37.22 | libv | [ 184.200000] EXT4-fs (mmcblk0p2): recovery complete |
| 11:37.35 | libv | close to a 3 minute wait right there :) |
| 11:38.35 | mnemoc | by default ondemand enjoys to run at 60MHz on the A10 |
| 11:38.56 | libv | ah, yes |
| 11:40.14 | mnemoc | http://linux-sunxi.org/Cpufreq has some settings that work nicely here |
| 11:40.59 | alcides | http://www.kickstarter.com/projects/adapteva/parallella-a-supercomputer-for-everyone |
| 11:42.19 | mnemoc | alcides: old news ;-) |
| 11:42.45 | alcides | mnemoc not old... not even sold... |
| 11:43.59 | mnemoc | alcides: but it was announced like a month ago |
| 11:45.08 | alcides | yes... but still away of the goal... only 50% |
| 11:45.59 | RaYmAn | I honestly think the majority of people that could potentially be interested in backing it has already seen it. |
| 11:46.19 | rm | would be nice |
| 11:46.24 | rm | but I just plain do not believe them |
| 11:46.35 | lundman | :) |
| 11:46.36 | RaYmAn | what part? |
| 11:46.37 | rm | and I don't believe I will get anything in return for any money sent |
| 11:47.21 | mnemoc | it's nice they use openness as flag |
| 11:49.21 | RaYmAn | mnemoc: definitely, but they still seem kind of low on details |
| 11:49.45 | jelly-home | I don't really see how their coprocessors are different from gpgpu solutions |
| 11:49.48 | RaYmAn | I mean, is it a custom soc with everything in same package (including paralella) or is it some standard soc with parallela as external chip etc |
| 11:50.04 | RaYmAn | jelly-home: can you program gpgpu cores individually? |
| 11:50.06 | mnemoc | it's a dual a9 soc + grid of their own not-arm cores called Epiphany |
| 11:50.23 | RaYmAn | mnemoc: yes, but that's kind of vague |
| 11:50.30 | jelly-home | RaYmAn: I don't want to... "parallel" usually means the same thing in parallel |
| 11:51.14 | RaYmAn | well, that is still one of the major differences. |
| 11:51.18 | RaYmAn | even if you don't want to |
| 11:56.18 | rm | http://www.kickstarter.com/help/faq/backer%20questions#GettRewa |
| 11:56.22 | rm | so it's as I assumed |
| 11:56.34 | rm | they are under no real obligation to deliver anything |
| 11:56.57 | rm | the most you can do about that is do a "direct message" or "post a public comment" |
| 11:57.40 | RaYmAn | sure, it's like that with any and all kickstarter projects |
| 11:57.57 | RaYmAn | Heck, you have the same issue if you preorder something and the company goes bankrupt |
| 11:59.15 | libv | mnemoc: boosting it to 1G helps avg performance... but... the whole machine tends to stall quite often |
| 11:59.29 | rm | RaYmAn, no |
| 11:59.47 | libv | mnemoc: i am currently worried about mmc not being stable |
| 11:59.51 | rm | on preorders+bankruptcy you can certainly get a refund |
| 11:59.58 | rm | complicated, but still |
| 12:00.19 | libv | 90% waiting... mmcqd/0 |
| 12:00.35 | RaYmAn | rm: only if there's enough money left :P |
| 12:00.50 | rm | right |
| 12:01.49 | mnemoc | libv: using latest u-boot or something older? what kernel branch? |
| 12:02.04 | libv | latest u-boot, latest 3.0 |
| 12:02.34 | RaYmAn | most companies doing kickstarter projects will pretty much be f*cked if they don't deliver though - community backlash etc, so presumably roughly equivalent to backruptcy |
| 12:02.42 | mnemoc | strange. I work purely on uSD on my 3 test devices and none has similar troubles |
| 12:02.43 | libv | aah, i forgot one step, but that should not affect mmc performance |
| 12:03.07 | libv | there are no modules or firmwares in this rootfs |
| 12:03.34 | mnemoc | that shouldn't affect anything |
| 12:03.41 | libv | i will try another sd card and replay some things, and document things on the linux-sunxi wiki |
| 12:03.49 | mnemoc | thanks |
| 12:04.16 | *** join/#arm-netbook itamar_ (~itamar@189-015-124-078.xd-dynamic.ctbcnetsuper.com.br) |
| 12:05.30 | *** join/#arm-netbook ssspiff (~quassel@unaffiliated/yukito) |
| 12:13.07 | oliv3r | mnemoc: you linked Cpufreq up there somewhere, but the github link on that page does no longer work :( |
| 12:14.44 | mnemoc | issue tracker moved from amery to linux-sunxi orga |
| 12:14.48 | mnemoc | back in 20m |
| 12:30.32 | *** join/#arm-netbook rz2k (~rzk@95-24-11-251.broadband.corbina.ru) |
| 12:51.43 | *** join/#arm-netbook pwhalen (~paul@CPE001310360dac-CM78cd8ec9e405.cpe.net.cable.rogers.com) |
| 13:02.15 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 13:14.48 | *** join/#arm-netbook cat_n9 (~communi@37-219-1-7.nat.bb.dnainternet.fi) |
| 13:30.34 | *** join/#arm-netbook QingPei (~qingpei@124.64.127.39) |
| 14:16.26 | *** join/#arm-netbook cat_n9 (~communi@a91-152-66-200.elisa-laajakaista.fi) |
| 14:25.09 | oliv3r | mnemoc: you back? |
| 14:25.48 | oliv3r | long 20m |
| 14:27.07 | *** join/#arm-netbook hp__ (~kvirc@118-168-194-44.dynamic.hinet.net) |
| 14:27.56 | mnemoc | oliv3r: ? |
| 14:29.15 | oliv3r | wb :) |
| 14:29.34 | oliv3r | mnemoc: i've sent you a pull-request on sunxi-tools |
| 14:29.40 | oliv3r | over on github |
| 14:30.44 | mnemoc | oliv3r: i would prefer if you can send it to the ML for discussion |
| 14:31.30 | RaYmAn | if I'm reading that right, they actually implemented a kernel driver to do exactly what libusb does in userspace? :/ |
| 14:32.26 | oliv3r | nope, this is the awusb driver from allwinnertech; i just cleaned it up and gave it a home on github (it came from tom's i belive) |
| 14:32.38 | oliv3r | oh, they, i thought you ment me; i belive so |
| 14:32.40 | mnemoc | but it's required by livesuit and buggy, so something we probably need to maintain to avoid chaos |
| 14:32.55 | oliv3r | but they based it on 'something' existing |
| 14:33.23 | mnemoc | oliv3r: http://www.kernel.org/pub/software/scm/git/docs/git-send-email.html |
| 14:33.56 | oliv3r | i'll get the patch into the mailing list, but leave the pull-request as is for now; if no real comments come (like my previous mail) you can still pull it and work can be done from there |
| 14:34.34 | RaYmAn | mnemoc: I'm looking forward to the day when we have a fully open solution for livesuit-like recovery |
| 14:34.42 | oliv3r | and yeah, i do think it should have a 'home' somewhere, sunxi-tools sounds sensible. |
| 14:34.50 | oliv3r | hometime |
| 14:35.08 | mnemoc | instead of getting this in the tools packages it might be a good idea to turn sunxi-boards into our own BSP package |
| 14:35.29 | mnemoc | s/packages/package/ |
| 14:36.49 | mnemoc | and work as glue to our other packages, including android, buildroot, "hwpacks", .... |
| 14:37.19 | mnemoc | but ML |
| 14:39.00 | mnemoc | RaYmAn: of course that is the ultimate goal |
| 14:52.46 | rz2k | Turl: you've asked yesterday about if that es2gears is cpu |
| 14:52.49 | rz2k | [ 159.870000] UMP<2>: New session opened [ 159.870000] Mali<2>: Session starting [ 161.090000] Mali<2>: Mali PM: OS runtime resumed |
| 14:53.05 | rz2k | digging in to r3p1 debug options |
| 14:54.30 | *** join/#arm-netbook leszcz (~marek@host-89-167-63-165.nplay.net.pl) |
| 14:56.17 | Turl | rz2k: UMP is just a memory allocator |
| 14:58.03 | jeremb | speaking about livesuit, there is now a Linux version, it should be easier to reverse engineering it |
| 14:58.05 | mnemoc | can you try the wip/linux-sunxi-3.0/disp branch? |
| 15:06.25 | rz2k | Turl: previously we had total fail with Mali itself |
| 15:06.43 | rz2k | UMP opens session but then libgles dies |
| 15:06.56 | rz2k | now I'm running glmark2-es2 successfully right now |
| 15:07.20 | Turl | change your governor to performance |
| 15:07.25 | Turl | then monitor load with htop or similar |
| 15:07.31 | Turl | it shouldn't eat all of your cpu |
| 15:09.25 | rz2k | also afaik libraries that I use right now (default mali r3p1 armhf) cant do anything on CPU |
| 15:10.15 | rz2k | glmark2 score:43 |
| 15:10.37 | rz2k | thats with mali_div=4, default one from mele a2000 script.bin |
| 15:11.57 | Turl | isn't the default =3? |
| 15:12.38 | rz2k | with 3 it will be 320mhz with 4 300mhz, but dont quoute me on this one. |
| 15:13.01 | Turl | just 20mhz difference? |
| 15:13.05 | rz2k | I just grabbed default script from nanda and using it. |
| 15:13.11 | Turl | I thought it was 960 or something of that sorts / div |
| 15:13.35 | rz2k | pokes mnemoc as a local mali mem/div expert |
| 15:13.49 | Turl | I once was playing with it and --'d the value |
| 15:13.52 | Turl | my mali didn't like it :) |
| 15:21.21 | mnemoc | i'll ignore you all until I get confirmation wip/linux-sunxi-3.0/disp can be merged :p |
| 15:28.32 | rz2k | interesting |
| 15:28.54 | rz2k | glmark2-es2 eats 3%-9% of CPU |
| 15:29.06 | *** join/#arm-netbook ol1ver (~Thunderbi@7of9.schinagl.nl) |
| 15:29.13 | rz2k | but X eats everything else entirely |
| 15:29.32 | mnemoc | at 1GHz? |
| 15:29.37 | rz2k | yep |
| 15:29.45 | mnemoc | :( |
| 15:30.13 | rz2k | looks like on each frame update x11 mali driver does some serious math or whatever |
| 15:30.25 | rz2k | or its just monkeycoded as usual |
| 15:32.34 | rz2k | previously on mesa sw rasterization glmark2 had 100% |
| 15:34.16 | Turl | maybe 'mali' is just dummy fb handling + mode setting |
| 15:34.57 | Turl | mode setting would be handled by disp though |
| 15:35.33 | *** join/#arm-netbook ol1ver (~Thunderbi@7of9.schinagl.nl) |
| 15:41.08 | rz2k | interesting results http://pastebin.com/gRrt7Rf4 |
| 15:41.36 | rz2k | looks like ARM forgot to implement half of the oGL ES2 |
| 15:42.09 | rz2k | (benchmark runs smooth though, just without bunch of shaders that are not implemented) |
| 15:42.37 | libv | but the mali userspace has a essl compiler built in |
| 15:42.49 | libv | gles2 mandates a compiler being available |
| 15:42.54 | Turl | the nand is so slow I cannot play music and use apps simultaneously :| |
| 15:43.50 | libv | rz2k: i am sure that there are other issues at play here, and the individual test cases failure messages should be looked at in detail |
| 15:45.07 | *** join/#arm-netbook arete74 (~arete74@host160-66-static.225-95-b.business.telecomitalia.it) |
| 15:46.39 | *** join/#arm-netbook jeremb_ (u2617@gateway/web/irccloud.com/x-yektuytbvvnajmtm) |
| 15:47.52 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 15:48.49 | rz2k | libv: here is a debug output http://pastebin.com/mAxU76ac |
| 15:49.14 | rz2k | also everything we have for native linux is proprietary libs and x11 driver that appears to do nothing |
| 15:49.43 | libv | rz2k: yes, i am quite acutely aware of the problem with arm gpu binaries |
| 15:50.24 | mnemoc | rz2k: tried bombing tom with daily reminders? ;-) |
| 15:51.27 | libv | Info: [texture] texture-filter=nearest:Debug: Validation failed! Expected: 0xff282a2b Actual: 0xffaeaeae |
| 15:51.30 | libv | wow. |
| 15:51.37 | libv | is that a checksum of the produced image? |
| 15:51.51 | libv | if so, what idiot wrote this. |
| 15:52.32 | libv | gl does not claim or require that different combinations of hardware and software create pixel perfect and identical renderings of the same scene |
| 15:56.12 | rz2k | all kudos go to author of glmark2 |
| 15:56.28 | libv | i know |
| 15:56.41 | libv | it's that greek linaro guy |
| 15:58.29 | Sv | sunxi is nice, i've been playing around with a hackberry |
| 16:25.11 | techn_ | rz2k: latest should be x11 libs |
| 16:25.32 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 16:28.19 | techn_ | .. yesterday, we got new r3p0/1 libs from Tom.. They seem to work now.. not perfect but working |
| 16:34.20 | mnemoc | r3p0? meaning we can merge that to the main branch and finally replace r2p4? |
| 16:35.16 | techn_ | yes! but main branch looses cedarx :( |
| 16:36.09 | techn_ | as libs are armhf only :( |
| 16:36.13 | techn_ | or :) |
| 16:36.50 | techn_ | I'm testing r3p0 and it seems glmark and es2gears works |
| 16:38.38 | mnemoc | uhm... not nice... that would trigger a fork :< |
| 16:42.24 | mnemoc | so will need both :| |
| 16:42.29 | mnemoc | sucks |
| 16:42.34 | Turl | ehm |
| 16:42.40 | Turl | how is it different than the current situation? |
| 16:42.45 | Turl | cedar never worked on armhf? |
| 16:43.05 | mnemoc | cedarx is still armel only |
| 16:43.14 | mnemoc | r2p4 is armel/armhf |
| 16:43.22 | mnemoc | r3p0/p1 is armhf only |
| 16:43.34 | Turl | you can probably bug tom to make a r3p0 armel |
| 16:43.38 | Turl | :) |
| 16:44.00 | mnemoc | techn_: ----^ ? |
| 16:44.28 | Turl | after all android runs on it |
| 16:45.35 | mnemoc | there is no connection between building for android and building for linux/armel |
| 16:46.09 | Turl | android is -mfpu=soft iirc |
| 16:47.05 | mnemoc | it's not about optimizations, it's about bionic vs. glibc, and x11 vs whatever android uses |
| 16:47.10 | Turl | s/fpu/float-abi/ |
| 16:47.27 | Turl | s/soft/softfp/ |
| 16:47.31 | mnemoc | different toolchain, different env |
| 16:47.38 | Turl | meh :< doesn't cache last sedfix |
| 16:47.52 | Turl | -mfloat-abi=softfp mnemoc |
| 16:48.00 | Turl | so there's no 'technical reason' it has to be armhf only |
| 16:48.29 | mnemoc | the technical reason is that he uses ubuntu/armhf to build the libs natively |
| 16:48.42 | Turl | crosscompilation? :P |
| 16:48.50 | mnemoc | don't ask that much |
| 16:49.12 | Turl | I'll build the bins myself |
| 16:49.28 | Turl | just get me the source :P |
| 16:49.34 | mnemoc | ARM blessed people only |
| 16:49.56 | Turl | yeah I know :'( |
| 16:51.35 | ManoftheSea | is still sad about the lack of display options on EOMA |
| 16:52.09 | ManoftheSea | or, higher res ones, anyway. |
| 16:59.09 | merbanan | mnemoc: would it be possible to do a binary translation from armel to armhf ? |
| 17:00.58 | mnemoc | in the sense that it's not impossible, yes. but unlikely considering viable time constrains ;-) |
| 17:01.08 | merbanan | just so it would be abi compatible |
| 17:06.11 | *** join/#arm-netbook vgrade_ (~martin@cpc2-nrte22-2-0-cust128.8-4.cable.virginmedia.com) |
| 17:06.38 | mnemoc | it's probably harder than making allwinner opensource cerdarx |
| 17:09.43 | merbanan | mnemoc: one can always hope |
| 17:15.05 | Turl | you could use android libs with libhybris |
| 17:15.37 | mnemoc | i doubt they work that deep down in the stack |
| 17:19.53 | *** join/#arm-netbook Yakuzzi (~za@ip-109-40-153-175.web.vodafone.de) |
| 17:23.00 | *** part/#arm-netbook QingPei (~qingpei@124.64.127.39) |
| 17:34.04 | *** join/#arm-netbook Gujs_ (~Gujs@cpe-92-37-75-238.dynamic.amis.net) |
| 17:34.19 | techn_ | mnemoc: I could ask armel libs.. do we want x11 or framebuffer libs? |
| 17:34.36 | mnemoc | x11 |
| 17:35.08 | mnemoc | asking for both only increases the odd of not receiving any |
| 17:35.12 | mnemoc | odds* |
| 17:35.16 | Sv | yes |
| 17:35.18 | techn_ | .. why ARM has made this so hard.. libs for every different platform :( |
| 17:35.26 | Turl | because |
| 17:38.17 | jelly-home | what's wrong with hardfloat? |
| 17:39.00 | libv | techn_: well, egl is where the rub is |
| 17:39.28 | libv | is the egl X11 based, or fb, or wayland, does it tie in with the 2d engine or not |
| 17:39.56 | *** join/#arm-netbook Yakuzzi (~za@ip-109-40-153-175.web.vodafone.de) |
| 17:41.05 | mnemoc | jelly-home: problem isn't with hf. problem is we have to deal with closed libraries. for cedarx we still only have debian/armel libs |
| 17:41.26 | mnemoc | jelly-home: and for mali r3p0/1 we only have ubuntu/armhf libs |
| 17:42.24 | mnemoc | so until we get cedarx libs for armhf our only option to move forward to r3p0/1 is to get new mali libs for debian/armel to match cedarx |
| 17:42.50 | mnemoc | or keep both in the kernel |
| 17:43.04 | mnemoc | making the drm/ump integration even messier |
| 17:43.10 | techn_ | mnemoc: btw. any progress getting armhf cedarx? :/ |
| 17:43.17 | *** join/#arm-netbook pawel58701 (~pkarpins@pc.193147149.ip.amg.net.pl) |
| 17:43.25 | mnemoc | techn_: you have more contact with Tom than I :| |
| 17:44.21 | mnemoc | but afaik the only dev within AW who can build them isn't very.... friendly |
| 17:45.42 | discopig | cpufreq really enjoys itself on A10, it keeps setting the cpu to 60mhz |
| 17:45.46 | mnemoc | otoh eva is happy telling everyone they are collaborating with gimli and that's enough |
| 17:46.46 | techn_ | gimli: you have armhf cedarx libs? or could you get them via your contact? :) |
| 17:47.05 | mnemoc | discopig: add http://linux-sunxi.org/Cpufreq#Tweaks to your rc.local |
| 17:47.12 | discopig | ahh thanks |
| 17:47.28 | mnemoc | it can be equally broken libs, we only need them recompiled, not fixed |
| 17:47.31 | gimli | techn_: nope |
| 17:47.34 | mnemoc | fixed is better obviusly |
| 17:47.47 | techn_ | mnemoc: I didn't understand that guy who had problems with latest commit.. Do we have a problem? |
| 17:48.07 | mnemoc | not that i know |
| 17:48.32 | *** join/#arm-netbook cat_n9 (~communi@37-219-97-244.nat.bb.dnainternet.fi) |
| 17:56.26 | *** join/#arm-netbook Yakuzzi (~za@ip-109-40-153-175.web.vodafone.de) |
| 18:00.07 | techn_ | xbmc seems to crash.. |
| 18:00.09 | techn_ | #3 0x41935528 in ump_reference_release () from /lib/libUMP.so |
| 18:00.09 | techn_ | #4 0x40ace42a in _egl_platform_map_dri2_buffer () from /lib/libGLESv2.so.2 |
| 18:00.15 | techn_ | .. |
| 18:00.33 | techn_ | #10 0x40ac8b22 in eglMakeCurrent () from /lib/libGLESv2.so.2 |
| 18:00.33 | techn_ | #11 0x007886d2 in CWinSystemX11GLES::RefreshEGLContext() () |
| 18:00.33 | techn_ | #12 0x00788b36 in CWinSystemX11GLES::SetFullScreen(bool, RESOLUTION_INFO&, bool) () |
| 18:00.33 | techn_ | #13 0x007881bc in CWinSystemX11GLES::CreateNewWindow(CStdStr<char> const&, bool, RESOLUTION_INFO&, bool (*)(XBM |
| 18:01.19 | techn_ | rz2k: have you tried xbmc? |
| 18:06.50 | techn_ | Oct 16 21:06:04 linaro-alip xbmc.bin: ASSERT EXIT: |
| 18:06.51 | techn_ | Oct 16 21:06:04 linaro-alip xbmc.bin: In file: arch_011_udd/ump_frontend.c function: p¡AÂ() line:39745208 |
| 18:06.51 | techn_ | Oct 16 21:06:04 linaro-alip xbmc.bin: Error in mapping pointer (not mapped) |
| 18:08.27 | rz2k | no, linaro's xbmc tries to initialize libGL, not gles |
| 18:08.45 | techn_ | I'm using linaros xbmc |
| 18:09.02 | techn_ | or trying to use :) |
| 18:21.03 | *** join/#arm-netbook cat_n9 (~communi@a91-152-66-200.elisa-laajakaista.fi) |
| 18:33.04 | lkcl | ManoftheSea: that's because you're misunderstanding things. EOMA goes up to the maximum permitted on an RGB/TTL interface, which, on a TI OMAP CPU is 2048x2048 @ 30fps. |
| 18:33.28 | lkcl | ManoftheSea: it's the SoCs which limit the maximum resolution, *not* the EOMA-68 specification. |
| 18:38.35 | ManoftheSea | that makes me a little happier. |
| 18:39.40 | ManoftheSea | lkcl: I have part of a schematic of, well basically of a USB hub. |
| 18:39.50 | ManoftheSea | But it's the necessary part of the micro board. |
| 18:40.15 | ManoftheSea | It takes the D+ and D- lines from the PCMCIA header and feeds it to a 7-port, multi-TT USB hub. |
| 18:40.40 | ManoftheSea | But, I don't know how to finish the board with footprints and connectors. |
| 18:43.59 | ManoftheSea | Actually, I should mail this to the list. |
| 18:54.27 | *** join/#arm-netbook j1nx_ (~IceChat9@163-62-223.ftth.xms.internl.net) |
| 19:07.37 | Turl | woot, someone deduped the sun[45]i usb stack :) |
| 19:08.02 | hno | Turl, what? |
| 19:08.43 | Turl | hno: check the mailing list |
| 19:09.03 | rz2k | rm: you wanted 1080p on vga? |
| 19:09.18 | rm | not me |
| 19:09.31 | rz2k | damn, anyway I have it running |
| 19:09.41 | Turl | rz2k: it was lundman probably |
| 19:10.26 | rm | rz2k, I wanted uhm |
| 19:10.31 | rm | 1650x1050 on HDMI |
| 19:10.35 | rm | can you do that? :) |
| 19:11.02 | rm | 1680x1050* |
| 19:11.14 | rz2k | nope if it is not in the modes list :/ |
| 19:11.29 | techn_ | rz2k: Even that wont help |
| 19:11.45 | rz2k | interesting thing is, X works on 1080p, when console is still in 720p in left-upper corner |
| 19:12.09 | rm | rz2k, do you have any success setting 75 Hz on VGA? |
| 19:12.27 | rm | with some lame resolution at least |
| 19:12.38 | rz2k | no, I think 60 is hardcoded somewhere |
| 19:12.43 | techn_ | Resolutions are hardcoded.. but that can be changed if same is done to vga-side.. https://github.com/techn/linux-allwinner/commit/1b0a097e82c8b8b8ecc54754fdf7259728ea4a6d |
| 19:13.07 | techn_ | .. that's still wip.. but atleast part of changes are there |
| 19:13.12 | libv | what is hdmi wired to? what is vga wired to? |
| 19:13.39 | Turl | I see GCCisms there https://github.com/techn/linux-allwinner/commit/1b0a097e82c8b8b8ecc54754fdf7259728ea4a6d#L2R946 |
| 19:14.37 | *** join/#arm-netbook merbzt (~benjamin@c-94-255-220-30.cust.bredband2.com) |
| 19:14.49 | libv | because 9y ago i heard "no, it cannot be done, we will need to rely on the modes programmed in the bios" |
| 19:15.21 | Turl | 9y ago only? |
| 19:15.34 | hno | Turl, got it. Nice. |
| 19:15.52 | libv | it took another 3-4 for people to realize that this was bogus, and that i was bang on :) |
| 19:15.59 | libv | 3-4 years even |
| 19:16.41 | hno | rz2k, the console driver probably is missing some hook to react on the resolution change. |
| 19:17.57 | hno | libv, we did custom video modes on EGA. Don't know a single graphics card that have had hardcoded resolutions. |
| 19:18.13 | *** join/#arm-netbook revident (~scott@fw.iplink.net) |
| 19:18.14 | libv | hno: where were you in the first half of the 2000s? |
| 19:18.39 | hno | Long away from video cards. GPUs isn't my thing. |
| 19:18.45 | libv | this is display, not gpu |
| 19:19.27 | libv | in any case, remember life before randr1.2 (however limited and shortsighted that was), before that happened people refused to believe different |
| 19:19.45 | hno | randr1.2 on EGA would be something.. |
| 19:19.49 | libv | so today i am quite weary of people stating "no, cannot happen" |
| 19:20.22 | libv | especially when it often is just about one person spending 3-4ds testing mode after mode, figuring out how the pll ticks and what its limits are |
| 19:20.22 | techn_ | Turl: there is much to improve.. but first I was thinking to get rid of that wip/disp branch |
| 19:21.04 | Turl | the kernel is full of allwinner quality code :) |
| 19:21.30 | ManoftheSea | Byond "Quality" |
| 19:21.56 | libv | Turl: it seems better than the code VIA threw out in 2003. there were actual register tables there, dumped straight from the VIA vga BIOS... |
| 19:22.02 | *** join/#arm-netbook rsalveti_ (~rsalveti@linaro/rsalveti) |
| 19:22.55 | libv | in any case, what is hdmi wired to? |
| 19:23.09 | Turl | libv: A10 I believe |
| 19:23.12 | libv | a special hdmi block which is not documented, i suspect, due to hdcp |
| 19:23.48 | libv | the tv-encoder most likely drives the vga connector |
| 19:25.16 | mnemoc | Turl: in the kernel those gcc-isms are welcomed. many others too. they call it the gnu99 standard :p |
| 19:25.19 | Maqs | apropos kernel for allwinner.. to replace an existing kernel, is it enough to build a new uImage and replace the old one? |
| 19:25.20 | hno | libv, most my video card hacking was in 1985-1990 or so. But have not seen any evidence that cards are less flexible in their timing & resolution capabilities overtime. |
| 19:26.01 | libv | hno: i have dealt with external tv encoders which really only did accept a few fixed modes |
| 19:26.18 | libv | so in some rare cases it does happen |
| 19:26.30 | mnemoc | Maqs: you also need to replace the modules |
| 19:26.31 | Turl | mnemoc: didn't know that |
| 19:27.25 | Maqs | mnemoc: ok, done.. but somehow it doesn't seem to work.. i don't get any output, so i cannot tell what's the problem :-/ |
| 19:27.49 | mnemoc | Maqs: booting from nand? what branch? |
| 19:28.12 | hno | libv, ah, yes, can imagine finding that in such things. Probably still seen in USB connected TV encoders. |
| 19:28.50 | Maqs | sunxi-3.0, booting from sdcard |
| 19:28.51 | hno | doubt the hardware as such is limited, but likely a firmware imposing it's own rules. |
| 19:29.21 | libv | hdmi seems to be freely programmable, but it will take quite a bit of work getting things that far :) |
| 19:29.28 | libv | as hdmi seems to be its own block |
| 19:29.35 | mnemoc | Maqs: do you see u-boot's output? what defconfig did you use? |
| 19:29.51 | Maqs | i just added a few things to what came from /proc/config.gz, compiled it, copied arch/arm/uImage |
| 19:30.06 | hno | The A10 display blocks seem very freely programmable indeed. But hidden far down behind many layers of odd abstractions. |
| 19:30.23 | ManoftheSea | Hey guys, if you're discussing the graphics and the A10... can you confirm how much res you can put out a single TTL/RGB? |
| 19:30.52 | hno | coming from an history of several operating systems and desire to oversimplify things in obscure ways. |
| 19:31.03 | Maqs | defconfig doesn't seem to compile due to some "usb glue" stuff |
| 19:31.20 | Maqs | it's an mk802 (a10) |
| 19:31.32 | mnemoc | Maqs: sun4i_defconfig works fine |
| 19:32.16 | mnemoc | Turl: still, that particular switch() would look better with ifs |
| 19:32.19 | Maqs | strange |
| 19:32.22 | hno | ManoftheSea, unknown what pixelrate the A10 accepts to output in TTL mode. Quite likely it does whatever you ask it to do, but signal levels might not be too great at higher frequencies. |
| 19:33.06 | Maqs | there is an '#error "missing bus glue for ehci-hcd"' |
| 19:33.37 | hno | Maqs, how are you building? |
| 19:33.39 | Turl | Maqs: are you using a 3.0 config on 3.4? |
| 19:33.48 | Maqs | nope, it's 3.0 both |
| 19:34.08 | Maqs | only defconfig did not work, the /proc/config.gz compiled just fine |
| 19:34.16 | Maqs | but does not run |
| 19:34.33 | hno | sun4i_defconfig, or defconfig? |
| 19:34.44 | Maqs | i don't get any output at all, my monitor just keeps searching for a source |
| 19:35.02 | Maqs | gotta check that.. |
| 19:35.15 | mnemoc | monitor :) |
| 19:35.29 | mnemoc | Maqs: less greed. try a serial console first |
| 19:36.22 | *** join/#arm-netbook rellla1 (~Thunderbi@p4FE560BD.dip0.t-ipconnect.de) |
| 19:37.53 | Maqs | i don't have any idea how to do that ;) |
| 19:38.28 | Maqs | i did "make ARCH=arm sun4i_defconfig" |
| 19:39.53 | *** join/#arm-netbook popolon (~popolon@82.225.234.108) |
| 19:40.16 | Turl | plug your uart to ttl adaptor and "screen /dev/ttyUSB0 115200" |
| 19:40.31 | mnemoc | Maqs: and CROSS_COMPILE= ? |
| 19:40.50 | Maqs | i compiled it on the mk802 |
| 19:42.25 | Maqs | ARCH=arm should be redundant, too.. i guess.. |
| 19:46.37 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 19:46.51 | hno | Maqs, yes |
| 19:47.54 | Maqs | ok, again.. mrproper sun4i_defconfig uImage modules modules_install |
| 19:48.20 | mnemoc | try in separated steps |
| 19:48.57 | hno | split mrporper and sun4i_defconfig in their own make steps. the other can be mixed. |
| 19:48.58 | Maqs | k |
| 19:49.31 | Turl | never makes modules, yet they're built the same |
| 19:49.51 | hno | modules_install builds modules |
| 19:50.08 | Turl | I just make uImage |
| 19:50.29 | Maqs | btw, may that have to do with armhf? |
| 19:50.44 | hno | Maqs, no |
| 19:51.13 | Maqs | i had to patch uboot to compile, as they use -msoft-float |
| 19:51.25 | hno | Turl, so you don't install modules? |
| 19:52.26 | hno | Maqs, you should not need to patch that |
| 19:52.57 | hno | armhf gcc supports -msoft-float as well. |
| 19:53.38 | Maqs | it does, but uboot seems to need some other things |
| 19:53.40 | Turl | hno: I install them manually using 'adb push' |
| 19:53.46 | Maqs | or is partly compiled hf, partly sf |
| 19:54.08 | Turl | hno: and my mele doesn't use any modules |
| 19:54.22 | Turl | I =y all the stuff I need |
| 19:54.48 | libv | hno: i ran into the same issue today, it clashed with some libs at link time |
| 19:56.36 | cat1 | techn_: hmm.. have no idea where this symbol should come from.. symbol lookup error: /usr/lib/libEGL.so.1: undefined symbol: _mali_clz_lut, do you? :) |
| 19:57.03 | techn_ | cat1: which lib you are using? |
| 19:57.16 | hno | libv, -msoft-float? |
| 19:57.53 | cat1 | techn_: i guess one that comes with this dir mali_opengl_hf_lib sorry, but do not remember where i download it from ;) |
| 19:58.16 | techn_ | cat1: I'll update latest to linux-sunxi |
| 19:58.18 | cat1 | techn_: what is the latest-and-greatest recommendation for egl libs? |
| 19:58.22 | techn_ | one moment.. |
| 19:58.29 | cat1 | techn_: ah, cool, thanks! |
| 19:58.31 | libv | hno: yes, u-boot built fine against a hf gcc, but during linking it fell over due to sf vs hf |
| 19:59.00 | Maqs | for uboot, i just commented out the -msoft-float in arch/arm/cpu/armv7/config.mk |
| 19:59.20 | libv | Maqs: s/soft/hard/ would've also worked |
| 19:59.38 | libv | to the same result :) |
| 20:00.11 | hno | wonder why they hardcode soft-float, |
| 20:00.30 | libv | true |
| 20:00.44 | Turl | one uboot to rule them all in the future? |
| 20:00.59 | libv | seems like that would fix u-boot build then :) |
| 20:01.04 | libv | hno: make it so :p |
| 20:02.08 | hno | one u-boot for all would be something.. but at least there is much less code duplication than a year ago. |
| 20:03.30 | techn_ | cat1: I cant upload to wiki |
| 20:04.25 | cat1 | techn_: maybe we should create temporary repo on github for binaries exchange? |
| 20:04.44 | techn_ | I'll email to you and mnemoc |
| 20:05.09 | techn_ | check your priv |
| 20:09.14 | rz2k | I was wrong or that was a bug, but fbcon works in 1080p, but in wrong colors |
| 20:09.19 | rz2k | green is blue |
| 20:10.05 | techn_ | rz2k: what you are testing? |
| 20:10.20 | rz2k | my script.bin with vga 1080p |
| 20:10.30 | techn_ | ah |
| 20:10.50 | techn_ | Test wip/disp :) |
| 20:11.26 | techn_ | It may even have fix for that problem :p |
| 20:11.52 | mnemoc | techn_: give me your ssh key to give you access to upload to dl.linux-sunxi.org |
| 20:14.55 | mnemoc | http://www.youtube.com/watch?v=fTbkNld0sHE <--- e-ink phone! |
| 20:16.21 | rz2k | lol, wanted to paste same link :p |
| 20:16.39 | rz2k | will it go 1 week on battery? |
| 20:17.06 | mnemoc | i'm faster ;-) |
| 20:18.31 | hno | rz2k, if you shut down the radio and no apps running then probably. |
| 20:24.09 | hno | 1 month they say in the video. But I beleive that when I se it. |
| 20:24.38 | mnemoc | 1 month powered off :p |
| 20:25.22 | rz2k | wants this right now http://www.hiapad.com/?p=1939 |
| 20:25.46 | mnemoc | http://armdevices.net/members-store/ .... charbax opened a shop... |
| 20:27.59 | mnemoc | kind of willing to donate those $20 just to support him.... |
| 20:31.50 | rz2k | you can buy it directly from hiapad http://www.hiapad.com/?page_id=1600 |
| 20:32.23 | mnemoc | nah. i want an imx6q laptop, not hdmi dongle :p |
| 20:39.01 | Turl | mnemoc: kindles can last 1 month |
| 20:39.18 | Turl | the gsm radio will kill it on a week though, unless they put an uber battery in there :P |
| 20:39.40 | Turl | also, the eink refresh is not that good for a device you'll use that much |
| 20:45.07 | techn_ | rz2k: I don't have fps problems anymore.. + I managed to get rid of LD_PRELOAD |
| 20:45.30 | techn_ | to ump's Makefile: |
| 20:45.53 | techn_ | LDFLAGS += -Wl,--no-as-needed -ldri2 -ldrm -lXfixes |
| 20:45.53 | techn_ | .. |
| 20:45.57 | techn_ | libUMP.so: $(UMP_OBJS) |
| 20:45.57 | techn_ | <PROTECTED> |
| 20:46.58 | rz2k | hmm |
| 20:47.03 | mnemoc | techn_: key please. then you can public those libs and patches to link from elsewhere |
| 20:47.04 | rz2k | and fps problem? |
| 20:47.21 | mnemoc | s/public/publish/ |
| 20:47.38 | rz2k | I mean I have same 30-40 fps and X11 eating all CPU |
| 20:47.56 | rz2k | when glmark/es2gears themselves eat 3%-5% |
| 20:48.05 | techn_ | rz2k: I had that yesterday.. today I havent seen it somehow |
| 20:50.47 | techn_ | constant 125fps on gears.. 50% for x11 and other half for es2gears |
| 20:51.44 | techn_ | mnemoc: hmm.. I'll send some key |
| 20:57.42 | *** join/#arm-netbook newbie1 (~kvirc@118-168-195-38.dynamic.hinet.net) |
| 21:02.36 | cat1 | techn_: with r3p1 i get: (EE) MALI(0): [maliSetupExa:582] failed to open UMP subsystem |
| 21:02.58 | techn_ | cat1: great.. now chmod /dev/ump |
| 21:03.04 | rz2k | chmod ump |
| 21:03.32 | rz2k | or use https://github.com/rzk/Mali-400-r3p0-04rel0-X11-drivers/blob/master/10-mali400.rules |
| 21:03.36 | rz2k | for udev |
| 21:04.37 | cat1 | techn_: ah, stupid me.. |
| 21:06.20 | cat1 | techn_: do you also see this |
| 21:06.20 | cat1 | [ 438.660000] UMP<1>: No handler for IOCTL. cmd: 0x40209007, arg: 0xbecf9930 |
| 21:06.27 | cat1 | and it continues.. |
| 21:07.00 | techn_ | cat1: you have old version of mali kernel drivers? |
| 21:08.49 | cat1 | techn_: riiiight.. i must have eaten some wrong mushrooms.. |
| 21:09.06 | *** join/#arm-netbook lerc_ (~quassel@121-74-231-26.telstraclear.net) |
| 21:10.21 | cat1 | techn_: i have whatever is in sunxi-3.4.. |
| 21:10.47 | techn_ | rebase next-mali? default is r2p4 |
| 21:12.38 | mnemoc | techn_: mali/ in your home goes to http://dl.linux-sunxi.org/mali/, all yours |
| 21:12.54 | techn_ | mnemoc: thanks |
| 21:13.15 | mnemoc | techn_: :) |
| 21:13.41 | cat1 | mnemoc: can we now have something really up-to-date in sunxi-3.4? |
| 21:14.52 | mnemoc | cat1: once next-mali is approved i'll merge it on both... |
| 21:15.07 | cat1 | let's vote now? :P |
| 21:16.15 | mnemoc | it's not about votes, it's an agreement |
| 21:17.32 | cat1 | if next-mali is not broken why not let it go? |
| 21:17.43 | hno | Maqs & libv: u-boot soft-float issue is really an gcc packaging issue. To link with -msoft-float you need the soft-fload libs installed (gcc-multilib package on Ubuntu) |
| 21:18.10 | hno | but probably works just fine to build u-boot armhf. |
| 21:18.24 | mnemoc | cat1: not my call, i don't use mali at all |
| 21:18.26 | libv | cat1: define "not-broken" with respect to graphics drivers |
| 21:18.42 | Maqs | hno: well, it works with hard-float |
| 21:18.47 | Maqs | (now) ;) |
| 21:18.58 | libv | cat1: what utopic world have you been living in so far? |
| 21:19.09 | cat1 | libv: definition: it does not behave worse than in master sunxi-3.4 |
| 21:19.10 | *** join/#arm-netbook simosx (~simosx@188.4.119.224.dsl.dyn.forthnet.gr) |
| 21:19.11 | *** join/#arm-netbook simosx (~simosx@ubuntu/member/simosx) |
| 21:19.35 | mnemoc | cat1: but cuts off people using cedarx |
| 21:20.01 | cat1 | mnemoc: and in which branch it is working? ;) |
| 21:20.32 | mnemoc | afaik is kind of works on sunxi-3.0 with armel userspace |
| 21:20.55 | cat1 | mnemoc: ok, but i am asking for 3.4 |
| 21:21.13 | libv | hno: removing -msoft-float from the config.mk, should solve the issue i guess, if a hf gcc defaults to hf for linking as well |
| 21:21.24 | mnemoc | cat1: i suppose it works in the same degree there too ;-) |
| 21:21.35 | hno | hf gcc defaults to hf linking yes. |
| 21:21.45 | libv | cat1: what stops you from merging locally yourself? |
| 21:22.11 | cat1 | libv: i am loosing baseline constantly :) |
| 21:22.22 | cat1 | libv: but otherwise nothing, sure i can do whatever |
| 21:22.27 | hno | Can't we throw in both mali versions? |
| 21:22.39 | mnemoc | hno: i think we will end up doing that |
| 21:23.00 | libv | heh, external mali.ko anyone? |
| 21:23.13 | hno | have been saying that all along.. |
| 21:23.18 | mnemoc | i suppose we can do it with one bool CONFIG_ |
| 21:23.52 | libv | http://www.phoronix.com/scan.php?page=article&item=fosdem_2010_unification&num=1 |
| 21:23.57 | hno | mnemoc, if this continues I think we will end up with 4 mali versions. So a dropdown. |
| 21:23.57 | mnemoc | problem with external mali is that we can't do the integration with disp/drm... |
| 21:24.17 | rz2k | 3 versions, r2p4, r3p0 and r3p1 :) |
| 21:24.17 | libv | mnemoc: what integration? |
| 21:24.49 | libv | mnemoc: maybe drm/kms is simply a broken model |
| 21:24.52 | hno | rz2k, right now yes. |
| 21:25.24 | libv | said the guy who came up with quite a few of the core ideas that eventually filtered into randr1.2 and kms |
| 21:25.46 | mnemoc | libv: the driver expects pre-cutted off memory chunk, and some special ioctrl()s |
| 21:25.57 | rz2k | lol. lets not go into linux graphics stack discussion, this will end in great holywar. |
| 21:26.05 | hno | and a little further down the line 4 versions to match the different distribution types. 1 armel, 1 android el, 1 armhf, 1 android hf. |
| 21:26.23 | mnemoc | cries |
| 21:26.57 | libv | mnemoc: surely the reserved memory can be reserved regardless of when the module is built? |
| 21:27.07 | libv | mnemoc: what ioctls would that be? |
| 21:27.36 | mnemoc | libv: it's a VERY large % of the total ram... not something to do when mali won't be used |
| 21:27.54 | hno | mnemoc, welcome to the land of binary blobs. Embrace one and they soon eat you full. |
| 21:28.00 | mnemoc | libv: ump related, to deal with some buffers |
| 21:28.25 | cat1 | tends to agree with mnemoc: we'd rather keep mali within. |
| 21:28.43 | hno | mnemoc, the ump fb ioctl is decoupled already, remember? |
| 21:28.44 | mnemoc | libv: 64MB+32M+16MB |
| 21:28.45 | libv | but ump and mali should be built externally, and mali depends on ump, and ump depends on memory being reserved for mali |
| 21:29.20 | libv | this at least is my simplified view of the world, never actually having touched the mali kernel driver |
| 21:29.59 | mnemoc | if we manage to fix mali's memory reserving to be done by the driver instead of pre-mmu... |
| 21:30.09 | libv | it could be pre-mmu |
| 21:30.30 | Turl | hno: there's no such thing as android hf as far as I'm aware |
| 21:30.44 | libv | the memory could still be reserved from config |
| 21:30.46 | mnemoc | Turl: android 5.0 is comming |
| 21:31.11 | Turl | android 5 is unlikely to hit anytime this year |
| 21:31.26 | Turl | and I haven't heard anything about it being hf either |
| 21:31.31 | Turl | it's gonna be a pain if that's true :P |
| 21:31.32 | hno | should work fine to reserve mali memory using mem= boot parameter. |
| 21:31.33 | libv | either the memory is reserved and ump is happy when loading, or ump refuses to load |
| 21:32.21 | hno | ump is not cause to memory reservation issues, that one plays friendly. mali.ko is.the bad boy. |
| 21:32.39 | mnemoc | and the drm driver? |
| 21:32.45 | mnemoc | kicked out too? |
| 21:33.06 | libv | mnemoc: seems that they all belong to the same graphics stack |
| 21:33.10 | hno | do that actually do anything at allö? |
| 21:33.28 | Turl | wasn't the drm thing a dummy interface? |
| 21:33.45 | libv | mnemoc: again, because intel and redhat cannot see things differently, doesn't mean that we have to give ourselves more pain than necessary dealing with the binary blobs |
| 21:34.51 | libv | we can only be flexible at the kernel side, so this is where we need to make sure that we are flexible, despite shortsightedness upstream |
| 21:35.36 | libv | when i finally do get a mesa/gallium based lima driver out, it will build externally |
| 21:35.37 | mnemoc | seriously pissed off by hipboi disappearance. we only need a r3p0 armel driver to not need this discussion.... and he is supposed to be the most interested one on have proper open source support for sunxi |
| 21:36.14 | libv | which will piss off quite a lot of people, and i have had BS thrown at me for my plans already, even though i only briefly mentioned this at fosdem |
| 21:36.28 | mnemoc | :) |
| 21:36.51 | libv | but in the latter case, the person doing so had to give in that his reasons for giving me crap was his own view of the world being wrong |
| 21:37.44 | cat1 | libv: are you working on lima? |
| 21:38.06 | mnemoc | cat1: he is lima |
| 21:38.08 | Turl | mnemoc: wasn't he moving or something? |
| 21:38.35 | mnemoc | Turl: he ended up staying in zuhai |
| 21:39.09 | libv | mnemoc: :) |
| 21:39.15 | libv | cat1: not often enough :p |
| 21:39.56 | cat1 | libv: i did not even get how to compile is from the sources :D |
| 21:40.04 | libv | but that's sadly more about company politics than anything else |
| 21:40.30 | libv | cat1: yes, the android ndk is not really made for this sort of thing |
| 21:40.43 | hno | Maybe he did return to Allwinner as well? |
| 21:40.58 | libv | cat1: also, lima is still fully about finding out how everything fits together |
| 21:41.13 | libv | there is no working driver there, there is some code to test driver like functionality |
| 21:41.21 | cat1 | libv: ah, kinda playground. |
| 21:41.50 | libv | cat1: at this stage, nothing else is possible yet |
| 21:42.09 | mnemoc | Turl: would it be possible to build both .ko? mali_r2p4.ko, mali_r3p1.ko without much change? |
| 21:42.47 | hno | mnemoc, yes. |
| 21:43.19 | cat1 | libv: yeah, i understand. |
| 21:43.21 | Turl | mnemoc: you'd need new kconfig variables |
| 21:43.32 | Turl | and make some makefile guards so they don't clash or something |
| 21:44.15 | mnemoc | Turl: would you take the challenge? ;-) |
| 21:44.39 | libv | what versions has allwinner seen already? |
| 21:44.46 | Turl | mnemoc: why do you need r2p4 still? |
| 21:45.05 | mnemoc | for people using cedarx on linux :< |
| 21:45.25 | mnemoc | or trying to... |
| 21:45.41 | cat1 | mnemoc: so the plan would be to keep separate github repo with all mali parts in there? this actually might work.. |
| 21:45.42 | rellla1 | trying to ;-) |
| 21:45.44 | mnemoc | cries |
| 21:45.48 | Turl | 'git revert' works wonders :) |
| 21:46.00 | cat1 | mnemoc: not that loud :) |
| 21:46.07 | mnemoc | cat1: no no... that's what I want to avoid at all cost |
| 21:46.22 | Turl | mnemoc: we should try to ask tom for softfp libs |
| 21:46.26 | Turl | problem solved :) |
| 21:46.38 | cat1 | mnemoc: ok, checking this possiblity out then ;) |
| 21:46.39 | mnemoc | cat1: I was thinking more of a CONFIG_MALI + bool CONFIG_MALI_LEGACY |
| 21:46.51 | Turl | mnemoc: in reality r3p0 is old already :< we need new android, softfp, hardfp r3p1 libs |
| 21:47.16 | mnemoc | hipboi!! |
| 21:47.20 | mnemoc | :< |
| 21:48.12 | libv | what libs exist, and can they be gathered at http://dl.linux-sunxi.org/mali/ please |
| 21:48.26 | Turl | libv: there's a wiki page with it |
| 21:48.44 | Turl | libv: http://linux-sunxi.org/Mali400#Binary_libraries_download_links |
| 21:48.50 | mnemoc | techn will hopefully gather them there soon-ish |
| 21:49.00 | libv | but there are only hf binaries apparently |
| 21:49.23 | mnemoc | libv: we have r2p4 for android and armel, r3p0 for android and armhf, and r3p1 for armhf |
| 21:49.44 | Turl | no idea where's the r2p4 armel release |
| 21:49.45 | mnemoc | and cedarx for android and armel |
| 21:49.48 | Turl | wiki lists an hf one |
| 21:50.33 | mnemoc | uhm |
| 21:50.49 | techn_ | I asked armel Mali libs.. Also gave a tip to get armhf cedarx lib.. gotta sleep.. cu |
| 21:51.01 | libv | the thing is... |
| 21:51.21 | libv | the mali ioctls in themselves have a version handshake at the start |
| 21:51.25 | mnemoc | armhf cedarx would be ideal |
| 21:51.39 | libv | at least for the r2 ones i have been doing lima against |
| 21:52.03 | techn_ | libv: also newer ones have it |
| 21:52.48 | libv | so theoretically it should be possible to have runtime compatibility in the kernel |
| 21:53.11 | libv | but that requires unifying the relevant versions in the same tree first |
| 21:53.28 | libv | and then separating out the differences to make them dynamic |
| 21:53.57 | libv | any volunteers? |
| 21:54.05 | cat1 | libv: i was thinking of the same |
| 21:56.45 | libv | ah... heh. |
| 21:57.01 | libv | cat1: i was in meego graphics adaptation btw. |
| 21:58.13 | cat1 | libv: hmm, can't recall you from nick ;) but i was doing battery management in harmattan |
| 21:58.14 | Turl | libv: the version checks are there because the lib-kernel interfaces change |
| 21:59.00 | libv | Turl: lima is happy from r2p2 to r2p4 |
| 21:59.14 | libv | even though job handling has changed |
| 21:59.45 | Turl | r2 -> r3 probably breaks stuff |
| 22:00.09 | libv | yeah, but you can detect this during the handshake |
| 22:00.15 | rz2k | now thats interesting |
| 22:00.15 | rz2k | http://pastebin.com/N4LrtkiL |
| 22:00.23 | rz2k | mali crashed running glmark2 |
| 22:00.36 | Turl | cubieboard website got a redesign? |
| 22:02.25 | rellla1 | Turl: added links to r2p4 armel libs in the wiki. afaik this one is used in most of the xbmc/cedarx "tries" |
| 22:07.19 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 22:12.56 | libv | in any case, shoring up mali enough to make it multi-version compatible, is possible but not very feasible in the current constellation, especially not going forward with arm throwing new kernel space drivers over the hedge |
| 22:16.35 | libv | it's going to be much easier with ump, mali, and mali_drm modular, with a limited changeset needed for initialization that is compatible with the linux-sunxi kernel, so that these changes can be thrown into new arm "heaps" |
| 22:17.03 | libv | also, without a decent open userspace driver, there is no upstreaming for these bits anyway |
| 22:18.16 | *** join/#arm-netbook tuliom (~tuliom@177.99.129.25) |
| 22:23.32 | hno | Turl, seems so. Looks shiny. Sadly the shop is still closed. |
| 22:24.13 | mnemoc | the second batch should be arriving this week iirc.... but i fear it's already sold |
| 22:24.40 | mnemoc | those days he decided to silently open aliexpress' sho[ |
| 22:27.14 | hno | hope he has been busy this week testing and shipping the first batch. |
| 22:35.11 | mnemoc | :) |
| 22:37.17 | libv | hrm... according to the mmu init of 3.0. mali uses 64mb, g2d uses 16 and lcd uses 32 (i am sure that this must be display instead though) |
| 22:37.43 | mnemoc | yes, lcd means fb |
| 22:37.50 | libv | mnemoc: so your 64 + 32 + 16 of earlier, of that, only the 64 is handed to ump, right? |
| 22:38.26 | mnemoc | don't know how ump gets them |
| 22:38.48 | mnemoc | the chunk in removed (not reserved) from meminfo, the kernel never see it |
| 22:39.02 | libv | sure |
| 22:39.21 | mnemoc | and the references to that address/size are hardcoded mali's config.h |
| 22:41.07 | mnemoc | libv: so this style is.... normal? |
| 22:41.15 | libv | on via unichrome, on amd hammer/k8 chipsets, asked the k8 how much memory we really had, the unichrome how much was reserved for it, and then mapped that last bit, and got mad cpu<->igp bandwidth :) |
| 22:41.35 | mnemoc | doh |
| 22:42.18 | libv | (the openchrome guys still haven't caught on to that one ;p) |
| 22:42.46 | mnemoc | :o |
| 22:45.26 | libv | so yes, very very common |
| 22:45.37 | libv | on x86 the bios lies to the kernel |
| 22:53.02 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 23:04.19 | *** join/#arm-netbook specing (~specing@unaffiliated/specing) |
| 23:29.06 | rz2k | xbmc running on r3p1 in fullhd http://i.imgur.com/rzsbO.jpg |
| 23:54.00 | alcides | 13fps? |
| 23:54.02 | alcides | hmmm |
