| 09:54 | jas-hacks | rabeeh: I agree with your conclusion that GPU load causes DDR power consumption. This is what I seen from the other boards. |
| 10:35 | _rmk_ | jnettlet: Fabio has reinvented uboot for the carrier-1 |
| 10:35 | _rmk_ | you have been pushing your patches upstream? |
| 10:36 | jnettlet | _rmk_, I think he is just pushing my patches for me |
| 10:36 | jnettlet | last I looked they had my copyright |
| 10:36 | _rmk_ | not sure... the email didn't say anything about you |
| 10:36 | _rmk_ | On a side note: I also have access to the carrier1 board now. I have |
| 10:36 | _rmk_ | sent the initial board support to the U-boot list, so hopefully it |
| 10:36 | _rmk_ | will reach the U-boot 2014.01 release. |
| 10:36 | _rmk_ | If you are interested in my U-boot patches, just let me know. |
| 10:37 | jnettlet | _rmk_, http://www.mail-archive.com/[email protected]/msg124856.html they are my patches |
| 10:37 | jnettlet | well parts of them. |
| 10:38 | jnettlet | Unfortunately he just wouldn't listen when we told him that 1)the board name was changing and 2) we were sorting out DDR timings and hang still |
| 10:40 | jnettlet | it would have been polite to note that they were my patches, but whatever. I have no desire to be drawn into the u-boot community. I am already getting way more emails about other iMX6 u-boot problems than I would like. |
| 10:43 | jnettlet | shesselba_away, you were correct that common clock / device-tree could handle my MMP3 gc clock issues. I just needed to step away from it for a bit and realized where my brain was getting stuck. |
| 10:46 | jnettle | 10:46 * jnettlet is safely back in openfirmware for the next day or so. |
| 12:37 | _rmk | 12:37 * _rmk_ sets a new kernel for the carrier1 building... based on f47671e2d861 in Linus' tree (the ARM merge) |
| 13:10 | _rmk_ | ok, probably later today I'm going to rebase the c1 patches into that commit, which means I won't be maintaining the v3.12 series anymore |
| 13:38 | _rmk_ | I forsee some git bisect activity with the carrier-1 is going to be needed |
| 13:44 | _rmk_ | gah, the FEC driver has been broken |
| 13:46 | _rmk_ | no, that's not it. |
| 13:46 | _rmk_ | it's going to have to be a bisect then |
| 13:49 | jnettlet | _rmk_, I think I have a patch for the FEC driver. |
| 13:51 | jnettlet | _rmk_, this work for you? http://fpaste.org/54008/38443349/ |
| 13:52 | jnettlet | I am assuming that upstream merged the freescale patch that broke this for me. |
| 13:54 | jnettlet | nope upstream looks okay. nevermind |
| 14:06 | _rmk_ | 12 bisect steps... |
| 14:06 | _rmk_ | and each step will require the cubox-i branch merged in |
| 14:07 | jnettlet | ouch |
| 14:07 | jnettlet | hopefully the branch merge is clean |
| 14:07 | _rmk_ | nope |
| 14:08 | _rmk_ | I'm going to need to keep the working v3.12+cubox-i |
| 14:08 | _rmk_ | bah |
| 14:08 | _rmk_ | around so I can load the test kernel on and update everything that ubuntu needs updated (initramfs and /lib/modules) |
| 14:09 | shesselba | jnettlet: great, I'd don't recall what it was about exactly, but great! :) |
| 14:10 | jnettlet | shesselba, about handling multiple device clocks accessed through the same hardware register. |
| 14:10 | shesselba | ahh, ok |
| 14:10 | shesselba | now you have a common provider and let it handle the different clocks? |
| 14:17 | jnettlet | we had a common provider already but we were using old clock enabling code that had everything hard coded. I had to add enable_masks to the device-tree that I could use to distinguish the different clocks. |
| 14:17 | jnettlet | a problem with implementing device-tree/common-clock but not going "all the way" |
| 14:37 | shesselba | yeah |
| 14:55 | _rmk_ | well, whatever is happening, it's needing a power cycle to restore things back to a workable state |
| 15:03 | jnettlet | oh those are always fun |
| 15:04 | _rmk_ | well, that one worked. |
| 15:05 | _rmk_ | somewhere between the H8300 merge and the nfs merge |
| 15:06 | _rmk_ | at least if it boots, I can just run my ./build-cubox-i.sh script to build and load the next iteration on it without any hastle |
| 15:59 | _rmk_ | I think I know what's causing it |
| 16:03 | _rmk | 16:03 * _rmk_ short-circuits the bisection to the point where I think the bad commit is, thereby saving 4 iterations |
| 16:13 | _rmk_ | rabeeh: here? |
| 16:16 | _rmk_ | rabeeh: what is the ENET_RXD0 ball connected to? |
| 16:16 | _rmk_ | is it also connected to one of the RGMII balls? |
| 16:31 | _rmk | 16:31 * _rmk_ decides he hates DT even more for causing weird problems |
| 16:46 | _rmk_ | okay, fixing that in DT fixes that problem |
| 16:47 | _rmk_ | and now I have two audio devices... one for the HDMI and one of the SPDIF socket |
| 16:47 | _rmk_ | and the SPDIF socket works :) |
| 16:47 | _rmk_ | but... |
| 16:47 | _rmk_ | (there always has to be a but) |
| 16:47 | _rmk_ | pulseaudio won't output to both simultaneously |
| 16:53 | _rmk_ | and I think pulseaudio went crap after the first track finished |
| 17:08 | _rmk_ | hmm. |
| 17:08 | _rmk_ | carrier-1 isn't playing back some of my mpegs properly |
| 17:09 | _rmk_ | mp3s |
| 17:10 | _rmk_ | pulseaudio[1546]: [alsa-sink] alsa-sink.c: ALSA woke us up to write new data to the device, but there was actually nothing to write! |
| 17:11 | _rmk_ | pulseaudio[1546]: [alsa-sink] alsa-sink.c: Most likely this is a bug in the ALSA driver 'snd_soc_imx_spdif'. Please report this issue to the ALSA developers. |
| 17:11 | _rmk_ | pulseaudio[1546]: [alsa-sink] alsa-sink.c: We were woken up with POLLOUT set -- however a subsequent snd_pcm_avail() returned 0 or another value < min_avail. |
| 17:34 | _rmk_ | and... now spdif doesn't work at all anymore |
| 17:34 | _rmk_ | imx-sdma 20ec000.sdma: Timeout waiting for CH0 ready |
| 17:34 | _rmk_ | fsl-spdif-dai 2004000.spdif: ASoC: 2004000.spdif hw params failed: -110 |
| 18:05 | _rmk_ | gah, time is also broken. how the fsck can they have broken that! |
| 18:38 | _rmk_ | oh, that's good. it's the spdif driver doing it, resetting the ipg clock rate, which then affects the system timers. |
| 18:39 | jnettlet | woops |
| 18:44 | _rmk_ | and that explains why SDMA failed. |
| 18:44 | _rmk_ | the ipg clock feeds the SDMA engine... |
| 18:44 | _rmk_ | "but the SDMA core is physically limited to a |
| 18:44 | _rmk_ | maximum 104 MHz frequency |
| 18:45 | _rmk_ | well, if its running at 132MHz... |
| 19:05 | nikitis | Hello, can someone verify my order? I already had one issue with it not going through. |
| 19:06 | jnettlet | nikitis, you are better off writing to the customer service on the website. This channel is for dev and engineering. |
| 19:07 | nikitis | what about forums access. I cannot post. I can log into the front page, but when I go to forums to use the same username it doesn't work, Are they different? |
| 19:07 | jnettle | 19:07 * jnettlet has no idea. |
| 19:09 | nikitis | ah yes it's seperate |
| 19:17 | _rmk_ | well, knocking out the ipg clock from spdif sorted that issue out... now I just need to get rid of the vinyl effect. |
| 20:01 | _rmk | 20:01 * _rmk_ wonders how rabeeh is driving the spdif output |