11:01 | topi` | jnettlet: do you remember if there's any Freescale blog entry about the i.MX6+ or is it just a rumor? |
11:02 | jnettlet | topi`, no it has been officially announced by FSL |
11:02 | topi` | jnettlet: I wish they'd adopt the newest A9 core from ARM, the r0p4 which contains plenty of power mgmt fixes and some improved internals |
11:02 | topi` | so the newest A9 cores are generally 5-10% faster than the original ones |
11:03 | jnettlet | http://linuxgizmos.com/freescale-pumps-out-three-new-i-mx6-socs/ |
11:03 | topi` | I hope they would ditch the 40 nm CMOS process since even the el cheapo stuff like Allwinners are all being made at 28nm nowadays |
11:04 | topi` | hmm, interesting, so there are DualPlus and QuadPlus :) |
11:04 | jnettlet | well I wished that they would release a new 64-bit replacement chip based on the a57 |
11:04 | jnettlet | yeah |
11:04 | jnettlet | but they are compatible with the iMX6D/Q so a straight out production swap |
11:05 | topi` | I guess i.MX8 is going to be 64-bit |
11:05 | jnettlet | it is supposed to be, but it was delayed |
11:06 | topi` | yikes, thermal_zone0 is showing 82 degrees C |
11:06 | topi` | I'm doing a kernel compile with "make -j6" :) |
11:06 | topi` | how can I see if it's being thermally throttled? |
11:06 | jnettlet | that is fine |
11:06 | jnettlet | cpufreq-info |
11:06 | jnettlet | it won't be throttled until a bit higher |
11:07 | jnettlet | we use industrial grade soc's so they are good to 105C |
11:07 | topi` | yeah, I guess the 40nm CMOS can take a lot of punishment |
11:07 | jnettlet | I am still tweaking the algorithms for that a bit. But my solution is far more robust than the FSL, or upstream solutions. |
11:08 | jnettlet | with a heatsink on I had to bring out a hair dryer to get it to overheat. It will clock down super low but it won't overheat. |
11:08 | jnettlet | usually you hit a steady state around 88C |
11:08 | jnettlet | at that point the heatsink will be about 67C |
11:09 | topi` | depends on how well the thermal paste has been applied ;) |
11:10 | jnettlet | nah, even with loose pads we get enough bond. We aren't talking about 125 watt tdp intel chips :) |
11:10 | topi` | :) |
11:10 | jnettle | 11:10 * jnettlet is going to walk the dogs now |
11:10 | topi` | do you have estimates how much a Quad dissipates when running under Linux and no CPU load? |
11:11 | topi` | must be under a watt, no? |
11:11 | jnettlet | good question. I haven't done the math on that. |
11:11 | topi` | you'd need some good power measurement tools |
11:11 | topi` | I guess rabeeh can do that :) |
11:12 | jnettlet | I actually found a pretty good power monitor that was not too expensive |
11:12 | jnettlet | The only thing I don't like about it is that it has no external data collection method. |
11:13 | jnettlet | http://www.portablepowersupplies.co.uk/portapow-premium-usb-dc-power-monitor/ |
11:25 | topi` | I have a Compulab Utilite2 computer on my desk as well, and have been making comparisons. I think the main reason why it is much faster at compiling the kernel is 2 MB of L2 cache instead of iMX6Q's measly 1MB |
11:25 | topi` | but it's fairly easy to throw 2MB when the chip is manufactured at 28nm |
11:26 | jnettlet | it is also .7Ghz per core faster :) So 70% faster on clock cycles |
11:27 | jnettlet | are you running the freedreno graphics driver on that board? |
11:27 | topi` | yeah, but the Krait cores are no IPC monsters |
11:27 | topi` | I haven't tried the Freedreno yet, there are serious problems trying to get a 3.19 kernel (by linaro) running on the device without freezing |
11:27 | jnettlet | are you using an SSD for compiles on both? |
11:28 | topi` | the HW side seems quite nice, I give Compulab credit for that, but it seems to be stuck in the 3.4 kernel provided by vendor |
11:28 | topi` | which is very sad |
11:28 | jnettlet | well that certainly makes it a bit less functional :) |
11:28 | topi` | jnettlet: SSD on the HB, and eMMC on the utilite |
11:28 | topi` | the eMMC is at around 50MB/s |
11:29 | topi` | but, more importantly, blocks a lot less than using a SD card |
11:29 | jnettlet | with the new kernels the HB uhs support can do up to 68MB/s with a "pro" quality sdhc |
11:29 | topi` | I'm very glad about the HB Edge, because that's clearly a device I can tell my boss that best fits our customers' needs |
11:29 | jnettlet | the HB Edge with the new plus socs will definitely be a powerhouse |
11:30 | topi` | have you been working on 3.18 or newer kernels for HB? |
11:30 | topi` | what about the eMMC in HB Edge? Is it based on the mmc 4.5 spec or faster? |
11:30 | jnettlet | yes, but they aren't released yet. The next jump will be 4.1 |
11:30 | jnettlet | but I just built a rebased 3.14 kernel on top of the yocto kernel. |
11:31 | topi` | do you think the "etnaviv" driver would be usable if tweaked sufficiently? |
11:31 | jnettlet | it is good for 2D, we are still working on 3d. |
11:31 | topi` | what's the yocto kernel? I mean, is it something that has some topic branches merged on top of Linus's tree? |
11:31 | jnettlet | I have a proof of concept, as does pengutronix for 3d but nothing that is consumable yet. |
11:32 | topi` | 2D is a good start. |
11:32 | topi` | we won't be using 3D, unless it can aid in video decode |
11:32 | jnettlet | yocto is managing a community version of the freescale released kernel. |
11:32 | jnettlet | well it can aid in video code, but really the VPU is the best way to go with that. |
11:33 | topi` | right |
11:33 | jnettlet | currently the upstream driver only supports h264 |
11:33 | topi` | I remember I had to use some binary blobs to get the HW video decoding to work |
11:33 | topi` | with gstramer |
11:34 | jnettlet | you have to use a firmware for that there is no getting around that. |
11:34 | topi` | right |
11:34 | topi` | I have no problems with binary blobs, as long as they don't taint my kernel |
11:34 | topi` | every time i see the infamous "kernel tainted" message, I shiver |
11:35 | jnettlet | lol...yeah none of that. |
11:35 | jnettlet | okay I am really going to walk the dogs now :) |
11:35 | topi` | (disclaimer: as a Nokia employee, I had to work on the "SGX" driver for the N900, a long long time ago) |
11:35 | topi` | we were *swimming* in Imagination provided binary blobs |
11:35 | topi` | jnettlet: don't let the dogs wait :) |
11:36 | topi` | this is a slow-paced channel anyway |
11:36 | Humpelstilzchen | topi`: so you are the one to blame |
11:48 | topi` | Humpelstilzchen: unfortunately :( |
11:48 | topi` | but that was years ago, I have forgiven myself |
11:48 | topi` | but the reasons why N900 shipped so late, were *multiple* |
11:48 | topi` | SGX graphics being just one tiny part of them |
11:49 | topi` | the organisation was just a bunch of guys when we started the N900, and then grew and grew and at the point of product launch, I think there were more than 200 ppl working on N900 |
11:49 | topi` | a lot of which external contractors, with very varying results. Needless to say, it was painful |
11:51 | topi` | jnettlet: I found the description of Cortex A9 revisions from ARM's docs. Changes in "r4p0" include "Enhanced data prefetch mechanism". I think this is mainly responsible for the speed difference between r4p0 and the older revs. My HB (iMX6Q) is using rev2 it seems (look at /proc/cpuinfo) |
11:53 | topi` | I think the r4p0 Data prefetch changes must somehow be related to this article: http://www.knowyourmobile.com/products/19628/nvidia-explains-why-tegra-4i-uses-arm-cortex-a9 |
11:54 | topi` | (the timing coincides, the r4p0 was released the same year) |
20:26 | rd_ | Can anybody tell if the mainline kernel supports wlan on the cubox-i ? |
21:16 | jnettlet | Yes it does but you need a firmware and nvram.txt file |