| 01:39 | taz_ | good night |
| 02:06 | shesselb | 02:06 * shesselba wonders why there are no HDMI-HEC-to-Ethernet break-out boxes |
| 04:38 | zombiehoffa | will the cheapest cubox-i1 handle xbmc no problem? |
| 04:47 | cbxbiker61 | the cheapest cubox-i should be fine, although personally i'd always opt for at least a dual-core, since xbmc is heavily threaded |
| 04:48 | zombiehoffa | I bought the most expensive one as soon as they announced it, but am reading more and thinking I bought way too much power for what I want to do. |
| 04:48 | zombiehoffa | will probably buy the cheapest or second cheapest for my secondary tv |
| 04:49 | zombiehoffa | If it had dual hdmi out I would replace my linux desktop with it. |
| 04:50 | cbxbiker61 | i don't think anyone has done an arm based dual hdmi, probably be a while before they do |
| 04:52 | cbxbiker61 | the extra cores on a xbmc box would be an advantage for audio transcoding, depending on what you're feeding it could be useful |
| 04:52 | zombiehoffa | mostly 720p mkv files x264 video and mostly mp3 audio, but sometimes it's the fancy 5.1 audio stuff |
| 04:53 | zombiehoffa | sometimes 1080p mkv that x264 |
| 04:53 | zombiehoffa | occasional diet of avi's, mpgs, etc. |
| 04:53 | zombiehoffa | avi's would mostly be divx |
| 04:53 | cbxbiker61 | the 720p/x264 wouldn't be a problem at all on the single-core |
| 04:54 | zombiehoffa | very rarely some some wmv files or whatever crapple is calling their proprietary audio/video formats now |
| 04:54 | cbxbiker61 | the dual may be better for the 5.1 getting down-mixed |
| 04:55 | cbxbiker61 | high bitrate 1080p, you |
| 04:56 | cbxbiker61 | high bitrate 1080p, you'd be better off with the two highest level cubox-i's, since their memory bandwidth is higher |
| 04:56 | zombiehoffa | so I may not be so overspecced as I thought.. |
| 04:57 | cbxbiker61 | although, i've already benchmarked the carrier-1, and it's bandwidth is double what the older cubox was, so i guess we'll see |
| 04:57 | zombiehoffa | I guess I should look forward to the new version that will come out next christmas that can support 4k video;) the cheapo version of that will handle everything I will possibly want to do and then some;) |
| 12:37 | NotRelevant | http://www.cnx-software.com/2013/11/07/via-unveils-vab-820-pico-itx-board-powered-by-freescale-i-mx6-quad/ |
| 14:40 | _rmk_ | just looking at the libcec work for IMX, it's buggy. There's no way the logical address allocation stuff can work as per the HDMI 1.3a spec with that backend. |
| 14:40 | _rmk_ | it'll select the first logical address for the class of device, and use that irrespective of whether there's any other device using it. |
| 14:41 | _rmk_ | why? because there's no reporting of the success/failure to send a message. |
| 14:41 | _rmk_ | more precisely, there's no handling of whether the message was acknowledged or not. |
| 15:02 | _rmk | 15:02 * _rmk_ wonders if that's because the imx6 silicon basically doesn't work |
| 15:04 | jnettlet_ | _rmk_, have you seen this blog post? http://stephan-rafin.net/blog/2013/09/30/i-mx6-cec/ |
| 15:05 | _rmk_ | yes, that's the one I've been looking at. |
| 15:06 | jnettlet_ | so his is working just because he only has a single CEC device? |
| 15:06 | _rmk_ | I guess so |
| 15:06 | _rmk_ | he always says every message transmitted was successful |
| 15:07 | _rmk_ | which, if you consider that when doing logical address allocation, you transmit a ping to the address you're going to assume, and if it _fails_ you use that logical address... |
| 15:08 | _rmk_ | if you get success for everything, you end up using logical address 15 (the broadcast/unassigned/too-many-devices) address |
| 15:09 | _rmk_ | sorry, but my experience of IMX6 hardware so far is it's totally buggered up in soo many ways so I'm beginning to get to the point of just not caring anymore about the carrier1 nor the cubox-i. |
| 15:09 | _rmk_ | everything I've come to with IMX6 has been one huge struggle because the hardware doesn't behave. |
| 15:11 | _rmk_ | the documentation is totally crap as well; it doesn't document many of the registers on the chip, and when it does it omits lots of information (unlike Marvell's docs) |
| 16:25 | MikeSet | 16:25 * MikeSeth tiptoes around rabeeh |
| 16:26 | MikeSeth | shipping date soon.. shipping date soon :P |
| 16:35 | jnettlet_ | _rmk_, while you were at the summit did you hear any of the chatter about linux dropping the fbdev api and how Android was going to deal with it? |
| 16:39 | _rmk_ | didn't hear anything like that, I don't think fbdev was discussed |
| 16:40 | _rmk_ | I've decided to debug this CEC thing a slightly different way... use a divider on the CEC line to attenuate, and feed it into the sound card :) |
| 16:40 | _rmk_ | capture at 96kHz and use audacity to measure the bit timings. |
| 16:41 | _rmk_ | and... |
| 16:41 | _rmk_ | the start bit low period is 328 samples long. |
| 16:41 | _rmk_ | 328 samples / 96kHz = 3.42ms |
| 16:42 | _rmk_ | low -> high -> low = 400 samples. / 96kHZ = 4.2ms |
| 16:42 | _rmk_ | what does the spec say... |
| 16:43 | _rmk_ | nominal 3.7ms (3.5 to 3.9ms) and 4.5ms (4.3 to 4.7ms) |
| 16:43 | _rmk_ | so basically the iMX6 is nonconformant. |
| 16:44 | _rmk_ | so, CEC is just not worth bothering with on this chip. |
| 16:44 | jnettlet_ | is CEC driven by the same clock as the HDMI signal? |
| 16:45 | jnettlet | 16:45 * jnettlet_ is wondering if it has to do with the way clocks are configured to drive HDMI |
| 16:45 | _rmk_ | no, it's driven by the 32768Hz clock, which gets synchronised by a 66MHz IPG clock |
| 16:46 | jnettlet_ | is it programmable? |
| 16:46 | _rmk_ | nope |
| 16:47 | _rmk_ | and I can't imagine that my sound card would be 8% out. |
| 16:48 | _rmk_ | you'd have to run it at about 30kHz to get the right start bit |
| 16:48 | jnettlet_ | I ran through some of the sub forum posts off of that main blog post. It seems as there may be a difference in CEC depending on if the SOC is a quad vs a solo/dl |
| 16:49 | jnettlet_ | _rmk_, sorry it was the plumber's conference that the topic was discussed. Finally found the lwn article. http://lwn.net/Articles/569704/ |
| 16:51 | _rmk_ | I wonder what's meant by a "ganged CRTC" |
| 16:54 | jnettlet_ | _rmk_, http://lwn.net/Articles/565422/ |
| 16:55 | jnettlet_ | it is about having to use multiple devices to drive a single CRTC to output to a display. |
| 17:08 | _rmk_ | not sure I understand that. |
| 17:08 | _rmk_ | I guess something to check is that other stuff on the 32768Hz clock runs at the right rate. |
| 17:10 | _rmk_ | but it's unlikely to be that the crystal is wrong... 8% is far too much |
| 17:29 | _rmk_ | Rabeeh... what have you done with the 32kHz? |
| 17:30 | _rmk_ | why is it ticking at 36kHz? |
| 17:30 | _rmk | 17:30 * _rmk_ rechecks the measurement... over 100sec. |
| 17:32 | _rmk_ | it's running at 36065Hz |
| 17:35 | jnettlet_ | hmmm that is 9% |
| 17:37 | _rmk_ | noooo, you're not using the internal ring oscillator are you? |
| 17:37 | _rmk_ | In addition, if the clock monitor determines that the OSC32K is not present, then the source of the 32 |
| 17:38 | _rmk_ | K |
| 17:38 | _rmk_ | will automatically switch to a crude internal ring oscillator. The frequency range of this block is |
| 17:38 | _rmk_ | approximately 10-45 kHz. It highly depends on the process, voltage, and temperature. |
| 17:39 | _rmk | 17:39 * _rmk_ dismantles the carrier-1 to check whether there's a 32kHz crystal anywhere |
| 17:39 | Bluerise | I don't think so... let me check my irc logs |
| 17:40 | Bluerise | ah, or not, it was about the ethernet crystal |
| 17:43 | _rmk_ | ok, rabeeh asked me what I'd want to do with the bit of board space where the 25MHz crystal next to the ethernet phy is... I now have an answer for that. |
| 17:43 | _rmk_ | replace it with a 32.768kHz crystal. |
| 17:44 | jnettlet_ | that point is crystal clear |
| 17:45 | _rmk_ | see section 4.5.2 in IMX6SDLCEC.pdf |
| 17:55 | jnettlet_ | yep already read it. It should switch over automagically. |
| 17:55 | jnettlet_ | except it doesn't exist. |
| 17:58 | _rmk_ | yep, the crystal doesn't exist, so it switches to the internal "crude" ring oscillator |
| 17:59 | _rmk_ | which might generate some kind of frequency somewhere between 0Hz and 1MHz if you're lucky. |
| 18:03 | _rmk | 18:03 * _rmk_ just hopes SolidRun haven't manufactured the next round of boards yet |
| 18:20 | _rmk | 18:20 * _rmk_ ponders the HDMI audio problem with Kconfig... |
| 18:42 | _rmk | 18:42 * _rmk_ kills the direct dependence on the irq handling between imx-hdmi and dw-hdmi-audio |
| 18:57 | _rmk_ | thereby allowing dw-hdmi-audio's interrupt handler to run in hardirq context rather than having to be pushed out to the thread needed for hdmi's handler |
| 19:11 | _rmk_ | that's better. |
| 23:04 | dv_ | so, no CEC ? |
| 23:07 | lioka | cmon, soldering xtal aint no that big problem :] |
| 23:13 | _rmk_ | lioka: if you want to dig up the imx6 BGA to get on the right balls... |
| 23:14 | _rmk_ | one of the crystal connections will be grounded, and there's a ground pin right next door |
| 23:14 | _rmk_ | dv: no CEC unless you're lucky with the internal ring oscillator |