| 00:03.40 | *** join/#arm-netbook stefanro1 (~stefan@p57B94A95.dip.t-dialin.net) |
| 00:04.49 | lundman | i was thinking more, you do all the work, and i get a binary. but I see we are on different pages :) |
| 00:16.34 | Turl | lundman: you have push permissions for that repo. I hope you use them wisely :) |
| 00:19.30 | lundman | damnit ;:) |
| 00:19.53 | Turl | damn slow interpipes :( uploading this repo is taking ages :P |
| 00:20.22 | lundman | it looks quite empty |
| 00:20.35 | lundman | but dont worry, I compile on arm, so it takes forever :) |
| 00:20.53 | Turl | you should push that one :P copy the zatab one and push it there with s/zatab/mele/ :P |
| 00:21.01 | Turl | lundman: you cannot build android on ARM |
| 00:25.05 | lundman | what, really? |
| 00:25.35 | lundman | I did just setup a linux for my zfs work, so I'll just get the cross |
| 00:25.50 | lundman | there is nothing to clone from https://github.com/allwinner-dev-team/android_device_allwinner_mele yet |
| 00:58.51 | Turl | lundman: >(21:20:53) Turl: you should push that one :P copy the zatab one and push it there with s/zatab/mele/ :P |
| 00:59.38 | lundman | none of those make any sense :) |
| 01:00.07 | Turl | 1) clone _zatab 2) commit s/zatab/mele/ 3) push to _mele 4) ... 5) basic profit! |
| 01:00.08 | Turl | :P |
| 01:00.25 | lundman | whats zatab? |
| 01:00.50 | Turl | lundman: https://github.com/allwinner-dev-team/android_device_allwinner_zatab |
| 01:01.23 | *** join/#arm-netbook slash_random (~david@host197.201-252-139.telecom.net.ar) |
| 01:02.20 | lundman | aha |
| 01:04.00 | lundman | heh apt-get git first i should think |
| 01:13.13 | *** join/#arm-netbook Holo_ (u6962@gateway/web/irccloud.com/x-magykgevhapjdjox) |
| 01:26.01 | lundman | how do I build zatab? |
| 01:27.03 | *** join/#arm-netbook libv_ (~libv@ppp-93-104-137-80.dynamic.mnet-online.de) |
| 01:55.25 | bsdfox | why was the raspi stuff able to release open source today? |
| 01:55.38 | bsdfox | isn;t their GPU IP of ARM too? |
| 01:56.05 | lundman | not sure I would agree that its open source |
| 01:56.13 | lundman | they opened the code that calls the binary microcode |
| 01:56.22 | lundman | which we already had |
| 01:56.28 | lundman | for mali |
| 01:57.07 | *** join/#arm-netbook avernos (~avernos@111.194.214.252) |
| 01:57.08 | *** join/#arm-netbook avernos (~avernos@unaffiliated/avernos) |
| 02:06.13 | ZaEarl_ | lundman, http://linux-sunxi.org/Building_CyanogenMod_for_ZaTab |
| 02:14.24 | libv | bsdfox, lundman: broadcom videocore has nothing to do with mali |
| 02:14.42 | lundman | hello captain obvious! |
| 02:14.47 | lundman | :) |
| 02:16.23 | lundman | guess i wasnt clear. They claim to be first to be open-source, and yet, it seems broadcom only released exactly the same amount that we have for mali |
| 02:16.39 | lundman | so, to me, it doesnt feel like they were they first, but rather, the last to join all the others |
| 02:16.41 | libv | bsdfox: bcm released code which just send opengles calls to the videocore dsp/gpu |
| 02:17.04 | libv | bsdfox: package it up, pipe it through the kernel, out to the rtos running on the videocore |
| 02:17.36 | libv | bsdfox: some people have rightfully stated "why didn't broadcom release this together with the kernel code and other rpi bits" |
| 02:39.58 | *** join/#arm-netbook steev (u1383@gentoo/developer/steev) |
| 02:44.52 | *** join/#arm-netbook Txl0591 (~tangxl059@202.101.116.160) |
| 02:48.38 | *** part/#arm-netbook Txl0591 (~tangxl059@202.101.116.160) |
| 02:50.06 | *** join/#arm-netbook gsilvis (~almostsix@50.12.163.241) |
| 03:17.05 | *** join/#arm-netbook tekzilla (~jon@hmbg-5f77319b.pool.mediaWays.net) |
| 03:20.26 | *** join/#arm-netbook carbont (7bf34f0e@gateway/web/freenode/ip.123.243.79.14) |
| 03:48.23 | *** join/#arm-netbook ZaEarl (~malmrose@17.host-182-48-148.compassnet.co.nz) |
| 04:09.07 | *** join/#arm-netbook cheng (~cheng@175.143.110.184) |
| 05:11.20 | libv | ooh! |
| 05:11.31 | libv | sunxi has big litter byte ordering! |
| 05:24.57 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@bzq-218-155-170.cablep.bezeqint.net) |
| 05:25.18 | *** join/#arm-netbook mSquare (~selvan@122.167.68.58) |
| 05:36.32 | *** join/#arm-netbook rellla (~Thunderbi@p5B078146.dip0.t-ipconnect.de) |
| 05:47.26 | libv | yeggid |
| 05:47.43 | libv | #define __bool signed char |
| 05:48.04 | libv | massive abi break if i fix that :( |
| 05:49.09 | lundman | ugh |
| 05:50.30 | libv | is there anything that we know of that is using the disp ioctls? |
| 05:54.53 | lundman | android seems to after it boots |
| 05:56.06 | libv | ah, yes, crap. |
| 05:57.12 | libv | well, that depends... do you have gralloc or hwc modules for allwinner lying about? |
| 05:57.55 | libv | strings on them should give you /dev/disp if it is trying to do funky stuff |
| 06:01.01 | lundman | i dont at the moment |
| 06:01.14 | libv | ah, i found code |
| 06:01.20 | rellla | morning |
| 06:02.59 | libv | crap.crap.crap. |
| 06:07.19 | libv | on the other hand, hwc will use only a minimal subset |
| 06:08.01 | rellla | does anybody know, if r2p4-armhf libs are broken? |
| 06:08.01 | rellla | i get a: libEGL.so: undefined reference to `_mali_clz_lut' |
| 06:08.01 | rellla | can remember, somebody spoke about it already in irc |
| 06:14.22 | rellla | mnemoc: what kernel-branch is recommended for r3p0/r3p1-libs? stage/sunxi-3.0? what's 'mali'-difference to next_mali? |
| 06:15.17 | *** join/#arm-netbook Quarx (~Quarx@46.233.246.161) |
| 06:21.34 | *** join/#arm-netbook pwhalen (~paul@CPE001310360dac-CM78cd8ec9e405.cpe.net.cable.rogers.com) |
| 06:24.39 | Gumboot | Winmodems. |
| 06:25.38 | Gumboot | The opposite extreme; zero CPU offload, and widely hated for being cheap and crappy as well as for not providing drivers for anything but Windows. |
| 06:26.39 | Gumboot | I don't remember people slagging off the RS232 ones that came before. |
| 06:27.54 | Gumboot | And yes, they did have that problem of becoming obsolete stupidly quickly. I remember there were an awful lot of cheap project boxes which were simply recycled 9600 bps modems which had become obsolete before they cleared the shelves. |
| 06:28.34 | Gumboot | goes to bed because it's 7:30am and that's where he should be. |
| 06:31.11 | libv | hrm... 46 |
| 06:31.34 | libv | 46 ioctls used by the aurora hw code |
| 06:33.06 | libv | abi for them should not change, better write some test code for that :( |
| 06:35.45 | hno | libv, you are trying to clean up disp ioctl structs/types? |
| 06:36.04 | libv | well, intending to |
| 06:36.39 | libv | without changing those there will be little real rewriting in the background |
| 06:37.01 | libv | so the users of disp need to be mapped out |
| 06:38.59 | andoma | mornin |
| 07:12.13 | oliv3r | lo |
| 07:13.10 | mnemoc | rellla: stage/sunxi-3.0 includes next_mali, but also other patches that need testing |
| 07:14.31 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 07:18.57 | rellla | mnemoc: then i'll give it a try - what's the recommended matching binary-libs for using fb? first i'd try those from github/linux-sunxi. i'm testing xbmc with armhf-cedars but i failed with the armhf-r2p4s with the mentioned error above. |
| 07:20.03 | mnemoc | rellla: fb doesn't need any lib. if using next_mali or the stage branches want r3p0 mali libs |
| 07:21.10 | mnemoc | iirc armhf r3p0 fb libs are untested, but the x11 ones are |
| 07:24.52 | rellla | surely, i meant s/fb-libs/mali-libs/. so its time to test the untested. |
| 07:24.55 | vanner | which mali version tested with sunxi-3.0 branch for X11? i'm going to build one today |
| 07:27.11 | vanner | or which kernel branch and mali driver is simple to use for linux with x11? |
| 07:29.18 | *** join/#arm-netbook pawel5870 (~pkarpins@pc.193147149.ip.amg.net.pl) |
| 07:29.26 | mnemoc | try the stage/sunxi-3.0 branch + r3p0 libs |
| 07:30.16 | vanner | thanks, i'll try it |
| 07:30.58 | mnemoc | rzk has some repos to compile the open source user space libs |
| 07:32.51 | *** join/#arm-netbook DEAT (~heh@14-201-99-152.tpgi.com.au) |
| 07:33.13 | vanner | ok, thanks |
| 07:38.23 | *** join/#arm-netbook DEAT (~heh@14-201-99-152.tpgi.com.au) |
| 07:47.02 | *** join/#arm-netbook AndChat138129 (~AndChat13@31.120.33.198) |
| 07:48.08 | mnemoc | http://www.aliexpress.com/store/product/TTF-to-USB-Serial-line/511685_665833183.html <---- the uSD breakout card is back on tom's shop |
| 07:48.57 | *** join/#arm-netbook AndChat138129 (~AndChat13@31.120.33.198) |
| 07:49.16 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 07:54.53 | *** join/#arm-netbook AndChat138129 (~AndChat13@31.120.33.198) |
| 08:04.40 | *** join/#arm-netbook gzamboni (~gzamboni@187.121.29.107) |
| 08:05.58 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 08:33.47 | popolon | http://www.raspberrypi.org/archives/2221 |
| 08:33.58 | popolon | looks like braodcomm changed a little :) |
| 08:34.20 | RaYmAn | only a day behind ;) |
| 08:34.24 | popolon | they have now the most opened ARM SoC |
| 08:34.36 | RaYmAn | it's arguable |
| 08:34.54 | popolon | why for ? |
| 08:34.59 | mnemoc | popolon: nope, the moved the private part within the "firmware" and open source an RPC client |
| 08:35.12 | mnemoc | not a driver |
| 08:35.15 | popolon | ah ok |
| 08:35.21 | RaYmAn | mnemoc: tbh, that's saying it wrong. They didn't move it into the firmware. It was always there |
| 08:35.59 | mnemoc | ah, ok |
| 08:36.24 | RaYmAn | As far as I can tell, it's not a malicious move that has been done now to avoid releasing source |
| 08:36.35 | RaYmAn | it was a technical design decision done early on |
| 08:36.40 | mnemoc | it's malicious to claim the SoC is open |
| 08:36.50 | RaYmAn | they claim the userspace is open |
| 08:36.50 | RaYmAn | :P |
| 08:36.55 | mnemoc | :) |
| 08:36.58 | RaYmAn | which is technically true |
| 08:41.29 | mnemoc | so they basically "fixed" the closed libs in userspace nightmare without having to disclose anything about the GPU beside that is has a gl interface |
| 08:42.32 | *** join/#arm-netbook cat_x301 (~cat_x301@gprs-internet-ff85ee00-146.dhcp.inet.fi) |
| 08:43.15 | mnemoc | but still pissed by the deceiving way it was announced |
| 08:43.15 | RaYmAn | pretty much |
| 08:50.35 | RaYmAn | Gumboot: if you are in any way related to tegra then, Please, for the love of god, fix the reboot to recovery issue (Bootloader doesn't clean boot-to-recovery misc flag => brick if recovery is broken. Impossible to enter fastboot because flag takes priority and it's never cleared. |
| 09:04.53 | *** join/#arm-netbook AndChat138129 (~AndChat13@31.120.33.198) |
| 09:05.29 | oliv3r | full brick? or does FEL mode still work? |
| 09:05.58 | RaYmAn | (not a10 - nvidia tegra.) |
| 09:12.09 | cat_x301 | is going to give a try for stage/sunxi-3.0 |
| 09:17.53 | oliv3r | stupid question, DirectFB, isn't that simply some 'form' of an 'Xserver'? to put it very very bluntly? I never quite understood what DirectFB waas, i thought at first it was a FB replacement or they where banging stuff directly onto the graphics card |
| 09:19.47 | mnemoc | it's an abstraction to use fb with hardware acceleration |
| 09:20.53 | oliv3r | but where does this hardware acceleration come from? I don't belive they write 'drivers' for all graphic chips? |
| 09:21.10 | mnemoc | they do :) |
| 09:21.27 | oliv3r | oh god, poor bastards :p |
| 09:21.42 | mnemoc | the a10's driver is hacked on top of vmware's |
| 09:21.49 | oliv3r | so to build, for example a htpc, you either use X or use directFB |
| 09:22.00 | mnemoc | using g2d/mp for hw acceleration |
| 09:22.20 | mnemoc | you can also use mali/fb libs |
| 09:22.37 | mnemoc | that is gl without x |
| 09:23.25 | oliv3r | so that's not-directFB |
| 09:23.28 | oliv3r | :p |
| 09:23.39 | oliv3r | or rather OpenGL -> Framebuffer |
| 09:24.01 | oliv3r | so what purpouse has directFB (on the graphics front) when you can do OpenGL -> Framebuffer |
| 09:24.51 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 09:25.59 | mnemoc | oliv3r: there are things that can be accelerated better in 2d than in 3d |
| 09:27.07 | oliv3r | for now, 2D 'hardware' is slowly dissapearing isn't it? |
| 09:27.32 | oliv3r | radeon's don't even have a 2D core anymore? I think the 3D engine handles it (though it may expose some 2D stuff still) |
| 09:28.28 | oliv3r | also with a lot of frontends (gnome, android?, xbmc etc) moving to 3D composed desktops, 2D will die at somepoint :) |
| 09:29.06 | mnemoc | the a13 doesn't have a 2d core. no idea about a10s or sun6i |
| 09:29.36 | oliv3r | a13 does have the mali core though, right? |
| 09:29.51 | oliv3r | it's probably inherit of the mali core |
| 09:29.53 | mnemoc | yes, same mali |
| 09:30.50 | *** join/#arm-netbook Hexxeh (u1532@gateway/web/irccloud.com/x-eroaqecbytirasew) |
| 09:36.35 | hno | rellla, you got armhf cedarx libs? |
| 09:37.01 | mnemoc | hno: https://github.com/linux-sunxi/cedarx-libs/tree/master/libcedarv/linux-armhf |
| 09:37.12 | hno | oh! |
| 09:37.37 | mnemoc | :) |
| 09:38.02 | mnemoc | you missed lot of action yesterday :) |
| 09:39.01 | hno | I'll catch up. |
| 09:39.20 | hno | Anything other I need to know? |
| 09:40.46 | mnemoc | as a summary only that, http://www.indiegogo.com/cubieboard?a=1658415, and that tom's paypal got blocked so contributions are currently CC-only |
| 09:41.05 | mnemoc | and that my chromebook got shipped :p |
| 09:42.17 | mnemoc | there is also a weird discussion about the specs of a eoma-server stabdard on the ML |
| 09:42.51 | hno | I noticed the blocked paypal account disucssion. |
| 09:43.09 | hno | and that there was a server discussion. |
| 09:43.43 | hno | so up to speed apart from the cedarx hf libs. |
| 09:43.44 | oliv3r | indiegogo = kickstarter? |
| 09:44.06 | hno | alternative kickstarter |
| 09:44.21 | mnemoc | oliv3r: almost. uses paypal and isn't limited to US projects |
| 09:44.54 | oliv3r | ah, didn't even know kickstarter was limited to US projects or paypal |
| 09:45.06 | mnemoc | oliv3r: they do wire transfers world wide for $25 |
| 09:45.20 | RaYmAn | kickstarter uses amazon payments generally |
| 09:45.44 | oliv3r | not doing too well yet |
| 09:45.54 | oliv3r | only 7k/50k |
| 09:46.00 | mnemoc | oliv3r: the campaign owners there needs to be US resident |
| 09:46.18 | mnemoc | oliv3r: in 1 day, and without notifying the 4k+ people in the notify me list |
| 09:46.33 | oliv3r | oh, it just started; then I take that back :) |
| 09:46.37 | oliv3r | very interesting indeed |
| 09:46.40 | oliv3r | pricey though :p |
| 09:46.52 | mnemoc | come on |
| 09:47.12 | oliv3r | i may order one using that instead of his ali-express shop |
| 09:47.18 | oliv3r | _may_ :p |
| 09:47.30 | oliv3r | i'm kinda debating whether I want to wait for an A40 cubieboard! |
| 09:47.53 | mnemoc | $49 (+10 of shipping) for a A10 dev board with sata, ethernet and 96 expansion pins, come on |
| 09:48.11 | RaYmAn | it's pretty unlikely a cubieboard 2 will come if this campaign fails :P |
| 09:48.16 | oliv3r | i think the $49 is with 'free' shoppppppping |
| 09:48.20 | mnemoc | oliv3r: they don't even have an official devkit yet. (tried to buy one) |
| 09:48.21 | oliv3r | shipping* |
| 09:48.44 | mnemoc | oliv3r: yes, that's promotional. only 32 pieces left |
| 09:48.58 | oliv3r | fine, i'll get one of those |
| 09:49.00 | oliv3r | you convinced me :p |
| 09:49.05 | mnemoc | :) |
| 09:49.29 | oliv3r | it probably won't be used for months! I need to bug hipboi for a uSD adapter though! |
| 09:49.39 | hno | mnemoc, I assume the cedar libs is from cubie? |
| 09:49.46 | mnemoc | oliv3r: it's available on his aliexpress shop |
| 09:49.48 | mnemoc | hno: yes |
| 09:49.49 | *** join/#arm-netbook akaizen (~akaizen@c-67-180-86-61.hsd1.ca.comcast.net) |
| 09:50.34 | mnemoc | oliv3r: http://www.aliexpress.com/store/product/TTF-to-USB-Serial-line/511685_665833183.html |
| 09:50.39 | mnemoc | TTF :p |
| 09:50.52 | oliv3r | no, i ment the uSD -> Jtag one (which is now also available) |
| 09:51.01 | mnemoc | oliv3r: it's that one |
| 09:51.06 | mnemoc | oliv3r: does both, uart and jtag |
| 09:51.06 | oliv3r | i'll pay 5USD extra on the indiegogo order and mail him |
| 09:51.24 | mnemoc | oliv3r: do it the other way around |
| 09:51.43 | oliv3r | but if i order from the cubie-shop, it won't help to reach the goal of 50k? |
| 09:51.44 | mnemoc | oliv3r: first ask |
| 09:51.59 | oliv3r | his gmail address? |
| 09:52.05 | oliv3r | also, only 32 left! |
| 09:52.09 | mnemoc | mr.hipboi |
| 09:52.29 | mnemoc | oliv3r: get the board, then you can do a "perk-less" donation |
| 09:53.51 | oliv3r | e-mailed him |
| 09:53.55 | oliv3r | lets see what he says |
| 09:54.34 | oliv3r | only CC :S need to use paypal for now |
| 09:54.47 | mnemoc | secure your freeshipping board first |
| 09:55.04 | mnemoc | his paypal account is temporarily blocked until further verifications |
| 09:55.46 | mnemoc | they shut it off after $500 :| |
| 10:00.11 | *** join/#arm-netbook rellla (~Thunderbi@p5B0780D5.dip0.t-ipconnect.de) |
| 10:16.29 | hno | $500? |
| 10:16.51 | hno | $5000 I could understand, but $500? |
| 10:16.53 | oliv3r | i'll try to secure it, but it requres CC i belive and that, I don't have |
| 10:18.15 | mnemoc | hno: pretty silly |
| 10:18.47 | mnemoc | oliv3r: debit cards should work too |
| 10:19.43 | oliv3r | and without either :) |
| 10:20.04 | oliv3r | paypal links to my bankacount |
| 10:20.37 | mnemoc | oliv3r: but he can't receive payments via paypal at the momemnt |
| 10:20.45 | oliv3r | so i'm stuck :( |
| 10:21.41 | mnemoc | receiving paypal payments is key for the campaign, so it will be fixed as soon as paypal allows it :| |
| 10:22.54 | oliv3r | guess that'll be tomorrow |
| 10:25.07 | mnemoc | hopefully |
| 10:27.14 | RaYmAn | hno: it's paypal :P |
| 10:27.29 | RaYmAn | It's probably not the amount itself, but the fact that a lot of transactions came in at once |
| 10:28.45 | mnemoc | you got a $5 payment to TI blocked, right? |
| 10:32.12 | RaYmAn | yeh |
| 10:32.22 | RaYmAn | presumably because they got tons of 5$ payments at the same time |
| 10:32.35 | mnemoc | :) |
| 10:32.50 | RaYmAn | any activity that seems fraudulent is flagged |
| 10:32.54 | RaYmAn | which imo is good |
| 10:33.02 | RaYmAn | it's a pity it has hit this project though :/ |
| 10:33.44 | RaYmAn | I mean, if I hacked 50 paypal accounts and wanted to try and go mostly unnoticed, i'd transfer a low amount from each account. |
| 10:33.59 | jelly | RaYmAn: do yu have to notify Paypal in advance if you set up a pledge like this? |
| 10:34.10 | RaYmAn | I don't really know - I don't think you really can |
| 10:34.29 | RaYmAn | it mihgt have helped if he had gotten it verified prior to opening up |
| 10:34.30 | jelly | "hi I hope I'm going to get lots of money this week, plz don't block kk" |
| 10:34.45 | jelly | oh, it's an unverified account? |
| 10:34.46 | RaYmAn | It's probably fully automated though |
| 10:39.31 | *** join/#arm-netbook ZaEarl (~malmrose@17.host-182-48-148.compassnet.co.nz) |
| 10:41.04 | slapin | hno, libv: A7HD serial port picture http://ossfans.org/a7hd_serial.jpg |
| 10:45.00 | mnemoc | slapin: http://linux-sunxi.org/Hyundai_A7HD :) |
| 10:52.34 | *** join/#arm-netbook Tomer (~rr@199.203.62.164) |
| 10:52.45 | Tomer | hi, any mk802 experts here? |
| 10:54.10 | rm | yes/no/maybe/likely |
| 10:54.16 | rm | what's the question? :p |
| 10:54.22 | *** join/#arm-netbook arnd (arnd@nat/ibm/x-abkruzqdwsufiqeb) |
| 10:55.15 | mnemoc | arnd! |
| 10:56.06 | slapin | mnemoc: There is currently no text in this page. You can search for this page title in other pages, or search the related logs, but you do not have permission to create this page. |
| 10:56.24 | mnemoc | slapin: of course, you haven't written it yet |
| 10:56.51 | slapin | mnemoc: ah, I see then |
| 10:58.00 | Tomer | rm, I bought an mk802 from amazon, it was working fine for a while, but since yesterday I plug it in the power and tv and the tv says "NO SIGNAL" |
| 10:58.17 | mnemoc | rip? |
| 10:58.51 | Tomer | I read online that I can try flashing the rom with LiveSuit and a specific image, tried it, it said it was done successfully and yet when I plug it into my tv there's no output |
| 10:59.51 | Tomer | the amazon page said it's MK802, and I see there's also a MK802-2 version (||), and theres another image for it, any chance it might work? |
| 11:01.45 | Tomer | how can I tell if its somehow "mk802 ||" and not just "mk802 |
| 11:03.18 | mnemoc | the mk802 ii has different ports |
| 11:06.00 | Tomer | ah, full hdmi port, 3 usb ports, thats not what I got |
| 11:06.17 | cat_x301 | mnemoc: hmm.. stage/sunxi-3.0 branch + r3p0 do no cope together, still getting unhandled ioctls. |
| 11:15.20 | *** join/#arm-netbook mSquare (~selvan@122.167.68.58) |
| 11:21.09 | mnemoc | cat_x301: never tried mali myself. I only merged next_mali which was *claimed* to be working |
| 11:23.32 | cat_x301 | mnemoc: no worries.. i am really pissed-off that i still cannot get ui running reliably.. but who said that it is going to be easy, huh? ;) |
| 11:30.49 | mnemoc | easy = boring |
| 11:39.21 | oliv3r | i'm backreading the r-pi crapnnouncement on /. and notice someone in the comments mentioning 'the chinese promise that the A10 have an entire free stack'. Obviously the mali core can't be controlled by china nor Allwinner, but what exactly do these chinese 'promise'? |
| 11:39.43 | oliv3r | it is stated that obvvviously A10 hasn't delivered yet, all there is is a promise |
| 11:41.41 | mnemoc | the main difference is that you can use any A10 device without any bit of closed code |
| 11:42.03 | mnemoc | if you are willing to give up on 3d and hardware accelerated video decoding |
| 11:42.40 | mnemoc | the r-pi was not even been able to boot without the blob |
| 11:42.43 | oliv3r | 49 USD board sold out :) |
| 11:42.51 | mnemoc | exceptable |
| 11:42.54 | oliv3r | r-pi is a piece of crap |
| 11:42.58 | RaYmAn | mnemoc: mm. So what you're saying is that if that code was in a bootrom it would be ok? :P |
| 11:42.59 | oliv3r | imo |
| 11:43.02 | oliv3r | the idea was really good |
| 11:43.08 | oliv3r | it's execution seriously flawed |
| 11:43.16 | mnemoc | RaYmAn: the bootrom is slim enough to not count :p |
| 11:43.29 | oliv3r | r-pie is only successful now because of it's hyping. i'm sure many are dissapointed |
| 11:43.45 | oliv3r | bootrom the 32k BROM? |
| 11:43.47 | RaYmAn | mnemoc: mm |
| 11:44.02 | oliv3r | i belive in richard stalmans words, that if it is true ROM, it is conciderd part of the hardware |
| 11:44.29 | oliv3r | if the BROM is flashable however, in any way whatsoever, it's firmware and needs to be set free :) |
| 11:44.47 | mnemoc | the BROM can be considered part of the hardware, yes |
| 11:45.14 | RaYmAn | that argument is kind of fail though |
| 11:45.22 | mnemoc | :) |
| 11:46.13 | mnemoc | the BROM only knows to poke around checking what's bootable, and to trigger (the also closed, but in true ROM) FEL |
| 11:46.32 | mnemoc | slim enough for me :) |
| 11:47.33 | mnemoc | RaYmAn: not for you? |
| 11:47.39 | oliv3r | FEL mode is also in ROM? |
| 11:48.24 | RaYmAn | mnemoc: I just think it's more of a gray area. Caring whether they put it on flash or on a microsd is rather irrelevant imo |
| 11:49.15 | mnemoc | RaYmAn: the BROM is not on flash, it's within the soc |
| 11:49.27 | mnemoc | oliv3r: yes |
| 11:49.30 | RaYmAn | The distinction seems rather irrelevant |
| 11:52.27 | mnemoc | RaYmAn: so you consider the slim brom of the a10 and the closed firmware of r-pi's (or tegra's) videocore to be ... equivalent in terms of the openness of a system? |
| 11:54.01 | RaYmAn | mnemoc: I consider the fact that the closed firmware encumbers much more of the system an issue wrt openness. |
| 11:54.17 | RaYmAn | I don't consider whether the firmware is on flash or ROM a considerable difference. |
| 11:56.07 | oliv3r | in the end, all firmware should be set free. In my opinion, it is still software. It is compiled code. And yes, in the ideal world, even your microwave or whatever device with whatever small piece of firmware, should be liberated. |
| 11:56.37 | oliv3r | I do find, for now anyway, the A10's BROM acceptable. It is small enough to not possibly cause problems for one. |
| 11:56.55 | oliv3r | the r-pi's firmware, is a huge blob, causing many problems |
| 11:57.17 | RaYmAn | definitely and *that's* exactly the issue. |
| 11:57.35 | RaYmAn | They could have put that huge blob on a ROM and according to your definition, it would suddenly be open. |
| 11:57.36 | mnemoc | that's why I used the term "slim" :< |
| 11:57.49 | RaYmAn | slim is rather vague |
| 11:58.33 | ZaEarl | if it's in a rom, and can't be changed, there's far less use in it being open. |
| 11:58.57 | mnemoc | problem is when they put a large and buggy pile of code in ROM to be "open" |
| 11:59.11 | RaYmAn | definitely |
| 11:59.14 | mnemoc | that's even worse than an upgradable firmware |
| 11:59.24 | RaYmAn | that was my primary point |
| 12:00.13 | hno | FSF seem to have changed their mind a bit on that when it comes to endorsable hardware. |
| 12:00.58 | Gumboot | RaYmAn: I do not know the issue. I could dig around, but it's a fair assumption that if I found it I could then not confirm or deny that I found it, let alone say anything about the outcome. |
| 12:01.22 | hno | Gumboot, tied hands? |
| 12:01.44 | Gumboot | I'm simply assuming that NDA would block me. |
| 12:02.10 | hno | tied hands. |
| 12:03.42 | RaYmAn | Gumboot: no worry - my point was rather to tell *someone* from nvidia :P It's a rather silly bug to have. I don't mind not hearing anything back ever. |
| 12:03.45 | arnd | I hope I can talk to some of the Mali folks next week during LinaroConnect, With the Broadcom VC4 "drivers" being open, we might be in a better position to ask for open user space for their stuff ;-) |
| 12:04.08 | libv | slapin: can you create a wiki page for the hyundai on linux-sunxi.org? |
| 12:05.45 | mnemoc | arnd: if arm/mali people can't see value in having real open mainlined drivers, we can't even dream about the rest understanding it :< |
| 12:06.02 | libv | :) |
| 12:06.29 | Gumboot | It's not about seeing the value in it. It's about the value in the opposite action being removed. |
| 12:06.33 | libv | guess why arm is not supporting lima or providing their own free driver? |
| 12:06.45 | mnemoc | $$ |
| 12:06.50 | arnd | mnemoc: well, I'm sure they see value in it already, it's just that for them it's a tradeoff against the value in keeping it closed |
| 12:07.51 | slapin | libv: I don't really remember how to operate mediawiki, so I will try to figure it out tonight |
| 12:08.02 | arnd | If I want to play with a10, is dx.com/p/ak802-844145525 the right hardware to get? |
| 12:08.13 | libv | slapin: it is not too bad, but of course it is completely different than moinmoin wikis |
| 12:08.14 | arnd | I just saw that it has now appeared in the european store |
| 12:08.29 | mnemoc | arnd: http://www.indiegogo.com/cubieboard?a=1658415 :) |
| 12:08.34 | libv | slapin: i am sure that if the developers were put in the same room, noone would come out alive |
| 12:09.17 | mnemoc | arnd: problem with those hdmi dongles is the access to the uart |
| 12:09.29 | mnemoc | arnd: but you can always get it out of the uSD pins |
| 12:09.31 | hno | arnd, doubt it's doable for ARM. Very different separation in IP boundaries, with most of the IP within the libraries and not so much the GPU/firmware. |
| 12:09.36 | libv | mnemoc: do you, with your allknowing mind, know of anything else that uses the disp engine besides the android hardware code for a10? |
| 12:09.53 | libv | hno: nope. |
| 12:10.07 | arnd | mnemoc: so I can't use uart and uSD at the same time then? |
| 12:10.27 | mnemoc | arnd: hno made some jtag based voodoo to have both... but it's evil |
| 12:10.34 | libv | hno: all i can find in the mali stuff is the algorithm for using the cache for the vertex shaders most efficiently |
| 12:10.35 | mnemoc | arnd: the simplest of all is to get a mele |
| 12:10.58 | libv | hno: and the compiler is cpu time optimised, not gpu efficiency |
| 12:11.08 | hno | libv, in the libs? |
| 12:11.12 | mnemoc | libv: ehm... don't know for sure... but adding some printk()s will tell :) |
| 12:11.46 | libv | mnemoc: well, strings | grep disp should reveal /dev/disp on some libs |
| 12:11.54 | libv | mnemoc: but nothing that you know of then |
| 12:12.11 | mnemoc | libv: not really into that part of the a10 world, sorry :< |
| 12:12.14 | hno | thought they had a bit more intelligence in there.. |
| 12:12.24 | libv | hno: check my fosdem video |
| 12:13.18 | libv | here i describe the one thing that might be controversial, and how i get around it |
| 12:15.46 | hno | slapin, you also have serial and JTAG at the pads closer to the CPU. The topmost two is serial, and the four below the resistors are JTAG. |
| 12:15.48 | libv | and the thing is pretty meek indeed: the polygon blocks layout for optimal efficiency, we can easily benchmark our way out of that one |
| 12:17.18 | *** join/#arm-netbook mnemoc (~amery@geeks.cl) |
| 12:17.25 | oliv3r | arnd: just don't mention their 'open' stuff being steaming pile of useless crap :) |
| 12:17.58 | oliv3r | mnemoc: arm udnerstands, arm management, doesn't. Appearantly, even ARM engineers tell arm to let them OSS it as it will be most beneficial |
| 12:19.03 | mnemoc | :) |
| 12:19.28 | hno | libv: http://www.phoronix.com/scan.php?page=news_item&px=MTA1NjI ? |
| 12:19.48 | libv | ah, will stephensons ear |
| 12:20.07 | arnd | oliv3r: it's not useless, it's just something else than what we would need from them |
| 12:20.14 | libv | hno: yes :) |
| 12:20.33 | libv | hno: as an added bonus, i aim will's laptops webcam at my gut for 10 minutes at the end :) |
| 12:21.00 | arnd | what broadcom has released is good for porting drivers to other operating systems or windowing systems, but it's useless for hacking on the driver itself |
| 12:21.12 | hno | Ok. Will listen on it carefully later today. At work doing other stuff at the moment. |
| 12:21.38 | libv | hno: i pretty much explained the one thing already though :) |
| 12:22.35 | hno | libv, possible, but not keeping up with the backlog here either at the moment. Mind on other high level C stuff. |
| 12:23.16 | libv | 31 minutes in this video is where i talk about this |
| 12:24.37 | oliv3r | libv: the projectlaunch vid from lima earlier this year at fosdem? |
| 12:24.44 | slapin | libv: any links to video? |
| 12:24.46 | libv | oliv3r: yeah |
| 12:24.56 | libv | slapin: the phoronix link has it |
| 12:25.52 | mnemoc | oliv3r: yes, i was refering to the "management". not the normal engs |
| 12:29.12 | libv | ok, so libcedarv/linux-armhf/sample/render talks to the disp engine, but in an even more limited way than android |
| 12:29.24 | libv | and we have source for that one :) |
| 12:30.01 | mnemoc | :) |
| 12:30.20 | slapin | do we have source for libcedarv? |
| 12:30.28 | mnemoc | no |
| 12:30.31 | oliv3r | nope |
| 12:30.55 | mnemoc | but we got armhf/neon libs yesterday |
| 12:31.07 | oliv3r | god that video is horrible. camera even falls |
| 12:31.28 | libv | nothing in the libs |
| 12:34.17 | oliv3r | libv i think you said in the vid, that GPU drivers is keeping manufacturers back; is this still the case you think? (I would assume so) if so, why hasn't it still changed? |
| 12:34.33 | libv | device manufacturers, yes |
| 12:35.22 | *** join/#arm-netbook Almamuetya (~almamuety@186.134.25.91) |
| 12:35.30 | libv | why it hasn't changed, well, for many reasons. |
| 12:35.58 | hno | slapin, only partial source of non-important parts stolen from ffmpeg. |
| 12:36.05 | libv | the cost of open sourcing things is high, and this way the silicon vendor shifts some of this higher cost of integration to individual device makers |
| 12:36.32 | libv | and the device makers of course do not get organized, and demand, in concert, that this is relieved |
| 12:36.57 | hno | libv, they won't until they understand that they can expect better. |
| 12:37.34 | libv | well, nokia meego did, but that depended on the people in the organization |
| 12:37.39 | oliv3r | well someone needs to tell them properly :) |
| 12:37.56 | libv | i doubt that the bazillion chinese device makers understand it |
| 12:37.57 | hno | linaro also understands. |
| 12:37.57 | oliv3r | I'm supprised google hasn't stepped up and done anything in this regard, they should be fully aware of this |
| 12:38.06 | libv | hno: linaro is not a device manufacturer |
| 12:38.13 | oliv3r | samsung is beginning to understand I'd guess? |
| 12:38.24 | libv | hno: also, the stakeholders in linaro tend not to be device makers |
| 12:38.25 | hno | true, but many rely on them. |
| 12:38.41 | hno | but longer term, not per product. |
| 12:39.01 | mnemoc | linaro is probably the most frustrated group of all. having access to the people and the code and not been able to open source the stuff :< |
| 12:39.03 | libv | hno: so linaro is kind of preaching to the choir, but in the meantime giving the less clued-up manufacturers an easier time already |
| 12:39.25 | hno | yes |
| 12:39.50 | hno | so three steps forward, 2.5 back. |
| 12:40.04 | libv | oliv3r: i fear that samsung might be like nokia in a few respects: apart from the fact that samsung actually is a viable company still today and actually manages to deliver what many customers want |
| 12:40.19 | libv | many different groups or factions in samsung will be pulling in different directions |
| 12:40.26 | libv | as is true for any big company |
| 12:40.30 | oliv3r | like nokia? gonna go in bed with MS only and become obsolete? |
| 12:40.56 | oliv3r | samsung has grown enormously in what, 30 years? |
| 12:41.29 | rm | don't forget that mobile is only part of Samsung |
| 12:41.31 | rm | unlike nokia |
| 12:41.48 | oliv3r | nokia used to make lots, including CRT's! |
| 12:42.36 | andoma | and tires and wellington boots |
| 12:44.40 | *** join/#arm-netbook Almamuetya (~almamuety@186.134.25.91) |
| 12:58.11 | *** join/#arm-netbook rsalveti (~rsalveti@linaro/rsalveti) |
| 13:02.59 | *** join/#arm-netbook alcides (~alcides@unaffiliated/alcides) |
| 13:12.10 | Gumboot | shifts his opinions around some more. |
| 13:13.20 | Gumboot | I see these words on libreplanet.org: "the hardware must run free software on every layer that is user upgradeable" |
| 13:14.31 | Gumboot | Which I guess makes the difference between an RS232-based modem running locked-in as well as locked-down firmware, and any of the more modern devices which get their blobs uploaded from the kernel. |
| 13:15.56 | libv | so... android, some test code in cedarv, and the display poking bit of C that's floating around on the web talk to /dev/disp ioctls |
| 13:16.14 | libv | anyone have suggestions for where to look for further nasties? |
| 13:18.51 | *** join/#arm-netbook Almamuetya2 (~almamuety@181.29.113.4) |
| 13:19.41 | *** join/#arm-netbook Almamuetya3 (~almamuety@186.134.25.91) |
| 13:20.53 | Gumboot | I tried to buy some Nokian tyres a couple of years back. Couldn't find a distributor, though. |
| 13:21.16 | Gumboot | Or maybe I couldn't find a tyre. They might have pulled out of the cycle tyre business. |
| 13:22.02 | Gumboot | No, looks like they're still doing them. |
| 13:24.57 | Gumboot | Anyway, I do wonder about the merits of endorsing something just because its firmware is locked in. It makes sense for something like an external peripheral, but once you start talking about bus masters there are big questions about degrees of intrusion into the system and bugs and security and snooping. |
| 13:25.27 | Gumboot | Thunderbolt blurs that boundary even further. |
| 13:26.35 | Gumboot | I'd have thought drawing the line at some kind of standardised interface would be more fundamental. |
| 13:26.50 | Gumboot | But evidently not the OpenGLES interface. |
| 13:29.12 | mnemoc | libv: would be you move your work upon the stage/sunxi-3.0 branch? :) |
| 13:29.53 | libv | i probably should, yes |
| 13:30.03 | mnemoc | \o/ |
| 13:30.58 | libv | but now things are not going to move as fast anymore... first need to write up some code to test /dev/disp interfaces and types, so i do not break the users too often :( |
| 13:32.24 | mnemoc | what about keeping /dev/disp for compatibility and adding a new interface in kms (or similar) fashion? |
| 13:32.39 | libv | mnemoc: starting from scratch is not too useful |
| 13:32.47 | mnemoc | ok |
| 13:33.25 | libv | mnemoc: i will rewrite the backend slowly, will add a disp ioctl versioning scheme, and will try to keep breakages limited |
| 13:33.47 | mnemoc | :) |
| 13:33.51 | libv | i never am one for throwing stuff away and starting from 0 |
| 13:34.17 | libv | i have seen too much NIH in my time, and hit too often by it (randr1.2, kms, radeon, openchrome, ...) |
| 13:34.27 | mnemoc | i was thinking more in refactoring to let both interfaces share |
| 13:34.35 | libv | if and when possible |
| 13:34.46 | mnemoc | fair enough |
| 13:35.04 | libv | again, i will make sure that i do not accidentally break stuff, and will strive for maximum compat |
| 13:35.15 | libv | and check out my fosdem 2010 talk slides :) |
| 13:35.38 | libv | http://www.phoronix.com/image-viewer.php?id=fosdem_2010_unification&image=xorg_unified_12_lrg |
| 13:36.16 | mnemoc | so you aim at a drm interface? |
| 13:36.53 | libv | i built up radeonhd modesetting from scratch to be build-time compatible with suse enterprise and debian stable |
| 13:37.05 | libv | and i am/was the only one doing so |
| 13:37.27 | libv | until a few months before that slide, i was compatible with xfree86 4.3 |
| 13:38.47 | libv | well, first i expose the innards in a sensible fashion, so that the actual bitbanging can be reused for kms |
| 13:38.57 | libv | but the drm concept is badly structured and broken anyway :) |
| 13:39.09 | mnemoc | :) |
| 13:39.40 | libv | having modesetting depend hard on a fully featured memory manager, and lumping everything, even 3d command queueing and some limited 2d accel together that badly is pretty unforgivable |
| 13:39.52 | Gumboot | What hardware are you talking about? |
| 13:40.36 | libv | working on sunxi disp atm |
| 13:40.47 | libv | but unichrome is the via igp |
| 13:41.06 | Gumboot | OK. It's just, I noticed in the rpi forum you mentioned your work on tegra. If that's on-topic in this channel then I'll have to leave. |
| 13:41.39 | Gumboot | I don't want to be a whiney bitch or anything... it's just ... you know ... not getting fired, and all that. |
| 13:42.22 | libv | Gumboot: someone else is working on tegra2 REing, someone who has been hanging around the lima channel for ages (but unable to directly contribute as he actually worked on the mali several years ago) |
| 13:42.54 | Gumboot | <fingers-in-ears>lalalalalalalalalala! |
| 13:42.59 | libv | ? |
| 13:43.15 | *** join/#arm-netbook Almamuetya3 (~almamuety@186.134.25.91) |
| 13:43.15 | Gumboot | I don't want to hear about reverse engineering work relating to my employer. |
| 13:43.20 | RITRedbeard | You work for Nvidia? |
| 13:43.30 | RITRedbeard | Tell them to quick sucking. |
| 13:43.34 | RITRedbeard | quit, rather. |
| 13:44.42 | libv | Gumboot: you do know that this channel is publically logged, right? |
| 13:44.43 | Gumboot | I think there's a diplomatic response to that, but I don't have the big book of party lines to hand. |
| 13:45.10 | Gumboot | libv: It's no secret where I work. I'm not hiding that. |
| 13:45.25 | libv | quite the opposite |
| 13:45.55 | Gumboot | My only concern is establishing that I'm not hanging out in a career-limiting channel. |
| 13:45.56 | libv | Gumboot: http://ibot.rikers.org/%23arm-netbook/20121024.html.gz |
| 13:47.21 | Gumboot | Yes yes, I know. It's right there in the topic, I think. Although that bit doesn't fit on my screen. |
| 13:47.35 | Gumboot | Yeah. Right there in the topic. |
| 13:47.47 | libv | mnemoc: in any case, don't worry, if anyone is going to keep the actively used disp bits running for long, then it's me :) |
| 13:48.09 | mnemoc | libv: :) |
| 13:48.53 | libv | btw, we might want to introduce a new ioctl |
| 13:49.10 | *** join/#arm-netbook Almamuetya3 (~almamuety@181.29.100.235) |
| 13:49.16 | libv | and allwinner has given us just what we need there: two reserved ioctls at the start of the table |
| 13:49.32 | libv | this new ioctl should be a versioning handshake |
| 13:52.14 | *** join/#arm-netbook Almamuetya4 (~almamuety@186.134.25.91) |
| 13:54.44 | libv | giving users of the disp ioctls to at least recognize and actively warn when they are running against an incompatible version (when one does happen), it's better to introduce this ioctl asap though |
| 13:54.59 | libv | s/to/a chance/ |
| 13:55.43 | *** join/#arm-netbook Almamuetya5 (~almamuety@181.29.100.235) |
| 13:56.26 | mnemoc | libv: give me a commit and I add it now |
| 13:57.01 | mnemoc | btw, I just added an entry message about the public logs. |
| 13:58.23 | libv | ok, and nice :) |
| 13:58.36 | libv | let me write it up and test it first :p |
| 13:59.39 | mnemoc | :) |
| 14:16.56 | *** join/#arm-netbook Almamuetya6 (~almamuety@186.134.25.91) |
| 14:17.03 | *** join/#arm-netbook pwhalen (~paul@CPE001310360dac-CM78cd8ec9e405.cpe.net.cable.rogers.com) |
| 14:22.31 | *** join/#arm-netbook Almamuetya7 (~almamuety@181.29.100.235) |
| 14:31.38 | *** join/#arm-netbook slash_random (~david@host197.201-252-139.telecom.net.ar) |
| 14:32.11 | *** join/#arm-netbook gzamboni (~gzamboni@150.236.205.77.rev.sfr.net) |
| 14:35.37 | *** join/#arm-netbook AndChat138129 (~AndChat13@31.120.33.198) |
| 14:36.30 | *** part/#arm-netbook mSquare (~selvan@122.167.68.58) |
| 14:45.28 | libv | hrm, how often is code that allwinner threw over the hedge going to be merged in that blatantly? |
| 14:46.01 | libv | if this is the norm, then there is no point in cleaning or restructuring |
| 14:48.09 | mnemoc | it's the first time. most of the a13-sdk stuff is in a separated branch |
| 14:48.29 | libv | and going forward? |
| 14:49.23 | mnemoc | not much |
| 14:49.27 | libv | because i will have to redo quite a lot of things, basically all sun4i/sun5i unification needs to be redone |
| 14:49.52 | libv | not much is not a satisfactory answer for me when it comes to blatantly merging raw allwinner code |
| 14:50.13 | mnemoc | it's not merged |
| 14:50.24 | *** join/#arm-netbook drachensun (~drachensu@142.196.83.182) |
| 14:50.45 | mnemoc | it was more of a panic |
| 14:50.56 | mnemoc | considering 4 flows of incompatibles patchsets |
| 14:51.14 | mnemoc | to the disp driver |
| 14:51.34 | mnemoc | as any cleanup needed to include the a13 code |
| 14:53.06 | mnemoc | https://github.com/linux-sunxi/linux-sunxi/commits/wip/linux-sunxi-3.0/sun5i <--- this is the rest of the junk |
| 14:55.35 | mnemoc | the bulk disp changes from the a13-sdk can also be left to rot... or "for future reference" ... as after the cleanups refactoring they be probably impossible to merge at all |
| 14:57.28 | mnemoc | but they haven't been merged into either of the main branches, only stage... so can be taken out |
| 14:59.16 | libv | well, with my heightened temperature and runny face, i am not up for rebasing and redoing that stuff today |
| 15:00.31 | mnemoc | i think techn rebased at least part of your refactoring already |
| 15:01.05 | *** join/#arm-netbook arokux (~arokux@merkur178.inf.uni-konstanz.de) |
| 15:01.16 | libv | rebasing will not work |
| 15:01.27 | mnemoc | was fearing so |
| 15:01.45 | libv | unification of sun4i/5i needs to be done afresh |
| 15:03.31 | mnemoc | another way is to apply the sun5i changes on top of the already unified one |
| 15:03.49 | libv | how? |
| 15:04.01 | libv | again, unification needs to be done afresh |
| 15:04.55 | mnemoc | meh :( |
| 15:05.48 | libv | all the rest can be rebased and manually retouched, but unification needs to be thought through from the start again |
| 15:06.17 | libv | as sun4i and sun5i diverge _a_ _lot_ now |
| 15:07.27 | libv | heh |
| 15:07.58 | libv | in some cases, sun4i settings get merged in, so some of the unification becomes superfluous |
| 15:09.37 | mnemoc | :< |
| 15:14.08 | *** join/#arm-netbook sspiff (~quassel@unaffiliated/yukito) |
| 15:14.42 | *** join/#arm-netbook alcides (~alcides@177.35.120.97) |
| 15:14.42 | *** join/#arm-netbook alcides (~alcides@unaffiliated/alcides) |
| 15:15.19 | cat_x301 | libv: what branch you're planning to take as a base for your work? |
| 15:15.45 | libv | cat_x301: what do you mean, planning? |
| 15:16.17 | cat_x301 | s/planning/taking :) |
| 15:17.25 | cat_x301 | libv: ah, never mind, just noticed that discussion was about sunxi-3.0.. |
| 15:18.20 | mnemoc | cat_x301: it also affects sunxi-3.4 |
| 15:19.33 | hno | I wonder.. is there really any differences between sun4i and sun5i disp hardware? |
| 15:19.49 | cat_x301 | mnemoc: yeah, i see. |
| 15:33.22 | *** join/#arm-netbook ssspiff (~quassel@unaffiliated/yukito) |
| 16:10.09 | *** join/#arm-netbook rellla (~Thunderbi@p4FE56214.dip0.t-ipconnect.de) |
| 16:11.20 | drachensun | rellla: have you tried to build xbmc for the new cedar hf libs? |
| 16:12.28 | mnemoc | http://wandboard.org/index.php/blog <--- pictures of a real wandboard |
| 16:19.53 | techn_ | evening |
| 16:20.22 | techn_ | mnemoc: I have terriple headache today.. so dunno if I can do the rebase |
| 16:20.52 | *** join/#arm-netbook arnd (~arnd@HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de) |
| 16:21.06 | techn_ | Tom has raised already 12k :) |
| 16:22.02 | mnemoc | techn_: it can't be rebased... unification needs to be redone entirely |
| 16:23.57 | mnemoc | techn_: hopefully libv will leave the anger caused by commit from the a13-sdk behind soon :) |
| 16:24.31 | techn_ | atleast part of it is cherry-pickable |
| 16:25.07 | techn_ | I think cherry-picking is the way |
| 16:25.28 | techn_ | and commit's which doesn't fit must be redone |
| 16:26.07 | mnemoc | git show $hash | git apply -3 --ignore-white-space tends to work better than cherry-picking |
| 16:26.51 | techn_ | I think cherry-pickin also has ignore white space option :/ |
| 16:27.06 | mnemoc | -3 is the magic part |
| 16:28.54 | techn_ | it's not documented .. what does it do? |
| 16:29.54 | mnemoc | 3-way merge |
| 16:32.16 | mnemoc | it's smarter regarding file changes |
| 16:32.26 | mnemoc | and files moved |
| 16:34.47 | libv | it won't help for the unification, again, unification has to be pretty much redone |
| 16:34.59 | libv | there is too much actual logic involved |
| 16:35.50 | mnemoc | that was exactly my thought when getting the commit in the stage.... "now or never" :< |
| 16:36.52 | mnemoc | but not sure if the "never" is such a bad idea :< |
| 16:39.13 | mnemoc | sun5i's hdmi is for the A10s SoC, from which we don't have anywhere to test |
| 16:39.37 | mnemoc | yet |
| 16:39.50 | *** join/#arm-netbook vinifr (b1138417@gateway/web/freenode/ip.177.19.132.23) |
| 16:39.51 | mnemoc | s/from/for/ |
| 16:40.44 | vanner | mnemoc, you recommended me try rzk's mali driver. how to it build for A10? |
| 16:41.27 | mnemoc | rzk: ----^ |
| 16:42.05 | rellla | drachensun: i have built it with success. now i'm trying to get it on a sd-card. a little complicated with my windows/vmware/no native linux/samba/nfs-connection ;-( |
| 16:42.10 | Maqs | mnemoc: what were the results of your u-boot sf/hf tests? did it work without -msoft-float? |
| 16:42.22 | libv | mnemoc: what do you mean with sun5i hdmi being for a10 soc? |
| 16:42.42 | mnemoc | libv: A10s != A10 |
| 16:43.00 | libv | ah, ok, and i guess that there are no such devices out there yet? |
| 16:43.05 | mnemoc | libv: it's a sun5i SoC designed for hdmi dongles |
| 16:43.10 | *** join/#arm-netbook empat0 (~empatzero@leer-4d0a933c.pool.mediaWays.net) |
| 16:43.35 | mnemoc | libv: right. Tsvetan (from olimex) was going to get some samples, but nothing yet |
| 16:43.40 | mnemoc | empat0: wb! |
| 16:43.42 | libv | i've seen a lot of tablets advertised as a13 with hdmi connectors, but i guess that they are just mislabeled |
| 16:43.46 | Maqs | empat0: :-) may i disturb you for a minute? |
| 16:44.18 | mnemoc | libv: the A10s and A13 have incompatible footprints, they can't share PCBs |
| 16:44.36 | libv | mnemoc: could these be external hdmi controllers? |
| 16:44.40 | libv | although, that would bump cost |
| 16:44.43 | drachensun | rellla: you built it in windows? |
| 16:44.48 | libv | way above a10 |
| 16:45.15 | mnemoc | libv: or external hdmi controller or actually A10 |
| 16:45.27 | rellla | in a virtual machine debian/unstable-amd64 cross-compile....... very strange for me :-) |
| 16:45.28 | empat0 | hi! just to inform you that armhf cedarx seems to work same as amel version. mali r3p0 framebuffer seems also to be ok, at leat for xbmc. |
| 16:45.34 | libv | the costs makes it more likely an a10 |
| 16:45.44 | mnemoc | empat0: great news! |
| 16:45.59 | libv | his brain is becoming more and more mush and more and more leniant to redoing some unification |
| 16:46.12 | rellla | empat0: thanks for the changes at github, i can't wait to try |
| 16:47.08 | mnemoc | libv: mail sent |
| 16:47.37 | libv | ? |
| 16:47.49 | mnemoc | "you got mail" (tm) |
| 16:48.21 | libv | ah, ok, will need a minute to hit |
| 16:48.39 | libv | aha, ta :) |
| 16:52.44 | drachensun | rellla: wow that does sound pretty tricky. I'm just trying to build on the device right now |
| 16:52.54 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 16:53.05 | slapin | libv: do you have vudeo of that presentation, where camera really shows what's on projector, and not some wall all the time? :) |
| 16:53.22 | slapin | s/vudeo/video |
| 16:54.31 | empat0 | which kernel version should i use for mali r3p0? is wip/linux-sunxi-3.0/next_mali ok or is there a better version? |
| 16:54.39 | libv | slapin: for fosdem? no |
| 16:54.52 | libv | slapin: this was someone in the room with a usb attached camera |
| 16:55.03 | libv | slapin: in room for 80 people holding 120 at least |
| 16:55.22 | mnemoc | empat0: try stage/sunxi-3.0 please |
| 16:55.26 | libv | you can see the demos in a separate video, and you can get the slides as well, all from phoronix |
| 16:55.26 | slapin | libv: I see |
| 16:55.43 | libv | slapin: fosdem is a bit of a happy mess from time to time |
| 16:55.54 | slapin | libv: thanks |
| 16:56.09 | libv | and it really shows in videos like this |
| 16:56.23 | libv | which is why we get to examine will's ear for that long |
| 16:56.49 | rellla | drachensun: i did with the armel-version, but i'm sick of waiting 6h and then maybe start from the beginning... but my binary is not proofed yet. maybe i'll have to do it native again.... |
| 17:01.22 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 17:01.45 | *** join/#arm-netbook arnd (~arnd@HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de) |
| 17:09.03 | slapin | libv: don't you have links for slides? I can't find any :( |
| 17:09.45 | mnemoc | http://www.phoronix.com/image-viewer.php?id=fosdem_2010_unification&image=xorg_unified_12_lrg |
| 17:10.05 | mnemoc | http://www.phoronix.com/image-viewer.php?id=fosdem_2010_unification&image=xorg_unified_01_lrg |
| 17:10.38 | *** join/#arm-netbook AndChat|138129 (~AndChat13@188-222-125-2.zone13.bethere.co.uk) |
| 17:10.40 | mnemoc | slapin: ---^ the second |
| 17:11.59 | *** join/#arm-netbook shivansps (ba3a4875@gateway/web/freenode/ip.186.58.72.117) |
| 17:12.40 | shivansps | hi guys, quick question |
| 17:14.49 | shivansps | i have the linaro beta from j1nx working on my novo 7 aurora, i downloaded and compiled natively extra modules, like the one for the goodix ts, but i cant modprobe them because it says invalid format... it was compiled for the correct kernel version... |
| 17:25.48 | *** join/#arm-netbook AndChat138129 (~AndChat13@31.124.118.76) |
| 17:26.06 | andoma | so does anyone know anything about the flickering that seems to happen in 1080p60? |
| 17:26.20 | andoma | it seems to disappear in 1080p50 unless i turn on multiple layers, then it's back again |
| 17:26.29 | andoma | but if i drop to 1080p24 then it works with multiple layers as well |
| 17:26.48 | andoma | feels like the display output is unable to fetch data in sufficient speed or something |
| 17:30.51 | shivansps | looks like bandwidth issue to me |
| 17:31.23 | shivansps | what HDMI version is on the A10? |
| 17:34.08 | slapin | mnemoc: thanks! |
| 17:35.43 | shivansps | damn, depmod -av complains about missing variables for the new modules, i guess i need to compile and change the kernel as well? |
| 17:35.55 | shivansps | even if the same version |
| 17:41.49 | slapin | mnemoc: these are wrong slides, for xorg unification, there's no Mali stuff there... |
| 17:47.46 | mnemoc | ah, sorry. didn't know you were talking about that talk |
| 17:48.45 | mnemoc | slapin: matching version isn't enough. it needs to be the same tree and same config |
| 17:49.14 | mnemoc | or you'll miss symbols |
| 17:51.15 | *** join/#arm-netbook AndChat|138129 (~AndChat13@188-222-125-2.zone13.bethere.co.uk) |
| 17:53.23 | libv | andoma: the multiple layers thing indeed seems like a memory bandwidth issue |
| 17:55.22 | andoma | shivansps: HDMI version? |
| 17:55.52 | andoma | libv: yeah hm . gonna play around a bit with it |
| 17:56.10 | andoma | maybe i can have my background layer in YUV color space to save some bw |
| 17:56.12 | andoma | see if that helps |
| 17:57.46 | empat0 | andoma: you can try to get rid of it by using scalermode (just scale 1:1) instead of normal mode. this worked for me in xbmca10 (heavy gles+vpu+layer rendering) |
| 17:58.24 | libv | empat0,andoma: so you guys are playing with the display engine ioctls? |
| 17:58.29 | libv | where? |
| 17:58.32 | andoma | libv: yes |
| 17:58.40 | empat0 | andoma: yes |
| 17:58.42 | andoma | empat0: ah interesting |
| 17:58.43 | libv | because i will need to make sure that the abis doe not change |
| 17:59.19 | mnemoc | empat0: what kind of ioctrl()s you use beside screen size? |
| 18:00.02 | empat0 | layer request, layer configuration, video layer |
| 18:00.14 | libv | empat0: where is the code for this? |
| 18:00.38 | shivansps | nevermind, every HDMI revision should support 1080P@60hz... there is a bandwidth issue before reaching HDMI |
| 18:00.59 | libv | shivansps: reduced blanking does 1080p@60hz just fine |
| 18:01.35 | libv | (if you do not trust me, run info cvt, scroll to the bottom :)) |
| 18:03.46 | empat0 | libv: https://github.com/empatzero/xbmca10/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/DVDVideoCodecA10.cpp, https://github.com/empatzero/xbmca10/blob/master/xbmc/windowing/egl/WinEGLPlatformGeneric.cpp |
| 18:04.20 | shivansps | yeah but when something does not work at 60hz and it des work at i.e. 24hz sounds strange, it definitely not filling the framebuffer or the HDMI is not able to transmit it, i say that because ive see some flickering even at X11 desktop at 1080P 60hz |
| 18:04.40 | shivansps | its strange |
| 18:06.06 | libv | empat0: ok, cloning |
| 18:06.40 | techn_ | mnemoc: Should I push libv's changes directly to stage branch? |
| 18:07.12 | *** join/#arm-netbook AndChat138129 (~AndChat13@31.124.185.65) |
| 18:07.34 | techn_ | shivansps: is it tearing or flickering? |
| 18:07.39 | libv | techn_: no, i would like to review things first. |
| 18:08.00 | empat0 | mnemoc: stage/sunxi-3.0 also runs the framebuffer mali r3p0, even a little faster |
| 18:09.04 | shivansps | flickering, but i did not see it happening at the never kernel and mali drivers version |
| 18:09.13 | shivansps | at lest i did not notice it |
| 18:09.20 | mnemoc | techn_: once you are both happy with the changes, yes, you can push directly |
| 18:09.48 | mnemoc | empat0: little fast then? |
| 18:09.54 | mnemoc | than* |
| 18:10.10 | mnemoc | techn_: but maybe a wip can do better first? |
| 18:10.17 | shivansps | im now using my tablet screen, so no HDMI... not sure if its psible to use dual outputs |
| 18:10.49 | shivansps | thats seems to works only in androd |
| 18:11.10 | Maqs | empat0: what kind of a10 device do you have/use for testing? |
| 18:11.37 | empat0 | Maqs: the plastic toy, mk802 |
| 18:11.41 | techn_ | mnemoc: libv.. I wont push those code relocations yet.. but first 4 commits which doesn't have any real code changes |
| 18:12.22 | libv | i think you mean 3, as the fourth is already done in stage |
| 18:12.47 | techn_ | 4th has some improvements over that |
| 18:13.17 | Maqs | empat0: ah, okay. me too. which u-boot/kernel? i'm had some problems with newer kernels + xbmca10, crashing after starting xbmc with hardware decoding |
| 18:13.22 | Maqs | therefore i wonder |
| 18:13.45 | empat0 | mnemoc: i estimate 10% faster than the wip/next_mali kernel |
| 18:13.57 | mnemoc | oh |
| 18:14.20 | Maqs | s/i'm/i/ |
| 18:14.38 | techn_ | empat0: mnemoc: root cause for that could be "CSC improvements" |
| 18:14.57 | shivansps | oh this is just great, xbmc now fails sqlite3 check and the dev lib IS installed... man i hate when those things happen |
| 18:15.12 | mnemoc | techn_: nice :) |
| 18:18.21 | empat0 | Maqs: is started with lubuntu, bootloader still from there, and upgraded kernel to 3.0.42 |
| 18:18.36 | empat0 | Maqs: miniand lubuntu |
| 18:19.50 | empat0 | shivansps: look at config.log, sure another lib missing |
| 18:20.10 | mnemoc | Maqs: btw, did you have the chance to test your mm/bootmem.c crash with recent sunxi u-boot and the patch with printk()s I gave you? |
| 18:20.21 | mnemoc | Maqs: or with mali disabled? |
| 18:22.49 | Maqs | mnemoc: didn't get back to my mk802 until this afternoon, so not yet. could you give me the patch again? i don't seem to have it in my backlog |
| 18:23.40 | mnemoc | Maqs: http://sprunge.us/SFKD ... it's just some tracing sting |
| 18:23.42 | mnemoc | stuff* |
| 18:23.53 | Maqs | thanks, i'll try it late |
| 18:23.54 | Maqs | r |
| 18:24.25 | Maqs | or rather wait until it is compiled :-) |
| 18:24.55 | Maqs | mnemoc: did you have success with armhf u-boot? |
| 18:25.50 | mnemoc | Maqs: didn't have time to try it. will do it tonight (in 3h) |
| 18:26.00 | Maqs | ok |
| 18:29.53 | techn_ | mnemoc: Maqs: http://linux-sunxi.org/FirstSteps, someone has update wiki with armhf hack |
| 18:30.00 | techn_ | .. for u-boot |
| 18:30.06 | *** join/#arm-netbook eFfeM (~frans@c73189.upc-c.chello.nl) |
| 18:30.18 | libv | techn_: i did |
| 18:30.45 | libv | techn_: as i did not know any better, feel free to correct this |
| 18:30.46 | mnemoc | libv: and boots fine? |
| 18:31.06 | techn_ | hno: could you fix that? also there is something broken with Makefiles.. it always does rebuild |
| 18:31.11 | libv | the sd card is not very reliable, but apart from that it works |
| 18:31.57 | mnemoc | Maqs: ----^ |
| 18:32.30 | *** join/#arm-netbook eebrah (~chatzilla@212.49.88.99) |
| 18:32.32 | Maqs | k, thanks.. that's about what i did |
| 18:33.33 | mnemoc | Maqs: and a ticket on u-boot-sunxi's issue tracker? :) |
| 18:34.11 | Maqs | nope, no ticket |
| 18:35.13 | Maqs | are there any kernel changes since 3.0.26 that make a newer u-boot necessary? i'm just asking because.. never touch a running system :-) |
| 18:36.18 | Maqs | interrupting u-boot and changing the configuration from command line is easier than taking the uSD out, putting it in an adapter, in the laptop, replacing a non-working u-boot and try again |
| 18:36.38 | mnemoc | Maqs: u-boot needs to pass proper atag mem and proper machine type. older versions of u-boot didn't do it. older versions of the kernel didn't need it |
| 18:37.41 | techn_ | https://github.com/linux-sunxi/u-boot-sunxi/issues/18 |
| 18:37.46 | mnemoc | this also makes that currently you can't run sunxi-3.4 from nand as the support for allwinner boot hacks was removed |
| 18:38.13 | mnemoc | 4 dings for one ticket.... i should really change the sync settings of my devices |
| 18:39.22 | Maqs | ok.. so SUNXI_IGNORE_ATAG_MEM=y would make it work with an older version of u-boot? |
| 18:39.41 | mnemoc | Maqs: when booting from nand, yes |
| 18:40.02 | Maqs | and not when booting from uSD? |
| 18:40.06 | mnemoc | old u-boot does do the hack either, it's boot1 |
| 18:40.26 | mnemoc | Maqs: try with the patch |
| 18:40.37 | mnemoc | Maqs: and next try with mali disabled |
| 18:40.49 | *** join/#arm-netbook AndChat138129 (~AndChat13@31.124.185.65) |
| 18:41.14 | Maqs | i guess the reason could then just be u-boot not passing atag mem etc. |
| 18:41.31 | mnemoc | with the patch we will know |
| 18:41.45 | Maqs | it's compiling |
| 18:41.55 | Maqs | i'll try as soon as it finishes |
| 18:42.02 | hno | techn_, what? |
| 18:42.51 | techn_ | hno: two ticket's.. armhf build and makefile problem :) |
| 18:43.09 | techn_ | both came from upstream? |
| 18:43.24 | hno | I don't know why uboot uÄstream forces softfloat build |
| 18:44.13 | mnemoc | hf uboot works fine for libv at least |
| 18:44.24 | mnemoc | will test on my devices "tonight" |
| 18:45.00 | hno | regarding make, if you specoify target then u-boot rebuilds all. But not if you just run make in a configured tree. |
| 18:45.08 | mnemoc | but removing the flag seems safe |
| 18:45.32 | mnemoc | hno: how do you identify a configured tree? |
| 18:46.41 | mnemoc | hno: it's for the bsp scripts |
| 18:48.57 | hno | mnemoc, if $(OBJDIR)/include/autoconf.mk exists then the tree is configured for some board already. |
| 18:49.22 | mnemoc | great |
| 18:49.25 | mnemoc | hno: thanks |
| 18:50.09 | *** join/#arm-netbook traeak (~bolsen@75-151-91-165-Colorado.hfc.comcastbusiness.net) |
| 18:52.06 | *** join/#arm-netbook AndChat138129 (~AndChat13@31.124.185.65) |
| 18:55.20 | techn_ | <PROTECTED> |
| 18:56.03 | mnemoc | libv: ---^ |
| 18:57.33 | hno | mnemoc, correction: $(OBJDIR)include/config.h |
| 18:58.52 | *** join/#arm-netbook ZaEarl (~malmrose@17.host-182-48-148.compassnet.co.nz) |
| 18:59.34 | techn_ | hno: could there be some check before touching that file :/ |
| 19:00.19 | hno | shouldn't be very hard to rewrite the u-boot build system to not rewrite the file if there is no change. |
| 19:00.23 | mnemoc | techn_: [ -s ..../config.h ] || make ... ? |
| 19:00.56 | mnemoc | techn_: some for the kernel, one (optional) make to configure, another to do the build |
| 19:01.04 | hno | mnemoc, only if you know it's configured for the same board, and that boards.cfg have not changed for that board. |
| 19:01.08 | techn_ | mnemoc: I think sunxi-bsp is wrong place to fix that problem |
| 19:01.46 | mnemoc | hno: yes, we are using O= to have one dir per config already |
| 19:02.00 | hno | techn_, so is sunxi u-boot. |
| 19:02.23 | mnemoc | techn_: i don't think it's good to overwrite the config every time.... we are better doing two calls |
| 19:02.49 | mnemoc | techn_: in the case of the kernel we will be destroying their .config tweaks |
| 19:03.00 | hno | ? |
| 19:03.16 | mnemoc | running defconfig on every `make linux` |
| 19:03.20 | techn_ | makefile system should keep track if something has changed.. but sure it can be worked around |
| 19:03.36 | mnemoc | defconfig forces an overwrite |
| 19:03.45 | techn_ | mnemoc: that's true |
| 19:03.48 | mnemoc | same as u-boot's make $myboard |
| 19:03.52 | hno | just as u-boot make boardname does. |
| 19:03.58 | mnemoc | :) |
| 19:03.59 | *** join/#arm-netbook freakazoid0223 (~matt@pool-173-75-233-172.phlapa.fios.verizon.net) |
| 19:04.08 | techn_ | Ok.. lets fix sunxi-bsp then :) |
| 19:04.09 | mnemoc | so that one should run only once |
| 19:04.13 | mnemoc | :) |
| 19:04.27 | traeak | what happened to the lima driver, btw? |
| 19:04.33 | hno | once per what? |
| 19:04.53 | hno | defconfig will change. u-boot boards.cfg will change. |
| 19:05.37 | hno | traeak, what driver? It it a reing project. |
| 19:05.58 | mnemoc | hno: once between the first `make linux` and `make clean` |
| 19:06.19 | Maqs | mnemoc: make uImage -C kernel_path/ won't work any more, as it will look for "drivers/gpu/mali/mali/arch/config.h" |
| 19:06.53 | mnemoc | Maqs: ticket please |
| 19:11.03 | *** join/#arm-netbook tzafrir_laptop (~tzafrir@212.179.75.202) |
| 19:12.30 | hno | mnemoc, why do you make clean? |
| 19:18.24 | mnemoc | hno: we don't. i'm just telling to not force as re-config as long as a config is there |
| 19:19.16 | mnemoc | in the hypotheical case someone wants to start from scratch a `make clean` could be done.... but as O= is used, that is basically a single rm -rf |
| 19:23.21 | libv | techn_: Conflicts kept in the message? |
| 19:23.33 | techn_ | libv: yes |
| 19:23.44 | mnemoc | is that considered good practice? |
| 19:24.02 | mnemoc | I always remove them... |
| 19:24.12 | mnemoc | Maqs: thanks |
| 19:24.29 | libv | conflicts from where, what information does it add to rebased or cherry-picked code? |
| 19:25.17 | Maqs | you're welcome |
| 19:25.35 | Maqs | kernel is building again now :-) |
| 19:28.07 | libv | also. --author |
| 19:30.23 | hno | mnemoc, so build will fail to pick upp defconfig changes on source updates. |
| 19:31.41 | mnemoc | hno: i find it quite evil to assume you want a full reconfig every time |
| 19:32.51 | mnemoc | at least for the kernel further `make` calls will update .config (and ask) |
| 19:33.03 | mnemoc | but from there to force a defconfig... |
| 19:36.40 | hno | mnemoc, fair. |
| 19:37.07 | hno | assuming this is a script used by humans and not in an automated build procedure. |
| 19:37.51 | mnemoc | < /dev/null solves that iirc |
| 19:37.59 | mnemoc | at least in the kernel case |
| 19:37.59 | hno | ? |
| 19:38.09 | mnemoc | taking defaults without the need of hitting enter |
| 19:38.49 | mnemoc | for the automated build procedure |
| 19:39.15 | mnemoc | but maybe in that case a `make clean` is better.... or not? |
| 19:43.24 | Maqs | mnemoc: http://dl.dropbox.com/u/11244516/atag-stuff.txt |
| 19:43.40 | Maqs | bank1 looks wrong |
| 19:47.59 | hno | mnemoc, make oldconfig do not pick up defconfig changes. Not even defconfig additions. Only defaults specified in Kconfig files. To pick up defconfig changes a make defconfig is needed. |
| 19:50.00 | hno | Maqs, Hmm... |
| 19:52.03 | techn_ | mnemoc: pushing configure target |
| 19:52.16 | hno | techn_, if you are annoyed by uboot defconfiging itself on make boardname then this fixes it: http://fpaste.org/njJx/ |
| 19:53.08 | techn_ | hno: cool :) |
| 19:53.32 | Maqs | wow, nice |
| 19:53.55 | Maqs | mnemoc: solved the problem. i just compiled u-boot for the cubieboard. dram.c was identical for mk802. |
| 19:54.02 | Marex | slapin: hey, going to ELCE ? |
| 19:54.07 | Marex | anyone else going to ELCE here ? |
| 19:54.10 | Marex | hno: hey ;-) |
| 19:54.22 | hno | Hi Marex |
| 19:54.46 | Marex | hno: I heard Stefan got involved in A10 stuff ... looks like you now have quite a lot of core uboot people involved |
| 19:55.01 | techn_ | mnemoc: pushed |
| 19:55.17 | hno | Yes.. not just need to shuffle the stuff into a form that can be digested on the ml.. |
| 19:55.25 | hno | now just.. |
| 19:55.37 | alcides | http://www.muktware.com/4655/opensuse-running-249-google-chromebook#.UImZHMVcEht |
| 19:55.46 | Maqs | now i'm just curious whether xbmc will work with this kernel or freeze again :-) |
| 19:57.20 | hno | Maqs, freeze kernel or xmbc? |
| 19:57.58 | Maqs | kernel, most likely disp, as xbmc was doing ioctl on /dev/disp |
| 19:57.59 | techn_ | Maqs: ppl are testing it currently.. first impression is good :) |
| 19:59.20 | Maqs | hno: http://dl.dropbox.com/u/11244516/ioctl-freeze.txt |
| 19:59.38 | Maqs | but it seems to have something to do with the kernel config i had |
| 20:00.41 | techn_ | oh.. that one |
| 20:03.24 | Marex | hno: I wonder if you'll cut it for this MW |
| 20:10.58 | techn_ | mnemoc: libv, wip is now merged to main stage.. Ill continue tomorrow |
| 20:11.50 | mnemoc | hno: so if .config is there, oldconfig, else defconfig ? |
| 20:12.40 | mnemoc | Maqs: with that garbage mem info it was expectable to get a crash :) |
| 20:13.20 | mnemoc | techn_: awesome, thanks! |
| 20:13.48 | techn_ | mnemoc: that was the easy part :D |
| 20:13.49 | Maqs | mnemoc: i finally managed to compile a new u-boot that actually works. i just used the cubieboard config. |
| 20:14.19 | libv | techn_: by tomorrow i should have redone the unification. |
| 20:14.40 | techn_ | libv: thanks :D |
| 20:14.41 | libv | that is, as long as my brain holds out |
| 20:16.14 | techn_ | hno: mnemoc: I'd like to add atleast a13_mid board how it should be done? |
| 20:16.59 | techn_ | .. I'm not sure if I have right u-boot dram parameters.. I took them from .fex file |
| 20:17.44 | techn_ | hmm.. hno's wiki had some method to get params to sd-card |
| 20:21.34 | techn_ | ok.. there's guide for this |
| 20:21.51 | Maqs | where does the a10 cpu speed come from? |
| 20:22.23 | Maqs | or better: where do i change it? |
| 20:22.39 | mnemoc | techn_: first the fex to sunxi-boards with verified dram_para |
| 20:22.49 | mnemoc | techn_: from there fexc can generate the dram.c |
| 20:23.15 | mnemoc | Maqs: governator :) |
| 20:24.42 | mnemoc | Maqs: I could add sanity checks to "validate" the atag mem info, but hno would kill me |
| 20:25.10 | Maqs | mnemoc: it works now. i compiled the current u-boot-sunxi for cubieboard |
| 20:26.31 | Maqs | i guess i'll have to compile with CONFIG_CPU_FREQ=y \o/ |
| 20:27.05 | mnemoc | Maqs: yes, was just wondering about the rest of the people who might be affected by the same problem |
| 20:27.27 | drachensun | ok, to get the parameters for a did memory dump in u-boot, was that a dump of nand or ram loaded by boot1? |
| 20:27.42 | drachensun | for a device I mean |
| 20:27.56 | mnemoc | drachensun: the rests of boot1 on dram |
| 20:28.24 | mnemoc | md.b 0x42400000 0x82d0 |
| 20:28.28 | drachensun | is there any chance that stays in memory after android boots and we could pull it then? |
| 20:28.54 | mnemoc | many times it's already zeroed at u-boot time :< |
| 20:28.54 | Maqs | mnemoc: how is the default cpu speed set without it enabled? |
| 20:29.06 | mnemoc | Maqs: u-boot sets it to 1GHz |
| 20:29.10 | drachensun | ok |
| 20:29.15 | *** join/#arm-netbook valhalla_ (~valhalla@78.134.59.22) |
| 20:29.21 | mnemoc | Maqs: recent u-boot I mean |
| 20:29.30 | mnemoc | Maqs: old once used 300MHz iirc |
| 20:29.37 | drachensun | I've got an A13 tablet here I would like to use but I can't find an obvious serial header |
| 20:29.37 | mnemoc | ones* |
| 20:30.27 | drachensun | and I somehow managed to kill an A10 netbook this morning probing what looked like the serial header, so I'm getting a little skiddish |
| 20:30.28 | *** join/#arm-netbook rellla (~yaaic@p4FE56214.dip0.t-ipconnect.de) |
| 20:30.41 | Maqs | mine is at 383.38 bogomips |
| 20:31.17 | *** part/#arm-netbook rellla (~yaaic@p4FE56214.dip0.t-ipconnect.de) |
| 20:31.43 | L84Supper | drachensun, which a10 netbook do you have? |
| 20:31.57 | mnemoc | hno: is the initial cpufreq down to 380MHz now? |
| 20:32.44 | drachensun | it just says "Netbook, 10-TabletPC" |
| 20:32.46 | L84Supper | drachensun, http://hksunlike.com/ maybe this one? |
| 20:33.02 | drachensun | yup |
| 20:33.17 | L84Supper | i have one of the same |
| 20:33.38 | L84Supper | 5 pin 0.1 spacing header pads? |
| 20:33.53 | techn_ | What is currently best JTAG? |
| 20:33.55 | L84Supper | or close to 0.1" |
| 20:34.18 | drachensun | yup |
| 20:34.22 | Maqs | i wouldn't have noticed, but for compiling xbmc it is surprisingly cold :-) |
| 20:34.31 | drachensun | the last pin, square solder mask was tx |
| 20:34.38 | techn_ | 10 years ago.. when I last time used it.. there was only poor clones and really expensive orginal ones |
| 20:34.40 | *** join/#arm-netbook rellla (~Thunderbi@p4FE56214.dip0.t-ipconnect.de) |
| 20:34.49 | drachensun | and it looked like the far 2 from it were ground, and I was getting output |
| 20:35.06 | drachensun | I soldered the wires on and tried again and it wont boot or do anything now |
| 20:35.09 | L84Supper | drachensun, did yours come with a choice of Chinese or Japanese Android? |
| 20:35.33 | drachensun | when I first ran it, it was already set for english |
| 20:35.39 | mnemoc | L84Supper: close tto 0.1" sounds more like 2mm |
| 20:35.57 | L84Supper | drachensun, I took it apart but never probed it for anything |
| 20:36.29 | L84Supper | mnemoc, yes 0.1" is close to 2mm and even closer to 2.54mm :) |
| 20:36.53 | drachensun | I'll let you know if I manage to figure out the pinout and get the parameters off it |
| 20:37.03 | mnemoc | L84Supper: I only mean to say that if 0.1" doesn't fit, it might be 2mm instead |
| 20:37.17 | drachensun | I have another, so I can try again but I was just really suprised it was fried, I can't figure out why |
| 20:37.21 | L84Supper | mnemoc, just kidding |
| 20:38.19 | L84Supper | drachensun, solder bridge maybe? hope you didn't zap it with some ESD |
| 20:38.39 | mnemoc | wow, the cubieboard campaign already reached 30% and he hasn't mailed the people on the notify me list yet |
| 20:39.14 | *** join/#arm-netbook user__ (~user@dynamic-adsl-78-12-178-17.clienti.tiscali.it) |
| 20:39.17 | L84Supper | mnemoc, unlike some other people in here that shall remain nameless, I can actually read mechanical drawings :) |
| 20:39.30 | mnemoc | L84Supper: :D |
| 20:40.20 | L84Supper | did Tom clear up his registration? I hope he'll actually get the kickstarter funds |
| 20:40.35 | debianin | hi all. hi mnemoc :) |
| 20:41.07 | drachensun | I did bridge two of the pins briefly in soldering, I'm still lousy with lead free solder, but they both showed as ground. I should have just clipped the damn battery before I worked on it |
| 20:41.13 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 20:41.22 | mnemoc | L84Supper: he sent all the papers paypal requested this morning. but until he went to sleep like 2h ago it was still blocked |
| 20:41.38 | L84Supper | ah ok |
| 20:52.55 | drachensun | well this A13 seems to have all the ram parameters in its bin file, so thats good maybe I dont need a header after all |
| 20:53.33 | drachensun | L84Supper: Have you used adb with the netbook? |
| 20:54.06 | mnemoc | drachensun: fexc -I bin -I uboot script.bin > dram.c |
| 20:54.22 | mnemoc | err |
| 20:54.26 | mnemoc | -O uboot |
| 20:55.42 | L84Supper | drachensun, I have only power it on and off, taken it apart for pictures and contemplated it's from of destruction :) |
| 20:55.55 | drachensun | lol |
| 20:55.55 | L84Supper | from / form |
| 20:56.30 | drachensun | its got no micro/mini usb so I'm not sure how I'm going to adb to run |
| 20:56.40 | drachensun | I guess I can just download the terminal app and work that way |
| 20:56.56 | L84Supper | I'm much more interested in the ARM Chromebook and possibly expanding it's emmc to 60x the size |
| 20:57.09 | drachensun | mnemoc: I'm just sure what you mean, where do I need to run that? |
| 20:57.45 | mnemoc | drachensun: fexc lives in the same dir as bin2fex/fex2bin |
| 20:57.55 | mnemoc | debianin: it's their ... backend |
| 20:57.57 | mnemoc | err |
| 20:58.15 | drachensun | ok, I thought so, I'm getting invalid out format -- "uboot" |
| 20:58.17 | mnemoc | i should readlly stop typing and go to take a nap :| |
| 20:58.25 | debianin | mnemoc, sorry? |
| 20:58.39 | mnemoc | debianin: my fault. wrong tab completion |
| 20:58.45 | debianin | ok no prob:) |
| 20:58.47 | mnemoc | drachensun: newer |
| 20:58.55 | drachensun | ok |
| 20:59.26 | mnemoc | drachensun: https://github.com/linux-sunxi/sunxi-tools |
| 21:01.17 | drachensun | ah cool so it will just create the file from the bin |
| 21:01.21 | *** join/#arm-netbook rz2k (~rzk@95-25-188-180.broadband.corbina.ru) |
| 21:01.34 | drachensun | and I cant take that straight over to u-boot? |
| 21:01.45 | drachensun | and I can I mean |
| 21:02.44 | mnemoc | almost |
| 21:02.49 | mnemoc | you need to add a "board" |
| 21:03.04 | mnemoc | see https://github.com/linux-sunxi/u-boot-sunxi/commit/7086c9884dc54c2fdbb63e1298db990f5e0636dd as example |
| 21:03.24 | mnemoc | Makefile is identical, board.c only changes the name |
| 21:03.31 | mnemoc | dram.c from fexc |
| 21:03.51 | mnemoc | and the new line in boards.cfg |
| 21:05.34 | mnemoc | assuming the dram_para in your script.bin is good, it should be simple |
| 21:11.39 | mnemoc | once confirmed to work, please mail this patch and the verified .fex |
| 21:12.39 | drachensun | will do, that is usually my trouble is submitting work, its not quite right ;-) |
| 21:13.27 | drachensun | I've actually got a few of these I need to go ahead and setup as proper devices instead of swapping files and rebuilding |
| 21:13.41 | *** join/#arm-netbook arnd (~arnd@HSI-KBW-149-172-5-253.hsi13.kabel-badenwuerttemberg.de) |
| 21:22.59 | *** join/#arm-netbook hp__ (~kvirc@220-136-73-68.dynamic.hinet.net) |
| 21:30.21 | *** join/#arm-netbook mysteryname (~mysteryna@14-202-9-167.tpgi.com.au) |
| 21:30.41 | *** join/#arm-netbook user__ (~user@dynamic-adsl-78-12-149-52.clienti.tiscali.it) |
| 21:41.36 | *** join/#arm-netbook merbzt (~benjamin@c-94-255-220-30.cust.bredband2.com) |
| 21:58.48 | *** join/#arm-netbook user__ (~user@2.230.147.159) |
| 22:05.31 | *** join/#arm-netbook tuliom (~tuliom@177.99.131.107) |
| 22:22.02 | *** join/#arm-netbook orly_owl (~david@unaffiliated/orly-owl/x-3167833) |
| 22:52.11 | *** join/#arm-netbook discopig (~Sv@unaffiliated/sv) |
| 23:09.05 | Turl | did I miss much today? :) |
| 23:09.26 | lundman | wife's birthday, we had cake |
| 23:09.36 | orly_owl | ^^ |
| 23:14.47 | ZaEarl | my atrix 2 just got an ota ICS update! |
| 23:15.10 | ZaEarl | Turl, how's your CM for the Atrix 4G. Looks like it won't be getting an ICS update. |
| 23:20.59 | Turl | ZaEarl: anything higher than gingerbread is gonna be forever broken, unless motorola steps up and gives us some kind of support |
| 23:21.10 | ZaEarl | I was afraid of that. |
| 23:28.27 | ZaEarl | Guess I'll be content with my Atrix 2 being updated. |
| 23:46.58 | L84Supper | http://www.muktware.com/4655/opensuse-running-249-google-chromebook#.UImQ8jtxC50 |
| 23:47.02 | L84Supper | openSUSE Running On $249 Google Chromebook |
| 23:47.23 | L84Supper | https://plus.google.com/u/0/109993695638569781190/posts/b2fazijJppZ |
| 23:48.08 | L84Supper | http://andrew.wafaa.eu/blog/geeko-goes-chrome/ |
| 23:56.08 | libv | good to see that andy is still on top of suse |
| 23:59.26 | *** join/#arm-netbook slash_random (~david@host197.201-252-139.telecom.net.ar) |
