| 01:14 | _rmk_ | jnettlet: fabio has sent a fix for the DI clock to uboot folk |
| 01:14 | _rmk_ | annoyingly, the discussion is only on driverdevel |
| 09:04 | rabeeh | jnettlet (and others): following is an android 4.2.2 snapshot build - http://dl.dropboxusercontent.com/u/72661517/tbr/snapshot-30102013.tar.xz |
| 09:04 | rabeeh | inside there are some instructions (README.txt) |
| 09:05 | rabeeh | please use the incorporated u-boot since it has booti command |
| 09:06 | rabeeh | oh; and one thing; android tries to enter deep sleep; so if you don't move the mouse at the beginning it will kill the main ui and restart it again and again |
| 09:06 | rabeeh | i'm looking for which feature needs to be removed from the kernel |
| 09:09 | jnettle | 09:09 * jnettlet downloading |
| 12:46 | rabeeh | jnettlet: let me know if you have something with the android image |
| 12:47 | rabeeh | for now i have a workaround to the deep sleep issue by going to settings, developer options and clicking on Stay Awake button |
| 12:48 | jnettlet | rabeeh, sure. Just putting together a Carrier 1 Fedora 18 base image for the XSCE guys right now. |
| 12:48 | rabeeh | oh nice |
| 12:48 | rabeeh | with hdmi? X ? accelerated? |
| 12:49 | rabeeh | or headless is good enough for them for now? |
| 12:49 | jnettlet | Just a server image for testing for now. I am working on X though today |
| 12:50 | jnettlet | rabeeh, which kernel are you using with the Android image? It seems like a wakelock should be held during init to keep the hardware awake |
| 12:50 | rabeeh | 3.0.35 |
| 12:50 | jnettlet | the android branch? |
| 12:50 | rabeeh | 4.2.2 |
| 12:51 | rabeeh | fsl has 4.3 in alpha |
| 16:30 | _rmk_ | whoa... not good. |
| 16:30 | _rmk_ | top just segfaulted |
| 16:31 | _rmk_ | jnettlet: any updates for your uboot wrt ram timings? |
| 16:31 | _rmk_ | I have your 2013.10-rc4-00014-g1676b11-dirty veresion |
| 16:34 | jnettlet | _rmk_, yeah you should probably grab the most recent. 2013.10-rc4-00031-geb08d21-dirty |
| 16:34 | jnettlet | that should up in my dropbox |
| 16:35 | jnettlet | I am reworking the init-scripts now to make things a little nicer. |
| 16:53 | rabeeh | _rmk_ / jnettlet: what uboot timing params? |
| 16:54 | rabeeh | is there a difference from the one jnettlet posted and the original one i posted? |
| 16:55 | rabeeh | _rmk_: were you doing something specific that caused top segfault? |
| 16:55 | rabee | 16:55 * rabeeh is worried |
| 16:57 | _rmk_ | rabeeh: I wasn't doing anything much at the time, I just noticed that top had segfaulted |
| 16:57 | rabeeh | so you just assumed it's ddr timing then |
| 16:58 | _rmk_ | nothing suggestive in the kernel messages |
| 16:58 | _rmk_ | well, this same fs has been fine on the cubox and it's just a direct copy off that |
| 16:58 | _rmk_ | only difference is it's running via nfs |
| 16:59 | _rmk_ | could be a multitude of things |
| 16:59 | rabeeh | segfaul on a silent machine is typically ddr timing, cpu issues (voltage) |
| 17:01 | rabeeh | but you are the first to report something like that; i haven't seen segfaults but only in the first stages of bringup (before tuning ddr parameters) |
| 17:02 | _rmk_ | I'm waiting for it to happen again |
| 17:25 | jnettlet | rabeeh, _rmk_, I think that _rmk_ was running my u-boot image that had your default clock gating settings which were causing some crashes. It will be interesting to see if the most up to date settings make a difference |
| 17:49 | _rmk_ | ok, now have 2013.10-rc4-00023-g5d1c16a-dirty instead on it |
| 17:57 | jnettlet | that should have the clock gating changes that were causing crashes, but is not the newest version. I will have to check why my build script isn't moving the image over. |
| 18:42 | Bluerise | _rmk_: Have you experienced prefetch aborts? (Not on the CuBox, just in general) |
| 18:44 | _rmk_ | Bluerise: it's possible that was one, I didn't investigate it too closely (partly because apport gobbled up the core dump) |
| 18:45 | Bluerise | I have here another i.MX6 board and I experience prefetch aborts... with L2 disabled... I guess when I boot Ubuntu (once), it'll be gone. |
| 18:45 | Bluerise | Thought you might have some ideas. |
| 18:46 | _rmk_ | I assume you mean "fatal prefetch abort" :) |
| 18:46 | Bluerise | yeah. |
| 18:46 | Bluerise | Fatal kernel mode prefetch abort at 0x5467a4c0 |
| 18:47 | _rmk_ | ah, an oops then, can you put it into fpaste or something like that :) |
| 18:47 | rabeeh | hi jas-hacks_ |
| 18:47 | Bluerise | Well, it's not Linux,... not sure if a dump would help at all, but sure. ;) |
| 18:48 | rabeeh | C1 for now ships with solo |
| 18:48 | _rmk_ | oh, it's BSD? |
| 18:48 | rabeeh | Cubox-i has all the versions |
| 18:48 | Bluerise | Yep. :) |
| 18:48 | _rmk_ | fun :) |
| 18:48 | jas-hacks_ | rabeeh: ok |
| 18:48 | Bluerise | I just wondered whether you had experience debugging those ;) |
| 18:48 | rabeeh | jas-hacks_: i'v tried using your xfce ubuntu but it crashed on X :) |
| 18:49 | _rmk_ | the closest I've come to BSDs is FreeBSD jails... remotely at that :) |
| 18:49 | rabeeh | but worked great on fbdev; i was amazed how fast it is on a non accelerated X |
| 18:49 | jas-hacks_ | rabeeh: on which board? |
| 18:49 | rabeeh | C1 |
| 18:49 | rabeeh | did you get your board? |
| 18:50 | rabeeh | oh; btw - carrier one === C1 |
| 18:50 | jas-hacks_ | rabeeh: Probably won't work on C1, all the GPU stuff is setup for Dual/Quad |
| 18:50 | rabeeh | it's not the same driver for gc880 / gc2k? |
| 18:51 | jas-hacks_ | Haven't received C1 yet :( |
| 18:51 | Bluerise | _rmk_: I wonder if it's a missing iomux or something... *sigh* |
| 18:52 | jas-hacks_ | Let me check, I thought solo didn't have gc2000 |
| 18:52 | jnettlet | rabeeh, yeah xfce is twiddling a bug in the X-server. I started debugging that on my Linaro image the other day |
| 18:52 | jnettlet | gc860 |
| 18:52 | jnettlet | is it an 880? |
| 18:52 | rabeeh | 880 |
| 18:52 | rabeeh | jnettlet: it was regardless of xfce |
| 18:52 | rabeeh | 'X :0 -ac' wouldn't run an X too |
| 18:53 | jnettlet | oh I have no problems running X on my kernel. Although eventually I do get a crash, but it is a known bug. |
| 18:53 | jnettlet | The gc880 and gc2k do use the same driver. |
| 18:54 | jnettlet | well should. Freescale has munged their libraries and headers a bit. I just stumbled across that earlier in the week and nearly lost it. |
| 18:54 | rabeeh | jas-hacks_: just looked at the queue; your are second on the top |
| 18:54 | rabeeh | we were out of C1 boards and now refilling |
| 18:55 | rabeeh | let me see if i can spare few and send immediately |
| 18:55 | rabeeh | svere also misses his C1 |
| 18:56 | jas-hacks_ | rabeeh: can you pastebin the X crash? |
| 18:59 | rabeeh | jas-hacks_: i wiped it |
| 18:59 | rabeeh | i will reproduce the issue once i'm done with android |
| 18:59 | rabeeh | but it was something related to missing library functions |
| 18:59 | rabeeh | user space |
| 19:00 | jas-hacks_ | rabeeh: no problems |
| 19:00 | rabeeh | micro sd cards looks the same |
| 19:00 | rabeeh | i have tons of them infront of me and try to remember which one does what |
| 19:00 | rabeeh | but at the end the only one inserted is the one that i remember what it really does |
| 19:01 | rabeeh | jas-hacks_: do you have one besides the gk802? |
| 19:02 | rabeeh | i mean another imx? |
| 19:02 | _rmk_ | rabeeh: you need to colour code them or sick labels on them or something... that's the advantage of the standard SD cards... you can trivially mark them up :) |
| 19:03 | _rmk_ | the endless persuit of "must be smaller" just means (a) it's easier to lose the things and (b) it's harder to mark what's on which card :p |
| 19:03 | jas-hacks_ | rabeeh: yes I have another custom (imx6q) board, I working on it for a customer |
| 19:03 | _rmk_ | thankfully, I have only three micro-sd cards here :) |
| 19:04 | _rmk_ | btw, top seems to be running fine, but then its run fine for ages with jnettlet's previous uboot too... |
| 19:05 | rabeeh | _rmk_: did the storm hit C1 ddr? :) |
| 19:05 | rabeeh | btw - is it over? |
| 19:05 | jnettle | 19:05 * jnettlet uses an ice-cube tray with little labels to hold the different sd-cards |
| 19:08 | jas-hacks_ | rabeeh: https://docs.google.com/file/d/0B0GYDB0rYa2MWk1GckVtc085Tlk/edit?usp=sharing |
| 19:11 | rabeeh | from the heatsink i guess it's a quad? |
| 19:12 | jas-hacks_ | yes quad, guess you must have the same issues on the cubox-i ? |
| 19:15 | dv_ | jnettlet: they are easy to lose, arent they :) |
| 19:16 | jnettlet | dv_, yep that is why I keep things compartmentalized. I have one ice-cube tray for my sdhc cards and another for my small screws for whatever is in pieces on my desk :-) |
| 19:16 | rabeeh | jas-hacks_: the quad is difinetely challenging |
| 19:17 | rabeeh | and when you deploy it in a box it's even harder. |
| 19:17 | rabeeh | but it's manageable; you just need to know good thermal dissipation techniques |
| 19:18 | jas-hacks_ | rabeeh: I'm surprised you managed to get inside 2x2, how do you keep it cool? |
| 19:19 | rabeeh | the microsom we have developed is 2"x1" |
| 19:19 | rabeeh | 47mm x 30mm to be exact; so it's tinier than that |
| 19:19 | jas-hacks_ | is the heatsink on the microsom? |
| 19:20 | jas-hacks_ | or do you use the case? |
| 19:21 | rabeeh | it's a blend of multiple techniques |
| 19:21 | rabeeh | the main idea is that plastic is a heat insulator |
| 19:22 | rabeeh | to get pass plastic you need to spread heat in a good manner and then user heat radiation to pass that |
| 19:22 | rabeeh | but at the end it's a blend of multiple techniques |
| 19:22 | rabeeh | also our DDR layout is way different that freescale recommends |
| 19:23 | rabeeh | (and as what i see on the board you have sent) |
| 19:23 | rabeeh | our ddr layout provides us tools to dramatically reduce power consumption too |
| 19:23 | rabeeh | choice of quality of power management devices |
| 19:23 | rabeeh | etc... |
| 19:24 | jas-hacks_ | what max temperatures (on the quad) are you reaching under load? |
| 19:24 | rabeeh | in room temperature (25c) max would be around 70c |
| 19:24 | dv_ | on the die? or on the outside? |
| 19:25 | rabeeh | that's with everything working (gpu/mem/ddr/ethernet/wifi) |
| 19:25 | rabeeh | everything |
| 19:25 | rabeeh | dv_: die ofcourse |
| 19:25 | rabeeh | outside it's ~40-45c on the plastic |
| 19:25 | rabeeh | depends which side you are measuring on |
| 19:26 | dv_ | hm |
| 19:26 | dv_ | 70C on the die isnt alarmingly hot |
| 19:26 | rabeeh | jas-hacks_: now here is a nice piece of information - if you heat an aluminum and plastic bodies to 45c; the aluminum would feel really hot; while the plastic would feel a bit warm |
| 19:26 | rabeeh | dv_: nop |
| 19:26 | rabeeh | it's way below the max |
| 19:26 | dv_ | well ... aluminium has much better heat conduction than plastic |
| 19:27 | rabeeh | max on imx6 is 90c on the consumer versions |
| 19:27 | rabeeh | which is pretty low also |
| 19:27 | dv_ | which is why a steel park bench feels much hotter than a wooden one |
| 19:27 | rabeeh | the older CuBox had Dove chip that can go up to 105 without issues |
| 19:27 | jas-hacks_ | we found that a lot of the heat is transferred to the pcb & onto to the components |
| 19:27 | rabeeh | i once didn't attach the heatsink and the device went up to 140c and was still working |
| 19:27 | dv_ | a customer of us made a thermography of the sabre SD once |
| 19:28 | dv_ | (under full load) |
| 19:28 | rabeeh | jas-hacks_: depends on which version of the chip you are using |
| 19:28 | rabeeh | if you are using dq; then no |
| 19:28 | dv_ | the temperature dropoff by distance from the imx6 was pretty big |
| 19:28 | rabeeh | most of the heat is transferred on the top side of the package (i.e. on the die) |
| 19:28 | rabeeh | dv_: which processor was on the sabre sd? |
| 19:28 | rabeeh | the dual lite? |
| 19:29 | dv_ | yes |
| 19:29 | jas-hacks_ | rabeeh: are using lidded or non-lidded? |
| 19:29 | rabeeh | what is lidded? |
| 19:29 | rabeeh | you mean the heat slag? |
| 19:29 | dv_ | 1-2cm meant a difference of ~20-30 C |
| 19:30 | dv_ | err, 2-3cm |
| 19:30 | rabeeh | dv_: was it in a closed environment? or in open air? |
| 19:30 | dv_ | open air |
| 19:30 | Bluerise | _rmk_: After I booted Linux once and soft-rebooted to my BSD, it boots fine. Hard-reset: same error |
| 19:30 | Bluerise | _rmk_: So, Linux seems to do something right... ;) |
| 19:31 | rabeeh | Bluerise: BSD on C1? |
| 19:31 | rabeeh | you already have something? |
| 19:31 | Bluerise | rabeeh: The C1 is actually fine. :) |
| 19:31 | dv_ | rabeeh: http://www.iwavesystems.com/media/catalog/product/cache/1/image/9df78eab33525d08d6e5fb8d27136e95/v/s/vss_5186_1.png |
| 19:31 | dv_ | except on the one I meant the imx6 is enclosed in black plastic |
| 19:31 | dv_ | not this aluminium case |
| 19:32 | Bluerise | I was donated a Utilite, and it seems to have the same problems as the Nitrogen6x a friend has.... |
| 19:32 | Bluerise | It's something I don't do, but Linux does right. Not sure what (yet) |
| 19:32 | dv_ | jnettlet: I noticed you have been coming up with a boot logo |
| 19:33 | Bluerise | The problem is that I still rely many things that have been set up by u-boot. |
| 19:33 | dv_ | jnettlet: can this be used for yocto? |
| 19:34 | jas-hacks_ | rabeeh: dv_ link is of the 'lidded' cpu (enclosed in a case). |
| 19:35 | dv_ | jas-hacks_: and what is the name of the regular black one? |
| 19:35 | dv_ | (the black one uses plastic, right?) |
| 19:36 | jas-hacks_ | dv_ : "non-lidded", normally it is metal (at least for the quad). |
| 19:37 | jas-hacks_ | the non-lidded has less contact surface area for heat transfer to a heatink/heat spreader |
| 19:38 | Bluerise | So, with all caches disabled, prefetching disabled... what causes fatal prefetch aborts? |
| 19:38 | dv_ | jas-hacks_: how can a cpu not be enclosed? |
| 19:39 | jas-hacks_ | dv_: it is enclosed |
| 19:40 | dv_ | okay, confused. I am thinking in terms of packaging http://en.wikipedia.org/wiki/List_of_integrated_circuit_packaging_types |
| 19:41 | dv_ | "non-enclosed" sounds to me as if the die isnt hermetically sealed |
| 19:42 | rabeeh | dv_: it is |
| 19:42 | rabeeh | the dq are flip chip |
| 19:42 | rabeeh | means that the substrate is on the upper side and the metal layers goes down |
| 19:43 | rabeeh | it's all sealed; but since the die itself is smaller than the package sometimes they add this 'lidded' cover (or heat slag) |
| 19:44 | rabeeh | which is basically an aluminum that gets attached on it's bottom side to the die and heat transfers the heat from the die to a larger area |
| 19:45 | dv_ | ah here: http://www.iwavesystems.com/media/import/Home/News%20Letter/wec7-bsp-pico.jpg |
| 19:46 | dv_ | thats how it looks like with the sabre SD here |
| 19:46 | dv_ | so, what? its flip chip inside with this black cover instead of the metallic one? |
| 19:47 | rabeeh | jas-hacks_: how much maximum power consumption do you see from your board? |
| 19:47 | rabeeh | i mean in the DC jack-in? |
| 19:48 | jas-hacks_ | around 7.5 Watts at 12v |
| 19:50 | jas-hacks_ | need to check that again because it seems low |
| 19:52 | jas-hacks_ | looks ok with (no peripherals attached) |
| 19:56 | jas-hacks_ | rabeeh: are you using LPDDR ram? |
| 20:20 | _rmk_ | okay, now building Fabio's v3 hdmi patch |
| 20:31 | ojn | cubox found another issue on -next. Whee. |
| 20:32 | ojn | (showing its usefulness in the bootfarm :) |
| 20:33 | rabeeh | jas-hacks_: regular DDR |
| 20:33 | rabeeh | i don't think your design is using LPDDR too |
| 20:33 | rabeeh | ojn: great :) |
| 20:34 | rabeeh | what was the issue? |
| 20:34 | ojn | _rmk_: btw, do you want to post the basic dt support for cubox-i so we can get it in for 3.13? |
| 20:35 | ojn | rabeeh: seems to be a problem with enabling threaded interrupts on the mmc controller, dove gives off to spurious/error interrupts during probe that the new threaded interrupt code doesn't handle and gets stuck |
| 20:35 | ojn | i haven't had time to actually fix the bug, I rarely do. But I do have time to bisect and report it. :-) |
| 20:36 | ojn | http://marc.info/?l=linux-mmc&m=138316145408963 |
| 20:36 | _rmk_ | ojn: I have... the problem is the patches aren't stable because I'm waiting for Sascha to sort out the DAT3 pinctrl configuration stuff |
| 20:37 | ojn | _rmk_: ah, ok |
| 20:37 | _rmk_ | ojn: I'm thinking it's going to have to wait until after this merge window, before I see those updates |
| 20:38 | ojn | _rmk_: yeah reading up on history now. |
| 20:39 | _rmk_ | it looks like the DAT3 stuff isn't in arm-soc yet... |
| 20:39 | _rmk_ | I just checked my build tree - arm-soc got pulled last night |
| 20:40 | ojn | _rmk_: yeah the last thread i saw was with shawn reconsidering his approach (6 days ago), I don't think I've seen anything since then |
| 20:40 | ojn | we're pretty much done adding code, there's one small outstanding broadcom pull request and that's mostly it. |
| 20:40 | _rmk_ | ojn: btw, look out for a link failure with imx stuff... |
| 20:40 | _rmk_ | arch/arm/mach-imx/built-in.o: In function `imx6q_pm_enter': |
| 20:40 | _rmk_ | platform-spi_imx.c:(.text+0x2648): undefined reference to `v7_cpu_resume' |
| 20:40 | ojn | _rmk_: with what config? |
| 20:40 | _rmk_ | caused by CONFIG_PM=y CONFIG_SMP=n |
| 20:41 | _rmk_ | one of my randconfig builds :) |
| 20:41 | _rmk_ | v7_cpu_resume is in arch/arm/mach-imx/headsmp.S |
| 20:41 | _rmk_ | which is only built when CONFIG_SMP=y |
| 20:42 | _rmk_ | but the PM code in arch/arm/mach-imx/pm-imx6q.c references it |
| 20:42 | _rmk_ | I was going to send an email about it but haven't got a round tuit yet :p |
| 21:24 | _rmk_ | okay, that's fabio's driver properly updated with all my other updates |
| 21:25 | jnettlet | fabio's imx-drm driver? |
| 21:25 | _rmk_ | fabio's hdmi add-on for imx-drm |
| 21:26 | jnettlet | ah okay |
| 21:27 | _rmk_ | is there a reason why the serial output on your latest uboot seems slower than previous? |
| 21:28 | _rmk_ | maybe its actually faster but because usb serial seems rather crap if you get the timing just right... |
| 21:29 | jnettlet | it may be because of USB polling mode needed to support usb keyboards. I still need to look into that more. |
| 21:30 | _rmk_ | http://tip4commit.com/ <-- these guys just sent me a mail |
| 21:31 | jnettlet | interesting. Although I don't have any bitcoins |
| 21:31 | _rmk_ | from what I hear, from one ex-bitcoin miner, there's lots of bitcoin fraudsters out there now. |
| 21:32 | _rmk_ | but I've always thought bitcoin mining itself sounded rather fraudulant |
| 21:32 | jnettlet | and not much money backing the project yet. |
| 21:33 | jnettlet | yeah not a big backer of it. |
| 21:34 | jnettlet | okay I have to head to bed now. Game 6 of the World Series starts in 5 hours. |
| 21:34 | jnettlet | :-) |
| 21:34 | _rmk_ | heh. enjoy. |
| 21:35 | _rmk_ | well, my old cubox-i branch had 29 commits. this one with the v3 hdmi driver has 28 commits. some different fixes to the hdmi driver, some are the same though. |