| 00:49 | dv_ | otavio: nevermind, saw the memset fix in the mailing list that addresses the gcc 4.8 problem. thanks to a typo, they werent being applied. |
| 08:09 | cbxbiker61 | well i got the developer board running |
| 08:09 | cbxbiker61 | interesting comparison... |
| 08:09 | cbxbiker61 | this is a memory speed test... |
| 08:10 | cbxbiker61 | sheevaplug 380 MB/s |
| 08:10 | cbxbiker61 | original cubox 1520 MB/s |
| 08:11 | cbxbiker61 | developer board 3900 MB/s |
| 08:12 | cbxbiker61 | i've got to get to bed, dentist appt tommorow morning |
| 08:13 | dbsx | cbxbiker61: 3900MB is great. My dentist is as 9AM. Good luck |
| 08:20 | jnettlet | cbxbiker61, dbsx, yeah They put the "good" memory in these guys. |
| 08:20 | jnettlet | can't wait to see how the 64-bit 1066 ddr performs. |
| 09:59 | jnettlet | rabeeh, Currently you are using USDH2 for the sdhc card. As best as I can tell that port does not support 1.8v signalling to support UHS-I. Is there any reason you can't use USDH3? |
| 09:59 | jnettlet | or am I misunderstanding something? |
| 11:46 | wumpus | cbxbiker61: nice stats, what do you use for memory speed testing? |
| 13:20 | jnettle | 13:20 * jnettlet wonders how much bandwidth and man-hours are wasted by people on the internet fighting over which is better Android or IOS? |
| 13:23 | shesselba | jnettlet: with microsoft releasing one windows PITA after the other, Linux vs. Windows isn't that interesting anymore :P |
| 13:24 | jnettlet | shesselba, sure but the start button is now back. |
| 13:24 | jnettlet | I just want to mute all the senseless gibberish on the internet. It is just white-noise at this point. |
| 13:25 | shesselba | ahh, please share if you ever find a way for it! |
| 13:26 | jnettlet | wumpus, did I understand that you just finished a port to u-boot 2013? |
| 13:57 | dv_ | using the VPU on my carrier one now \o/ |
| 14:03 | otavio | :-) |
| 14:03 | otavio | rabeeh: the boards arrived |
| 14:03 | jnettlet | dv_, did you get a Yocto build working? |
| 14:04 | rabeeh | otavio: great |
| 14:04 | rabeeh | dv_: Great !!! |
| 14:10 | dv_ | jnettlet: yes |
| 14:18 | wumpus | jnettlet: eh, I didn't do anything with u-boot |
| 14:18 | jnettlet | wumpus, okay. thanks for getting back. |
| 14:24 | dv_ | _rmk_: the race condition patches you mentioned, what kernel fork and version are they based on? |
| 14:30 | jnettlet | dv_, they are based on rabeeh's kernel for the Cubox |
| 14:32 | purch | dhl got my C1 two hours ago, how fast does it travel to north europe? |
| 14:33 | dv_ | jnettlet: a colleague tried to apply them to the imx kernel |
| 14:33 | dv_ | but the differences are pretty large |
| 14:34 | dv_ | thats not unexpected though, since _rmk_ told me they may not apply cleanly |
| 14:34 | jnettlet | dv_, well the vivante codebase is very different v2 to v4 |
| 14:35 | jnettlet | I am working on cleaning up the source for the Marvell chips and then it needs to be ported to Freescale |
| 14:39 | jnettlet | right now I am working on sorting out gpu frequency scaling with common clock. It was something that I never implemented because of the way the XO hardware works. Now I think I want it in the driver. |
| 14:42 | jnettlet | dv_, there is also another race that _rmk_ and I were discussing before deciding the right way to "fix" the problem is a new kernel driver. I have a patch worked out in my head for that also. |
| 14:43 | jnettlet | that should hopefully fix the remaining races. |
| 14:49 | dv_ | alright |
| 16:10 | dv_ | very interesting. there are efforts to mainline the VPU and IPU support |
| 16:10 | dv_ | see Robert Schwebels response here: https://community.freescale.com/message/353601#353601 |
| 16:31 | wumpus | woohoo, got the carrier one working (on serial) |
| 16:38 | jnettlet | grrr. amazon sent me the wrong color for my case. |
| 16:38 | jnettlet | and it does look like some dremelling will need to be done to get the C1 board to fit. |
| 16:39 | wumpus | now let's get some more decent rootfs on it |
| 16:39 | wumpus | jnettlet: some 'incompatiblity' with the holes? |
| 16:40 | jnettlet | wumpus, yep. |
| 16:41 | jnettlet | between the ethernet and usb ports |
| 16:42 | jnettlet | it actually appears to be the USB port. |
| 16:51 | jnettlet | wumpus, https://plus.google.com/112696520735663897193/posts/7e3sNJg4UfG |
| 16:52 | jnettlet | actually, rabeeh ^ you might want to take a look also. It could just be this case manufacturer |
| 16:57 | wumpus | hm I see, it's misaligned quite a lot |
| 16:58 | jnettlet | it could be this case though |
| 16:58 | jnettlet | and there are various types. |
| 16:58 | wumpus | but if it's the case it wouldn't fit the rpi either |
| 16:59 | wumpus | right, if there's multiple types of the rpi too that complicates things |
| 17:00 | wumpus | hah fbdev is working, that's step 1 |
| 17:02 | wumpus | though somehow it chose 640x480 instead of 1280x1024 |
| 17:04 | dv_ | otavio: renamed plugins to gstreamer-imx |
| 17:04 | jnettlet | dv_, thank you. |
| 17:06 | jnettle | 17:06 * jnettlet out to walk the dogs. |
| 17:13 | cbxbiker61 | ok, r-pi tests out at 340 MB/s, so the new cubox-i has 10 times! the memory bandwidth. |
| 17:13 | otavio | dv_: thx |
| 17:14 | cbxbiker61 | i'll detail the the tests on the forum when i get back from the dentist |
| 17:14 | cbxbiker61 | http://www.alasir.com/software/ramspeed/ramsmp-3.5.0.tar.gz |
| 17:15 | wumpus | cbxbiker61: thanks |
| 17:16 | dv_ | nice. I can play 1080p video smoothly |
| 17:17 | dv_ | but for some reason, the video mode is set to 640x480, even though I specified 1280x720 in the kernel command line |
| 17:17 | otavio | dv_: edid? |
| 17:17 | dv_ | maybe |
| 17:18 | dv_ | I'll try to force 720p in the xorg.conf |
| 17:20 | wumpus | dv_: same problem that I have, I specify 1280x1024 but get 640x480 |
| 17:24 | wumpus | I use a hdmi->dvi adapter to conenct to a DVI monitor that may be causing it |
| 17:25 | dv_ | me too |
| 17:25 | dv_ | but VPU, IPU, and the GPU's direct textures all work nicely |
| 17:26 | wumpus | what kernel and rootfs are you using? |
| 17:26 | dv_ | not sure if a power supply with 1A is a good idea with HD video though :) |
| 17:26 | wumpus | seems the default kernel has no galcore |
| 17:26 | dv_ | I am using the kernel from github.com/SolidRun/linux-imx6.git |
| 17:27 | dv_ | it is a forked boundarydevices linux-imx kernel |
| 17:27 | dv_ | I build both kernel and rootfs with yocto |
| 17:27 | wumpus | I'm using the prebuilt one from the wiki, i thought it would be that one |
| 17:27 | dv_ | I already gave otavio my changes so he and his colleagues can add c1 support to meta-fsl-arm |
| 17:28 | dv_ | yes, the prebuilt one doesnt have galcore. or gstreamer. |
| 17:28 | dv_ | if you want to build it yourself, don't fall into the same trap I fell into, and use gcc 4.7 or earlier. not 4.8. |
| 17:37 | wumpus | what root fs are you using? ubuntu? |
| 17:45 | dv_ | well... yocto :) |
| 17:46 | dv_ | its a source distro |
| 17:53 | jnettlet | dv_, can you post your dmesg and Xorg logs when you get a chance? |
| 17:57 | dv_ | jnettlet: for the xorg.conf, look here: https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-graphics/xorg-xserver/xserver-xf86-config/mx6/xorg.conf |
| 17:58 | jnettlet | dv_, actually I am looking for the logs. I want to see if I can figure out why the resolutions aren't detected properly |
| 17:58 | dv_ | dmesg here http://pastie.org/private/uidlarqneodzytz5h7ugkq |
| 17:58 | jnettlet | you may also want to build fbset into your image if the command isn't there. |
| 17:59 | dv_ | xorg.0.log http://pastie.org/private/htwgdttgagvacroatxw2xw |
| 17:59 | dv_ | its not just X that is using 640x480 though |
| 17:59 | dv_ | its the framebuffer as well |
| 18:00 | dv_ | also, just like wumpus, I am using a DVI<->HDMI connector |
| 18:04 | wumpus | I remember I needed some patch for the gk802 (imx6 quad) kernel to get dvi<->hdmi to work at all, but that was quite some time ago, and this problem is different as there is image out just not the right resolution |
| 18:06 | jnettlet | what do you guys have in /sys/class/graphics/fb0/modes |
| 18:06 | wumpus | that was this patch https://github.com/boundarydevices/linux-imx6/commit/7d8752905c118af9063738a533227de0b2f6ecd4 |
| 18:07 | wumpus | V:640x480p-60 |
| 18:07 | wumpus | V:640x480p-60 |
| 18:08 | dv_ | U:800x600p-56 |
| 18:08 | dv_ | V:640x480p-60 |
| 18:08 | dv_ | V:640x480p-60 |
| 18:09 | jnettlet | wumpus, yeah that looks like a different problem. |
| 18:14 | nikitis | Why so small resolution? |
| 18:14 | nikitis | There are no TV's that small anymore |
| 18:15 | jnettlet | yes but it is the fallback spec for hdmi. A VGA resolution takes a lot less bandwidth and is more tolerant to wiggle in the signal. |
| 18:16 | jnettlet | To get any HDMI device certified you need to support 1080p, or 720p and 640x480 |
| 18:16 | _rmk | 18:16 * _rmk_ back 'ome :) |
| 18:17 | jnettlet | _rmk_, welcome back. hope you are fully rested. |
| 18:23 | _rmk_ | well, that doesn't matter as I have three large sticks of Cromer Rock here to enjoy :) |
| 18:29 | jnettlet | okay I will bite. What is that? Sounds like some form of British Crack to me. |
| 18:34 | _rmk_ | http://en.wikipedia.org/wiki/Rock_%28confectionery%29 |
| 18:36 | _rmk_ | the ones I have are 1" dia by 1ft long |
| 18:38 | jnettlet | oh yeah. I have seen that here in Denmark |
| 18:41 | jnettlet | _rmk_, what is with this feet and inches business? The metric system not good enough for you? I bet you still give weights in stones though. |
| 18:42 | _rmk_ | jnettlet: I grew up mid-conversion so I just end up using whatever is most convenient |
| 18:43 | jnettlet | fair enough |
| 18:44 | _rmk_ | and yes, particularly for gliding, I use pounds/stone because that's what the aircraft are invariably placarded using |
| 18:44 | _rmk_ | I know, not very European of me |
| 19:55 | rabeeh | i wonder how much of the previous messages were actually sent? |
| 19:55 | rabeeh | jnettlet: the only deviation from the pi's case is about 1.5mm of the ethernet connector that our is standing out |
| 19:55 | rabeeh | we are spinning the board the next week; so maybe it's a good time to fix that. |
| 19:55 | rabeeh | which case is it? |
| 19:55 | rabeeh | what about the other connectors? |
| 19:55 | rabeeh | otavio: one note is that in the first batch we have sent last week (that you got today) the micro USB which is the DC jack is not soldered correctly. |
| 19:55 | rabeeh | if you have soldering station i suggest you solder the mechanical metals beneath the micro USB. |
| 20:01 | rabeeh | jnettlet: looks like design fault - the misaligned usb ports |
| 20:08 | _rmk_ | urgh, I'll do that on mine shortly |
| 20:13 | _rmk_ | is it just that there's insufficient solder, because the mounting holes for it on the underside look filled on mine |
| 20:20 | rabeeh | _rmk_: yeah |
| 20:20 | rabeeh | part of the boards that were sent last week had this issue |
| 20:21 | rabeeh | about third of them. |
| 20:21 | rabeeh | to whom broken that we already sent new one |
| 20:25 | _rmk_ | it looks like the top side could do with a little more solder though |
| 20:25 | _rmk_ | just want to check - it's PbF ? |
| 20:52 | wumpus | etnaviv works on the C1 :) looks like crap at 640x480, but hey |
| 21:04 | rabeeh | wumpus: great |
| 21:04 | rabeeh | what are you running? |
| 21:05 | wumpus | the self compiled kernel from https://github.com/SolidRun/linux-imx6.git, and the original rootfs with a few changes and a cross-compiled etnaviv |
| 21:08 | wumpus | but it only wants to do fbdev at 640x480 on my dvi monitor for some reason, even though I picked 1280x1024 on the kernel command line |
| 21:09 | wumpus | it feels very fast though |
| 21:13 | dv_ | yeah |
| 21:13 | dv_ | main bottleneck is I/O |
| 21:14 | dv_ | (which is obvious) |
| 21:19 | _rmk_ | ok, my kernel now boots with... |
| 21:19 | _rmk_ | Machine: Freescale i.MX6 Quad/DualLite (Device Tree), model: Solid-Run Cubox-i D |
| 21:19 | _rmk_ | L/Solo Carrier-1 Board |
| 21:21 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/carrier-1-3.12-rc3.log |
| 21:23 | _rmk_ | http://www.home.arm.linux.org.uk/~rmk/cubox/0001-ARM-imx-initial-IMX6-Cubox-i-carrier-1-support.patch |
| 21:34 | _rmk_ | rabeeh: I need you to look at this: http://thread.gmane.org/gmane.linux.drivers.devicetree/46115/focus=269646 |
| 21:35 | jnettlet | hmmm my micro-usb connector definitely needs some more solder. Will do that tomorrow. |
| 21:35 | _rmk_ | jnettlet: be careful with it otherwise you can end up filling the inside of it too |
| 21:35 | rabeeh | jnettlet: please do it asap; it will be ripped off pretty quick |
| 21:36 | _rmk_ | that's very easy to do |
| 21:36 | jnettlet | rabeeh, well that is why I wanted to know about the reset hookup. I pretty much just leave the cable in now. |
| 21:36 | _rmk_ | rabeeh: basically what I'm being told is that you _can't_ feed a transmit clock into GPIO 16 even if its configured as ENET_REF_CLK |
| 21:37 | rabeeh | _rmk_: in RMII mode? |
| 21:37 | _rmk_ | rabeeh: and that message above has been confirmed by freescale as correct |
| 21:37 | _rmk_ | for the AR8035, which we run in RGMII mode |
| 21:38 | rabeeh | _rmk_: notice that there is huge confusion about the naming ENET_REF_CLK |
| 21:38 | rabeeh | let me give you the exact situation now - |
| 21:39 | rabeeh | as you can see AR8035 is fully functional on the C1 board; internally we have boards without the crystal 25MHz |
| 21:39 | _rmk_ | the schematic for this bit would be helpful |
| 21:39 | rabeeh | _rmk_: ok |
| 21:39 | rabeeh | that might be best then. |
| 21:39 | rabeeh | _rmk_ in the SOM design; the most complex part was this; and the bring up burned 3 weeks only on this |
| 21:40 | _rmk_ | I can imagine :) |
| 21:40 | _rmk_ | it looks like it's something everyone goes through |
| 21:41 | rabeeh | _rmk_: typically no |
| 21:41 | rabeeh | the board booted in 3hrs after arrival |
| 21:41 | rabeeh | add to that the reset straps of the phy than wants to know which mode it's running and the phy address |
| 21:42 | rabeeh | all those reset straps are pull ups and down from the i.MX6 pins itself |
| 21:42 | rabeeh | for now; the ar8035 is running fine; the ar8030 can only transmit packets |
| 21:43 | rabeeh | on the ar8030 the clock is being generated from the i.MX6; and sent through GPIO_16 |
| 21:43 | rabeeh | the receive side is still not functional and completely ambiguous |
| 21:44 | rabeeh | if you are familiar with RMII; the CRS_DV and the two data receive signals are completely valid and in sync with the clock |
| 21:44 | rabeeh | but somehow the enet refuses to receive those packets |
| 21:47 | rabeeh | _rmk_: withregards schematics; i don't want to throw something that is ambiguos |
| 22:32 | dv_ | rabeeh: with hdmi, you didnt see the 640x480 issue wumpus and I had? |
| 22:32 | dv_ | (we both think this is a hdmi<->dvi problem) |
| 22:48 | rabeeh | dv_: we use pure hdmi |
| 22:51 | rabeeh | there are some reports from boundary devices about hpd - http://boundarydevices.com/dvi-support-on-i-mx6-boards/ |
| 22:52 | rabeeh | but we don't have that since we use level shifter from 5v to 3.3v to detect the monitor |
| 23:31 | rabeeh | dv_: is edid detected correctly? |
| 23:32 | dv_ | how do I determine this? |
| 23:32 | rabeeh | you can find that with 'i2cdump' |
| 23:32 | rabeeh | i mean just read the edid eeprom on the monitor |
| 23:32 | rabeeh | i think it should be 'i2cdump -f 0x2 0x50' |
| 23:33 | rabeeh | you should get first 8 bytes 0x00ffffffffffff00 |
| 23:33 | rabeeh | http://en.wikipedia.org/wiki/Extended_display_identification_data |
| 23:33 | dv_ | i'll check |
| 23:45 | dv_ | I only see a bunch of FF bytes |
| 23:46 | dv_ | no wait |
| 23:46 | dv_ | it starts with 0123456789abcdef , then the rest is 0xff |
| 23:46 | dv_ | argh , stupid me. thats not part of the output :) |
| 23:47 | dv_ | so I get this: http://pastie.org/private/cyq3uegla0voxzqeodvwla |
| 23:56 | rabeeh | dv_: i can't recallt exactly which i2c bus is the hdmi on |
| 23:57 | rabeeh | please try - |
| 23:57 | rabeeh | i2cdump -f 0x0 0x50 |
| 23:57 | rabeeh | i2cdump -f 0x1 0x50 |
| 23:57 | rabeeh | i2cdump -f 0x3 0x50 |
| 23:57 | rabeeh | the third one might not work at all |
| 23:57 | dv_ | ah. 0x1 worked |
| 23:58 | rabeeh | ok. what's the output? |
| 23:58 | dv_ | http://pastie.org/private/k9cxrlkiszxxszzeoyo7hq |