| 00:02.08 | ManoftheSea | This looks like a job for systemd-nspawn |
| 00:20.43 | *** join/#arm-netbook drachensun (~drachensu@142.196.83.182) |
| 00:55.13 | WarheadsSE | ManoftheSea: ? |
| 00:56.32 | WarheadsSE | I can help you with a distcc setup & premade cross chains if you like ManoftheSea |
| 01:12.32 | *** join/#arm-netbook bsdfox_ (~Bob@unaffiliated/bsdfox) |
| 01:16.01 | ManoftheSea | WarheadsSE: thanks, but I have cross-arm gcc from emdebian. |
| 01:16.24 | ManoftheSea | I'm not sure how to configure sunxi-linux/xf86-video-mali on my x64 box to work on my a10 |
| 01:16.39 | ManoftheSea | So, I'm emulating ARM and using the a10 rootfs to build it. |
| 01:17.21 | WarheadsSE | eeeeeeww |
| 01:18.06 | buZz | why not just compile it on the a10? |
| 01:18.37 | WarheadsSE | it doesnt take long |
| 01:19.01 | WarheadsSE | kernel yes, xf86 & needed bits? ~ maybe 15 minutes on a bad day |
| 01:19.12 | WarheadsSE | on a _BAD_ day |
| 01:19.21 | buZz | why do you want xf86-video-mali btw? |
| 01:19.30 | buZz | is it finally faster than straight fbdev? |
| 01:20.55 | ManoftheSea | Hmm, I only got an .la, no .so... |
| 01:21.09 | ManoftheSea | Because I don't have the space for a compile chain on my uSD |
| 01:21.24 | ManoftheSea | dunno. |
| 01:21.37 | ManoftheSea | I don't have any video acceleration. So, this was something I could try. |
| 01:21.38 | buZz | ok just experimenting |
| 01:21.45 | ManoftheSea | I also have no audio across the hdmi. |
| 01:21.56 | ManoftheSea | And, rather than ask a million questions, I was gonna try some things first. |
| 01:22.10 | ManoftheSea | unless you want to hold my hand through it all. |
| 01:23.46 | buZz | hdmi sound on my A10 worked when i first booted it |
| 01:24.16 | buZz | once in linux, i have two alsa devices, one for analog, one for hdmi |
| 01:24.35 | *** join/#arm-netbook stefanro (~stefan@p57B94420.dip.t-dialin.net) |
| 01:24.45 | ManoftheSea | yep, I saw those. |
| 01:26.18 | buZz | and when you play on the second alsa device? |
| 01:26.39 | ManoftheSea | I'll have to try it and confirm, but I thought I tried both. |
| 02:10.15 | ManoftheSea | alsamixer says sun4i-sndhdmi has no controls |
| 02:10.23 | ManoftheSea | buZz: is that right? |
| 02:10.29 | buZz | yes |
| 02:10.32 | buZz | it has no controls |
| 02:15.56 | ManoftheSea | ok, well, now I have static. |
| 02:16.05 | ManoftheSea | Is it because VLC can't decode the MP3? |
| 02:22.33 | ManoftheSea | hmm, quod libet is able to play the mp3. |
| 02:22.49 | ManoftheSea | VLC, Y U NO WORK? |
| 02:23.02 | ManoftheSea | it's stuttery, though. Bleh. |
| 02:23.03 | buZz | no clue, i always use mplayer |
| 02:23.25 | buZz | did you set 'performance' governer? |
| 02:23.32 | ManoftheSea | dunno. Will check. |
| 02:23.44 | ManoftheSea | I know conky was telling me cpu was at .2 GHz |
| 02:23.53 | buZz | yes, thats probably true then |
| 02:23.56 | ManoftheSea | and it typically sits at 60 MHz, with %30 use. |
| 02:24.01 | buZz | it will not play mp3 smooth at 60mhz |
| 02:31.20 | *** join/#arm-netbook slapin_nb (~slapin@host-69-152-66-217.spbmts.ru) |
| 02:40.12 | *** join/#arm-netbook mSquare (~selvan@122.167.81.174) |
| 02:44.20 | *** join/#arm-netbook mSquare1 (~selvan@122.167.81.174) |
| 03:13.12 | ManoftheSea | hmm, okay, so now I've almost got rygel running. |
| 03:13.24 | ManoftheSea | since audio problem seems to have been with vlc. |
| 03:19.03 | ManoftheSea | grumble grumble, no joy. |
| 03:19.23 | ManoftheSea | But now it's issue with rygel, it seems. anyway, thanks buzz for the help. |
| 03:19.31 | *** join/#arm-netbook aholler (~aholler@p57B204BE.dip0.t-ipconnect.de) |
| 03:35.27 | Sv | :) |
| 03:37.17 | *** join/#arm-netbook mSquare (~selvan@122.167.83.70) |
| 03:51.15 | buZz | your welcome ;) |
| 04:01.57 | *** join/#arm-netbook mSquare (~selvan@122.172.194.230) |
| 04:17.49 | *** join/#arm-netbook Jef91 (~Instantbi@bodhilinux/team/Jef91) |
| 04:32.47 | *** join/#arm-netbook L84Supper (~Larch@unaffiliated/l84supper) |
| 04:32.48 | *** join/#arm-netbook aholler_ (~aholler@p57B202FE.dip0.t-ipconnect.de) |
| 05:01.00 | *** join/#arm-netbook mSquare (~selvan@122.167.96.114) |
| 05:30.05 | *** join/#arm-netbook mSquare1 (~selvan@122.166.182.220) |
| 05:36.07 | *** join/#arm-netbook mSquare (~selvan@122.172.224.154) |
| 05:44.57 | *** join/#arm-netbook mSquare (~selvan@122.172.198.30) |
| 05:47.39 | *** join/#arm-netbook mSquare1 (~selvan@122.167.225.249) |
| 05:51.01 | *** join/#arm-netbook jquip (~johnny@223.232.26.18) |
| 06:30.49 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 06:53.12 | *** join/#arm-netbook Quarx (~Quarx@94.137.12.144) |
| 07:14.49 | *** join/#arm-netbook mSquare (~selvan@122.167.230.167) |
| 07:48.00 | *** join/#arm-netbook rellla (~rellla@p5B07817F.dip0.t-ipconnect.de) |
| 08:08.44 | *** join/#arm-netbook mSquare (~selvan@122.178.197.243) |
| 08:17.51 | *** join/#arm-netbook Quarx (~Quarx@94.137.12.144) |
| 08:18.08 | *** join/#arm-netbook Quarx (~Quarx@94.137.12.144) |
| 08:23.48 | *** join/#arm-netbook mSquare1 (~selvan@122.178.228.41) |
| 08:55.50 | *** join/#arm-netbook Yaku (~Yaku@c213-100-205-158.cust.tele2.se) |
| 09:01.16 | *** join/#arm-netbook pcat (~cat@188.238.190.129) |
| 09:06.21 | *** join/#arm-netbook xxiao (~xxiao@li41-126.members.linode.com) |
| 09:09.52 | *** join/#arm-netbook robws (~robws1@38.99.170.111) |
| 09:17.40 | *** join/#arm-netbook pwhalen (~paul@CPE001310360dac-CM78cd8ec9e405.cpe.net.cable.rogers.com) |
| 09:20.23 | *** join/#arm-netbook pcat (~cat@37-136-222-233.nat.bb.dnainternet.fi) |
| 09:28.46 | *** join/#arm-netbook mSquare (~selvan@122.178.207.134) |
| 09:33.55 | *** join/#arm-netbook tinti (~tinti@201.62.162.119) |
| 09:44.37 | *** join/#arm-netbook jquip (~johnny@sentry.hbcse.tifr.res.in) |
| 10:17.31 | *** join/#arm-netbook jquip (~johnny@sentry.hbcse.tifr.res.in) |
| 10:22.54 | *** join/#arm-netbook jquip (~johnny@sentry.hbcse.tifr.res.in) |
| 10:30.08 | *** join/#arm-netbook jquip (~johnny@sentry.hbcse.tifr.res.in) |
| 10:31.24 | *** join/#arm-netbook tinti_ (~tinti@maxtrack-F4-0-3-gacc04.bhe.embratel.net.br) |
| 10:36.34 | jinzo | so what's the status around cubieboard avability? I see it is listed in the shop again? |
| 10:44.55 | hramrach | jinzo: some are available |
| 10:45.21 | hramrach | there was like 2k manufactured and like 1.5k shipped in the last batch iirc |
| 10:45.53 | jinzo | so the indegogo batch was shipped already? |
| 10:46.09 | hramrach | yes, those are shipped already |
| 10:46.52 | hramrach | the express shipped already arrived the post shipped are somewhere in transport |
| 10:47.29 | jinzo | oh goodie. |
| 11:08.47 | *** join/#arm-netbook jquip (~johnny@sentry.hbcse.tifr.res.in) |
| 11:20.14 | *** join/#arm-netbook rellla2 (~rellla@p5B0781EE.dip0.t-ipconnect.de) |
| 11:21.59 | rm | you sure about that? <hramrach> yes, those are shipped already |
| 11:22.11 | rm | if that would be the case, people would receive tracking numbers |
| 11:22.57 | rellla2 | i have confirmed my address, but not received a tracking number yet. standard shipping. |
| 11:23.20 | rm | jinzo, if you mean the aliexpress shop, then it's only a preorder, it says "Ships out within 45 days" there |
| 11:33.39 | *** join/#arm-netbook jquip (~johnny@sentry.hbcse.tifr.res.in) |
| 11:49.32 | jinzo | hm interesting |
| 12:17.53 | mnemoc | rm: hipboi mails tend to end on people's spam box |
| 12:17.59 | mnemoc | easy to miss |
| 12:18.21 | hramrach | rm: maybe they are still working on the standard shipping packages. those were to go in shipping after the priority shippng packages |
| 12:18.30 | hramrach | spam box may be another reason |
| 12:18.57 | hramrach | and longer time to obtain tracking numbers from the post another |
| 12:21.48 | jinzo | the whole cubieboard project could really benefit from an English speaking person that could do the PR (stuff has been shipped, etc), and a proper mail system (there're a lot, albeit payable e-mail services that are designed for souch things) |
| 12:22.30 | jinzo | but, that's the case with most of the Chinese based projects |
| 12:23.34 | mnemoc | in the cubieboard's case all falls on tom' shoulders |
| 12:24.38 | mnemoc | as the rest of the team doesn't speaking english at all or fear too much to sound stupid talking it |
| 12:25.00 | jinzo | and they all seem quite busy |
| 12:26.15 | Quarx | mnemoc: hello, sunxi-3.4 is ready for android? |
| 12:27.05 | mnemoc | Quarx: 3.4 is still incomplete (compared to 3.0), but it is an android kernel |
| 12:27.30 | mnemoc | jinzo: also need to consider it's not their day job |
| 12:28.26 | jinzo | indeed - but didn't tom say it'll be his at least? |
| 12:28.38 | mnemoc | it will |
| 12:29.02 | mnemoc | but he still needs to freelance to feed his family and pay the bills |
| 12:29.30 | jinzo | makes sense indeed. |
| 12:31.16 | mnemoc | hope he can live from his boards/shop soon :) |
| 12:32.01 | jinzo | isn't shop operated by one of his friends or something like that? |
| 12:32.09 | jinzo | but yes, hopefully he'll succeed |
| 12:33.07 | jinzo | on the other hand, I think that the cubieboard future (eg. new boards) are quite a lot depended on Allwinner releasing some source/open source support |
| 12:36.36 | mnemoc | the aliexpress shop is operated by one of his friends in shenzhen, because the post service in his province has different rules |
| 12:37.04 | rellla | is tom still staying in contact with allwinner's software-devs? at least he is a vendor of their product?! imho i'll be the only way to do a step forward... |
| 12:37.36 | rellla | s/i'll/it will/ |
| 12:37.42 | mnemoc | rellla: yes, he has friends/partners inside allwinner walls |
| 12:37.56 | mnemoc | but that doesn't mean they can leak stuff |
| 12:38.42 | mnemoc | and now allwinnertech's site lists the cubieboard and the olinuxino in a devkit section |
| 12:39.05 | rellla | i'm not talking about leaking ;-) most important thing is to have someone, where you can talk to inside. |
| 12:39.32 | RaYmAn | Now that cheap chinese i.mx6q devices are out, it'd be kind of awesome with a cubie6q! :> |
| 12:39.51 | RaYmAn | I know, unlikely, but :) |
| 12:40.11 | mnemoc | let the wand people ship :p |
| 12:40.54 | RaYmAn | they are only dual-core/lite variants |
| 12:45.11 | RaYmAn | mnemoc: after working with tegra, and allwinner a10, It's just insane to see how open and well documented freescale is :P |
| 12:48.35 | mnemoc | :D |
| 12:49.07 | RaYmAn | also, I think this might be why they wanted to get rid of the a10 sticks: http://dx.com/l/consumer-electronics/2012-12/mini-pc.aspx?utm_source=dx&utm_medium=cdn&utm_campaign=h004minipc |
| 12:49.17 | RaYmAn | that's a lot of different sticks with dual and quad core cpus :P |
| 12:50.13 | mnemoc | the quad-core term is overrated... |
| 12:50.40 | mnemoc | people forgets about the diff between quad-a9, quad-a5, quad-a7 and quad-a15 |
| 12:50.48 | mnemoc | only "quad" matters |
| 12:52.41 | mnemoc | most of those "quad core" sticks are a5 |
| 12:53.24 | mnemoc | but yes, cortex-a8 is obsolete in that market |
| 12:55.26 | mnemoc | i trust the wand people will add a quad and populate the sata connector before going into production |
| 13:09.28 | *** join/#arm-netbook Avernos (~avernos@221.223.232.98) |
| 13:09.28 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 13:24.52 | *** join/#arm-netbook eebrah (~chatzilla@212.49.88.105) |
| 13:33.17 | *** join/#arm-netbook Jef91 (~Instantbi@bodhilinux/team/Jef91) |
| 13:35.26 | RaYmAn | mnemoc: most of the actual quad core sticks around now are freescale. Which is quad a9 at around 1ghz, + quad gpu vivante gc2000 |
| 13:38.21 | rellla | Rayman: so it would be better to begin investing in freescale than in allwinner due to better open sources and allwinner's dead end? |
| 13:41.17 | rellla | RaYmAn: ^ - case sensitivity ;-) |
| 13:43.45 | RaYmAn | freescale devices are also a bit more expensive though |
| 13:43.51 | RaYmAn | but open source wise, they are miles ahead. |
| 13:44.21 | RaYmAn | i.mx6 is in mainline, or at least arm-soc so it will be soon. By freescale engineers :P |
| 13:44.36 | RaYmAn | mind you, I don't actually have any freescale dev-type devices |
| 13:44.40 | RaYmAn | so I have limited info |
| 13:45.07 | jinzo | rellla, there's a little known about next gen allwinner products. Maybe they'll open source their shit :D |
| 13:46.06 | jinzo | I wonder what's the Vivante GPU situation like, they boast X11 support |
| 13:46.12 | mnemoc | RaYmAn: i'm still pondering about getting that hi802/8GB for $99.... but I have zero use for it :| |
| 13:46.13 | rellla | i.mx6 just started to flood from ali.. and dx imho - that's the space allwinner is ahead. |
| 13:47.19 | rellla | jinzo: i'm hoping for progress. ordered another 2 uhost-devices :-) |
| 13:47.34 | mnemoc | rellla: the $20 deal? |
| 13:47.42 | mnemoc | that's hard to resist |
| 13:47.47 | RaYmAn | mnemoc: yeah :P me too. If only to play with the platform |
| 13:48.05 | jinzo | indeed. but they're sold out now. |
| 13:48.06 | rellla | mnemoc: yep. but not sure, if really allwinner is inside... |
| 13:48.44 | rellla | otherwise i'll have some rockchip-device, too \o/ |
| 13:49.39 | RaYmAn | for 20$, won't matter much :P |
| 13:50.40 | rellla | 32€ |
| 13:51.03 | tTTttt | is the encrypt_para section in script.bin related to crypto engine? |
| 13:51.57 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 13:53.59 | tTTttt | https://github.com/linux-sunxi/sunxi-boards/blob/master/sys_config/a13/a13_mid.fex |
| 13:54.22 | tTTttt | there is also encrypt.ko module in factory firmware |
| 13:55.13 | RaYmAn | mnemoc: the thing stopping me is that a odroid u2 costs almost the same :P |
| 13:56.17 | RaYmAn | though, freescale is more open source friendly |
| 13:56.43 | jinzo | exynos is mainline too afaik |
| 13:56.52 | jinzo | so - they're somewhere there |
| 13:57.07 | RaYmAn | yeah |
| 13:57.20 | mnemoc | tTTttt: REing time :) |
| 13:58.07 | tTTttt | trying to load that module hangs insmod, but says that it detects 'chip encrypt' at the address set in script.bin |
| 13:58.10 | tTTttt | http://pastebin.com/raw.php?i=Xh21ugYS |
| 13:58.24 | tTTttt | then spams errors forever |
| 13:58.32 | mnemoc | tTTttt: the GPS controller is on a similar state. we have a gpl-violating gps.ko and some "hints" in an script.fex file |
| 13:59.25 | tTTttt | but how can a crypto accelerator be communicated by twi? shouldn't it map memory directly somehow? |
| 13:59.45 | tTTttt | or is twi virtual, and the twi controller itself is a crypto engine? |
| 14:00.23 | mnemoc | many controllers within the A10 need a companion chip |
| 14:00.47 | mnemoc | well... not many. but wemac and gps do |
| 14:00.58 | mnemoc | it might also be the case of the crypto engine |
| 14:01.15 | mnemoc | or it's a totally unrelated chip |
| 14:01.35 | mnemoc | like all the TS drivers we have |
| 14:01.38 | hramrach | everyone boasts X11 support |
| 14:01.48 | hramrach | but you never know until you get teh device |
| 14:02.17 | mnemoc | that's part of the fun ;-) |
| 14:02.31 | hramrach | I prefer Mali based devices because there is more than one chip manufacturer using those |
| 14:02.40 | *** join/#arm-netbook ganbold_ (~Ganbold@202.21.108.58) |
| 14:03.03 | hramrach | so it's more likely stay around and morelikely the driver get usable over time |
| 14:03.12 | tTTttt | kernel module itself looks like a modification of mma7660.ko module provided in the same firmware |
| 14:04.13 | tTTttt | and mma7660 itself is a accelerometer, not a crypto engine |
| 14:04.17 | hramrach | but if somebody has a board with working X11 I would like to hear |
| 14:05.38 | mnemoc | sun4i/sun5i devices run X11/fb fine. 3d acceleration is less "out of the box" but mostly works too |
| 14:05.56 | mnemoc | 2d acceleration is pending |
| 14:06.17 | mnemoc | ssvb is working on some drivers to improve the xorg experience |
| 14:07.05 | hramrach | I don't really care about 2d accel |
| 14:07.13 | hramrach | you have glamour these days |
| 14:07.25 | RaYmAn | hramrach: supposedly freescale boards has fully working acceleration. But I don't have one yet. |
| 14:07.54 | hramrach | but accel is clearly required. shadowfb is unlikely to fly on something that rund the cpu on 60MHz by default |
| 14:09.29 | hramrach | if lima worked out somehow that would be great |
| 14:09.52 | libv | lima will never cover for what shadowfb does. |
| 14:10.12 | hramrach | why would it not? |
| 14:10.22 | libv | the mali is not a 2d engine/blitter |
| 14:10.25 | hramrach | shadowfb is workaround for lack of GPU (support) |
| 14:10.33 | hramrach | you don't need one |
| 14:10.38 | hramrach | 3d can blit all right |
| 14:10.48 | libv | yes, very expensively |
| 14:10.58 | libv | often more expensive than the cpu |
| 14:11.12 | hramrach | yes and no |
| 14:11.44 | hramrach | if you go the shadowfb route then you have the fb in linar structure and blitting on CPU is easy |
| 14:11.59 | hramrach | but the CPU can't do other stuff then because it is blitting |
| 14:12.31 | hramrach | if you go the glamour route then the fb is possibly organized in some baroque tiles |
| 14:12.40 | hramrach | so blitting on cpu is very expensive |
| 14:13.04 | libv | i have not seen this on telechips, amlogic or allwinner |
| 14:13.06 | hramrach | blitting on gpu may take longer than on CPU but it frees the CPU |
| 14:13.24 | hramrach | also it's hard to tell when you have no driver to test with |
| 14:14.02 | libv | and on the n9, using pvr2d over the cpu really hit us bad in several cases |
| 14:14.47 | libv | on allwinner we have g2d, which should be used but isn't used today |
| 14:16.00 | hramrach | the hit for mixing GPU and CPU operation is also that you have to set up synchronization so the CPU and GPU agree on the state of the memory |
| 14:16.17 | mnemoc | libv: hi. did you have time to look at hdmi/edid changes in stage/sunxi-3.x and/or ssvb patches on the ml? :) |
| 14:16.19 | hramrach | so if you want any 3d at all it's cheaper to do everything on th GPU in post cases |
| 14:16.29 | hramrach | *most |
| 14:16.43 | libv | mnemoc: not really, fosdem is nearing, and i still have some way to go to get q3a working on top of lima. |
| 14:17.06 | mnemoc | libv: new videos? :) |
| 14:17.18 | hramrach | lima is workable? |
| 14:17.40 | libv | mnemoc: around fosdem timeframe, yes |
| 14:17.44 | *** join/#arm-netbook eebrah (~chatzilla@212.49.88.99) |
| 14:17.53 | mnemoc | libv: :) |
| 14:19.50 | libv | i have some single frame gles1 dumps that replay correctly already, and i have a handle on what is going on in the back as well, but that does not mean that i am home free on this goal yet |
| 14:20.36 | *** join/#arm-netbook datagutt (~datagutt@unaffiliated/datagutt) |
| 14:25.17 | libv | hramrach: i now know how to blit relatively cheaply on mali, and it is magnitudes more efficient than doing so on pvr, but g2d will still beat it both in ease of use, speed and power consumption. |
| 14:26.48 | libv | hramrach: i had hoped that we finally did dispell "we do not need $good_idea, as we can do it all on the gpu"-myth |
| 14:26.56 | *** join/#arm-netbook DEAT_ (~heh@14-201-99-152.tpgi.com.au) |
| 14:26.57 | hramrach | I wonder how g2d and mali will mix together if/when both are available and supported |
| 14:27.05 | libv | ati r600 was such a mess. |
| 14:27.37 | hramrach | it still is a mess |
| 14:27.44 | libv | no overlays, no usable dma engine or blitter... |
| 14:27.51 | libv | even imagination has caught on now |
| 14:28.06 | libv | rogue should come with its own blitter. |
| 14:28.08 | hno | slapin, not available until monday from what it looks. |
| 14:28.57 | hramrach | there is some problem with the dma engine on r600 but don't remember what |
| 14:29.49 | hramrach | anyway, if the gpu can do it and it's the cheapest way there is now it should |
| 14:30.03 | hramrach | if g2d turns out better it's cool |
| 14:30.46 | libv | designed for what microsoft said would ship in windows 7, which it later on dropped, and it ended up being silicon that was partly untested and partly highly IP encumbered |
| 14:31.03 | libv | at least this was the excuses that ati made for not giving us the info back in 2007 |
| 14:31.14 | libv | but that was just the dma engine |
| 14:31.35 | libv | all normal 2d operations were emulated on the shaders by microcode |
| 14:31.37 | hramrach | the IP encumberance is somewhat *the* problem in graphics |
| 14:32.16 | hramrach | doing 2d on shaders does not sound that bad |
| 14:32.24 | hramrach | you have the shaders anyway |
| 14:32.26 | libv | in any case: overlays are back, 2d engines are back, media engines are back |
| 14:32.39 | libv | shaders require context switches and stuff |
| 14:32.46 | libv | expensive. |
| 14:33.22 | hramrach | radeons do have media engines |
| 14:33.40 | hramrach | but they are unusable due to IP encumberance :> |
| 14:33.43 | libv | r600 famously did not. |
| 14:33.56 | libv | untested silicon |
| 14:34.01 | libv | dead silicon |
| 14:34.05 | hramrach | heh |
| 14:34.23 | libv | which they had to own up to on the day after the big press release |
| 14:34.33 | libv | r600 also has overlays |
| 14:35.01 | libv | but... they only supported rgb colour spaces, so they were not very useful |
| 14:35.08 | libv | and they were most likely not tested |
| 14:36.26 | libv | hramrach: in case you are wondering, i was at SuSE at the time, and i was the co-author for the "freeing ati proposal" to AMD, and egbert eich, matthias hopf and i did get to free ATI |
| 14:39.13 | *** join/#arm-netbook Quarx (~Quarx@94.137.12.144) |
| 14:40.58 | mnemoc | libv: what's your plan after fosdem? |
| 14:41.15 | *** join/#arm-netbook Yaku (~Yaku@c213-100-205-158.cust.tele2.se) |
| 14:41.48 | libv | not sure yet, i should start poking at mesa to see whether it will allow using an external compiler |
| 14:42.18 | libv | when i have q3a running, all major questions have been answered, so it is about time to start writing an actual driver. |
| 14:43.09 | libv | will be fun to see q3a later on run on top of mesa on the same hw, methinks that it will not be a favourable comparison :) |
| 14:43.19 | Yaku | why does mxplayer have hw support on almost all devices, do they have insider info´s that are simply not availible to anyone else ? |
| 14:43.41 | mnemoc | libv: :) |
| 14:44.14 | mnemoc | Yaku: android provides a layer of hw acceleration to all players |
| 14:44.31 | mnemoc | Yaku: they only add the UI |
| 14:44.51 | oliv3r | Im secretivily hopeing hipboi hasn't shipped my melee A1000g yet, and i can wait for a super A1000g with an A20 ;p |
| 14:45.17 | mnemoc | oliv3r: he isn't listing them anymore |
| 14:45.32 | mnemoc | not sure what's his plan regarding mele-reselling |
| 14:46.23 | Yaku | oh i thought the a1000g a2000g have an a13 |
| 14:49.14 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 15:05.54 | oliv3r | jinzo: the mail system is just fine thank you :p i think it ends up in spam boxes due to content? Though a payed mail service could be whitelisted by things like gmail more easily. |
| 15:06.23 | mnemoc | Yaku: no, they are the same as before but with 1GB of RAM and more NAND |
| 15:07.54 | RaYmAn | mailchimp.com even lets you send 12k emails pr month for free |
| 15:10.51 | mnemoc | but to an small set of addresses |
| 15:11.15 | RaYmAn | s/mailchimp.com/mandrill.com/ |
| 15:11.27 | RaYmAn | arg, mandrillapp.com |
| 15:11.41 | RaYmAn | they have a really nice api and stuff |
| 15:11.43 | mnemoc | tom tried mailchimp for the initial notify-me list.... the free quota of subscribers got filled in a week |
| 15:11.53 | RaYmAn | yeah, mandrill doesn't have subscribers |
| 15:12.02 | RaYmAn | it just has recipients |
| 15:12.16 | RaYmAn | so you need to maintain list elsewhere |
| 15:12.25 | mnemoc | neither a page describing the product :| |
| 15:12.27 | RaYmAn | but then you can just send through them and they add trust and stuff |
| 15:12.33 | RaYmAn | they have a really nice json api |
| 15:12.40 | mnemoc | https://mandrillapp.com send me directly to the login page |
| 15:12.49 | RaYmAn | (and let you send through smtp as well) |
| 15:13.01 | mnemoc | ok https://mandrill.com/ |
| 15:13.02 | RaYmAn | ah |
| 15:13.05 | RaYmAn | I guess it was that then |
| 15:13.06 | RaYmAn | lol |
| 15:13.48 | mnemoc | i think he is going to use shopify. don't know if they offset spam lists too |
| 15:13.58 | mnemoc | s/offset/offer/ |
| 15:14.22 | mnemoc | RaYmAn: nice thing this mandrill |
| 15:14.26 | RaYmAn | very much so :) |
| 15:14.28 | mnemoc | didn't know it |
| 15:14.30 | oliv3r | mnemoc: well He was supposed to send me one, but payment is going stupid, and i did e-mail him, but he still hasn't replied yet. twice i think |
| 15:14.46 | RaYmAn | also given you can just setup smtp through that and they add trust automatically etc |
| 15:15.40 | oliv3r | it's stupid that I need a third party to 'add trust' |
| 15:15.50 | oliv3r | stupid stupid stupid :S |
| 15:15.59 | RaYmAn | it probably has something to do with the insane amount of spam being sent :P |
| 15:16.04 | mnemoc | oliv3r: it seems he left civilization. he tends to be always-on on android/gtalk but not currently |
| 15:16.09 | ssvb | libv: g2d is slightly (?) misdesigned and can't support premultiplied alpha, it means that OVER compositing operation need to be emulated in several passes and/or done in some really roundabout ways |
| 15:16.40 | oliv3r | mnemoc: hopefully he'll be back after chinese new year :) |
| 15:16.53 | mnemoc | ssvb: how's your neon-fu? ;-) |
| 15:17.22 | mnemoc | oliv3r: nah... the new year holidays are in like over a month |
| 15:17.23 | ssvb | libv: some operations are not supported by g2d at all, which means mixing g2d and cpu rendering is unavoidable - we need to have a design which minimizes performance hit on such switches |
| 15:18.05 | ssvb | libv: if mali is more versatile, then it may potentially beat g2d for 2d graphics |
| 15:18.54 | ssvb | libv: or we may want to be able to have a mix of g2d/mali/cpu rendering in the end |
| 15:19.45 | mnemoc | ssvb: the problem is in the current g2d driver on the mixer processor itself? |
| 15:20.22 | mnemoc | +or |
| 15:20.23 | ssvb | mnemoc: the current g2d driver is not usable for anything practical for sure |
| 15:20.31 | libv | ssvb: due to the way the mali is designed, and how the mali kernel works, mixing should be easy |
| 15:23.42 | libv | as said, it's a much much better situation than on powervr, but the gpu is not the most efficient way to handle these things, both in codesize, cpu overhead and power consumption. |
| 15:24.52 | ssvb | mnemoc: the mixer processor hardware does not support all the needed operations, so it's not a perfect solution, but still should be useful |
| 15:25.41 | hramrach | libv: I heard today nVidia is more free than ati |
| 15:25.58 | mnemoc | even if it's only to move the mouse pointer it should be notizable |
| 15:26.07 | libv | hramrach: first off s/ati/amd/ |
| 15:26.23 | hramrach | because nVidia refused to cooperate all the stuff was reverse-engineered. no AtomBIOS, no firmware now |
| 15:27.00 | hramrach | because AMD/ATI cooperates somewhat there is somewhat working driver with somewhat documented blob inside |
| 15:27.19 | libv | hramrach: secondly, you have to distinguish between amd and the former ati (which probably still is not integrated properly -- signs are that the original amd is losing ground on the former ati) |
| 15:27.34 | ssvb | hramrach: "if somebody has a board with working X11 I would like to hear" - by working X11 do you mean XRENDER acceleration for 2D? |
| 15:27.35 | libv | and you also have to distinguish between the desktop nvidia and tegra |
| 15:27.52 | libv | they are also different entities in the same company |
| 15:28.38 | hramrach | not much different. in term sof opensource. cooperation is exactly zero |
| 15:29.06 | libv | i was under the impression that the tegra people were opening up more and more |
| 15:29.15 | hramrach | tegra does not work. it will if/when somebody makes a driver without any info from nVidia. nouveau is that for desktop |
| 15:29.40 | libv | as for atombios... iirc nvidia has fuc to achieve the same |
| 15:29.42 | hramrach | maybe they are. but tegra2 is noway near working |
| 15:30.07 | hramrach | nVidia does. nouveau does not. where would they get it? |
| 15:30.28 | libv | ati, with the help of redhat and some "community members", has nicely killed my work on reducing atombios dependance for the common and simple things like modesetting |
| 15:30.39 | ssvb | mnemoc: about your neon question, most of the 2d graphics operations are already done with neon for software rendering, but of course there is always some room for improvement |
| 15:30.40 | libv | the nouveau guys are creating their own fucs |
| 15:31.02 | hramrach | with the result that modesetting fails on ati hardware |
| 15:31.13 | hramrach | it's 100% working on all the board devs have |
| 15:31.27 | hramrach | it's 100% broken on all the board I have |
| 15:31.38 | libv | none of the bigmouths on ati are even attempting to even work with atombios or hacking it |
| 15:31.53 | libv | hey, i gave two years of my life trying to correct the bs |
| 15:32.07 | libv | talk to the idiots who went and killed a proper open source driver |
| 15:32.07 | hramrach | :s |
| 15:32.37 | libv | airlied, ajax, daniels, ... in the end pretty much the whole in-crowd of X.org |
| 15:33.00 | jelly-home | libv: you mean video-radeonhd? |
| 15:33.03 | libv | they happily sided with ATI just so they could try to get the glory of freeing ati |
| 15:33.09 | hramrach | they maybe thought that working with ati would get a driver done |
| 15:33.31 | libv | they worked against amd, against free software, against long term supportable graphics drivers, against preloaded laptops without fglrx |
| 15:33.36 | hramrach | they get some inside info |
| 15:33.47 | hramrach | and they trade it for making hte driver forever broken |
| 15:34.00 | libv | hramrach: they got info we at suse were sometimes asking for but never got |
| 15:34.13 | libv | hramrach: and we were contractually tied with amd on delivering |
| 15:34.37 | hramrach | soo nice |
| 15:34.38 | libv | but some ati elements happily informed the other side just to kill us off |
| 15:35.04 | libv | because we were the ones that pushed ati open, ati killed us off later on that way |
| 15:35.11 | libv | and the idiots went along with it |
| 15:36.51 | hramrach | there is nothing to say. everyone can see where radeon is now and where nouveau is |
| 15:37.02 | ssvb | hramrach: btw, you mentioned glamor, but it gets beaten by software rendering at the moment - https://ickle.wordpress.com/2012/12/30/sandybridge-acceleration/ |
| 15:37.10 | hramrach | I looked at some of the radeon code :s |
| 15:37.31 | libv | my gfs laptop died, so i got a cheap hp (as a lot of my friends still work at suse and do preloads on hp) |
| 15:37.43 | libv | we got a cheapo 15.6"er with SLED preinstalled |
| 15:37.51 | libv | _with_ fglrx |
| 15:38.04 | libv | as radeon is just a bringup and support nightmare |
| 15:38.23 | hramrach | so is fglrx |
| 15:38.31 | libv | not as bad as radeon |
| 15:38.33 | hramrach | but you can blame on amd then |
| 15:38.43 | hramrach | it's bad in different ways |
| 15:38.46 | libv | this is exactly what we set out to fix when we proposed to free ati to amd |
| 15:38.54 | libv | amd has its own set of troubles |
| 15:38.59 | libv | ati now runs the show inside amd |
| 15:39.12 | libv | and we were first used as the crowbar to push this bad acquisition open |
| 15:39.33 | libv | later on we were partly victimized when amd lost control completely in the 2008 financial crisis |
| 15:39.36 | ssvb | hramrach: but AMD/ATI at least did manage to get EXA acceleration working slower than glamor, so glamor may be perceived as an improvement :) |
| 15:40.46 | ssvb | hramrach: anyway, looks like you are not interested in the subject |
| 15:40.47 | libv | but what pisses me off the most is the role some noisy X.org people played, and that those very same people still make big statements today, despite their radeon work representing a massive intelectual sell-out |
| 15:41.50 | libv | if it wasn't for my lima work these days, people would still blame me for being evil novell and trying to corrupt the freeing of ati |
| 15:42.04 | hramrach | ssvb: the problem with sw accel on desktop is that if you want to do sw accel and 3d you will have to do some expensive buffer migration |
| 15:42.36 | hramrach | so even if glamour is slower in microbenchmark it can possibly get better overall performance - or not |
| 15:42.48 | hramrach | depending on how slower it is and what else you use |
| 15:42.59 | ssvb | hramrach: libv said that modern ATI hardware supports overlays, so you may have a chance keeping 2d and 3d cleanly separated |
| 15:43.17 | libv | popular notion on radeonhd is exactly opposite of the facts |
| 15:43.25 | hramrach | the number of overlays is limited |
| 15:43.37 | libv | one per crtc |
| 15:43.54 | hramrach | so you can't expect to make every 3D application and overlay |
| 15:44.03 | libv | and there is no 2d engine left on the generations of hw i worked on |
| 15:44.16 | libv | not sure whether this got fixed for r700, it might've been |
| 15:44.18 | ssvb | hramrach: microbenchmark what? the only relevant benchmark is recording and replaying what real applications do, and that's cairo-perf-trace for you |
| 15:44.56 | libv | err, r800 and later, when the naming changed |
| 15:45.02 | ssvb | hramrach: glamor and exa are slower than software rendering on a lot of real use cases |
| 15:45.22 | hramrach | indeed, they are. |
| 15:45.53 | hramrach | the problem they are trying to solve (and poorly at this time) is that |
| 15:46.09 | hramrach | 1) software rendering takes the CPU from other workloads |
| 15:46.37 | ssvb | hramrach: 1) you have a lot of freaking cpu cores nowadays |
| 15:46.47 | hramrach | 2) for software rendering the buffer has to be migrated so that CPU can access, and if GPU rendering is attempted lateer it has to be migrated back |
| 15:46.55 | libv | i think chris wilsons sna might finally bring intel 2d accel performance bettering xaa |
| 15:46.57 | ssvb | 2) overlays |
| 15:46.59 | hramrach | ssvb: not on every system. |
| 15:47.19 | hramrach | overlays do not solve 2 |
| 15:47.30 | hramrach | you have exactly 1 |
| 15:47.38 | libv | exa performance only became acceptable when anholt crippled xaa, and when xaa was actively deprecated |
| 15:47.39 | ssvb | hramrach: on *all* modern systems, and the number of cpu cores will be increasing |
| 15:47.40 | hramrach | it's _very_ rare resource |
| 15:47.58 | hramrach | no, modern netbook ahs two underpowered cores |
| 15:48.12 | hramrach | not all modern systems are meant to replace your heating |
| 15:49.06 | hramrach | also even with truckload of freaking cores you can *still* havesoftware that uses them |
| 15:49.39 | ssvb | and modern atom netbooks have hyperthreading, which is good for 2d graphics in theory (when one hardware thread is memory bandwidth bound, the other hardware thread can still do something) |
| 15:51.11 | hramrach | libv: that's one of the most glaring problem in X |
| 15:51.25 | ssvb | hramrach: about overlays, I'm currently trying to prove you wrong with the ddx driver for allwinner a10 hardware :) |
| 15:51.31 | hramrach | for backwards compatibility you have to jump through hoops in so many places |
| 15:52.28 | hramrach | ssvb: how do you combine N applications rendering in software and M applications rendering with GPU with 1 overlay? |
| 15:53.30 | hramrach | also some applications would like to use the oveerlay themselves. well, since the modern ati drivers don't support them any way they have to do without |
| 15:53.51 | ssvb | hramrach: one most demanding application gets an overlay for GPU, the others just run slower |
| 15:56.28 | hramrach | since A10 is not powerful enough to run multiple applications anyway it might work out well |
| 15:56.48 | ssvb | hramrach: it seems to work really well in my preliminary tests (though allwinner a10 has more than one extra overlay, but I'm initially testing the code with only one) |
| 15:57.14 | hramrach | cool |
| 15:58.51 | tTTttt | what does it mean that buffer has to be migrated? |
| 16:00.19 | tTTttt | is the buffer the size of cpu cache? |
| 16:00.30 | ssvb | tTTttt: yes, we need to switch between using on overlay and buffer copies depending on windows stacking and layout |
| 16:00.52 | ssvb | tTTttt: that's the thing I'm trying to get right at the moment |
| 16:01.39 | tTTttt | how big exactly is that cache? |
| 16:02.11 | ssvb | tTTttt: A10 has only 256K of L2 cache |
| 16:02.54 | tTTttt | and it's such big problem to flush it? |
| 16:03.10 | ssvb | but how is it relevant? the caches are not shared between cpu and mali |
| 16:03.46 | tTTttt | but physical memory is |
| 16:04.20 | *** join/#arm-netbook ganbold_ (~Ganbold@202.21.108.58) |
| 16:05.30 | ssvb | if overlay is used, flushing caches is not necessary, because mixing cpu with gpu rendered data is done by the display controller |
| 16:07.50 | hramrach | tTTttt: that's the problem. not only have you to flush the cache. You have to turn it off so that when the ther *PU is finished rendering you get the data from the shared RAM and not the cache. or you have t ophysically move the buffer if the RAM is not shared. |
| 16:09.02 | tTTttt | and there is no more direct way of communicating cpu with gpu? |
| 16:10.01 | ssvb | hramrach: the discrete desktop gpu accelerators surely have it tough because of slow pci express bus |
| 16:10.03 | hramrach | the cache is separate. So only one can have stuff cached. What else can you do |
| 16:10.24 | tTTttt | control cache meybe |
| 16:10.40 | ssvb | hramrach: integrated intel graphics and embedded systems have a lot less problems :) |
| 16:10.51 | *** join/#arm-netbook rellla (~Thunderbi@p4FE564EF.dip0.t-ipconnect.de) |
| 16:10.56 | hramrach | they have more with the current drivers |
| 16:11.03 | hramrach | at least integrated ATI |
| 16:11.27 | hramrach | the memory is just reserved for the graphics at boot or at init with AtomBIOS |
| 16:11.37 | hramrach | and used like normal VRAM |
| 16:12.34 | ssvb | tTTttt: the solution for what problem (and on what hardware) are you trying to find? the questions about the caches seem to be really random |
| 16:13.14 | tTTttt | nvm, i don't think i'll ever understand how gpus work |
| 16:14.03 | hramrach | ssvb: as for the problem I am trying to solve without success is to get working graphics on any hardware, with decent desktop and video and 3d performance |
| 16:14.57 | ssvb | hramrach: I guess ati/amd problem is that they need to support both discrete and integrated graphics, so they might be trying the lowest common denominator approach (something that sucks in all configurations) |
| 16:15.58 | hramrach | they tread integrated as discrete so it sucks |
| 16:16.36 | hramrach | the problem is that maybe the hardware is not capable of abusing UMA in any way because it is made by the people wh odo discrete graphics after all |
| 16:16.54 | hramrach | or maybe the hardware could but AtomBIOS cannot |
| 16:17.30 | hramrach | at any rate the integrated graphics performance sucks for multiple reasons |
| 16:18.05 | hramrach | one of them being that GPU rendering with Mesa/dri is CPU intensive |
| 16:19.12 | hramrach | the Intel drivers do abuse UMA because they only do integradet graphics and they do ahve in-house knowledge of CPU/chipset/.. behaviour so they can play cache games |
| 16:19.33 | hramrach | you sometimes lose when going with them, though. |
| 16:19.43 | hramrach | on some chipsets you get severe corruption |
| 16:21.45 | hramrach | all in all if you want to see fast graphics get an ancient mac with 40MHz processor or what it was and install OS6 |
| 16:21.50 | hramrach | sad :( |
| 16:24.32 | *** join/#arm-netbook bsdfox_ (~Bob@unaffiliated/bsdfox) |
| 16:46.16 | tTTttt | /proc/iomem lists mali cache as memory area |
| 16:48.56 | *** join/#arm-netbook L84Supper (~Larch@unaffiliated/l84supper) |
| 16:54.37 | tTTttt | or are those registers controlling the cache? |
| 17:10.12 | *** join/#arm-netbook rz2k (~rz2k@128-69-239-76.broadband.corbina.ru) |
| 17:15.42 | *** join/#arm-netbook hg_5 (~chatzilla@unaffiliated/hg-5/x-8664886) |
| 17:18.17 | *** join/#arm-netbook hramrach (~hramrach@gateway/tor-sasl/hramrach) |
| 17:26.17 | *** join/#arm-netbook servili007 (~servili00@unaffiliated/servili007) |
| 17:59.06 | *** join/#arm-netbook servili007 (~servili00@unaffiliated/servili007) |
| 18:01.46 | *** join/#arm-netbook voronaam (~avorona@159.153.138.99) |
| 18:10.48 | slapin | hi, all! |
| 18:11.40 | slapin | do anybody remembers how I should split sdcard so spl and u-boot are hidden by first partition? |
| 18:11.47 | slapin | any examples? |
| 18:12.53 | xenoxaos | you should just be able to make the first partition offset by X |
| 18:13.33 | xenoxaos | so in fdisk when it asks you the first partition start location....you just specify +20M or whatever you want |
| 18:13.58 | xenoxaos | at least that's what i've done on other devices |
| 18:23.11 | WarheadsSE | slapin: ^ precisely that |
| 18:24.08 | WarheadsSE | script referenced here does it: http://archlinuxarm.org/platforms/armv7/mele-a100 (mkA10card.sh |
| 18:25.56 | *** join/#arm-netbook lkcl (~lkcl@host-92-26-21-157.as13285.net) |
| 18:35.43 | *** join/#arm-netbook Soravux (483585d7@gateway/web/freenode/ip.72.53.133.215) |
| 18:40.54 | *** join/#arm-netbook pcat (~cat@gprs-internet-bceeea-19.dhcp.inet.fi) |
| 18:43.54 | Soravux | Hello everyone! Anybody knows why there is no Linaro snapshot images (rootfs) of ubuntu-desktop for precise and quantal? |
| 18:45.13 | Soravux | Since their webpage ( https://wiki.linaro.org/Platform/DevPlatform/Rootfs ) links to a precise release that 404s... |
| 18:46.58 | mnemoc | http://releases.linaro.org/12.11/ubuntu/precise-images/alip still works |
| 18:48.12 | Soravux | Ok then, LXDE it is! |
| 18:48.34 | mnemoc | http://releases.linaro.org/12.11/ubuntu/precise-images/ubuntu-desktop |
| 18:49.18 | Soravux | Oh you're right, it's just not in the snapshots |
| 18:49.23 | Soravux | Thanks! |
| 18:49.34 | mnemoc | yw |
| 19:21.07 | hramrach | how you make a rootfs? |
| 19:21.19 | hramrach | you debootstrap and add some random junk? |
| 19:22.10 | mnemoc | basically yes |
| 19:22.42 | mnemoc | rellla made a debian on <http://dl.linux-sunxi.org/rellla/debian-unstable-armhf.tar.bz2> |
| 19:22.48 | hramrach | I will probably need init and dhcpcd |
| 19:22.51 | hramrach | hmm, and login |
| 19:23.30 | mnemoc | making custom debian-based distros is totally out of scope of the channel |
| 19:23.52 | hramrach | not custom distro |
| 19:24.20 | hramrach | just need something that boots and connects to the net to install more packages |
| 19:25.24 | *** join/#arm-netbook ZaEarl (~malmrose@c-67-172-235-190.hsd1.ut.comcast.net) |
| 19:25.30 | mnemoc | start from an existing rootfs, then chroot+qemu-static and apt-get install the res |
| 19:25.34 | mnemoc | rest* |
| 19:25.55 | hramrach | do you use initramfs on arm or are all required drivers built-in? |
| 19:26.51 | mnemoc | cnxsoft has a tutorial about using initramfs... but it's not required |
| 19:27.23 | hramrach | it's kinda required for sane distro |
| 19:27.25 | jukivili | I use initramfs |
| 19:27.33 | hramrach | otherwise you need special image for each device |
| 19:27.48 | hramrach | but I am fine with not using one for now |
| 19:28.15 | *** join/#arm-netbook vgrade (~root@static.43.45.47.78.clients.your-server.de) |
| 19:29.13 | hramrach | and you still need special image for each device anyway with the current state of the bootloader/drivers |
| 19:31.25 | Soravux | Anybody built the sunxi-bsp repo recently? When I make [...], it spits an assertion fail ( 2.22 assertion fail /cbuild/slaves/oorts/crosstool-ng/builds/arm-linux-gnueabihf-linux/.build/src/binutils-2.22/bfd/elf32-arm.c:13830 )... |
| 19:32.16 | *** join/#arm-netbook eebrah (~chatzilla@41.223.57.75) |
| 19:32.24 | mnemoc | hramrach: in arm devices you either have a device specific kernel entirely, or a multi-platform kernel receiving a dts from the bootloader. eitherway there is no real use for initramfs as on x86 machines |
| 19:35.48 | *** join/#arm-netbook markatto (~markatto@marktmerritt.com) |
| 19:36.03 | mnemoc | you only need to get root mounted, and there aren't that many =m able options involved |
| 19:36.29 | mnemoc | considering you already need a device specific kernel |
| 19:36.54 | hramrach | mnemoc: not sure how much differnt boards very but the root medium nac be any of flash/mmc/sata/usb |
| 19:37.41 | hramrach | out of these at least usb does not like being built-in too much |
| 19:37.44 | mnemoc | and the point of making those =m on a device-specific kernel is? |
| 19:38.16 | mnemoc | slowing down the boot? |
| 19:38.59 | hramrach | if it is not device specific unused modules will not be loaded possibly saving memory |
| 19:39.23 | mnemoc | it's not that you'll have 100 mtd/mmc/sata/usb controllers... it's only one... the one in the SoC |
| 19:40.08 | mnemoc | in the initramfs they'll be automatically modprobed too |
| 19:40.18 | hramrach | if you need a specific kernel for each SoC then sure |
| 19:40.46 | hramrach | and even if it is the same SoC some variants may not have some pieces |
| 19:41.00 | hramrach | like mtd and sata is not always available |
| 19:41.42 | mnemoc | in multi-platform, yes, initramfs makes more sense |
| 21:10.15 | jelly-home | well initramfs has uses other than picking correct drivers to enable mounting rootfs, like hibernate/resume support |
| 21:11.19 | techn_ | on embedded systems drivers are usually build in :/ |
| 21:12.51 | techn_ | btw. how is deep sleep on a10 working? |
| 21:12.56 | hramrach | you do not need hibernate/resume support in initramfs when the resume device is available to the kernel without extra drivers |
| 21:13.24 | techn_ | or is it even supported with linux |
| 22:03.52 | *** join/#arm-netbook Guest_______ (5b8c38b7@gateway/web/freenode/ip.91.140.56.183) |
| 22:16.29 | RaYmAn | mnemoc: hah, apparently those freescale sticks just has an internal microsd card instead of nand |
| 22:16.38 | RaYmAn | I guess it makes sense given how crap most of this cheap nand is |
| 22:17.24 | mnemoc | even a cheap uSD is several times more expensive than those nands they use |
| 22:18.04 | RaYmAn | sure, but at least it means you can easily replace them with a decent one if you want |
| 22:18.35 | mnemoc | or if it wears out |
| 22:18.38 | RaYmAn | yeah |
| 22:18.40 | RaYmAn | or if you brick it :D |
| 22:18.50 | RaYmAn | just ordered one |
| 22:18.51 | RaYmAn | lol |
| 22:18.53 | RaYmAn | couldn't resist |
| 22:19.02 | RaYmAn | we'll see how it is in uhm, a month or so when it arrives ;) |
| 22:19.06 | mnemoc | which? |
| 22:19.10 | RaYmAn | gk802 |
| 22:19.15 | RaYmAn | from geekbuying.com |
| 22:19.22 | mnemoc | somehow I like the hi802 more |
| 22:19.39 | RaYmAn | yeah I'm not really sure there's any difference |
| 22:19.49 | andoma | what's this thing with 802 anyway? |
| 22:20.00 | RaYmAn | some posts claim that hi802 is a crappy clone |
| 22:20.04 | RaYmAn | good question |
| 22:20.07 | RaYmAn | it dosn't really make sense |
| 22:20.22 | RaYmAn | I'd want to differentiate my product from the piece of crap mk802 is if it was me :P |
| 22:20.24 | mnemoc | 802 became code name for hdmi stick :p |
| 22:20.36 | RaYmAn | apparently |
| 22:20.51 | rz2k | <RaYmAn> some posts claim that hi802 is a crappy clone - they are same |
| 22:21.00 | rz2k | both made by richtechie |
| 22:21.05 | mnemoc | doh |
| 22:21.12 | rz2k | which run hiapad.com |
| 22:21.27 | rz2k | they have videos of retina demos and debugging hi802 |
| 22:21.35 | rz2k | so I believe they are the source |
| 22:38.33 | RaYmAn | rz2k: yeah, looks that way |
| 22:48.20 | mnemoc | so gk802 is a mere rebranding of hi802/8GB? |
| 22:48.25 | RaYmAn | no |
| 22:48.33 | RaYmAn | they are both rebrandings of Richtech one |
| 22:48.42 | RaYmAn | richtechie* |
| 22:51.39 | RaYmAn | from android build.prop on gk802 rom: |
| 22:51.41 | RaYmAn | ro.product.model=GK802 |
| 22:51.41 | RaYmAn | ro.product.brand=Freescale |
| 22:51.41 | RaYmAn | ro.product.name=richtechie_6dq |
| 22:52.01 | mnemoc | :) |
| 22:52.07 | RaYmAn | I'm going to bet that hi-802 says the same thing |
| 22:52.12 | RaYmAn | but I haven't found a rom download for that yet |
| 22:53.02 | RaYmAn | oh joy, the usual rtl8192 wifi |
| 22:58.22 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 23:29.11 | hramrach | mnemoc: so with usb you get assorted drivers for non-compliant usb storage devices built-in just in case you were booting from one |
| 23:29.31 | hramrach | but you don't have the uscsi or what it's called |
| 23:29.52 | hramrach | so in case you were lucky and had compliant device |
| 23:30.05 | hramrach | it would not work in the enhanced mode |
| 23:30.36 | hramrach | so there you have reason to have initramfs with *any* device that has usb. |
| 23:53.27 | Yaku | maybe a stupid question but what´s the difference between an otg and an usb host port, i was just looking at the pictures of the mk808 i´ve ordered and even in the description the ports are differently named, but somehow i don´t directly get the difference, maybe i can´t use an usb hub on an otg port ? |