| 15:21 | jnettlet | Okay guys, ready for consumption. https://github.com/linux4kix/linux-linaro-stable-mx6 |
| 15:47 | pahartik | jnettlet: Is that appropriate for Armada? |
| 15:47 | jnettlet | pahartik, nope that is for the MX6. I have an Armada branch that will land within the next month |
| 15:48 | pahartik | jnettlet: Plan acknowledged |
| 15:51 | _rmk_ | okay, hopefully that'll get the imx-drm updates into 3.15 |
| 15:55 | jnettlet | _rmk_, with the new structure and loading? |
| 15:58 | _rmk_ | its all "imx-drm:" prefixed commits up to "imx-drm: imx-hdmi: add hotplug support to HDMI component" |
| 15:58 | _rmk_ | including that one |
| 15:59 | kaipee | anyone have experience of using lirc on the GeexBox build? |
| 15:59 | _rmk_ | I squished two pairs of patches together this morning as it no longer made sense fo rthem to be separate |
| 16:00 | jnettlet | kaipee, not yet no |
| 16:00 | jnettlet | sorry |
| 16:01 | kaipee | I had a go at it over the weekend but kept running into issues |
| 16:01 | kaipee | ...also there seem to be 2 differing lirc guides on the wiki :/ |
| 16:02 | jnettlet | kaipee, probably one for the cubox and one for the cubox-i. They are very different devices |
| 16:02 | _rmk_ | bear in mind that there's the cubox wiki for dove based cuboxes, and the cubox-i wiki for imx6 based cubox-i's |
| 16:02 | _rmk_ | www.solid-run.com = dove cubox, imx.solid-run.com = imx6 cubox-i |
| 16:03 | kaipee | jnettlet: how can I tell? |
| 16:03 | kaipee | 1 > http://www.solid-run.com/mw/index.php/IR_remote_control |
| 16:03 | kaipee | 2 > http://imx.solid-run.com/wiki/index.php?title=GeeXboX#Remote_control |
| 16:03 | _rmk_ | so that's www.solid-run.com, so that's the dove cubox |
| 16:03 | _rmk_ | and the second is imx.solid-run.com, so that's the imx6 cubox-i |
| 16:04 | kaipee | right :S |
| 16:04 | kaipee | I think I followed the first one |
| 16:05 | kaipee | is it possible to add an image/header to one of the wikis so that it clearly defines which is for the newer cubox-i ? |
| 16:06 | _rmk_ | kaipee: given that most people refer to both as just "cubox" and drop the very important "-i" I doubt that would do much good. |
| 16:06 | _rmk_ | a picture of them also doesn't work |
| 16:07 | kaipee | _rmk_: it would allow to easily identify which wiki is for which device |
| 16:07 | kaipee | not necessarily an image of the device - a logo or something |
| 16:07 | jnettlet | _rmk_, I think a bit of code that can be fed serial numbers and spit back models and links to appropriate content would be best. |
| 16:08 | _rmk_ | jnettlet: feed in your MAC address? :) |
| 16:08 | _rmk_ | doesn't stop google searches hitting the wrong site though |
| 16:08 | kaipee | maybe a subdomain ? |
| 16:13 | kaipee | imx.solidrun.com/wiki & dove.solidrun.com/wiki ? |
| 16:15 | _rmk_ | maybe something for solid-run to consider |
| 16:15 | jnettlet | _rmk_, do you have lirc enabled on your kernel? |
| 16:15 | _rmk_ | # CONFIG_LIRC is not set |
| 16:16 | jnettlet | grrr. completely forgot to check that. |
| 16:38 | _505 | for the wiki, I did suggest once to rabeeh to place a banner on the old wiki to warn people |
| 16:39 | _505 | unfortunately, due to some configuration, I cannot login and edit the old wiki, otherwise I could do it myself |
| 16:40 | _505 | seems like the cache is full, or /tmp not writeable. something only SR can fix |
| 18:43 | davorin_mbp | hyv�� iltaa (o; |
| 19:46 | meph1s_ | on the cubox-i, is the /dev/rtc0 or /dev/rtc1 the battery-powered one ? |
| 19:47 | meph1s_ | cubox-i4 * |
| 19:47 | jnettlet | meph1s_, should be /dev/rtc0 |
| 19:49 | meph1s_ | shouldnt "hwclock --systohc" write the time to the clock? 5 seconds without power and it's resettet :/ |
| 19:50 | jnettlet | what does cat /sys/class/rtc/rtc0/name say? |
| 19:51 | meph1s_ | rtc-pcf8523 |
| 19:51 | meph1s_ | the other (rtc1) is: snvs_rtc |
| 19:52 | jnettlet | yep then /dev/rtc0 is the right one. |
| 19:52 | meph1s_ | hm okay, thank you :) |
| 19:52 | jnettlet | what does hwclock -D say when you first boot up? |
| 19:52 | jnettlet | is the clock wrong? |
| 19:54 | meph1s_ | it was in the year 1970.. |
| 19:55 | meph1s_ | but now it's working, how long should the clock keep the time (unpowered) ? |
| 19:56 | jnettlet | quite a while |
| 19:58 | meph1s_ | okay.. |
| 19:59 | meph1s_ | 20 seconds without power |
| 19:59 | meph1s_ | jnettlet: http://pastebin.com/cuc1e9NM |
| 19:59 | meph1s_ | jnettlet: /dev/rtc is a symlink to /dev/rtc0 |
| 20:00 | jnettlet | meph1s_, oh. I have a patch for that |
| 20:00 | jnettlet | just fixed it the other day |
| 20:00 | meph1s_ | really? that would be awesome |
| 20:00 | jnettlet | which kernel are you running? |
| 20:00 | meph1s_ | 3.0.35-gde37251 |
| 20:01 | meph1s_ | from rabeeh's github page |
| 20:01 | jnettlet | okay let me check what the driver looks like there. |
| 20:02 | meph1s_ | jnettlet: on which version are you? |
| 20:02 | jnettlet | I just released my 3.10.30 lts kernel today :-) |
| 20:02 | meph1s | cool! |
| 20:02 | jnettlet | but the driver looks the same, this should apply. https://github.com/linux4kix/linux-linaro-stable-mx6/commit/ca8c204e88e1cc5fdbf6064c036dcdea7eaf6a29.patch |
| 20:03 | meph1s | jnettlet: great, thank you very very much |
| 20:04 | jnettlet | meph1s, let me know if it works okay. We done limited testing on it. |
| 20:19 | meph1s | jnettlet: didn't worked for me :( |
| 20:19 | meph1s | jnettlet: the patch applied with a little offset but without errors |
| 20:19 | jnettlet | output from hwclock -D |
| 20:20 | meph1s | http://pastebin.com/X3pMTbLS |
| 20:22 | jnettlet | try hwclock -w |
| 20:22 | jnettlet | then hwclock |
| 20:22 | meph1s | the first one fails |
| 20:22 | meph1s | the second "hwclock -w" works |
| 20:23 | jnettlet | and now does hwclock work? |
| 20:23 | jnettlet | to read it back? |
| 20:23 | meph1s | yes, until i power off for 20sec |
| 20:23 | meph1s | then its in the old state |
| 20:23 | jnettlet | have you tested this with the patch? |
| 20:24 | meph1s | yes. with and without your patch |
| 20:24 | meph1s | the same result |
| 20:24 | _rmk_ | jnettlet: we really need that driver to report if power was lost and/or the oscillator isn't running at driver probe time |
| 20:24 | jnettlet | _rmk_, yep |
| 20:24 | jnettlet | I actually had that output in there and removed it. |
| 20:24 | jnettle | 20:24 * jnettlet is way too optimistic |
| 20:25 | meph1s | thank you anyway, i'm going to setup ntp and never shutdown anymore :-D |
| 20:26 | meph1s | my old cubox has an uptime over a year... i hope the new one will do the same :) |
| 20:26 | jnettlet | what are you doing on a cubox for a year? |
| 20:27 | meph1s | it's my NAS |
| 20:27 | meph1s | 5 harddisks connected via eSata |
| 20:28 | meph1s | cuboxes are kind of the only arm devices which support port-multiplying on sata |
| 20:28 | meph1s | and they are pretty cool |
| 20:28 | meph1s | can't get enough of them :D |
| 20:36 | davorin_mb | 20:36 * davorin_mbp should receive 30 cuboxes tomorrow (o; |
| 20:37 | meph1s | are there known issues with power management on the cubox-i? sometimes (while compiling gentoo) the cubox just resets. |
| 20:37 | _rmk_ | jnettlet: looks like we need to program control register 3 for battery switch over |
| 20:37 | meph1s | davorin_mbp: thats alot of! o_O |
| 20:38 | davorin_mbp | i know...but most are already sold... |
| 20:38 | _rmk_ | oh, ignore that, it already does |
| 20:39 | meph1s | which kernel would you prefer? which is the most stable in your opinion? |
| 20:46 | _rmk_ | meph1s: not sure if this will apply to jnettlet's kernel, but try adding this and see what you get after removing power for 20sec: http://www.home.arm.linux.org.uk/~rmk/cubox/pcf8523.diff |
| 20:48 | meph1s | _rmk_: thank you |
| 20:49 | meph1s | _rmk_: but for the moment i got bigger troubles with the hw-reset-to-uboot on CPU-load :( |
| 20:49 | meph1s | _rmk_: i saved the link and will try that later |
| 20:50 | _rmk_ | it's not designed to fix the problem, merely to report what state the RTC ended up in. |
| 20:50 | _rmk_ | that may give a clue as to why it's not working for you |
| 20:51 | jnettlet | _rmk_, I will merge it to my tree thanks. |
| 20:51 | jnettlet | fyi meph1s is running rabeeh's 3.0.35 kernel, but it looks like the same driver |
| 20:52 | _rmk_ | jnettlet: I should call you The Patch Dyson, because you're always hoovering up my patches :) |
| 20:52 | meph1s | _rmk_: jnettlet: did someone of you got issues like that? http://pastebin.com/psHrgckR |
| 20:52 | jnettlet | _rmk_, :-) |
| 20:53 | meph1s | it just reboots sometimes, without any reason :( |
| 20:53 | jnettlet | meph1s, and you are using the powersupply that came with it? |
| 20:53 | meph1s | yes |
| 20:53 | meph1s | 5V, 3A |
| 20:53 | jnettlet | should be fine. |
| 20:55 | meph1s | hmm... |
| 20:56 | meph1s | seems to be a problem with the mmc reader |
| 20:56 | meph1s | as i tried 4 different cards, with always the same problem |
| 20:56 | hste | jnettlet: have you looked more into barebox? |
| 20:57 | meph1s | but it's in a reboot-loop while reading the kernel image then |
| 20:57 | meph1s | uboot -> load kernel -> uboot -> load kernel -> and so on |
| 20:58 | _rmk_ | jnettlet: it may be useful to print register 0x20d8008 in SPL if it contains a non-0x00000001 value |
| 20:59 | _rmk_ | that's the reset status register |
| 21:06 | _rmk_ | meph1s: how warm does the cubox-i feel? |
| 21:11 | meph1s | _rmk_: the bottom of the case is exactly 42.4?C |
| 21:15 | _rmk_ | so warm but not hot |
| 21:17 | meph1s | i've tested a litte bit, it seems like that the reset happens on heavy sd-card io-load |
| 21:17 | meph1s | portage-sync, package-install, ... |
| 21:17 | meph1s | i use a default ext4 file system, without the "options" described in the wiki |
| 21:17 | meph1s | wiki says: mkfs.ext4 -O ^has_journal -E stride=2,stripe-width=1024 -b 4096 /dev/sdX1 |
| 21:18 | meph1s | i did: mkfs.ext4 /dev/mmcblk0p1 -L system |
| 21:18 | meph1s | could that be the reason? |
| 21:20 | _rmk_ | but you also said that it happens when the kernel is loading? |
| 21:20 | meph1s | first time, it crashes on heavy io-load |
| 21:20 | meph1s | then it will always reset on "loading uImage" |
| 21:21 | meph1s | until i power off, and power on again |
| 21:21 | _rmk_ | which is also reading off SD card... |
| 21:21 | meph1s | yep |
| 21:23 | _rmk_ | I have no idea |
| 21:24 | meph1s | okay :/ |
| 21:25 | meph1s | Could someone translate that sentence for me? |
| 21:25 | meph1s | # Hat tip to hste and jas for this recipe |
| 21:26 | meph1s | found here: http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard |
| 21:27 | jnettlet | hste and jas are community members :-) |
| 21:28 | meph1s | hahaha Okay :-D |
| 21:28 | meph1s | thank you |
| 21:28 | jnettlet | It says thanks to them for the wiki entry |
| 21:28 | jnettlet | or the directions on how to build |
| 21:32 | Fishscene | Greetings. I was wondering if it was possible to install IPfire on cubox-i Pro |
| 21:34 | jas-hacks | jnettlet, _rmk_: noticed the newer kernel, it is working ok? |
| 21:34 | jnettlet | jas-hacks, still testing, but I haven't crashed it in weeks |
| 21:34 | jnettlet | no more glx glitches either |
| 21:36 | jnettlet | Fishscene, it looks like they support arm. I see no reason why it wouldn't run on the Cubox-i |
| 21:38 | Fishscene | Gotchya. I'll continue then. |
| 21:41 | jas-hacks | is the plan to take imx-drm into mainline? |
| 21:42 | jnettlet | imx-drm is in mainline |
| 21:42 | jnettlet | it is just under staging :-) |
| 21:44 | _rmk_ | whee, Greg just took my updates to it. |
| 21:45 | _rmk_ | which is a big step forward towards it moving out of staging |
| 21:47 | jnettlet | great! |
| 21:54 | _rmk | 21:54 * _rmk_ speed-reads 29 emails from Greg. |
| 21:56 | LangeOortjes | jnettlet: Where did you release your 3.10.30 kernel? Should I just checkout your github repository? |
| 21:57 | jnettlet | LangeOortjes, that is where it is at. https://github.com/linux4kix/linux-linaro-stable-mx6/ |
| 21:57 | jnettlet | make sure you are setup to use device-tree |
| 21:58 | LangeOortjes | jnettlet: okay, I didn't quite get that sentence I am afraid. |
| 21:59 | jnettlet | LangeOortjes, which image are you running on your CBi? |
| 21:59 | LangeOortjes | Arch Linux |
| 22:00 | jnettle | 22:00 * jnettlet wonders if there is a howto for device-tree kernels on the forums yet. |
| 22:01 | Fishscene | Is there a wiki for installing IPFire on the Cubox-i? I'm unable to get the cubox-i to boot when I flash the arm version of IPFire. Either from the cubox (yes, I know it's the wrong image), or from the IPfire website. Either way, I see the uboot files and such, but the light on the cubox-i does not light up when I plug the power in. |
| 22:02 | jnettlet | Fishscene, you will need to tweak their image. The binaries should run, but you will need u-boot and a kernel built for the CBi |
| 22:04 | Fishscene | Gotchya. I believe I have found exactly what you are talking about here, so I'll proceed with that: http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard |
| 22:08 | Fishscene | uhh... first problem. I'm using Ubuntu 13.10 x64. Wiki says to install "arm-linux-gnuabi", but no such package exists. I can see gcc packages for it though. Should I install "gcc-arm-linux-gnueabi"? There's a ton of other packages as well, but gcc seems the most likely.. |
| 22:08 | LangeOortjes | jnettlet: Arch Linux's standard linux-armv7 kernel package ships with .dtb files for quite a few architectures |
| 22:09 | jnettlet | LangeOortjes, do you have a boot.scr or uEnv.txt in your /boot directory? |
| 22:09 | jnettlet | or maybe neither |
| 22:09 | LangeOortjes | jnettlet: none |
| 22:10 | LangeOortjes | Arch Linux ships the cubox-i 3.0.35 kernel as a uImage |
| 22:10 | jnettlet | Did you setup custom boot variables within u-boot and save the environment, or are you just using the default kernel loading mechanisms |
| 22:10 | jnettlet | Do you have a /boot partition? |
| 22:11 | LangeOortjes | jnettlet: My sd-card is just one big partition really. There are u-boot instructions for booting, let me print my env variables |
| 22:12 | jnettlet | LangeOortjes, that is okay. It sounds like the easiest way to get this solved is have the Arch guys build a custom recipe. |
| 22:12 | LangeOortjes | jnettlet: http://pastebin.com/zEVHP9RV, if you are interested |
| 22:13 | LangeOortjes | jnettlet: Yeah I was looking for the PKGBUILD descriptions, which I cannot find, but this is something I will try to figure out tomorrow. |
| 22:13 | jnettlet | who are the Arch gurus on here? |
| 22:14 | LangeOortjes | so much to learn here, coming from `standard' x86_64 hardware |
| 22:15 | dv_ | here be dragons |
| 22:15 | LangeOortjes | :) |
| 22:24 | jnettlet | LangeOortjes, what does your irc nick mean? |
| 22:28 | _dab_ | jnettlet and _rmk_ . Awesome work on the kernel. |
| 22:29 | jnettlet | _dab_, thanks making progress. |
| 22:30 | _dab_ | My i4pro (which I loaned to someone) has a slow ethernet depending on what sort of switch/router it is connected to when using rabeehs kernel. |
| 22:31 | _dab_ | should I expect something similar with yours? |
| 22:32 | jnettlet | _dab_, I have only tested with my switches and routers and I can get 500+Mbps in iperf testing |
| 22:32 | _dab_ | good, rabeeh said it was a flow control issue |
| 22:33 | jnettlet | it is possible it is due to ethernet flow control, let me check if ethtool can turn that off. |
| 22:33 | _dab_ | great. I have to wait until I get my i4pro back from loan. |
| 22:36 | _dab_ | rabeehs explanation 'Because of the internal limitation the gig port sends flow control on/off that low end home switches doesn't know how to handle; thus corrupts the packets.' |
| 22:41 | jnettlet | _dab_, yeah I will have to see if that can be turned off with software. |
| 22:41 | jnettlet | this is not really a limitation of the cubox-i, a lot of hardware runs into this problem |
| 22:44 | _dab_ | if ethtool can switch it off good |
| 22:46 | Fishscene | I'm at a complete loss. I have no idea how to get IPFire installed on my cubox-i. Would someone be able to work with me on this? Perhaps we can write up a step-by-step for the wiki? |
| 23:06 | LangeOortjes | jnettlet: my nickname is Dutch for Long Ears (actually oortjes is the diminitutive of ears). |
| 23:07 | jnettlet | ah |
| 23:12 | LangeOortjes | alright, now it really is time for bed! Thanks for giving me a pointer, I will see if I can get any further with maybe some additional information from the arch ARM community |