| 00:11.50 | Turl | is there any reason to keep r2 libs around still? |
| 00:44.21 | *** join/#arm-netbook L84Supper (~Larch@unaffiliated/l84supper) |
| 00:56.10 | ssvb | hramrach: ARGB cursors should be fixed now, it was one of the problems preventing real direct rendering without memory copy overhead for gnome-shell |
| 00:58.30 | ssvb | hramrach: now I just need to implement DRI2 buffers swapping in this roundabout way required by the mali blob |
| 01:28.36 | Turl | ssvb: gnome shellcan run on gles? neat |
| 01:29.58 | *** join/#arm-netbook stefanro (~stefan@p57B949B3.dip.t-dialin.net) |
| 01:31.02 | ssvb | Turl: yes, at least in linaro/ubuntu |
| 02:04.31 | *** join/#arm-netbook cnxsoft (~cnxsoft@node-r4w.pool-118-172.dynamic.totbb.net) |
| 02:10.33 | *** join/#arm-netbook mSquare (~selvan@122.167.87.116) |
| 02:15.50 | *** join/#arm-netbook gsilvis (~almostsix@50.12.163.241) |
| 02:24.20 | Turl | ssvb: what's the performance like? |
| 02:27.14 | ssvb | Turl: not very good, it seems to be quite heavily stressing the CPU (even with redundant memory copies eliminated) |
| 02:43.27 | Turl | :( |
| 02:55.58 | *** join/#arm-netbook mSquare (~selvan@122.167.87.116) |
| 03:09.04 | *** join/#arm-netbook sv (~discopig@unaffiliated/discopig) |
| 03:14.30 | *** join/#arm-netbook mSquare1 (~selvan@122.178.230.93) |
| 04:11.34 | *** join/#arm-netbook Avernos_ (~avernos@111.192.253.27) |
| 04:20.48 | *** join/#arm-netbook Avernos (~avernos@unaffiliated/avernos) |
| 04:26.03 | *** join/#arm-netbook aholler_ (~aholler@p57B2036E.dip0.t-ipconnect.de) |
| 04:29.37 | *** join/#arm-netbook mSquare (~selvan@122.178.250.172) |
| 04:29.54 | *** join/#arm-netbook KoH__ (~kane@trir-4d0bb593.pool.mediaWays.net) |
| 05:40.10 | *** join/#arm-netbook eebrah (~chatzilla@212.49.88.97) |
| 06:04.48 | *** join/#arm-netbook Eigen (~Eigen@S0106001310f0b056.vn.shawcable.net) |
| 06:09.36 | *** join/#arm-netbook mSquare (~selvan@27.34.241.70) |
| 06:19.09 | libv | Turl: there is little pain in supporting r2p4 as well |
| 06:19.38 | libv | and i will have to make this build a lot more complex, but that's fine, as the way the test was handled so far was suboptimal anyway |
| 06:29.33 | *** join/#arm-netbook Eigen_ (~Eigen@S0106b8c75dc9a198.vn.shawcable.net) |
| 06:34.14 | *** join/#arm-netbook cnxsoft (~cnxsoft@node-r4w.pool-118-172.dynamic.totbb.net) |
| 06:41.30 | *** join/#arm-netbook fragmint (~fragmint@108-77-196-171.lightspeed.tukrga.sbcglobal.net) |
| 06:45.51 | *** join/#arm-netbook abesis (~abesis@78.187.167.191) |
| 06:56.51 | *** join/#arm-netbook sky770 (~sky770@122.177.225.162) |
| 07:08.10 | *** join/#arm-netbook rellla (~rellla@p5B07934A.dip0.t-ipconnect.de) |
| 07:14.42 | *** join/#arm-netbook sky770_ORIG (~sky770@122.177.225.162) |
| 07:22.06 | *** join/#arm-netbook rellla (~rellla@p5B07934A.dip0.t-ipconnect.de) |
| 07:33.35 | *** join/#arm-netbook Ershov (~Thunderbi@89.163.11.110) |
| 07:45.21 | *** join/#arm-netbook herdingcat (~huli@218.10.51.7) |
| 07:47.03 | *** join/#arm-netbook pcat (~cat@37-219-42-37.nat.bb.dnainternet.fi) |
| 08:01.19 | *** part/#arm-netbook Ershov (~Thunderbi@89.163.11.110) |
| 08:15.57 | Turl | https://plus.google.com/u/0/108769532003403740583/posts/JDa7cscGr1M |
| 08:18.57 | sky770_ORIG | ^ +1 Turl :) |
| 08:19.27 | sky770_ORIG | Turl: post it on #cubieboard too :p |
| 08:21.52 | sky770_ORIG | Turl: but I am still looking forward to a Cubieboard with 2GB of RAM (and a A20 will be icing on the top :D) |
| 08:30.20 | focus | To get a pl2303 USB-RS232 converter working, I need CONFIG_USB_SERIAL_PL2303=m in kernel config. Anybody know what that means? |
| 08:32.07 | Turl | focus: it means what you said |
| 08:32.10 | oliv3r | so far, no A20 cubieboard though :( |
| 08:32.12 | oliv3r | WHEN! WHEN! |
| 08:32.16 | Turl | make menuconfig and enable it |
| 08:33.15 | focus | Turl: I plead ignorance, what must I do next - find kernel config file, add the line and recompile the kernel? |
| 08:33.38 | Turl | focus: make whatever_defconfig; make menuconfig |
| 08:33.43 | Turl | then choose it on the pretty menus |
| 08:33.47 | Turl | then compile kernel |
| 08:33.58 | zumbi | mnemoc: hey, what's up? |
| 08:35.17 | focus | This for pengpod - so I guess download his kernel to the pengpod from here https://github.com/npeacock/linux-sunxi, and then do what you tell me to do? |
| 08:39.22 | Turl | yeah, make pengpod_a10_max_defconfig; make menuconfig; choose, compile |
| 08:39.48 | focus | Turl: thanks - I work on that |
| 08:48.30 | *** join/#arm-netbook Brandon15811 (~Brandon15@ec2linux.exaktop.tk) |
| 08:51.55 | *** join/#arm-netbook rellla2 (~rellla@p5B078559.dip0.t-ipconnect.de) |
| 09:01.24 | *** join/#arm-netbook eebrah (~chatzilla@212.49.88.100) |
| 09:12.17 | *** join/#arm-netbook z72ka (~72ka@mail.vzlu.cz) |
| 09:15.27 | *** join/#arm-netbook cnxsoft (~cnxsoft@node-r4w.pool-118-172.dynamic.totbb.net) |
| 09:15.42 | hramrach | ssvb: I can't say I see some general performance improvement but at least the animated 'beachball' cursor looks way better now :) |
| 09:15.44 | hramrach | thanks :) |
| 09:20.50 | ssvb | hramrach: these fixes were just needed to ensure that the cursor always stays on top and never goes under disp layer |
| 09:25.30 | *** join/#arm-netbook abesis (~abesis@78.187.167.191) |
| 09:26.59 | ssvb | hramrach: if you want to see the expected performance, you can check this branch - https://github.com/ssvb/xf86-video-sunxifb/commits/wip-swapbuffers |
| 09:29.52 | ssvb | hramrach: it avoids the memory copy done on CPU, but also shows that we need real double buffering to get correct rendering in gnome-shell instead of using the same buffer and treating buffers swap as no-op |
| 09:32.18 | ssvb | hramrach: or more like to get correct picture visible at any time, this is exposed only by gnome-shell so far (for example kwin_gles or other gles applications don't seem to be affected) |
| 09:38.14 | ssvb | hramrach: the problems implementing correct swap buffers operation are explained in https://groups.google.com/d/msg/linux-sunxi/kZNl9bFdE-g/Cm4TrycWwHwJ :( |
| 09:39.30 | ssvb | hramrach: but I'll try to get it working later today |
| 09:44.53 | hramrach | hmm, I don't see what is wrong with that mali expectation |
| 09:45.35 | hramrach | except you might need to allocate new buffer before doing swapbuffers I guess |
| 09:46.03 | hramrach | hmm, I wonder if the semantics are defined for this |
| 09:46.14 | hramrach | in the GL spec or wereever |
| 09:46.46 | hramrach | you expect that for N buffernigh application has allocated N buffers and cycles between |
| 09:47.17 | hramrach | but in fact the buffers are not cycled that way and you can get any random buffer |
| 09:47.43 | hramrach | so mali just goes with that an only allocated the back buffer to which it is going to render |
| 09:48.14 | hramrach | maybe it's just DRI2 bug it does not work |
| 09:48.45 | ssvb | the code in the DDX driver is just a simple backend which allocates or destroys buffers |
| 09:48.52 | ssvb | we have a DRI2 framework in the X server which decides what exactly needs to be created or destroyed |
| 09:49.33 | hramrach | which is likely largerly untested except with the current X drivers |
| 09:49.36 | ssvb | and there is a bit of misunderstanding between the mali blob and this DRI2 framework |
| 09:49.45 | hramrach | so when you do something differently you are likely to hit a bug |
| 09:52.31 | hramrach | basically swapbuffers should move the back buffer one place towards the front as I understand it |
| 09:53.40 | ssvb | what we need to do now is adding an ugly workaround in the DDX driver, so that it would handle the buffers not exactly in the way it is asked, but in the way the mali blob seems to intend to incorrectly request them |
| 09:54.36 | hramrach | I still don't see what is incorrect with what the mali blob does |
| 09:55.13 | hramrach | it alocates back buffer, renders, swaps buffers, and allocates new back buffer for rendering, right? |
| 09:55.40 | ssvb | the mali blob happens to be rendering to the already destroyed buffer, this can't be right |
| 09:56.01 | ssvb | because it thinks that this destroyed buffer is actually the correct one |
| 09:56.20 | hramrach | so it tracks the buffers incorrectly |
| 09:56.43 | hramrach | or maybe thinks there are actually only two buffers :s |
| 09:57.09 | hramrach | and just tosses the buffere obtained with getbuffers |
| 09:57.50 | *** join/#arm-netbook fragmint (~fragmint@108-77-196-171.lightspeed.tukrga.sbcglobal.net) |
| 09:57.55 | ssvb | there are two buffers, but the way mali blob requests them, we first get 4 buffers created, then 2 of them are immediately destroyed |
| 09:58.56 | ssvb | the mali blob thinks that it has two buffers, but one of them is correct and another one is destroyed from the X server point of view |
| 09:59.25 | ssvb | and the second correct buffer just remains unused |
| 09:59.58 | hramrach | hmm, so on getbuffers you get front *and* back even if you requested only back |
| 10:00.25 | ssvb | yes, that's something weird in DRI2 |
| 10:00.50 | hramrach | and when you swap the backbuffer gets destroyed? |
| 10:00.59 | hramrach | that's really odd |
| 10:01.35 | ssvb | yep |
| 10:01.45 | ssvb | anyway, I'll try to handle some sort of workaround in the DDX |
| 10:01.53 | hramrach | that sounds like dri2 bug |
| 10:02.30 | hramrach | swapbuffers has no business destroying backbuffers |
| 10:02.33 | ssvb | you are free to debug it and contribute a fix :) |
| 10:02.45 | hramrach | what would be the point of backbuffers then /o\ |
| 10:03.41 | ssvb | the old backbuffer gets destroyed when you request a new one, not when you swap it |
| 10:05.16 | *** join/#arm-netbook Ershov (~Thunderbi@89.163.11.110) |
| 10:05.29 | *** join/#arm-netbook popolon (~popolon@og-free.planet-service.fr) |
| 10:05.42 | hramrach | but it's supposed to be on hte front now? |
| 10:06.12 | ssvb | that's what the mali blob thinks |
| 10:06.33 | hramrach | well, technically the blob never requested a front buffer so it is not required that the front buffer pointer is valid |
| 10:07.12 | hramrach | but you are supposed to draw to the back buffer so what does it use the buffer for? |
| 10:07.24 | *** join/#arm-netbook fragmint (~fragmint@108-77-196-171.lightspeed.tukrga.sbcglobal.net) |
| 10:12.59 | *** join/#arm-netbook Ershov (~Thunderbi@89.163.11.110) |
| 10:15.13 | ssvb | hramrach: http://lists.x.org/archives/xorg-devel/2009-April/000725.html |
| 10:15.45 | ssvb | more specifically "DRI2GetBuffers would create the requested set of buffers and destroy all previously existing buffers" |
| 10:18.08 | hramrach | so they fix that with the new function |
| 10:18.57 | hramrach | and mali wrongly uses the old one |
| 10:19.07 | hramrach | or did it not make it into the X server? |
| 10:20.20 | ssvb | the mali blob does not try to use the new function |
| 10:20.32 | *** join/#arm-netbook sspiff (c24e0469@gateway/web/freenode/ip.194.78.4.105) |
| 10:21.10 | ssvb | it uses the old one, but makes incorrect assumptions about it |
| 10:23.09 | *** join/#arm-netbook pcat (~cat@37-219-42-37.nat.bb.dnainternet.fi) |
| 10:23.42 | hramrach | well, the old function is rather stupid |
| 10:24.06 | hramrach | still shows that nobody tested that the blob actually works. Not that it's not expected :s |
| 10:25.03 | ssvb | yes, and unfortunately now we need to do something about it |
| 10:27.46 | ssvb | I hope it will not turn out to be too ugly/unmaintainable |
| 10:30.00 | *** join/#arm-netbook grevaillot (~moot@z.f00.be) |
| 10:30.09 | hramrach | how hard is it to make it call the new function instead? |
| 10:31.32 | ssvb | ask libv, I'm not touching the evil blob :) |
| 10:32.30 | ssvb | actually we may try to also report this bug upstream, whoever it is |
| 10:33.21 | hramrach | it might be already fixed in r2 as well |
| 10:33.32 | ssvb | also the latest r3p2 release might have some bugfixes already, so this problem may be theoretically already fixed |
| 10:34.16 | hramrach | p2 then |
| 10:34.43 | ssvb | I can try to run some tests on ODROID-X |
| 10:34.55 | ssvb | it should have the newer drivers |
| 10:36.46 | *** join/#arm-netbook Ershov (~Thunderbi@89.163.11.110) |
| 10:43.56 | mnemoc | zumbi: hi :) |
| 10:46.55 | zumbi | mnemoc: hi |
| 10:48.16 | mnemoc | zumbi: http://packages.linux-sunxi.org/debian/ still feels lonely :< |
| 10:48.20 | zumbi | mnemoc: I was trying to cross build packages for sun4i and sun5i |
| 10:48.35 | zumbi | I failed so far, not sure why it triggers native build |
| 10:49.00 | jelly | zumbi: using make-kpkg, make deb-pkg, or something else? |
| 10:49.13 | zumbi | jelly: something else |
| 10:49.25 | zumbi | jelly: debian linux packages |
| 10:50.02 | jelly | ah, the most complicated way (and arguably the most correct, but) |
| 10:50.34 | mnemoc | persoanlly I always cross compile, so I suppose it's a debian/rules problem |
| 10:51.35 | zumbi | jelly: I got packages for mx233, switch source tree to sunxi was a bit more of a problem |
| 10:52.03 | zumbi | mnemoc: I did not have much time to play with it, so I'll contact you if I got issues |
| 10:52.10 | zumbi | (next time I play) |
| 10:52.14 | mnemoc | :) |
| 10:52.35 | zumbi | mnemoc: so, one question, I did separated packages for sun4i and sun5i, is that right |
| 10:52.47 | zumbi | sun5i should also work with a13 olinuxino? |
| 10:53.12 | zumbi | (sun5i_defconfig) |
| 10:54.21 | mnemoc | it's basically a per-soc thing |
| 10:54.29 | mnemoc | sun4i + axp209 -> A10 |
| 10:54.35 | mnemoc | sun5i + axp209 -> A13 |
| 10:54.43 | mnemoc | sun5i + axp15 -> A10S |
| 10:55.18 | mnemoc | i'm not sure if both pmus can coexist yet |
| 10:55.46 | mnemoc | for a13 we usually use a13_defconfig instead of sun5i |
| 10:55.50 | zumbi | I see, so we need three different configs |
| 10:56.05 | mnemoc | probably x2 |
| 10:56.10 | zumbi | x2? |
| 10:56.25 | mnemoc | full featured vs. headless |
| 10:56.49 | mnemoc | 3d and video decoding takes a huge amount of memory |
| 10:57.05 | mnemoc | and it's still a build-time choice |
| 10:57.22 | zumbi | can those be modules? |
| 10:57.26 | mnemoc | no :< |
| 10:57.47 | mnemoc | (yes, it sucks badly) |
| 10:58.04 | zumbi | makes me want to run away |
| 10:58.18 | mnemoc | those units need big chunks of continuous memory at a predefined address |
| 10:58.21 | zumbi | I feel lucky of not owning those chips |
| 10:58.48 | mnemoc | and so it can't realiably be allocated on load time |
| 10:58.55 | jelly | while you're at it, can you patch aufs in so I don't have to build my own :-) |
| 10:59.30 | zumbi | jelly: either I do, or if you do, send me patch and I'll include it |
| 10:59.44 | jelly | 3.0 or 3.4? |
| 10:59.47 | zumbi | mnemoc: so, which defconfigs are those |
| 11:00.06 | zumbi | yeah, also I was using sunxi-3.0, not sure if that's the right tree |
| 11:00.20 | zumbi | maybe sunxi-3.0 is stable and sunxi-3.4 is devel? |
| 11:00.52 | jelly | they're both kind of stable, and stage/* is kind of devel |
| 11:00.59 | mnemoc | zumbi: 3.4 has broken usb gadget, beside that it's mostly as good as 3.0 |
| 11:01.25 | zumbi | so, is it worth to just do 3.4? |
| 11:01.42 | jelly | do both! Now you're up to 12 builds :-) |
| 11:01.59 | mnemoc | zumbi: hansg even uses stage/sunxi-3.4 in his F18 port |
| 11:02.00 | zumbi | (it should be just one build .. :-)) |
| 11:03.04 | jelly | mnemoc: oh, that might explain the choice of this berryboot dude to do base off stage/sunxi-3.4 as well |
| 11:03.16 | mnemoc | risky choice |
| 11:03.25 | jelly | had trouble merging his aufs tree to sunxi-3.4 |
| 11:21.21 | jinzo | hm, anything new on the A31 code/SDK/whatnot side? |
| 11:24.46 | mnemoc | jinzo: nope |
| 11:26.50 | jinzo | FFS |
| 11:26.58 | jinzo | what about the ACM quad cores? |
| 11:27.12 | mnemoc | acm? |
| 11:27.47 | mnemoc | acm.org made SoCs? :p |
| 11:28.28 | jinzo | or ACT, lemme check |
| 11:28.36 | jinzo | quite popular, cheapest quad cores out there |
| 11:30.26 | jinzo | Atm7029 |
| 11:30.33 | jinzo | damn, missed on both counts :D |
| 11:33.45 | RaYmAn | quad a5? |
| 11:34.49 | jinzo | A9 |
| 11:37.01 | RaYmAn | everything online seems to say a5 |
| 11:37.09 | jinzo | my mistake then |
| 11:37.20 | RaYmAn | except some speculation that it might be a9 because performance seems better than expected from a5 |
| 11:37.52 | mnemoc | http://postimage.org/image/y2l75mw49/ <--- how are the connectors used for lvds called? |
| 11:42.54 | hramrach | varies per lvds |
| 11:43.11 | oliv3r | i've seen several different kind of connectors used |
| 11:43.19 | mnemoc | but as a general term? the kind of connector |
| 11:43.19 | oliv3r | i dont thinnnk there's 'a lvcds' connector |
| 11:43.33 | mnemoc | two of those in the module of the picture |
| 11:43.33 | oliv3r | those flat flip thingie connectors? good question |
| 11:43.40 | oliv3r | gimme 2 mins |
| 11:43.52 | oliv3r | i'll see if i can find it on digikey :) |
| 11:43.55 | hramrach | flat cable connector or something |
| 11:44.02 | hramrach | those on front |
| 11:44.23 | hramrach | there was some tla for it but can't remember |
| 11:44.34 | oliv3r | I would assume flexible cable latch |
| 11:46.04 | oliv3r | flat-flex cable latch or flat flex ZIF latching connector |
| 11:46.07 | mnemoc | close, http://en.wikipedia.org/wiki/Flexible_flat_cable |
| 11:46.31 | oliv3r | but that's not the connector :p |
| 11:46.42 | mnemoc | zif latching connector sounds "pro" :) |
| 11:46.47 | oliv3r | and I was spot on :p flexible flat or flat flexiable :p |
| 11:47.21 | oliv3r | is that ... L84Supper's (if im not mistaken) board? |
| 11:48.16 | mnemoc | http://www.bddgroupllc.com/ <-- this people |
| 11:48.29 | hramrach | oh yeah, the disks using this cable are called ZIF interface disks |
| 11:48.47 | hramrach | but FFC connector should give you the results you want |
| 11:49.54 | hramrach | they are more like SIF, anyway |
| 11:50.23 | hramrach | it's not like you put the cable on the connector and it just drops in as is the case with the CPU ZIF sockets ;-) |
| 11:57.00 | *** join/#arm-netbook focus (~focus@host81-149-149-147.in-addr.btopenworld.com) |
| 11:58.14 | oliv3r | with the CPU sockets you still have to lock the lever in place, so it's quite similar :p |
| 11:58.28 | oliv3r | so it's not a LVDS intervace, but disk interface! |
| 11:59.30 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 12:00.11 | focus | Hi, is there some instructions somewhere to set up cross compiler so I can compile a kernel on a x86? I left my Pengpod at home + I don't think I got enough space on that left now. |
| 12:00.43 | hramrach | oliv3r: it may be any interface. it just connects wires |
| 12:00.54 | RaYmAn | focus: plenty, it's pretty generic, so google it :) |
| 12:01.37 | focus | I suppose I should have :( too lazy |
| 12:02.22 | focus | My excuse is that this be first time I be doing it. |
| 12:02.38 | rm | let me try that... http://www.google.com/search?q=a10+cross+compile+kernel&sourceid=chrome&ie=UTF-8 |
| 12:02.44 | rm | oh look, worked ^^ |
| 12:02.55 | oliv3r | focus: pure kernel? ARCH=arm make menuconfig |
| 12:02.59 | oliv3r | ARCH=arm make :) |
| 12:03.11 | focus | I know how to use Eclipse. So I probably try that - or is it better to go command line? |
| 12:03.37 | rm | know how to derp deplipse |
| 12:03.42 | hramrach | I don't think eclipse has LInux kernel plugin ;-) |
| 12:03.51 | rm | click the above link, the instruction you need is the 1st result |
| 12:03.51 | rm | afk |
| 12:04.56 | focus | rm: looks like it be what I need. I work on it - thanks. |
| 12:21.14 | w00tc0d3 | my desktop environment is getting way more 'elite' everyday oO I even don't want it lol |
| 12:21.29 | w00tc0d3 | gnome 3 3 days ago -> awesome wm -> now configuring dwm oO |
| 12:36.38 | *** join/#arm-netbook hipboi (~hipboi@27.23.190.235) |
| 12:52.48 | *** join/#arm-netbook herdingcat (~huli@218.10.51.7) |
| 13:11.11 | *** join/#arm-netbook cnxsoft (~cnxsoft@node-r4w.pool-118-172.dynamic.totbb.net) |
| 13:15.52 | focus | anyone - 1GB RAM, but what max flash size A10 can support? |
| 13:16.59 | hramrach | thre is a datasheet somewhere - in chinese |
| 13:17.19 | hramrach | but large flash nand sizes are impractical - expensive |
| 13:18.05 | hramrach | there are 2 SDIOs so you can use one SD card as flash - at least 32G SDHC supported, maybe SDXC |
| 13:18.24 | hramrach | 2+ |
| 13:18.33 | hramrach | not sure how many really |
| 13:18.34 | focus | hramrach: I want min 16GB, 32GB ideal - but internal type - not the external SD card type |
| 13:18.53 | hramrach | you can mount SD slot inside case |
| 13:19.44 | focus | hramrach: the issue is the wearing - but then again F2fs is here, so may be its not a big issue once someone ports it to the A10 |
| 13:20.16 | hramrach | the SD card can be replaced - infinite life |
| 13:20.24 | hramrach | soldered nand has limited write cycles |
| 13:20.31 | focus | But as you know, I'm building KiCAD boards, and I wanted to give the bigger option |
| 13:20.48 | focus | hramrach: you got a point there about replacing it on demand |
| 13:22.30 | hramrach | also 2GM ram is supported, theoretically |
| 13:22.49 | hramrach | but the memory controller is undocumented so nobody knows how to set it up |
| 13:23.21 | focus | May be I settle for the doable and then worry about the extended on 2nd iteration :( |
| 13:24.17 | hramrach | you may still have issues if you don't use the AW reference design |
| 13:24.41 | hramrach | differnt trace length or something - different timing parameters -undocumented |
| 13:24.44 | focus | hramrach: I bought the $1000 wits-tech dev kit |
| 13:25.17 | hramrach | I don't know what the kit includes |
| 13:25.27 | focus | The company wants a product built asap |
| 13:26.12 | hramrach | maybe you should have picked TI or something then |
| 13:26.22 | focus | The kit includes a beefed up tablet like device with lots of IO, 7" screen, a DVD with Android and the minimal lychee linux, plus board layout guides and other material that wits will email |
| 13:26.35 | hramrach | some company that can give you the docs for the outside interface at least |
| 13:26.39 | focus | TI is too expensive for the company |
| 13:27.07 | hramrach | board layot guides should help then |
| 13:27.48 | focus | The best now looking to be A10 or iMX6 series with its 6000 page documentation + much lower prices than what is advertised on web pages. Quad core is $18 I believe, dual is $14 and single is down to about $8. |
| 13:27.51 | mnemoc | what does the wits' kit give you that isn't already publicly avaialbe? |
| 13:27.53 | focus | Volume prices |
| 13:28.24 | focus | mnemoc: yep BIG Mistake!! - I found out about this IRC through some link in Aliexpress. |
| 13:28.32 | mnemoc | focus: :) |
| 13:28.53 | hramrach | plus perhaps the layout guides |
| 13:28.58 | focus | You known when working for company, the pressure is on, so the money gets spent with limited knowledge about all the things out there |
| 13:29.31 | hramrach | mining stuff from the interwebs costs money too |
| 13:29.34 | mnemoc | it's kind of facepalm-ish that wandboard doesn't make a quad variant, sell the so-dimm separatedly and neglects to include sata connector on their board |
| 13:29.43 | *** join/#arm-netbook fragmint (~fragmint@108-77-196-171.lightspeed.tukrga.sbcglobal.net) |
| 13:30.06 | hramrach | I find hardware design facepalmish most of the time |
| 13:30.11 | hramrach | but then I don't do it |
| 13:30.15 | mnemoc | :) |
| 13:30.50 | w00tc0d3 | aight |
| 13:30.54 | hramrach | and I somewhat understand that once you send the PCBs for product run you have to live with what was designed there until next rev |
| 13:30.59 | w00tc0d3 | finally a proper GTK theme |
| 13:31.00 | focus | hramrach: my aim is to release everything in open source KiCAD so anyone can make it to their own heart's content. I mean you want quad core? Sure put 4 A10's on the friggin board!! :)))) |
| 13:31.38 | hramrach | would be interesting project to make that work |
| 13:31.49 | hramrach | but not very practical I suspect |
| 13:32.06 | hramrach | what interconnect would you use? |
| 13:32.15 | hramrach | spi? |
| 13:32.20 | focus | I fully intend - and very practical - because I am also building infrastructure prototyping boards |
| 13:33.11 | focus | hramrach: it is down to the person. You could put ethernet for each CPU - now you got 1 with LCD and 3 additional ones as headless servers!!!!!!! :))))) |
| 13:33.26 | focus | Quad core as you never seen em before! |
| 13:33.59 | focus | The one with LCD will run slow because it must share LCD RAM access and updates with software, but the other 3 do not, and run 10x quicker |
| 13:34.07 | hramrach | well, basically a tiny mosix cluster |
| 13:34.15 | hramrach | or what was the linux custering calles |
| 13:35.06 | focus | Or use the ports to directly talk to each other with a special protocol anyone can design (my intended focus of R&D) |
| 13:35.42 | hramrach | gpio interconnect, hmm |
| 13:36.15 | focus | Thats not clustering per se - the CPUs would have micro relays to power them out. They come on line if they need to be doing some serious work only. |
| 13:36.30 | focus | yada yada could go on :) |
| 13:38.23 | hramrach | what is target boarrd size? |
| 13:38.24 | *** join/#arm-netbook focus (~focus@host81-149-149-147.in-addr.btopenworld.com) |
| 13:38.26 | hramrach | ITX? |
| 13:38.34 | hramrach | what is target boarrd size? |
| 13:39.05 | focus | The project is here http://www.gplsquared.com/SoM2/SoM2.html |
| 13:39.36 | focus | The CPU is on a SoM board. The motherboard is in project http://www.gplsquared.com/SoM1/SoM1.html |
| 13:40.49 | focus | Currently the SoM2 board is currently reached stage of infrastructure break out board to build and test boards to destruction / prototype functions around it. |
| 13:41.38 | focus | I get 10 SoM boards built later this week with the CPUs soldered on at the factory. |
| 13:43.00 | focus | Then the fun begins :) |
| 13:43.17 | hramrach | good luck with that |
| 13:43.42 | hramrach | not sure what I would do with such device but I am sure you have some use cases since you are designing it ;-) |
| 13:46.16 | focus | We are hardware engineers and like software engineers we have 'ethics' about sharing. No one holds back a datasheet by convention. But ARM holds back and that is incredibly annoying. So when this project is finished, I'd be a lot happier because all engineers can design their own boards without being left out of the race. |
| 13:46.39 | *** join/#arm-netbook rz2k (~rz2k@95-25-199-38.broadband.corbina.ru) |
| 14:10.22 | hramrach | as a not hardware designer I am more interested in actual application of such board |
| 14:11.03 | hramrach | at least teh design looks intereting but that would not be enough incentive to buy one I guess ;-) |
| 14:15.13 | *** join/#arm-netbook aluclinux (~daniel@187.11.237.63) |
| 14:15.52 | focus | hramrach: may aim is Internet of Things IoT. |
| 14:16.03 | focus | I define IoT as innards of a capacitive tablet |
| 14:16.18 | focus | with Linux running on it |
| 14:17.02 | focus | So I can design any applications with say Gambas and then as I press the buttons on the tablet interface, it does something. |
| 14:17.19 | focus | So no need for real buttons on switches |
| 14:17.33 | focus | I got me a pengpod and it already does all that!! |
| 14:18.25 | focus | There is code here for MK802 http://www.gplsquared.com/mk802/mk802.html with HDMI display - and it talks as well! |
| 14:19.11 | focus | If I got a 5" and 7" innards of a capacitive tablet with linux running, then my company can use it by dropping the thing into their equipment to control it. |
| 14:19.13 | pucko | which dist can I use to crosscompile the sunxi-kernel? |
| 14:20.28 | focus | hramrach: The gambas program already communicates via serial RS232 optically isolated - so when it controls equipment, it just needs to run RS232 and send out messages, and log the responses and display them on the front panel |
| 14:20.53 | focus | Targe cost about $30, because all I want are the innards - no battery etc. |
| 14:20.56 | RaYmAn | pucko: any, assuming you have a suitable crosscompiler available. |
| 14:23.45 | bfree | pucko: debian+emdebian works as described at http://linux-sunxi.org/Debian (and with gcc 4.7 for kernel 3.4 anyway) ... ubuntu also is painless |
| 14:24.45 | *** part/#arm-netbook aluclinux (~daniel@187.11.237.63) |
| 14:26.42 | bfree | zumbi: are you trying to use the stock debian kernel packaging? it's a bit over the top and adds extra hassles (and if I remember right the docs bit triggered the cross-build problems) :-/ have you seen https://github.com/bfree/linux-sunxi-fll ? though I admit I've been compiling natively ;) |
| 14:27.29 | zumbi | bfree: yes, and no |
| 14:27.53 | zumbi | bfree: I have modified stock packaging to just create linux-image and linux-headers packages |
| 14:28.08 | zumbi | I have not seen that github tree |
| 14:29.06 | bfree | https://github.com/bfree/linux-sunxi-debian is as far as I bothered going with the debian style packaging ... imho it's just madness really until building a mainline kernel with a view to getting patches to debian |
| 14:33.00 | bfree | zumbi: I actually have a new config now for sun4i since last night (well native compile finished while I slept) which has expanded it out to something more like a distro kernel (way more modular, needs an initrd) ... just have to actually install the package and test it works before pushing up the new config (which makes build time about 2.5 times longer) |
| 14:34.58 | bfree | zumbi: and http://dl.linux-sunxi.org/niall/debian/ ... which has a u-boot also |
| 14:35.23 | hramrach | focus: maybe A13 would be better then |
| 14:35.38 | hramrach | cheaper but sufficient for the application |
| 14:36.09 | zumbi | bfree: cool! I'll have a look |
| 14:36.33 | zumbi | bfree: those packages should probably go under l-s.o/debian |
| 14:36.49 | bfree | zumbi: I've barely begun sunxi-tools, which is the only other piece to make it enough to go from scratch to booting in to it (i.e. fexc) ... but that should be fairly easy |
| 14:37.41 | zumbi | bfree: right, not sure if at olimex someone was trying to work on those |
| 14:37.51 | zumbi | bfree: I started doing olinuxino mx233 board |
| 14:38.44 | zumbi | bfree: we should coordinate and upload to http://packages.linux-sunxi.org/debian/ |
| 14:39.10 | bfree | zumbi: well I'd rather the fuller kernel and not just defconfig ... and I've only touched sun4i as that's all I have. and some docs and testing would also be useful before attempting to promote them (i.e. a proper repo in packages.l-s.o/debian) |
| 14:39.40 | zumbi | bfree: I have no sunxi hw |
| 14:40.03 | zumbi | but I would like to attempt to build images for developers |
| 14:40.19 | zumbi | then we can test-fix them |
| 14:40.31 | zumbi | but if no packages, no images, no test, no fix |
| 14:40.47 | zumbi | FOSS motto, release often, release early |
| 14:40.49 | bfree | zumbi: the big gap you might see in that github was me waiting for my cubieboard ;) |
| 14:41.22 | zumbi | :) |
| 14:41.54 | zumbi | bfree: I am pretty short on time for this stuff |
| 14:42.03 | zumbi | but still I think its worth doing |
| 14:42.14 | zumbi | but no hassle |
| 14:42.22 | focus | hramrach: need the sata for big devices with mass data storage such as security cams |
| 14:44.25 | pucko | bfree: I'll try debian then |
| 14:44.43 | pucko | current kernel have constants oops |
| 14:44.43 | hramrach | SATA is definitely best storage option on A1x so if you need store data locally, sure |
| 14:45.37 | hramrach | reportedly it can do up to 50MB/s but MMC and NAND is limited to ~10MB/s |
| 14:46.27 | hramrach | not sure about the nand, may be due to the installed nand chip |
| 14:46.38 | hramrach | but getting fast chips is difficult anyway |
| 14:46.39 | focus | hramrach: 128GB SATA SSD is about $120 - store 1 picture a second for 1 year from web cam :) |
| 14:46.58 | mnemoc | hramrach: i get 120MB/s with externally powered 3.5" drive, and someone in #cubieboard reported 200MB/s with ssd |
| 14:47.01 | focus | install and forget security |
| 14:47.35 | focus | On pengpod I got apache working |
| 14:47.52 | hramrach | anybody has any idea how large cards does A1x support? |
| 14:49.01 | hramrach | there is supposedly sdxc about which kernel babbles that it's not working every time you insert sdhc card |
| 14:49.19 | focus | So I reckon a simple web program on A10 + 128GB SSD + webcam and you got 1 year remotely accessible camera with LCD touch screen to tell you if you had visitors |
| 14:49.57 | hramrach | plus you can write the software so that it overwrites the old pics with the new pics after a year |
| 14:50.33 | focus | hramrach: yep! + its IoT so it can contact other IoT and let them know to turn on the lights :) |
| 14:51.12 | focus | Beeelllion of IoT devices being held back because of a lack of ARM documentation - soon to change with this IoT on KiCAD |
| 14:51.49 | hramrach | there is 128GB sdxc for sale |
| 14:51.53 | focus | They shoot themselves in the foot holding back documenation. I could have done this half a year ago if it wern't for lack of info |
| 14:52.02 | hramrach | but I doubt anybody tried that with an A10 device |
| 14:52.10 | focus | hramrach: :) |
| 14:52.22 | *** join/#arm-netbook Avernos_ (~avernos@221.223.235.211) |
| 14:53.46 | L84Supper | oliv3r: that board was on the ML http://www.allwinner.com/devkit/DevKit.php |
| 14:54.09 | *** join/#arm-netbook ZaEarl (~malmrose@c-67-172-235-190.hsd1.ut.comcast.net) |
| 14:54.15 | hramrach | well, about the datashits they produce |
| 14:54.22 | hramrach | that's industry standard |
| 14:54.32 | L84Supper | oliv3r: http://www.bddgroupllc.com/ |
| 14:54.54 | hramrach | as a SoC maker you get chip info under NDA |
| 14:55.16 | hramrach | so you make some driver that somewhat works so you can demonstrate the SoC |
| 14:55.42 | hramrach | and produce some marketing-speak datashit that does not reveal anything you are not allowed to |
| 14:56.29 | hramrach | and next year you license new chip core with docs under NDA and star making that, and forget about the old one |
| 14:57.12 | hramrach | maybe some SoC maker figures out that focusing on docs and fixing stuff makes better product |
| 14:57.28 | hramrach | but I am not so sure better product sells better |
| 14:57.43 | hramrach | it's marketing what sells stuff, not quality |
| 14:57.55 | hramrach | the market is moving too fast for quality to have impact |
| 15:01.02 | Gumboot | I got my SATA up to 220MB/s. 50MB/s is rust-based? |
| 15:01.11 | hramrach | hmm, micro-sdxc is up to 64GB so far |
| 15:01.28 | hramrach | Gumboot: depends on the disk and driver you test with I guess |
| 15:01.45 | hramrach | good to know it goes higher |
| 15:01.56 | Gumboot | I should probably have done read speed tests when I had the fancy SSD plugged in. |
| 15:02.02 | Gumboot | (had to remove that for lack of power for writes) |
| 15:02.45 | Gumboot | I guess I could try harder to contrive a test which goes directly to the cache. |
| 15:03.39 | Gumboot | Also, I dare say that a lot of SoC vendors have a very strong disincentive to release any source code they _could_ simply because of all the negative PR it generates. |
| 15:04.33 | hramrach | does releasing source code generate bad press? |
| 15:04.43 | Gumboot | Yes. |
| 15:04.56 | Gumboot | Everything that is released can point to taint in things that aren't. |
| 15:05.07 | Gumboot | Which means that people just demand even more. |
| 15:05.19 | Gumboot | Releasing a little bit is just stirring that shit for yourself. It's not worth it. |
| 15:05.56 | *** join/#arm-netbook rsalveti_ (~rsalveti@unaffiliated/rsalveti) |
| 15:06.46 | hramrach | if they can't really release the code there is not much point trying to go half-way and releasing GPL violating tree with every driver they have written in object form and claiming it's GPL and using the GPL licensed kernel symbols |
| 15:06.47 | Gumboot | Nobody criticises a completely closed system as much as one where they've not been able to do a thorough job of openening it. |
| 15:07.22 | hramrach | well, the system which was OpenWRT was thoroughly criticised for being closed |
| 15:07.25 | Gumboot | If you don't want shit flung at you, you should stay closed. |
| 15:07.37 | hramrach | they only released the code on demand from people complaining |
| 15:08.48 | hramrach | also the NDAs and general secrecy is to avoid patent litigation. Patent trolls cannot sue you for info you have not released |
| 15:09.18 | L84Supper | I don't anything changing in China much over the next few years so I'd just get used to it and adapt. |
| 15:09.19 | hramrach | technically they could but they will focus on easier targets |
| 15:10.12 | L84Supper | in China they are more concerned about somebody copying their work too easily vs complying with the GPL |
| 15:10.34 | hramrach | copying is one thing |
| 15:11.03 | hramrach | I don't think not releasing the drivers will stop anybody, in fact |
| 15:11.03 | Gumboot | I don't think the drivers are an interesting thing to rip off, compared to the hardware. |
| 15:11.09 | Gumboot | Unless you're talking winmodems. |
| 15:11.20 | hramrach | but releasing htem is work (=cost) and most of the time they are not allowed |
| 15:11.44 | Gumboot | Releasing things under GPL is especially expensive because of the extensive review process. |
| 15:11.59 | L84Supper | if you could actually convince a supplier there that by releasing source would vastly increase their sales they would do it in a heartbeat, they just follow the easiest path to the money, nothing more |
| 15:12.06 | Gumboot | There's a whole lot of strict partitioning that has to be done. |
| 15:13.16 | Gumboot | L84Supper: They wouldn't simply go ahead and breach NDA. You have to convince the whole chain. |
| 15:13.21 | hramrach | it would allow more quality and longer lived products based on their chips |
| 15:13.23 | focus | hramrach: holding on to datasheets is not a done thing in chip circles - its a new thing in SoC circles. Billions get invested into making chip, and you want engineers out there producing products to create demand to get a return on chip manufacturing investment |
| 15:13.39 | hramrach | but the market is about spitting out cheap junk as fast as you can |
| 15:13.51 | focus | holding on to datasheets is like shooting yourself in the foot. |
| 15:13.56 | Gumboot | hramrach: Or expensive junk. |
| 15:14.18 | hramrach | spittoung out cehap junk and selling as expensive as you can |
| 15:14.27 | L84Supper | Gumboot: with money being the bottom line you'd be surprised by how suddenly creative the process of leaking source would become |
| 15:14.55 | focus | i think its big corporations forcing hardware companies to sign their NDAs and then forcing them to let other sign NDAs down the chain. |
| 15:15.09 | L84Supper | face and money, what else is there? |
| 15:16.15 | focus | probably media companies worst offender with their graphics chips and encoders - I really don't understand how it all works - but I know its a new thing |
| 15:16.18 | hramrach | well, you get to negotiate the terms when buying the chip IP |
| 15:16.42 | hramrach | but at that time not much thought is spent on the way the software side will be done I suspect |
| 15:16.53 | focus | hramrach: opencores.org - no need to buy any ip except for ARM core and graphics |
| 15:16.55 | hramrach | so they sign the NDA and are done with it |
| 15:17.13 | focus | yes I guess - too easy to sign NDA |
| 15:17.34 | focus | Lock out Linux through NDAs |
| 15:17.47 | focus | Lock out open source developers through NDAs |
| 15:17.51 | L84Supper | GPL is far from their focus, how does releasing source and the GPL increase their profits? |
| 15:18.00 | L84Supper | even if there was no NDA? |
| 15:18.20 | hramrach | yes, long term support is not the goal |
| 15:18.21 | focus | more products get made - more chip sales |
| 15:18.32 | L84Supper | thats not true |
| 15:18.41 | L84Supper | that's fantasy |
| 15:18.55 | mnemoc | believes the only way is a shame campaign against ARM itself for implicitly supporting the GPL violations of their licensees |
| 15:19.41 | focus | L84Supper: to argue that way is to let the reverse be true also - i.e. no datasheets leads to more product sales :) |
| 15:19.52 | mnemoc | as it's not something than can be solved by legal or economic measures. only PR |
| 15:20.39 | L84Supper | hire Carl Rove or get Glen Beck to smear ARM with some GPL commie nonsense, it could work in the USA |
| 15:20.57 | hramrach | focus: no, good datasheet availability has very limited impact on chip sales |
| 15:20.58 | focus | mnemoc: or just one chip maker breaking ranks and publishing everything including graphics controller. It could be Microchip and their PICs with a 1GHz chip. All others must fail including ARM!!!!!!! |
| 15:21.01 | libv | is getting somewhere with mali-libs now |
| 15:21.21 | *** join/#arm-netbook pwhalen (~paul@CPE001310360dac-CM78cd8ec9e405.cpe.net.cable.rogers.com) |
| 15:21.28 | mnemoc | libv: eh? |
| 15:21.33 | libv | if all goes well with autodetection: make; make install is all you need now |
| 15:21.40 | mnemoc | \o/ |
| 15:22.03 | hramrach | because most manufacturers are fine producing devices with half-working GPL-violating software |
| 15:22.28 | libv | make config VERSION=r3p0 ABI=armhf EGL_TYPE=x11; make; make install is the worst case scenario |
| 15:22.39 | focus | hramrach: its price and datasheets and software together. Allwinner had price, and software grew around it and datasheets get leaked. It is best available save for iMX6 now which may has datasheets + low price but not the very big software support around it |
| 15:22.50 | libv | gets you a fresh libUMP.so.[23] as well |
| 15:23.36 | hramrach | focus: I agree A10 is best available at the moment. AW or ARM had no part in that incident most likely, however |
| 15:24.05 | focus | If Microchip bring out a Linux chip fully documented, then ARM will fail overnight. PIC chip has register names and names for bitfields - something which no ARM has - so software is not portable between chips!!! |
| 15:24.31 | bfree | zumbi: cross compiling (emdebian on debian) my kernel package fails for me also at dh_strip on scripts/bin2c :-/ it looks a bit like https://bugs.launchpad.net/ubuntu/+source/linux-linaro-mx51/+bug/715429 where scripts/bin is x86-64 :-( |
| 15:24.40 | focus | hramrach: yep! In fact they feed off it!! They tell me about sunxi site! Despite not being their own! |
| 15:24.51 | libv | focus: more !!! |
| 15:25.38 | zumbi | bfree: paste failure log |
| 15:26.06 | zumbi | bfree: while I was able to build mx233, when doing sunxi, it tried to build x86 instear arm arch |
| 15:26.24 | focus | I ask Microchip to bring out a 1GHz chip - but trolls jumped on it and spoiled the conversation |
| 15:26.24 | hramrach | what was the multicore chip with no grahics core again? |
| 15:27.50 | focus | hramrach: that problem is about to be nuked!! The KiCAD files will allow you to drop multiple CPUs to a board with copy and paste. One of those CPUs could be 100% graphics rendering chip with custom software. In fact it can 2 or more!! :))) |
| 15:28.33 | focus | So you have one CPU with LCD, and 1 or two doing the graphics rendering and talking through GPIO pins to the chip with LCD. Problem about 3D rendering sorted! |
| 15:28.47 | focus | No more graphics accelerators needed. |
| 15:29.15 | focus | If you want to spend $200 on a graphics card, then just get a card built with 20 A10's on it :)))) |
| 15:29.26 | bfree | zumbi: I guess you want a whole build log, and that will take a little while to do on -j1 (for a clean log)? just the relevant part erroring out is dull, just a "file format not recognised" when arm-linux-gnueabihf-strip is called on the scripts/bin2c |
| 15:29.47 | focus | A lot more data bandwidth between one CPU and RAM than lots of cores and one RAM. |
| 15:30.20 | hramrach | focus: but problem getting all the data to hte display in the end |
| 15:30.24 | focus | So 20xA10 each with 1GB RAM has astonishing power. |
| 15:30.29 | hramrach | could do some whacky LVDS interconnect, though |
| 15:30.30 | libv | focus: sure... |
| 15:30.44 | zumbi | bfree: ok |
| 15:31.01 | libv | focus: so what will be driving the display then? |
| 15:31.18 | focus | hramrach: should not be a problem, because images are built up on a pipeline and so all it does is parallel rendering and physics to make it real |
| 15:31.39 | focus | the final bit of the rendering is bit blitting to update the LCD. That can be a meager LCD + A10 |
| 15:31.54 | libv | focus: well, make it so! |
| 15:31.58 | hramrach | focus: I will believe when I see it happen |
| 15:32.02 | libv | focus: go! go and do it! |
| 15:32.13 | focus | libv: who said I won't ? :))) |
| 15:32.31 | libv | focus: i haven't said so, but i will |
| 15:32.32 | bfree | zumbi: I'll do it -j12 (VM with 6 cpus) ... will probably be good enough for this actually (and takes ~12minutes, rather then probably a couple of hours for -j1) |
| 15:32.37 | hramrach | I guess you could also make a LVDS interconnect that concentrates data from multiple processors ;-) |
| 15:32.39 | libv | focus: then go, quickly. |
| 15:33.04 | hramrach | so each scans out its bit and you compose it into a single image |
| 15:33.14 | focus | After the first SoM is out, the second is or third is copy paste x 10 or x20 board; muahahahah they said it could not be done.. but it can!! |
| 15:33.32 | libv | focus: you forgot an extra !!! |
| 15:34.12 | libv | it's very important to get the number of ! right |
| 15:34.22 | hramrach | you can cut&paste 20 boards next to each other |
| 15:34.36 | hramrach | and get 20 single chip computers on a single PCB |
| 15:34.45 | hramrach | the interconnect is the difficult part |
| 15:35.07 | hramrach | some companies like Cray or SGI were making their living on that |
| 15:35.09 | focus | hramrach: yes divide the processing - between processors with intelligent algorithms - that effectively becomes an R&D vehicle for students wanting to build their own 3D graphics engines |
| 15:35.16 | hramrach | and SGI still was last time I checked |
| 15:35.44 | focus | hramrach: they did not have 1GHz ARM with 1GB RAM for $20 to make it happen |
| 15:36.53 | hramrach | the scanout speed for 1080p is more than the speed of the RAM interface on A10 it seems |
| 15:37.33 | hramrach | so you can't make an A10 cut & paste picture data from multiple buffers into one in real time |
| 15:38.09 | focus | hramrach: that is why the data has to be pumped into a A10+LCD through GPIO. The A10 pastes it into the RAM and the HDMI blits it to screen. |
| 15:38.31 | libv | ? |
| 15:38.43 | focus | I mean controllers blitz it to LCD or the HDMI |
| 15:38.48 | focus | from the RAM at a fast rate |
| 15:39.03 | hramrach | does not seem viable |
| 15:39.23 | focus | The data to the RAM does not need to be updated at high speed |
| 15:39.23 | libv | focus: what happened to all those other projects you have been talking about over the last 6 months? |
| 15:39.25 | hramrach | but I am not very familiar with the A10 bandwidth bottelnecks |
| 15:40.01 | hramrach | focus: the data to the ram needs to be updated at tehscanout speed for realtime rendering |
| 15:40.14 | focus | libv: some drew blanks - but others are racing. I am not sure where I am on each |
| 15:40.32 | hramrach | sometimes you can use compression but sometimes you simply need the whole thing |
| 15:40.40 | libv | you're the one doing "things", right? |
| 15:40.46 | libv | how can you not be sure where you are? |
| 15:41.11 | focus | hramrach: the way it works the data gets pumped from CPU to CPU where each bit is added. |
| 15:41.43 | hramrach | the last one needs to work at full scanout speed |
| 15:42.04 | focus | So a intense scrolling screen for a racing sim can be built by one CPU, and then another CPU does the road, etc. |
| 15:42.27 | *** join/#arm-netbook aesok (~aesok@128-72-132-189.broadband.corbina.ru) |
| 15:42.36 | hramrach | but at the end one CPU needs to feed it to the LVDS/HDMI |
| 15:42.45 | hramrach | at speed surpassing the RAM IO speed |
| 15:42.47 | focus | The rate of flow of information is not that bad - about quarter to half of the CPU taken up in data transfer the remainder is rendering CPU cycles |
| 15:43.09 | focus | I did some calculations once - it were not too bad |
| 15:43.23 | libv | what bus are they all using to communicate? |
| 15:43.41 | hramrach | GPIO :-D |
| 15:43.49 | focus | Not all pixels need to be updated - so it can be almost no bandwidth at times |
| 15:43.51 | ssvb | hramrach: the scanout is indeed taxing memory bandwidth quite a lot, but surely not exceeding it - https://github.com/ssvb/tinymembench/wiki |
| 15:44.43 | hramrach | ssvb: there seems to be a problem reported with artifacts high-dotclock modes reported |
| 15:45.01 | *** join/#arm-netbook Marex (~Marex@2a01:430:d:0:2cc:6ff:fefc:db16) |
| 15:45.01 | hramrach | eg. you can scan out at 1080i but not 1080p |
| 15:45.29 | hramrach | maybe the problem is elsewhere |
| 15:45.34 | focus | the scanout is handled by the final CPU + LCD/HDMI contoller - how the data gets into that RAM to be scanned out can be very slow. |
| 15:46.06 | hramrach | but since the clock syncs but part of the data is bad it reminds me of those old SDRAM GPUs which had about the same issue |
| 15:46.19 | hramrach | lower the dot-clock and artifacts gone |
| 15:46.30 | focus | so if a scene is not updating, the scanout remains high frequency high bandwidth, but you may be moving only 100 pixels at a time so the second CPU is hardly going to get taxed, same with GPIO pins |
| 15:46.57 | ssvb | hramrach: I can scanout 1080p, but there seem to be some kind of buffer underruns in the display controller if the the GPU and/or CPU is accessing memory at the same time |
| 15:47.15 | ssvb | hramrach: 50Hz works more reliable than 60Hz for 1080p |
| 15:47.24 | hramrach | so about the speed of the ram IO |
| 15:47.38 | hramrach | but you cannot update it from the CPU |
| 15:47.57 | focus | It is updated by the CPU - thats how games software works |
| 15:48.06 | focus | without accelerators |
| 15:48.13 | focus | but not clever |
| 15:48.46 | hramrach | focus: the problem is in the worst case you have to update everything |
| 15:49.10 | hramrach | because either everything has chenaged or too much ahas cahnged to calculate the difference |
| 15:49.22 | focus | hramrach: thats true even in complex games - crysis frame rate drops to about 12fps on complex scenes on medium graphics cards |
| 15:49.47 | focus | So as things get complex, the frame rate drops |
| 15:50.10 | hramrach | with A10 the usable frame rate drops to 0 because the memory bandwidth is occupied by scanout |
| 15:50.47 | hramrach | ssvb: which device? |
| 15:51.23 | hramrach | or rather what ram speed the Mele default 360MHz? |
| 15:51.58 | focus | not usually hramrach: the penpods have lCD scanout and it plays videos reasonably well - so its rendering it in software and allowing scanout hardware to function at the same time |
| 15:52.03 | *** join/#arm-netbook bsdfox (~Bob@unaffiliated/bsdfox) |
| 15:52.09 | ssvb | hramrach: Mele A2000, here are the benchmark results with and without driving the 1080p monitor (you can compare how individual tests are affected) - https://github.com/ssvb/tinymembench/wiki/Mele-A2000-%28Allwinner-A10%29 |
| 15:52.39 | ssvb | hramrach: I'm clocking the memory at 480MHz |
| 15:54.03 | hramrach | well, so driving the monitor somewhat affects benchmark (like -30%) but gives you display artifacts |
| 15:54.43 | ssvb | how do you get artifacts? is there a reproducible test case? |
| 15:55.06 | hramrach | I don't have a 1080 capable screen so can't check |
| 15:55.14 | focus | display artifacts are normally taken care of by clever software - not so clever software == artifacts |
| 15:55.44 | hramrach | ssvb | hramrach: I can scanout 1080p, but there seem to be some kind of buffer underruns in the display controller if the the GPU and/or CPU is accessing memory at the same time |
| 15:56.21 | ssvb | hramrach: in this case how do you know there is a problem? |
| 15:56.44 | hramrach | I don't know how did you notice the underruns |
| 15:56.58 | focus | stripes on screen |
| 15:57.22 | hramrach | on an S3 trio I had this issue that right part of the screen showed stripes of garbage |
| 15:57.33 | hramrach | with high dot clocks |
| 15:58.53 | hramrach | on modern discrete graphics cards there is some watermak logic that suspends the GPU when there is not enough memory bandwidth to process the scanouts |
| 15:59.16 | hramrach | but A10 does not have that or it is not documented |
| 16:00.13 | libv | ssvb: 480MHz really is a great one |
| 16:01.03 | hramrach | cubieboard comes clocked at that speed according to sunxi wiki |
| 16:01.09 | hramrach | not sure how to check |
| 16:02.40 | Turl | use the sunxi memory tool thingy that prints stuff about the memory |
| 16:03.59 | bfree | zumbi: ooops, I did it -j1 ... bah, may as well let it finish anyway now for the cleaner log |
| 16:04.47 | hramrach | Turl: where do you get that? |
| 16:04.58 | hramrach | sunxi-tools does not seem to have one |
| 16:05.39 | Turl | hramrach: see here, the tool is linked http://linux-sunxi.org/Submitting_Boards |
| 16:08.25 | focus | hramrach: /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq |
| 16:08.50 | hramrach | it says 480 |
| 16:09.32 | hramrach | http://paste.debian.net/235265/ |
| 16:10.06 | focus | hramrach: I believe it autoscales - check it again with something running |
| 16:11.00 | hramrach | well, the CPU freq says 1008000 |
| 16:11.05 | libv | ssvb: do we even have a wiki page about "overclocking", although i think overclocking is not the right word for bump up the memory clock |
| 16:11.07 | hramrach | I wonder why it is scaled that high |
| 16:11.47 | hramrach | it's overclocking if factory testing is done at lower clock |
| 16:11.51 | Turl | libv: 'betterclocking' |
| 16:12.07 | Turl | libv: wonder if dram clock should be controllable from inside linux |
| 16:12.16 | hramrach | the parts might be designed to run higher (depending on the RAM chips used) but not tested to actually work |
| 16:12.49 | hramrach | you have ram frequency scaling too |
| 16:12.59 | hramrach | so technically it is controllable already |
| 16:13.12 | libv | seems like we have no wiki page for that |
| 16:13.18 | hramrach | or do you? |
| 16:13.27 | hramrach | I think I heard something about that |
| 16:15.04 | bfree | zumbi: http://dl.linux-sunxi.org/niall/crossfail.log.gz |
| 16:15.50 | ssvb | libv: we probably need to collect some statistics about cpu and memory overclocking stability, based on a few reports so far it looks like the cpu is not really overclockable but the ram is |
| 16:15.50 | zumbi | bfree: thanks, I'll have a look later on, gotta go now |
| 16:16.15 | libv | ssvb: indeed |
| 16:19.20 | hramrach | well, some people say the CPU is overclockable to ~1.2GHz |
| 16:19.38 | hramrach | not sure how helpful that would be |
| 16:19.39 | ssvb | the memory chips used in Mele A2000 are DDR3-1333, Allwinner-A10 SoC specs say that it supports up to 400MHz (DDR3-800), I have no idea why the vendor is clocking memory in Mele at 360MHz by default (maybe they just don't need memory bandwidth for their primary use cases?) |
| 16:20.06 | hramrach | probably |
| 16:20.13 | hramrach | and safety margin |
| 16:20.42 | hramrach | lower clock = more complying parts = less costs for trashed hardware |
| 16:21.35 | libv | ssvb: yeah, could be |
| 16:22.38 | rm | maybe lousy PCB layout |
| 16:23.08 | rm | I remember Tom once said |
| 16:23.21 | ssvb | or it could be that they were hunting some software bug, decided to clock down the memory speed to check if it helps, somehow fixed the bug but forgot to restore the memory clock speed to the original settings :) |
| 16:23.43 | rm | one of the strength of the A10 (A13 etc), is that even a mediocre electrical engineer can design a stable board with it |
| 16:24.07 | rm | gths* |
| 16:24.30 | hramrach | they provide a reference design |
| 16:24.37 | mnemoc | wonders about the eoma68-a10 card :| |
| 16:24.45 | libv | ssvb: is there a difference in powerdraw? |
| 16:25.04 | ssvb | libv: I have not measured it |
| 16:25.16 | hramrach | Mele is not battery powered so not much of a concern anyway |
| 16:25.26 | L84Supper | he said "mediocre electrical engineer" that would require step up :) |
| 16:25.46 | rm | I don't remember the exact words |
| 16:26.08 | rm | but I got that bit to mean the A10 is kind of solid and rather tolerant to various blunders of PCB designers |
| 16:26.58 | focus | mnemoc: eoma has a few problems - thats why I design infrastructure board to break out all the pins of A10 and thrash out all the issues. |
| 16:27.09 | L84Supper | getting it work is one thing, getting it stable over a wide temp range and conditions is another |
| 16:27.49 | mnemoc | focus: that can only be done if you marry one particular soc, eoma is supposed to be soc-agnostic |
| 16:28.24 | focus | Actually I never design final boards first and test boards second - so I don't know why all rush to build final boards first. |
| 16:28.46 | mnemoc | but (in theory) it should have been trivial that "even a mediocre electrical engineer can design a stable [eoma68] board with it" |
| 16:29.57 | focus | The high speed stuff close to the CPU, low speed stuff is all pinned out - at least I hope so! |
| 16:30.37 | mnemoc | but after more than a year, it didn't happen, and ended up been designed closed by wits-tech :| |
| 16:30.47 | focus | SAD!!!!!!! |
| 16:30.54 | mnemoc | and in the wrong formfactor |
| 16:31.15 | focus | and loose money for Allwinner - because they don't do datasheets |
| 16:31.24 | focus | Doh! Going in circles!! |
| 16:31.33 | L84Supper | that is mostly due to the attitude of the mastermind behind eoma68 |
| 16:32.08 | hramrach | I think if he was really bent on making the board he would have one by now |
| 16:32.25 | hramrach | there is Olinuxino, Cubieboard, .. |
| 16:32.38 | hramrach | Mele, MK802 and clones .. |
| 16:32.55 | mnemoc | and cpinc rogers com so-dimm + reference carrier board |
| 16:33.55 | mnemoc | as a not-EE I can't tell if something is hard/easy in that arena... i can only be sad |
| 16:34.00 | focus | I nearly fell into same trap of no info - but some people come forward with info and I was able to finish BGA diagram |
| 16:34.46 | *** join/#arm-netbook vinifm (~vini@177.19.132.23) |
| 16:35.24 | hramrach | oh, and that pcduino thing |
| 16:36.22 | mnemoc | hramrach: uh. first time I hear about that one |
| 16:36.32 | hramrach | was on the ML |
| 16:38.59 | mnemoc | focus: /q |
| 16:41.33 | hramrach | they don't specify SoC but by the features and price it looks like AW A1x |
| 16:42.31 | hramrach | prohibitive shippping costs outside US and somewhat more expensive board but for US people it might be good deal |
| 16:43.30 | focus | mnemoc: you be right. Its the only way things get done. |
| 16:43.58 | *** join/#arm-netbook alcides (~alcides@unaffiliated/alcides) |
| 16:44.19 | Turl | A10 yep hramrach |
| 16:44.20 | Turl | https://s3.amazonaws.com/pcduino/Hardware/PC+Duino_V01-20130128.pdf |
| 17:07.13 | *** join/#arm-netbook Eigen (~Eigen@S0106001310f0b056.vn.shawcable.net) |
| 17:08.37 | *** join/#arm-netbook rsalveti (~rsalveti@unaffiliated/rsalveti) |
| 17:10.46 | libv | yay, seems to work. now for some shopping and then drink, and tomorrow i'll push out a cleaned up version of this code |
| 17:11.04 | libv | and then we can install mali libs with surprising ease |
| 17:21.41 | SPG | 03Wei 05master f102550 06rhombus 03allwinner_a10/orders/ArrayBo.mdwn * 14http://git.hands.com/?p=rhombus.git;a=commitdiff;h=f102550 |
| 17:33.16 | *** join/#arm-netbook gimli (~gimli@xbmc/staff/gimli) |
| 17:36.10 | *** join/#arm-netbook jochensp (~jochensp@vis.informatik.uni-osnabrueck.de) |
| 17:36.11 | *** join/#arm-netbook Gujs (~Gujs@cpe-92-37-76-193.dynamic.amis.net) |
| 17:36.11 | *** join/#arm-netbook brakew (~ludde@nl102-236-113.student.uu.se) |
| 17:38.34 | *** join/#arm-netbook w00tc0d3 (~smuxi@212.83.63.95) |
| 17:38.34 | *** join/#arm-netbook w00tc0d3 (~smuxi@unaffiliated/w00tc0d3) |
| 17:39.02 | *** join/#arm-netbook ln2 (~ln2@12.sub-75-198-116.myvzw.com) |
| 17:59.07 | *** join/#arm-netbook pcat (~cat@gprs-internet-bcee1b-232.dhcp.inet.fi) |
| 18:12.49 | *** join/#arm-netbook Turl (~Turl@cyanogenmod/maintainer/Turl) |
| 18:34.39 | *** join/#arm-netbook abesis (~abesis@217.131.210.89) |
| 18:39.08 | *** join/#arm-netbook eebrah (~chatzilla@212.49.88.109) |
| 18:46.14 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 19:41.49 | *** join/#arm-netbook focus_it (~focus_it@cpc7-dals17-2-0-cust182.hari.cable.virginmedia.com) |
| 19:48.05 | w00tc0d3 | any interesting things here to talk about? |
| 19:48.32 | *** part/#arm-netbook nemik (~cyanact@c-67-162-60-211.hsd1.il.comcast.net) |
| 19:51.03 | w00tc0d3 | Ellie Goulding - Figure 8 :) |
| 19:51.45 | *** join/#arm-netbook anunnaki (~anunnaki@c-174-54-115-236.hsd1.pa.comcast.net) |
| 20:10.52 | hramrach | focus: seen this one? https://laotsao.wordpress.com/2011/10/29/icubecorp-mvp-harmony-unified-processor-technology/ |
| 20:16.04 | OmegaPhil | err, isnt that called an APU |
| 20:17.36 | *** join/#arm-netbook tinti (~tinti@pdpc/supporter/student/tinti) |
| 20:18.16 | specing | WARNING vapourware detected |
| 20:19.58 | rm | I believe lkcl knows something about this |
| 20:20.27 | jinzo | wasen't there some talks about using that tech gor the "open source" SoC? |
| 20:21.12 | jinzo | oh it's quite old (the blog post) |
| 20:23.15 | jinzo | a local company called Beyond Semiconductors - that used to make/design some specific silicon announced a forray in the tablet CPU/SoC field (http://www.cnx-software.com/2013/02/06/beyond-semiconductor-ba25-application-processor/ ) |
| 20:23.23 | jinzo | we'll see what comes out of it. |
| 20:23.53 | specing | Beyond Semiconductor, a company founded in 2005, and based in Ljubljana, Slovenia |
| 20:23.57 | specing | WTF |
| 20:23.59 | specing | here?!? |
| 20:24.05 | specing | no way... |
| 20:24.07 | jinzo | yeah, you didn't know of them? |
| 20:24.21 | jinzo | A year or so ago they had quite a big hiring action |
| 20:24.22 | specing | Or maybe they found a way to use the 2um fab at uni :D |
| 20:25.11 | jinzo | they're part of the uni lj incubator (or at least were) |
| 20:25.26 | specing | scratches head |
| 20:25.54 | jinzo | I tought everyone knows them around here :P |
| 20:26.33 | jinzo | (and note, I don't think they're actually making the silicon, probably only license it out - and quite some big licensees.) |
| 20:27.22 | roxfan | ba is based on openrisc btw |
| 20:29.42 | specing | I see mentions of wishbone, yes |
| 20:29.47 | jinzo | don't know much about it, but I sure hope they'll be GPL compliant |
| 20:30.18 | jinzo | because that's their only way of making a dent in this market with BA25 |
| 20:30.20 | jinzo | imo. |
| 20:34.21 | specing | otherwise we can go bang at their door :) |
| 20:35.17 | jinzo | yeah, they were listed at the LUI building (that's accross the Mobitel devops center and besides the slovenian defence ministry) |
| 20:35.35 | jinzo | but I don't think they were actually located there. |
| 20:40.54 | *** join/#arm-netbook vinifm (~vini@177.19.132.23) |
| 21:15.05 | hramrach | specing: as for vaporware they offer an evb with 600MHz dualcore processor |
| 21:16.06 | hramrach | that's not impressive performance-wise |
| 21:16.44 | hramrach | for the core to be useful they should pack more in the chip and up the clock a bit |
| 21:17.18 | hramrach | well, the 600MHz one could do something too |
| 21:17.50 | hramrach | but is simewhat behind the competition performance wise |
| 21:25.46 | hramrach | hmm, the ba cores are mentioned in th news but cannot find anything actually using them. Cannot find even news mentioning ic1 but it's also very unsearchable |
| 21:25.58 | hramrach | pff |
| 21:30.16 | roxfan | there was some wireless chips company bought by nxp recently |
| 21:31.41 | roxfan | this one http://www.nxp.com/products/rf/wireless_microcontrollers/JN5148.html |
| 21:31.58 | roxfan | it's not really mentioned in docs but the core is a BA |
| 21:32.00 | hramrach | OmegaPhil: an APU is something AMD does which has CPU and GPU cores on one die |
| 21:32.21 | hramrach | by their terms pretty much all ARM SoCs with graphics are APU |
| 21:33.19 | roxfan | https://github.com/teco-kit/Jennisense/wiki/Jennicgettingstarted |
| 21:33.26 | hramrach | the thing icube is making has one unified core which handles both general computing and media/graphics/.. |
| 21:34.25 | OmegaPhil | kk |
| 21:36.20 | hramrach | roxfan: interesting |
| 21:37.21 | hramrach | but more PIC class device than a SoC |
| 21:42.18 | hramrach | $1k evb ;-) |
| 21:48.19 | *** join/#arm-netbook hp__ (~kvirc@d5153E228.access.telenet.be) |
| 22:02.38 | *** join/#arm-netbook leowt (~leowt@a109-51-172-239.cpe.netcabo.pt) |
| 22:06.59 | *** join/#arm-netbook Eigen (~Eigen@S0106001310f0b056.vn.shawcable.net) |
| 22:12.43 | *** join/#arm-netbook Eigen_ (~Eigen@S0106b8c75dc9a198.vn.shawcable.net) |
| 22:26.35 | *** join/#arm-netbook anunnaki (~anunnaki@174.54.115.236) |
| 22:44.18 | *** join/#arm-netbook leowt (~leowt@a109-51-172-239.cpe.netcabo.pt) |
| 22:51.06 | *** join/#arm-netbook anunnaki (~anunnaki@174.54.115.236) |
| 23:41.06 | *** join/#arm-netbook techn_ (~quassel@a91-152-35-60.elisa-laajakaista.fi) |