| 03:31 | mhoney | will support for the original cubox and cubox pro be dropped? |
| 06:11 | jnettlet | mhoney, I am working on some new cubox code right now :-) |
| 09:27 | jnettlet | shesselba, with all the device-tree patches you have merged upstream should the cubox just boot on mainline now? |
| 11:29 | jnettle | 11:29 * jnettlet has finally sorted out device-tree booting the original cubox and ION mm. now to finish userspace |
| 13:00 | rabeeh | jnettlet: anything new with regards spl? |
| 13:20 | jnettlet | rabeeh, I haven't checked the list in the last few days to see if anyone has done anything with the assembly part. I haven't had time myself to get into it. |
| 13:27 | rabeeh | ok. |
| 13:27 | rabeeh | so i guess we will have three u-boots then |
| 13:32 | _rmk_ | why do we need three? |
| 13:32 | jnettlet | rabeeh, well hopefully not. If I can get caught up with other code the assembly is no problem. I was just working on the early boot loader code for the XO-4 earlier in the week. |
| 13:33 | jnettlet | I assume we just need to read out the chipid and then branch to different ddr configs accordingly, then jump off to the normal u-boot init sequences |
| 13:35 | jnettlet | _rmk_, 1 for 32-bit 800Mhz, 1 for 64-bit 800Mhz 1 for 64-bit 1066Mhz |
| 13:36 | rabeeh | and the last one will auto detect if it's i2u or i4p and accordingly set total memory to 1GB or 2GB |
| 13:37 | jnettlet | I assume the cpuid is stored in the SOC registers |
| 13:37 | rabeeh | yes. |
| 13:37 | rabeeh | from fsl point of view; those are two dies |
| 13:37 | jnettlet | okay |
| 13:38 | rabeeh | the first die is solo/dual lite; and second is dual/quad |
| 13:38 | rabeeh | first is wire bond bga (probably that's why they limit ddr to 400mhz) |
| 13:38 | rabeeh | second is flip chip; so better heat dissipation and can get faster ! |
| 13:38 | rabeeh | (thus you can overclock the dual / quad to 1.2ghz; and even more |
| 13:39 | rabeeh | we putting on the quad samsung memories up to 1600 |
| 13:39 | rabeeh | 1600Mbps |
| 13:39 | rabeeh | so overclockers can have a party :) |
| 13:40 | jnettlet | or us boring non-overclockers can have a nice stable system :-) |
| 13:43 | rabeeh | overclocking is sometimes a christmas present |
| 13:43 | rabeeh | you work and work and work on optimizing thing and then overclocking it will put the extra |
| 13:44 | rabeeh | for C1; 4 out of 5 systems were overclocked |
| 13:44 | rabeeh | the overclocked system failed for Rudi; but i know why |
| 13:44 | rabeeh | it's simply stretched overclocking and not the final overclocking i'm looking for |
| 13:45 | rabeeh | by stretched i mean it's configured for 400mhz and overclocked to 528 while keep the 400mhz cas latency, tRCD etc... |
| 13:45 | rabeeh | if you configure it to 528MHz and run it at 528MHz it would run without issues; |
| 13:45 | rabeeh | but for now i'm battling with my biggest enemy - time |
| 13:47 | _rmk_ | they say time machines haven't been invented yet - I disagree, because where does all the time go. :) |
| 13:49 | Coolgeek | ask doctor who |
| 13:51 | _rmk_ | Coolgeek: I want no timey wimey explanations |
| 13:53 | Coolgeek | hehe |
| 14:49 | jnettlet | ah just added a counterweight to the front bottom of my cubox. it can sit on the edge of the desk without rocking back now. |
| 15:04 | dv_ | jnettlet: I think you told me the audio device on the c1 is just a DAC connected over I2S, right? |
| 15:04 | dv_ | no fancy usb audio chip? |
| 15:05 | jnettlet | dv_, _rmk_ would know better, but from what I have looked at in the 3.0.35 code that is correct. |
| 15:05 | dv_ | good. I need that. |
| 15:05 | dv_ | usb audio chips can buffer in unpredictable ways |
| 15:06 | jnettlet | I still haven't played with audio myself yet. |
| 15:10 | jnettle | 15:10 * jnettlet thinks we probably need a support chart somewhere for various kernel revisions. |
| 15:10 | jnettlet | _rmk_, you have audio sorted in mainline on the C1, right? |
| 15:12 | jnettle | 15:12 * jnettlet is still tracking down why the vivante driver is dog slow on 3.10 kernels |
| 15:16 | _rmk_ | jnettlet: yep, both hdmi and spdif |
| 15:17 | jnettlet | excellent. |
| 15:17 | _rmk_ | I think there's also PWM-based audio, how good that is I'm not sure |
| 15:18 | Wizzup | so I've been out of the cubox loop for a while, still have the device |
| 15:18 | Wizzup | I heard about the etnaviv driver |
| 15:18 | Wizzup | but couldn't find any mention on the wiki |
| 15:18 | Wizzup | I'll probably update the gentoo guide in a bit |
| 15:18 | jnettlet | Wizzup, just google for it. The project is located on sf.net |
| 15:19 | Wizzup | sure, I just expected it to be mentioned on the sr wiki somewhere |
| 15:19 | Wizzup | ;-) |
| 15:19 | rabeeh | _rmk_: the c1 board has pwm signals connected to the audio interface |
| 15:19 | rabeeh | two pwms |
| 15:19 | jnettlet | Wizzup, it is still a wip. There is GLESv2 support but a 2d driver hasn't been written for it yet. |
| 15:20 | rabeeh | _rmk_: want snapshot of the schematics? |
| 15:20 | _rmk_ | rabeeh: oooh :) |
| 15:20 | jnettlet | _rmk_, you have tested spdif from the digital coax out? |
| 15:20 | dv_ | Wizzup: you might also want to talk to wumpus |
| 15:21 | rabeeh | _rmk_: i wonder how you are going to tell that to dt |
| 15:21 | rabee | 15:21 * rabeeh should cleanup the schematics and publish it soon |
| 15:22 | dv_ | is the I2S DAC connection on the microsom or on the c1? |
| 15:23 | jnettlet | rabeeh, you can use device-tree overlays to dynamically alter the kernel's live device-tree. |
| 15:24 | rabeeh | dv_: it's on c1 |
| 15:24 | rabeeh | there is a dac; but unconnected |
| 15:24 | dv_ | rabeeh: and what does the cubox i4pro use? |
| 15:24 | jnettlet | well there is a patchset for it. I have not followed if it has been accepted yet. |
| 15:24 | rabeeh | what's connected right now is two pwms for audio jack |
| 15:24 | rabeeh | once you use the dac there is a microphone input too |
| 15:25 | rabeeh | dv_: no analog on CuBox-i :) |
| 15:25 | dv_ | reason why I ask: I'd like to experiment with synchronized audio playback, but I need to be sure there is no additional buffering or other kinds of delays |
| 15:25 | jnettlet | dv_, _rmk_ had simultaneous playback of hdmi and spdif the other day. |
| 15:25 | dv_ | jnettlet: I mean on 2 different devices |
| 15:25 | jnettlet | ah. |
| 15:25 | dv_ | so c1 and cubox-i could play synchronized |
| 15:26 | rabeeh | oh |
| 15:26 | jnettle | 15:26 * jnettlet thought pulseaudio did that. |
| 15:26 | dv_ | er ... not so well. |
| 15:26 | rabeeh | how is the sync being done? |
| 15:26 | dv_ | sure, you can use rtp for that. but I can achieve a phase shift of <2ms with the multiroom solution I wrote for our company |
| 15:26 | dv_ | that cant be done just with rtp, like pulseaudio does |
| 15:27 | rabeeh | is <2ms good enough for audio? |
| 15:27 | dv_ | we do the sync with rtp,rtcp, and synchronized gstreamer pipeline clocks |
| 15:27 | dv_ | yes |
| 15:27 | dv_ | sonos has around 4 ms for example |
| 15:27 | rabeeh | imx6 has isochronous ethernet support |
| 15:27 | dv_ | apply airplay is bigger still |
| 15:27 | dv_ | also, <2ms over wifi I mean |
| 15:28 | dv_ | on ethernet we can reach 400 us sometimes |
| 15:28 | jnettlet | dv_, who do you work for, if you don't mind me asking. |
| 15:28 | dv_ | (there are some bugs that cause uncertainty, its work in progress) |
| 15:28 | jnettle | 15:28 * jnettlet just realized he has never asked before. |
| 15:28 | dv_ | at 400 us, we can start looking at left-right sync, that is, one device, one channel |
| 15:29 | dv_ | jnettlet: streamunlimited, a viennese company specialized in consumer electronics , with focus on highend audio |
| 15:29 | dv_ | one of our projects is using an imx6 , thats how I got in contact with that soc |
| 15:29 | jnettlet | cool |
| 15:30 | dv_ | as much as you people complain about the imx6 idiosyncrasies .... just have a look at stuff from TI for more pain :) |
| 15:30 | dv_ | (thats what we had been using sometimes) |
| 15:32 | Wizzup | jnettlet, dv_: ok, ty, just wanting to try it out later probably. thx |
| 15:37 | _rmk_ | jnettlet: yep, coax spdif works |
| 15:37 | _rmk_ | jnettlet: you need stuff that was merged during this merge window for it though |
| 15:39 | _rmk_ | jnettlet: and no, I didn't have simultaneous audio output via hdmi and spdif - pulse doesn't appear to support that |
| 15:39 | _rmk_ | you can direct different applications to different outputs, but not a single application to two outputs |
| 15:40 | jnettlet | _rmk_, oh there is a plugin I think you need to load |
| 15:40 | _rmk_ | I can see why - it'd have to do some stretching/squeezing if each interface plays back at slightly different rates (due to unsynchronised clocks) |
| 15:40 | jnettlet | load-module module-combine-sink sink_name=combined in your config |
| 17:05 | rabeeh | jnettlet: congrats; your u-boot changes to boot the dual and quad were used almost as-is :) |
| 17:08 | jnettlet | rabeeh, hurray |
| 17:08 | jnettlet | send me a push for whatever changes need to be merged back to the repo |
| 17:09 | rabeeh | ok. |
| 17:09 | rabeeh | will do that probably tomorrow |
| 17:09 | rabeeh | i need to do more testing on the mainline u-boot |
| 17:09 | jnettlet | no hurray. that hardware isn't out in the wild yet :-) |
| 17:10 | rabeeh | i wish android would work as-is on the mainline u-boot so i could through away the 2009.08 version i'm holding only for this |
| 17:10 | rabeeh | jnettlet: next week it will be |
| 17:10 | rabeeh | :) |
| 17:10 | dv_ | \o/ |
| 17:10 | jnettlet | what is android angry about? |
| 17:10 | rabeeh | booti |
| 17:10 | dv | 17:10 * dv_ is looking forward to his i4pro |
| 17:10 | rabeeh | booti command |
| 17:11 | jnettle | 17:11 * jnettlet still has to order one. |
| 17:12 | jnettlet | rabeeh, are you still using the same Android image or do you have a new one I can poke at? |
| 17:12 | rabeeh | new one |
| 17:12 | rabeeh | much more things fixed |
| 17:13 | jnettlet | I could take a look at it. I need a break from vivante, vmeta, ION fun with 3.10 |
| 17:17 | dv_ | I can imagine :) |
| 17:19 | jnettlet | dv_, I am closing in finally. Then I just need to merge the fsl imx 3.10 kernel back into the linaro-lsk kernel and I can publish the repo. Then move onto the next mess. |
| 17:19 | jnettlet | I still need to sort out why the graphics is so much slower on 3.10 vs 3.0.35 |
| 17:19 | jnettlet | very disturbing |
| 17:27 | rabeeh | jnettlet: you can play with the graphics engine clock |
| 17:27 | rabeeh | maybe 3.10 is not setting it correctly? |
| 17:28 | rabeeh | _rmk_: i just had a funny idea; boot from cec |
| 17:28 | rabeeh | i wonder what is the longest cec cable that can be made |
| 17:30 | jnettlet | rabeeh, that was my first thought, but I then tested on the XO-4 which uses a fixed graphics clock of 400Mhz and was getting the same performance. That is a 3.6 kernel. I still have to test on my older 3.0 XO kernel. That is for tomorrow |
| 17:55 | lioka | rabeeh: yeah, after 'boot-from-scsi-scanner-with-bootloader-on-paper' things were soo boring |
| 18:05 | _rmk_ | rabeeh: has the rename of the c1 happened yet? |
| 18:05 | rabeeh | _rmk_: not yet |
| 18:05 | rabeeh | next week is the public poll |
| 18:33 | _rmk_ | jnettlet: do your vivante drivers still do a gcmkVERIFY_OK(gckGALDEVICE_Construct(...)); in the driver setup? |
| 18:58 | jnettlet | _rmk_, they only do that when tearing down the device. |
| 18:59 | jnettlet | oh in driver setup, |
| 18:59 | _rmk_ | the 0.8.0.2905 version does this, and it's broken :) |
| 18:59 | _rmk_ | which I believe is the version you have for olpc |
| 19:01 | jnettlet | this version does. gcmkONERROR(gckGALDEVICE_Construct(...) |
| 19:03 | jnettlet | the versioning is 4.6.9 build 1210 for Marvell chipsets and build 4699 for Freescale chips. Although I am trying to get a newer build from Marvell. |
| 19:14 | hste | I had the 1210 on my first 3.0.35 4.1.0 tree for gk802 using this git https://github.com/ajayramaswamy/linux-imx-gk802/ |
| 19:15 | _rmk_ | hste: bear in mind that some of us don't want to end up being bound by FSLs "you can only use this on FSL devices" stuff |
| 19:15 | _rmk_ | ideally, we'd like to get something for the vivante stuff into mainline which can be used by anyone, so not touching the FSL versions is quite important |
| 19:15 | jnettlet | well my driver is using almost the entire kernel driver from 4699 and just handling the interface to userspace based on driver interface. |
| 19:16 | hste | thats nice, but a big task |
| 19:17 | jnettlet | _rmk_, that is only for the binary libraries |
| 19:19 | hste | jnettlet: so it only the userspace that is closed and not the kernel? |
| 19:19 | jnettlet | it is really annoying because from 1441 to 4699 the userspace definitions have been changed to be able to handle 64-bit architectures... |
| 19:19 | jnettlet | hste, yep, we have GPL licensed kernelspace code. |
| 19:23 | hste | it should be possible to diff the kerneltrees on gpu-viv to find whats changed then |
| 19:29 | jnettlet | yeah I have that all sorted out. It was made more difficult by the way that freescale handle's there kernel version branches, but I have most of the parts I want. |
| 20:39 | _rmk_ | anyone know whether Ami Vider is connected with solid-run in any way? |
| 23:21 | unununium_ | Hello everybody after a long time of not being here! :) |