| 00:49 | Coburn | alright so |
| 00:49 | Coburn | another day at the office and time to try to get HDMI output on the cubox |
| 00:49 | Coburn | if _rmk_ is around, I would appreciate his advice |
| 02:57 | Coburn | okay, so compiling the amanda patches seems to be ok, but now I got configure: error: Package requirements (libdrm_armada >= 2.0.0) were not met: |
| 02:57 | Coburn | |
| 02:57 | Coburn | No package 'libdrm_armada' found |
| 02:57 | Coburn | hmm |
| 03:14 | Coburn | fixed that, got another error |
| 03:14 | Coburn | ../../src/vivante_accel.h:57:14: error: field 'batch_list' has incomplete type |
| 03:14 | Coburn | ../../src/vivante_accel.h:99:14: error: field 'batch_node' has incomplete type |
| 03:21 | Coburn | shot rmk an email... hope I get this fixed, otherwise it's game over for the cubox, I'd rather go intel atom |
| 05:14 | _dab_ | question: uboot only sees my usb kbd if it is in the top slot, is this expected behaviour? |
| 05:37 | Coburn | _dab_: there's a bug in stock uboot |
| 06:04 | jnettlet | _dab_, that is fixed in the rabeeh's repo. I can build you a new set of binaries if you want. |
| 06:09 | jnettlet | Coburn, _rmk_'s drivers are built against the old V2 version of the vivante driver. It is on my list to the latest vivante drivers working on both the old and new platforms so we can upgrade. |
| 06:17 | _dab_ | Coburn: I am using rabeeh's repo |
| 06:19 | jnettlet | _dab_, what does usb tree report? |
| 06:20 | _dab_ | when it works I can tell you, when it does not I cannot because I don't have a keyboard to interrupt |
| 06:20 | jnettlet | _dab_, are you using a boot.scr? you can add it there. |
| 06:20 | Coburn | _dab_: there's a bug in the usb logic in uboot that a person called dbsx fixed. He supplied me with a patched bootloader. |
| 06:21 | Coburn | what happens with the bug is anything on port 1 hangs usb startup |
| 06:21 | _dab_ | Sorry, talking cubiox-i |
| 06:21 | Coburn | oh |
| 06:21 | Coburn | jnettlet: please save my sanity and suggest me a kernel that has a working xorg driver ;) |
| 06:21 | Coburn | I'm *this* close of saying nope to the cubox and going intel atom |
| 06:22 | _dab_ | jnettlet: +-2 Human Interface (1.5 Mb/s, 100mA) ... |
| 06:22 | jnettlet | Coburn, 3.0.35 for now. I am working on getting my 3.10 kernel out but my time has been limited this week. |
| 06:22 | Coburn | alright. can you provide me with links, jnettlet? |
| 06:23 | Coburn | if so I'll download and get the sucker working |
| 06:25 | jnettlet | https://github.com/SolidRun/linux-imx6 |
| 06:25 | Coburn | jnettlet: I'm talking about CuBox Dove. |
| 06:26 | Coburn | Not imx6, unless your kernel is a hybrid compatible with both, jnettlet |
| 06:26 | jnettlet | Coburn, oh then you want to use _rmk_'s kernel tree. |
| 06:27 | jnettlet | just make sure you add it to an existing linux-stable repo or else it crushes his bandwidth. |
| 06:27 | Coburn | jnettlet: where is rmk's kernel tree? I need a tarball |
| 06:27 | Coburn | I'm not a git user as per such |
| 06:28 | jnettlet | there is no tarball available for it. |
| 06:28 | _dab_ | jnettlet: verfied problem by inserting two usb keyboards and after turning the cubox the right way up, it is the top one that never works |
| 06:28 | jnettlet | _dab_, okay that makes more sense. |
| 06:28 | Coburn | jnettlet: is it on github or can I git clone it? |
| 06:29 | _dab_ | other than that and no GUI cursor, uboot seems pretty good |
| 06:29 | Coburn | wait, uboot has a GUI now? |
| 06:29 | _dab_ | on cubox-i |
| 06:29 | jnettlet | Coburn, his latest changes are here. http://ftp.arm.linux.org.uk/cgit/linux-cubox.git/?h=drm-armada-fixes |
| 06:29 | jnettlet | but like I said add that as a remote for a clone of linux-stable. You can mirror that repo from github |
| 06:30 | Coburn | uh |
| 06:30 | jnettlet | _dab_, don't let it fool you. u-boot is pure evil |
| 06:31 | Coburn | I'm not sure if I follow. |
| 06:31 | Coburn | So what do I clone, and then what do I add as a remote? |
| 06:31 | jnettlet | You clone linux-stable from github. Then add _rmk_'s repo as a remote |
| 06:32 | _dab_ | jnettlet: like the link it just needs to be handled very carefully http://en.wikipedia.org/wiki/Tiger_snake |
| 06:33 | jnettlet | _dab_, barebox will be much nicer. Including booting direct to linux so we aren't initializing devices twice. |
| 06:34 | jnettlet | should cut 3-5 seconds off the boot time |
| 06:34 | Coburn | jnettlet: I really am confused. |
| 06:34 | Coburn | I'm trying to reread your instructions, but I'm getting lost. |
| 06:34 | _dab_ | I ventured in barebox sometime ago on sheevaplugs and gave up and went back to uboot. I hope it has improved |
| 06:35 | jnettlet | Coburn, I am pretty busy right now and can't give you my full attention. I will try and get back to you in an hour or so. |
| 06:35 | Coburn | jnettlet: ok, I'll be around. |
| 08:23 | Coburn | jnettlet: you still busy? |
| 08:29 | jnettlet | Coburn, yeah a lot going on this morning |
| 08:29 | Coburn | ok |
| 08:29 | Coburn | well, could you email instructions to me? |
| 10:59 | _rmk_ | and they're in. :) |
| 11:01 | Bluerise | :o |
| 11:05 | dv_ | cubox-i patches got accepted into meta-fsl-arm , so now cubox-i and HB are supported in OE \o/ |
| 11:05 | dv_ | many thanks to otavio |
| 11:10 | MikeSeth | nice |
| 11:11 | _rmk_ | Coburn: I do need to push out some updates for the dove drm Xorg driver which should resolve that build error (caused by stuff changing in X) |
| 11:11 | Coburn | _rmk_?? |
| 11:13 | _rmk_ | ... and now pushed |
| 11:13 | _rmk | 11:13 * _rmk_ wonders if that "_rmk_??" was an auto-response |
| 11:23 | xraxor_ | what does that mean dv_ ? |
| 11:25 | dv_ | xraxor_: cubox-i rootfs cann now be built with yocto and openembedded |
| 11:25 | dv_ | and openembedded is big |
| 11:26 | xraxor_ | thanks, i almost thought was OpenELEC you meant |
| 11:28 | _rmk | 11:28 * _rmk_ fails to find Coburn's email |
| 11:56 | jnettlet | _rmk_, I think Coburn needs help getting a Cubox kernel greater than 3.10 going. My morning has been too busy to give detailed instructions. |
| 11:56 | Coburn | jnettlet?? |
| 11:56 | jnettlet | _rmk_, I take that back it does look like a horrible auto-responder |
| 11:57 | jnettlet | very annoying |
| 11:57 | xraxor_ | Coburn |
| 11:58 | jnettlet | or maybe not |
| 11:58 | jnettle | 11:58 * jnettlet is just confused |
| 11:58 | xraxor_ | lol maybe hes drunk |
| 11:58 | _rmk_ | it does look like an autoresponder - probably needs more than just the nick though |
| 11:59 | xraxor_ | wend is near, it sucks tho i have sore throat dont think will be having beers at the wend |
| 11:59 | _rmk_ | jnettlet: well, when Coburn is around... |
| 11:59 | Coburn | _rmk_?? |
| 11:59 | _rmk_ | yep, definitely an autoresponder |
| 11:59 | xraxor_ | lol |
| 12:00 | jnettle | 12:00 * jnettlet will not address Coburn any longer then |
| 12:00 | jnettlet | interesting it does not pick that up. |
| 12:00 | _rmk_ | xraxor: honey and vinegar to help sooth that |
| 12:00 | _rmk_ | jnettlet: I think it's timed so it doesn't respond too often |
| 12:00 | _rmk_ | because if I mention something else with Coburn in... |
| 12:00 | Coburn | _rmk_?? |
| 12:00 | _rmk_ | hmm. |
| 12:01 | _rmk_ | let's try that again, Coburn |
| 12:01 | _rmk_ | yep Coburn doesn't respond now |
| 12:01 | Coburn | _rmk_?? |
| 12:01 | _rmk_ | hmm. |
| 12:01 | jnettlet | is it every other Coburn |
| 12:01 | jnettlet | or Coburn |
| 12:01 | jnettlet | and Coburn |
| 12:01 | _rmk_ | Coburn must have something following maybe? |
| 12:01 | Coburn | _rmk_?? |
| 12:01 | jnettlet | strange |
| 12:01 | _rmk_ | Coburn |
| 12:01 | _rmk_ | Coburn . |
| 12:01 | Coburn | _rmk_?? |
| 12:02 | Coolgeek | Coburn hello |
| 12:02 | Coburn | Coolgeek?? |
| 12:02 | _rmk_ | Coburn. |
| 12:02 | Coburn | _rmk_?? |
| 12:02 | _rmk_ | yep, definitely needs something following. |
| 12:02 | Coolgeek | it's so useless |
| 12:03 | _rmk_ | yep, and I can't see the point of saying "nick??" |
| 12:03 | jnettle | 12:03 * jnettlet loves the fact we just spent 5 minutes trying to reverse engineer what a stupid autoresponder was doing |
| 12:04 | Coolgeek | so refreshing jnettlet :p |
| 12:04 | _rmk_ | but we still haven't answered the biggest question of all: will coburn's autoresponder blend? |
| 12:04 | Coburn | _rmk_?? |
| 12:07 | Coolgeek | can we make an autoresponder to the Coburn's one ? |
| 12:07 | Coburn | Coolgeek?? |
| 12:07 | _rmk_ | jnettlet: the errors he posted last night looked like trying to build it against a newer Xorg, and the version he has doesn't have the compat-api stuff in |
| 12:07 | jnettlet | _rmk_, yeah but he doesn't even have a kernel with galcore included best as I can tell |
| 12:08 | _rmk_ | yea, I still need to sort out the last reminants of the non-gpl'd headers in that |
| 12:08 | jnettlet | I am definitely going to start another repo that allows galcore to be built outside the kernel as a module. It will make integration with upstream kernels a bit easier |
| 12:09 | jnettlet | _rmk_, don't bother. I am testing the latest galcore release across the platforms today and will then re-implement my mrvl/fsl specific changes |
| 12:09 | lioka | jnettlet: that would be great |
| 12:10 | _rmk_ | jnettlet: that's whta I'm hoping for :) |
| 12:10 | jnettlet | My end of Jan kernel push date is upon me and I need to just get stuff out. |
| 12:10 | _rmk_ | what |
| 12:10 | dv_ | jnettlet: just tested the newer drivers. they seem to have a similar issue like the one fixed by your CEA mode patch |
| 12:10 | dv_ | that is, in X11 I get 1024x768 at most with a DVI monitor |
| 12:11 | jnettlet | dv_, the KMS drivers? |
| 12:11 | dv_ | are they kms? |
| 12:11 | jnettlet | which kernel? |
| 12:11 | dv_ | I am talking about the 4.6.9 ones |
| 12:11 | dv_ | kernel is 3.0.35 with backported patches |
| 12:11 | jnettlet | oh, yeah the galcore changes don't effect it. It is the IPU/HDMI/EDID code that is restricting that. |
| 12:12 | dv_ | this: https://lists.yoctoproject.org/pipermail/meta-freescale/2014-January/006720.html |
| 12:12 | dv_ | ah perhaps its the backported patches then that cause this |
| 12:12 | jnettlet | yeah that is just supporting the latest Vivante userspace binaries |
| 12:17 | otavio | dv_: jnettlet: I think this is a regression of X11 driver |
| 12:17 | otavio | I pinged someone internal at FSL and he is looking at it |
| 12:18 | otavio | I think they broke it when added XRandR support to X11 |
| 12:19 | dv_ | okay |
| 12:20 | dv_ | so I just point my finger at them :) |
| 12:27 | jnettlet | dv_, hopefully over the weekend you can switch to my 3.10 kernel and the KMS driver. |
| 12:35 | otavio | jnettlet: are you using 3.10.17? |
| 12:36 | jnettlet | My kernel is based on the linaro 3.10 with 3.10.17 merged and then patches of my own and upstream |
| 12:36 | otavio | dv_: when I have something real (which I can share) I let you know. |
| 12:36 | otavio | jnettlet: oh |
| 12:36 | otavio | any special reason to not base on 3.10.17? |
| 12:36 | otavio | I mean, FSL one. |
| 12:37 | otavio | There are some fixes which were not merged yet in 3.10.17 (the ones from 3.10.z stable tree) but apart from that it is really FSL fixes and drivers. |
| 12:40 | jnettlet | yeah, lsk will get maintenance from upstream for 2 years. I would much rather trust Linaro to do that then just let FSL pile on patches upon patches. |
| 12:40 | jnettlet | If I base on lsk I can cherry-pick relevant fixes from FSL, or upstream depending which one is better. |
| 12:41 | jnettlet | I have already found multiple patches in the FSL 3.10.17 that are just wrong. |
| 12:46 | _rmk | 12:46 * _rmk_ pulls cubox-i stuff forward now that some more patches have been merged |
| 13:03 | MikeSeth | 11:33 [freenode] CTCP VERSION reply from Coburn: KVIrc 4.2.0 svn-6190 'Equilibrium' 20120701 - build 2012-07-04 14:48:08 UTC - Windows 7 Professional (x64) Service Pack 1 (Build 7601) |
| 13:03 | Coburn | MikeSeth?? |
| 13:03 | MikeSeth | some people.. |
| 13:04 | dv_ | jnettlet: and communication with freescale about these issues isnt exactly easy, correct? |
| 13:05 | dv_ | I tried to get some more contacts regarding the vpu wrapper library, but only got very confusing replies |
| 13:07 | jnettlet | dv_, I am not sure what the proper channels are to report bugs and submit patches to fsl. |
| 13:07 | dv_ | community.freescale.com could be one. perhaps you can also post them on meta-freescale |
| 13:07 | jnettlet | I think maybe their forums, but anything I have seen reported against 3.10.17 always gets brushed off because it is not the supported release yet. |
| 13:07 | dv_ | but yeah, a clear channel isnt designated |
| 13:09 | jnettlet | I am just not a big fan of community.freescale.com, I would rather have a mailing list or something else a little easier to track progress of a bug. |
| 13:10 | dv_ | I think the meta-freescale mailing list would be suitable for this |
| 13:10 | jnettlet | actually if they could enable the bug-tracker and do pull requests from github that would be excellent. |
| 13:10 | jnettlet | yeah but meta-freescale is OE specific right? |
| 13:10 | dv_ | hmm yeah, but I guess talking about kernel patches is ok too |
| 13:11 | dv_ | otavio: what do you think? |
| 13:13 | otavio | jnettlet: dv_: yes, we can pick kernel patches there. I can also work as a proxy for this. |
| 13:14 | dv_ | this would be cool, it would make the work of jnettlet and _rmk_ more visible |
| 13:14 | dv_ | btw whats the relation between jnettlets 3.10 kernel and rmk's 3.13 (or 3.14? ) one? |
| 13:16 | _rmk_ | dv_: my patch set is now based on this morning's tip of Linus' tree |
| 13:17 | jnettlet | dv_, _rmk_ is putting things upstream, I am backporting and merging to a long term stable kernel |
| 13:17 | otavio | _rmk_: :) |
| 13:18 | otavio | _rmk_: does the ethernet DT thing been fixed? |
| 13:18 | otavio | dv_: I can help but I need jnettlet to help me as well doing the patchesets as clean and as documented as possible. |
| 13:18 | jnettlet | because my stuff isn't going upstream I can do things like patch galcore, figure out what patches are in the FSL that can fix problems upstream |
| 13:18 | _rmk_ | dv_: I'm doing the "let's get stuff sorted out and into mainline", jnettlet is doing the "let's provide something complete with all the bells and whistles for you guys to use" |
| 13:19 | _rmk_ | ... and more modern :) |
| 13:20 | wbx | _rmk_: where is your stuff accessible? |
| 13:20 | _rmk_ | otavio: ethernet is fine for AR8035... I don't think SolidRun have made any boards with the AR8030 fast ethernet chip on. |
| 13:20 | otavio | _rmk_: I second both. |
| 13:20 | MikeSeth | somebody posted this screenshot on the forums, http://imx.solid-run.com/forums/download/file.php?id=12 |
| 13:21 | MikeSeth | are those ethernet phy error messages on top normal? |
| 13:21 | _rmk_ | so all boards have the gigabit AR8035 phy on, which is now fully supported in mainline :) |
| 13:21 | _rmk_ | as of last night |
| 13:21 | _rmk_ | urgh, jpeg. |
| 13:21 | jnettlet | MikeSeth, yeah that is do the PFD errata. I was testing a u-boot patch for that. |
| 13:22 | _rmk_ | wbx: latest set of patches aren't pushed out yet (it's building) but there's previous sets at http://www.home.arm.linux.org.uk/~rmk/cubox/ |
| 13:22 | jnettlet | s/do/due/ |
| 13:22 | _rmk_ | wbx: but... that doesn't cover all the fun bits like gpu and vpu yet |
| 13:22 | jnettlet | _rmk_, does your latest round include eSATA and wifi fixes? |
| 13:23 | _rmk_ | I want to get imx-drm sorted out in mainline, and then hopefully jnettlet will have the vivante stuff in shape :) |
| 13:23 | _rmk_ | eSATA yes, wifi... still a no on that |
| 13:23 | _rmk_ | eSATA is still a hack though |
| 13:24 | _rmk_ | the ahci_imx driver has at least had some attention recently, so post merge window I'll look at sorting it out better |
| 13:24 | wbx | _rmk_: so someone want to follow your develop line, needs to apply patches from here hummingboard-cubox-i-v3.13-20140120/ ? you have no git repo online? |
| 13:25 | jnettlet | wbx, I can start mirroring _rmk_'s repo to my github account |
| 13:25 | jnettlet | _rmk_, are you okay with that? |
| 13:25 | _rmk_ | wbx: I'm trying not to for stuff which changes frequently - as I'm intending to track mainline, updating the patches as things happen, git doesn't make that much sense |
| 13:26 | wbx | my devie is not yet delivered, but I do not want to start with the old kernel. |
| 13:26 | wbx | _rmk_: but how you manage then the patches? without git? |
| 13:27 | _rmk_ | wbx: my work-flow is to provide clean and simple patches suitable for merging into mainline - last thing I want is lots of historical baggage behind them. |
| 13:27 | wbx | _rmk_: okay. I understand. |
| 13:28 | _rmk_ | wbx: I do keep them in git, but I have additional tools on top of git which facilitate keeping the patches clean, which has the effect of (from an external point of view) lots of rebasing. |
| 13:28 | _rmk_ | that basically means anyone trying to take a git version and build upon it will find the history has changed when they update to a later version |
| 13:30 | _rmk_ | given that some of my patches are down-right hacks which break other stuff (like the eSATA one)... that certainly is not be upstreamable in it's current form, so it will eventually be replaced. |
| 13:30 | wbx | _rmk_: what devices you develop for? i1, i2, i2ultra or i4pro? |
| 13:31 | _rmk_ | hb and i4pro, but I've been mindful of the i1-i2ultra |
| 13:31 | _rmk_ | what's just gone into mainline is the basic support for all the imx6 solid-run platforms |
| 13:32 | Coolgeek | is there still someone who work on the first cubox ? |
| 13:32 | wbx | _rmk_: okay, good to know. |
| 13:32 | _rmk_ | Coolgeek: Linux cubox 3.13.0+ #799 PREEMPT Mon Jan 27 22:56:18 GMT 2014 armv7l armv7l armv7l GNU/Linux |
| 13:32 | jnettlet | besides some basic bootstrapping most the boards should behave relatively similar. |
| 13:32 | jnettlet | unfortunately we have recently found a couple of differences but nothing major |
| 13:33 | dv_ | Coolgeek : there are some things that need fixing in my Vmeta Gstreamer plugins, but Cubox-i has priority atm |
| 13:33 | Coolgeek | thought so dv_ :) |
| 13:33 | wbx | i ordered i2ultra and my college i4pro. |
| 13:33 | jnettlet | Coolgeek, where it matters yes. It will benefit from the new Vivante driver work |
| 13:33 | _rmk_ | most differences are at the SoC level post boot-strapping, which is taken care of using the right DT include :) |
| 13:34 | jnettlet | _rmk_, did you see that Armv8 is growing ACPI support? |
| 13:35 | _rmk_ | so.. mainline has three DT files: one for the hummingboard, one for the imx6s/dl cubox-i, and one for the imx6q |
| 13:35 | _rmk_ | jnettlet: yep, I'm aware of that |
| 13:36 | jnettlet | so all this work on DT we get to do again with UEFI and ACPI...hurray!!! |
| 13:36 | _rmk_ | it's more meant for server, not for embedded |
| 13:37 | Coolgeek | the fun is not in the straight line ! |
| 13:37 | wbx | _rmk_: are all cubox-i models imx6s? |
| 13:37 | dv_ | No |
| 13:37 | _rmk_ | I believe embedded will stick with DT |
| 13:38 | wbx | ah, s for single cpu and q for quad. |
| 13:38 | jnettle | 13:38 * jnettlet wonders what will distinguish ARMv8 server vs embedded/mobile |
| 13:38 | jnettlet | yeah s/dl d/q are the two distinctions |
| 13:38 | jnettlet | solo/dual-lite dual/quad |
| 13:39 | wbx | but what is used inside cubox-i2 and cubox-i2ultra? |
| 13:39 | wbx | jnettlet: ah. okay. |
| 13:39 | wbx | now I got it. |
| 13:40 | wbx | cubox-i1 and cubox-i2 are s/dl and cubox-i2ultra and cubox-i4pro are d/q |
| 13:40 | _rmk_ | well, that eventually built :) |
| 13:40 | _rmk_ | I'll try it out in a bit |
| 13:40 | _rmk_ | back later. |
| 14:12 | jnettlet | #cubox is slowly working its way up to 100 lurkers |
| 14:13 | MikeSeth | they're waaaatching |
| 14:15 | jnettlet | _Adik_, I dug up that patch for you to test. Do you need me to build you new u-boot binaries? |
| 14:16 | _Adik_ | jnettlet: hi |
| 14:16 | _Adik_ | would be great if you could build it for me |
| 14:17 | jnettlet | _Adik_, okay let me clean up my tree. |
| 14:17 | matoking | Any people here who've had their Cuboxes shipped recently |
| 14:18 | matoking | Mine is supposed to be shipped by the end of the month and I'm becoming more anxious every moment :P |
| 14:18 | _Adik_ | is here any special howto about updating uboot or is it a matter of dd onto cd card? |
| 14:18 | _Adik_ | *sd card |
| 14:20 | jnettlet | _Adik_, just a couple of dd commands |
| 14:28 | _rmk_ | well, it boots, and the annoying warning and backtrace which pops up when no displays are connected is gone :) |
| 14:29 | _rmk_ | or... are connected but are powered off |
| 14:31 | jnettlet | _Adik_, https://dl.dropboxusercontent.com/u/736509/i4pro/u-boot/SPL https://dl.dropboxusercontent.com/u/736509/i4pro/u-boot/u-boot.img |
| 14:31 | jnettlet | you can get the dd commands from http://imx.solid-run.com/wiki/index.php?title=Building_the_kernel_and_u-boot_for_the_CuBox-i_and_the_HummingBoard |
| 14:31 | _rmk_ | eurgh, maybe not |
| 14:31 | _rmk_ | looks like NFS is broken |
| 14:32 | jnettlet | ??? |
| 14:32 | _rmk_ | # touch test |
| 14:32 | _rmk_ | touch: cannot touch `test': Operation not supported |
| 14:32 | _Adik_ | jnettlet: the one with SPL is correct? |
| 14:32 | _Adik_ | I cannot download it |
| 14:33 | jnettlet | try this. https://dl.dropboxusercontent.com/u/736509/i4pro/u-boot/SPL |
| 14:33 | jnettlet | looks the same |
| 14:34 | _Adik_ | maybe it is the proxy here |
| 14:34 | _Adik_ | Ill try later from home, will flash it and report you back |
| 14:34 | jnettlet | okay good luck |
| 15:57 | dv_ | jnettlet: nice to hear about 3.10 |
| 15:58 | dv_ | I am not sure whether or not to follow up with meta-fsl patches for it though |
| 16:03 | dv_ | if I understand otavio correctly he'd prefer it to use the 3.10 fsl one with your patches on top |
| 16:13 | jnettlet | dv_, he is more than welcome to rebase and maintain the patches on top of the fsl kernel. Since I am maintaining patches for multiple platforms that is just not an option. |
| 16:15 | jnettlet | For me fsl is not upstream. They are a fork of upstream. Linaro is as well but they are a much more qualified maintainer of a a long term fork, which is what I am interested in. |
| 16:16 | dv_ | I find this parallel development of linaro and fsl curious |
| 16:17 | dv_ | so linaro is doing something similar to what you are doing. rolling up the fsl changes in a better way. |
| 16:22 | jnettlet | not really. Linaro, and really GKH, has agreed to a long term support kernel. Where they will pick a kernel version based on features and stability and then maintain it with security and bugfixes for 2 years. |
| 16:23 | jnettlet | I am basing my work on that since I want something relatively stable for a while because my time and patience for chasing after bugs introduced by new features is limited right now. |
| 16:24 | jnettlet | 3.10 lks is a good balance for me. |
| 16:24 | dv_ | ah okay |
| 16:24 | jnettlet | I am then taking all the work done on Mrvl/FSL and merging that into a single kernel repo, maybe on different branches I am not sure. |
| 16:25 | dv_ | and _rmk_ then works on taking your patches and mainlining them |
| 16:25 | jnettlet | On top of that I am backporting features that I think developers need, or the platforms need that are upstream. |
| 16:25 | dv_ | thats actually a pretty nice workflow |
| 16:26 | jnettlet | those features are _rmk_'s patches, and also things like zswap which is a great feature for the HB1/CBi's with limited RAM |
| 16:26 | dv_ | it produces a full-featured kernel (yours), and one which mainlines more and more parts over time (_rmk_'s) |
| 16:26 | jnettlet | that is hope |
| 16:26 | jnettlet | the hope |
| 16:27 | jnettlet | and as we find ways to get more and more patches upstream, my kernel is needed less and less. Hopefully by the time the 2 years is up everything will be upstream. |
| 16:27 | dv_ | yeah |
| 16:30 | jnettlet | since I am not being paid by any company to do any of this, I am doing it my way :-P |
| 16:31 | jnettlet | oh 88 users. I think that is the highest count I have seen |
| 16:51 | _rmk_ | yea, NFS in Linus' tip is busted |
| 16:54 | jnettlet | get out the pitchforks |
| 16:54 | jnettlet | Someone in Japan has reviewed the CBi. http://translate.google.com/translate?sl=auto&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&u=http%3A%2F%2Fgigazine.net%2Fnews%2F20140114-cubox-i1-review%2F&act=url |
| 16:55 | jnettlet | provided the English translated link |
| 17:00 | hste | jnettlet: did u read it in Japaneese? :) |
| 17:01 | jnettlet | hste, not at all. Would love to be able to, but I am having a hard enough time with Danish |
| 17:01 | jnettlet | Actually I bet Japanese is easier than Danish |
| 17:01 | hste | jnettlet: Danish is easy to read :) at least for me |
| 17:03 | hste | jnettlet: but counting in Danish is difficult |
| 17:03 | kuguar-tsk | I have successfully connected the mouse to android. third. and it works. |
| 17:03 | jnettlet | yeah yeah. Do you watch the Netflix show LilyHammer? |
| 17:03 | hste | jnettlet: yes. Its were I was borned :) |
| 17:03 | hste | +h |
| 17:04 | jnettlet | hste, ha. Pretty accurate? |
| 17:04 | hste | nope :) |
| 17:04 | kuguar-tsk | need |
| 17:04 | kuguar-tsk | to add to the list of incompatibilities mouse |
| 17:05 | kuguar-tsk | a4tech glaser series |
| 17:05 | jnettlet | kuguar-tsk, so one mouse works and the other doesn't? |
| 17:05 | kuguar-tsk | two mouse not works |
| 17:05 | hste | jnettlet: http://www.youtube.com/watch?v=s-mOy8VUEBk this one is about the difficult Danish |
| 17:06 | kuguar-tsk | but in debian they works fine |
| 17:06 | jnettlet | hste, I have seen that, and that is not far from the truth |
| 17:06 | jnettlet | kuguar-tsk, could be the android kernel config is missing a driver needed. |
| 17:07 | jnettlet | can you post the dmesg output of a debian boot with the mouse connected? |
| 17:07 | kuguar-tsk | yes |
| 17:13 | kuguar-tsk | jnettlet, http://paste.org.ru/?vducdb |
| 17:16 | jnettlet | kuguar-tsk, hmmm strange seems like a normal usb hid device |
| 17:16 | _rmk_ | hste: what can be really difficult is opening a packet of danish blue :) |
| 17:17 | _Adik_ | jnettlet: just tested the u-boot that you compiled for me earlier |
| 17:17 | jnettlet | and? |
| 17:17 | _Adik_ | works really good, 20 boots = 20 succesfull |
| 17:17 | jnettlet | excellent! |
| 17:17 | _Adik_ | compleatly different experience than before! |
| 17:18 | jnettlet | rabeeh, looks like my pfd patch may be a winner. |
| 17:19 | _Adik_ | so, the only problem that persists is the kernel... |
| 17:22 | hste | _rmk_: I like danish blue :) |
| 17:23 | _rmk_ | so do I... up to the point where it takes knives and scissors to get into the packet because they've sealed it soo well |
| 17:28 | jnettlet | the Danes are ridiculous with their packaging. |
| 17:37 | _rmk_ | found he-who-has-an-autoresponder-on-his-nick's email |
| 17:37 | _rmk_ | sent from an IP with no DNS |
| 17:38 | _rmk_ | certain ISPs reject outright for that offence |
| 17:41 | jnettlet | as they should |
| 17:42 | jnettlet | tlw come back we need your for 90 |
| 20:08 | MikeSeth | a thought just occurred to me |
| 20:08 | MikeSeth | I can write a simple php script to collect and compare uboot/dmesg output |
| 20:09 | MikeSeth | would that be useful? |
| 20:19 | mpd_guy | hi, I've just setup archlinux on my cubox. I've setup mpd and am streaming the sound through hdmi to my hifi equip. that is working pretty well. but the cubox is going to disable the hdmi output after about 5 minutes of inactivity. do you have an idea how to fix that? |
| 20:21 | mpd_guy | i've no X server installed. so it is nox X/ DPMS related |
| 20:21 | _rmk_ | does that mean you're using a normal virtual console or something graphical? |
| 20:21 | _rmk_ | that was going to be my question :) |
| 20:21 | _rmk_ | TERM=linux setterm -blank 0 >/dev/tty1 |
| 20:23 | _rmk_ | that disables the virtual console blank timeout |
| 20:24 | mpd_guy | ooh cool. that worked well :-) |
| 20:27 | _rmk_ | you'll need to do that at each boot, so you may want to consider putting it in the rc.local startup script... which'll be somewhere under /etc |
| 20:27 | mpd_guy | yeah, sure :-) |
| 20:28 | mpd_guy | I am just wondering about the TERM variable. the value linux seems to link to the kernel, doesn't it? because usually there is something like xterm in it |
| 20:28 | MikeSeth | oh this is actually an annoyance in debian too |
| 20:29 | MikeSeth | good idea |
| 20:30 | _rmk_ | mpd_guy: well, it's a linux-specific control code sequence |
| 20:31 | _rmk_ | The linux console based upon the vt100 standard plus a number of extras |
| 20:31 | _rmk_ | one of them is the ESC [ 9 ; ] sequence which sets the blank timeout |
| 20:32 | _rmk_ | so, I could've told you this instead: echo -en '\033[9;0]' >/dev/tty1 |
| 20:33 | mpd_guy | well... that is... nothing I am going to use :D |
| 20:35 | mpd_guy | I had a look for the man page of setterm before going to ask here. And I got really no idea or breadcrumb that I've to reference to a term "linux". |
| 20:36 | mpd_guy | but that is working pretty good. thx again! |
| 20:47 | _rmk_ | yea, it's not that well documented, because most people just tend to run it from the console |
| 20:48 | _rmk_ | it doesn't make sense to run it from within xterm or similar (and may do something unexpected) |
| 21:15 | jnettlet | you can add consoleblank=0 to the kernel command line as well |
| 23:21 | xraxor | if women loved me as much as the flu it would b like heaven lol |
| 23:21 | xraxor | second time in space on couple of months |