01:54 | cardiel | Will a SanDisk Extreme microSDHC (80mb/s) card work on cubox-i4? |
03:01 | mhoney_work | cardiel, That would be cool indeed, but I doubt your going to get 80mbs |
05:28 | jmontleo | cardiel, i have an ultra and it works with the 3.0.35 kernel; been trying to build something 3.12 or 3.13 and have been having an abysmal time of it, though I don't think it's necessarily the card |
08:28 | MikeSeth | rabeeh: here yet? |
10:40 | jnettlet | jmontleo, okay looking at the 3.0.35 kernel and the data I have collected I see what is going on with newer and upstream kernels. |
10:46 | MikeSet | 10:46 * MikeSeth pokes rabeeh |
10:48 | jnettlet | _rmk_, did you say that you had working SDHC card detection? I ask you because you are booting your rootfs over nfs and can easily test it. |
10:51 | jnettle | 10:51 * jnettlet thinks we need to mask off the CARD_INSERT _REMOVE interrupts and use SPI mode for card detection |
10:52 | _rmk_ | works here |
10:53 | jnettlet | you looked at this when you setup device tree. We are using SPI mode for the DAT3 and setting it up as a GPIO? |
10:54 | _rmk_ | DAT3 is setup as DAT3, but with a pull-up instead of pull-down |
10:54 | _rmk_ | but that's to work around the driver always enabling DAT3 detection |
10:55 | _rmk_ | we're using the card detect as the primary detection |
10:57 | jnettlet | okay then something definitely is not working correctly because we are constantly firing off card insert card removed interrupts and then checking the card state to see if it is present. |
10:57 | jnettlet | more like polling than actual detection |
10:58 | _rmk_ | 55: 1170 GIC 55 mmc0 |
10:58 | _rmk_ | 09:58:24 up 1 day, 16:56, 2 users, load average: 0.00, 0.01, 0.05 |
11:00 | jnettlet | 55: 7681 GIC mmc0 |
11:00 | jnettlet | 10:00:38 up 1 min, load average: 2.07, 0.81, 0.29 |
11:02 | _rmk_ | removing and inserting a couple of times: |
11:02 | _rmk_ | 55: 1773 GIC 55 mmc0 |
11:02 | _rmk_ | and it becomes stable: |
11:02 | _rmk_ | 55: 1773 GIC 55 mmc0 |
11:05 | jnettlet | okay /me has to figure out what we are missing in the 3.10 device-tree to fix this |
12:16 | MarcusVinter | jnettlet, Its alive, thanks for all your help the past days. |
12:16 | jnettlet | MarcusVinter, excellent! Let us know what you end up using it for. |
12:17 | MarcusVinter | I will do. It's basically a thin client type device but a bit more complicated. |
12:33 | dv_ | i4pro is here \o/ |
12:37 | jnettlet | _rmk_, oh your hummingboard dts file is different. |
12:38 | dv_ | jnettlet: does the uboot config differ between i1, i2, i2ultra, i4pro? |
12:38 | jnettlet | dv_, currently yes. soon no |
12:38 | dv_ | config for i4pro is ? |
12:39 | jnettlet | dv_, I think rabeeh has binaries posted. |
12:39 | dv_ | so what about https://github.com/linux4kix/u-boot/tree/imx6/board/solidrun/mx6_cubox-i ? |
12:39 | _rmk_ | looks like my i4pro has been dispatched |
12:40 | _rmk_ | thanks rabeeh! |
12:40 | dv_ | the i4pro is noticeably heavier than the original cubox |
12:40 | _rmk_ | dv: so it doesn't get dragged around by the cables? |
12:41 | _rmk_ | my cubox tips backwards through the weight of the hdmi cable |
12:41 | jnettlet | dv_, yeah I counter weighted my cubox, and then suggested it to rabeeh. They had been on the fence to include it and my push got the ball rolling |
12:45 | jnettlet | and my i4pro just showed up. Thanks rabeeh |
12:45 | dv_ | jnettlet: so, the link I posted contains incomplete code? |
12:46 | dv_ | if so, I'll just stick with rabeeh's binaries. otherwise I'd try to integrate it with the yocto recipes |
12:55 | jnettlet | dv_, nope that is all there. You specify the different configs at compile time. |
12:56 | dv_ | what confuses me is that in https://github.com/linux4kix/u-boot/tree/imx6/board/solidrun/mx6_c1 there are config files for solo,dual,quad |
12:56 | jnettlet | I would wait until the SPL code is tested to push to yocto. Then you can have 1 build for all devices |
12:56 | dv_ | but not for cubox-i |
12:56 | cardiel | if i install debian with the netboot installer, will xorg then use accelerated drivers when playing videos or using xbmc? |
12:56 | dv_ | hmm okay, how long do you estimate will this take? and otavio, how soon should I submit the patches? |
12:59 | jnettlet | dv_, if you don't mind updating your patches later I would say go ahead. |
12:59 | dv_ | okay |
12:59 | jnettlet | there is just going to be a lot of consolidation churn in the next month |
12:59 | dv_ | thats fine by me. otavio, what do you say? |
13:04 | MikeSeth | okay, so who's responsible for vivante gpu/vpu extensions? |
13:05 | MikeSeth | rabeeh asked for debian packaging help a couple of days ago |
13:05 | dv_ | what extensions? do you mean additions to the kernel? |
13:05 | MikeSeth | yeah |
13:05 | MikeSeth | and I understand userspace libraries as well |
13:05 | dv_ | hmm... freescale I guess |
13:05 | dv_ | note that vivante will not ever talk to you directly |
13:06 | dv_ | they expect you to talk to your vendor (in this case, freescale) |
13:06 | MikeSeth | uhh, I understand that there's some code on top of the BSP |
13:06 | jnettlet | Yeah Vivante writes the drivers and then provides them to the chip makers who release their version of the driver. |
13:06 | MikeSeth | jnettlet: so this needs to be managed as binaryonly debs? |
13:06 | jnettlet | MikeSeth, for now yes. But there is an OSS driver in the works |
13:06 | dv_ | the gpu userspace libraries yes (libEGL, libGAL, libGLESv2 etc.) |
13:07 | dv_ | vpu firmware as well |
13:07 | jnettlet | yeps |
13:07 | dv_ | and I think something related to audio is binary only as well |
13:07 | dv_ | thats about it |
13:07 | MikeSeth | http://imx.solid-run.com/forums/viewtopic.php?f=2&t=326&start=10#p1655 <- I'm talking about this post |
13:08 | dv_ | oh, right, you need to deal with the mesa<->binary conflict |
13:08 | dv_ | otavio and others added some workarounds to make sure mesa's libEGL and libGLESv2 are not used |
13:08 | jnettlet | I am not sure how debs do it, but rpms allow you to specify a provides and conflicts |
13:08 | dv_ | but that is OE specific |
13:09 | MikeSeth | jnettlet: debs do too, and there's a divertion system in place as well, and some namespacing support |
13:09 | _rmk_ | jnettlet: debian's control allows the same |
13:09 | jnettlet | really what works best is what I generally have been doing and putting them in /usr/lib/ilbgfs with an ldconfig file |
13:09 | jnettlet | /usr/lib/libgfx that is |
13:10 | jnettlet | basically look at what nvidia does and do that. |
13:11 | MikeSeth | anywhere I can read about the summary of what binaries need to be packaged and where they come from? |
13:12 | dv_ | http://download.ossystems.com.br/bsp/freescale/source/ check this out |
13:12 | dv_ | this is a mirror for the fsl source |
13:13 | dv_ | overall, I'd strongly recommend to take a look at https://github.com/Freescale/meta-fsl-arm . even though it is for OpenEmbedded, it is being maintained by fsl developers and contractors. |
13:13 | MikeSeth | great, that's a start |
13:13 | MikeSeth | thanks |
13:13 | jnettlet | freescale still hasn't released the updated gpu binaries for the 3.10.17-beta kernel code drop. |
13:15 | dv_ | next best thing I see is this https://github.com/Freescale/meta-fsl-arm/blob/master/recipes-graphics/gpu-viv-bin-mx6q/gpu-viv-bin-mx6q_3.10.9-1.0.0-hfp.bb |
13:16 | jnettlet | yeah that is what I am using |
13:17 | MikeSeth | in the sense of wtf per minute, how nice is it working with fsl & vivante platforms? |
13:17 | MikeSeth | I'm totally invading rabeeh's office some soon |
13:17 | dv_ | overall I think its okay. freescale support is much better than that of most vendos |
13:18 | dv_ | *vendors |
13:18 | dv_ | compare it to say, marvell |
13:18 | jnettlet | freescale is pretty in touch with their developers and the community which is nice. |
13:18 | MikeSeth | I used to work with a guy who stocked up on an experimental line of Fuji DSL chips.. man that was a disaster |
13:18 | dv_ | in fact, sometimes they support almost too much :) I remember that 5000 page PDF monstrosity |
13:18 | jnettlet | I think their constant Vivante updates is proving that Marvell was the weak link in that chain |
13:19 | dv_ | software tends to be the weaker sport in fsl stuff |
13:19 | dv_ | *spot |
13:19 | dv_ | damnit, cant type today |
13:19 | jnettlet | yeah, but we are speeding that up pretty quickly |
13:19 | dv_ | yes |
13:20 | dv_ | they also officially support wayland, which is a big plus in my book |
13:21 | dv_ | MikeSeth: I think rabeeh is catching up on his lost sleep during the last moments of development. |
13:21 | MikeSeth | dv_: I bet he does |
13:21 | dv_ | so, he'll sleep for a couple of months :) |
13:21 | MikeSeth | this is so typically israeli |
13:21 | dv_ | ? |
13:22 | jnettlet | Is there a question you need answered that we can't answer? |
13:22 | MikeSeth | dv_: there isn't, you know, strictness |
13:22 | MikeSeth | jnettlet: at this stage, no, I still have a bunch of imx manuals to read up |
13:22 | dv_ | well, I observed just how much rabeeh was working the last few months, and was genuinely concerned he'd burn out |
13:23 | dv_ | so I'd cut him some slack here |
13:23 | MikeSeth | i was curious though, couldn't the internal ROM on imx6 be used to facilitate basic initialization w/o sdcard, and boot from pxe or usb? |
13:23 | jnettlet | MikeSeth, no |
13:24 | MikeSeth | then I know even less about the boot sequence than I thought |
13:24 | dv_ | right. this is something I was wondering about too. so even if your system is on a hard disk connected via sata, you need to put in an sd card |
13:25 | MikeSeth | jnettlet: do all imx-based products require MMC boot then? |
13:25 | jnettlet | dv_, yes |
13:26 | jnettlet | MikeSeth, I don't know about all of them. Just the MX6 |
13:26 | MikeSeth | also, as imx supports HAB, there should be some boot code that predates MMC boot -somewhere- no? |
13:27 | jnettlet | there is an internal rom that reads a set of fuses that are set by the manufacturer and control the boot device |
13:28 | MikeSeth | oh.. I thought those were intended for crypto & device identification |
13:28 | jnettlet | they do multiple things, set ethernet MAC |
13:29 | MikeSeth | http://www.fedevel.com/welldoneblog/2013/10/how-does-arm-boot/ <- I'm reading this now |
13:29 | MikeSeth | also there's otp override mechanism |
13:35 | MikeSet | 13:35 * MikeSeth ponders a wandboard |
13:51 | otavio | dv_: what is the problem |
13:52 | dv_ | otavio: you need my patches asap, right? |
13:53 | dv_ | we were discussing the SPL support in uboot |
13:53 | otavio | dv_: about mesa |
13:53 | dv_ | I would wait until the SPL code is tested to push to yocto. Then you can have 1 build for all devices |
13:53 | otavio | ? |
13:53 | dv_ | oh that |
13:53 | otavio | dv_: no; SPL will take a while to be ready |
13:53 | dv_ | you added some workaround to filter out the libEGL, libGAL etc. |
13:53 | dv_ | to avoid collisions between mesa and the vivante userspace binaries |
13:53 | jnettlet | otavio, rabeeh has SPL booting the devices now. It just won't be mainline for a while |
13:54 | dv_ | MikeSeth now faces the same problem |
13:54 | dv_ | (except he is packaging everything for debian, not openembedded) |
13:54 | otavio | jnettlet: yes; mainline work is progressing but not complete |
13:55 | otavio | jnettlet: in this case, add the u-boot recipe in yocto for it |
13:55 | otavio | dv_: ^ |
13:55 | MikeSeth | not *packaging*, just *want to* :) |
13:55 | jnettlet | but does yocto only pull from mainline? |
13:55 | dv_ | otavio: alright |
13:55 | jnettlet | ah okay, we can pull from a solidrun repo |
13:55 | otavio | yes |
13:55 | otavio | sure |
13:55 | otavio | I'd prefer people commit to finish SPL in mainline ... |
13:55 | otavio | but |
13:55 | dv_ | ah, and otavio, I pointed MikeSeth to the ossystems package mirror. is this stuff for yocto only, or can he use it for debian as well? |
13:56 | MikeSeth | I'm sorry if this isn't clear, I'm very new to hw programming and embedded in general |
13:57 | dv_ | MikeSeth: no worries, we all got confused about this at first. the embedded world tends to be chaotic. |
13:58 | dv_ | at least you start with freescale. the marvell stuff was far less organized |
13:58 | jnettlet | yeah documentation what? drivers, well we have some 2.xx android drivers you can reference |
13:59 | dv_ | yes, and some random code drops, containing the same package 3 times, with slight differences. no version numbers, no explanation. |
14:00 | otavio | dv_: he can use |
14:01 | dv_ | the fsl packages sometimes have strange versioning (3.5.7 / 12.09 / 11.04 / 1.1 / etc.) but overall its much nicer |
14:14 | MikeSeth | is the internal imx ROM an actual ROM? or is it some sort of flash? |
14:18 | jnettlet | it is a ROM. |
14:18 | jnettlet | if you want in depth answers for the SOC you should probably join the freescale dev forums. |
14:18 | MikeSeth | I will |
14:38 | jnettlet | _rmk_, which kernel are you running on your hummingboard? I just grabbed your tree and device-tree and get this just after boot. |
14:38 | jnettlet | 55: 59019 GIC 55 mmc0 |
14:54 | jmontleo | jnettlet, so do you think it's something to do with the dtb? I've tried a couple versions for the heck of it with no luck |
14:55 | jnettlet | jmontleo, have you tried _rmk_'s tree? |
14:56 | jnettlet | haven't narrowed it down to any patch that screams "I have fixed the problem" yet. |
14:56 | jmontleo | yes - that's what I have been trying; first when it was 3.12-rc4 and after when it was updated to 3.13-rc7; dunno; maybe I have something in my .config that is screwing it up, but the only thing I have gotten to boot is the copy of the 3.0.35 kernel i pulled off the debian image to get started |
15:01 | jnettlet | hmmm that is strange. I just compiled his kernel and device tree and it booted right up. hundred thousands of interrupts but it booted |
15:02 | jnettlet | hmmm oh but _rmk_ doesn't boot off the sdhc card. I wonder if that has something to do with it. |
15:04 | MikeSeth | which reminds me, I should stock on cards |
15:04 | jmontleo | jnettlet, any chance you can pastebin the .config you are using? i'm also using an i4pro; don't know if that would/could be making a difference |
15:04 | jnettlet | jmontleo, shouldn't. actually let me try and boot this on my i4pro to see what happens |
15:22 | jnettlet | jmontleo, just tested _rmk_'s kernel device-tree on my i4pro and am seeing the same problem as you. |
15:24 | _rmk_ | jnettlet: does it have that problem on the HB? |
15:24 | jnettlet | _rmk_, HB just has the interrupt storm but survives it |
15:25 | _rmk_ | wonder if it's got something to do with DAT3 being used |
15:28 | jmontleo | jnettlet, ah - ok, so something different about i4 |
15:29 | _rmk_ | well, my i4pro has arrived after the email about it being sent this morning |
15:29 | jnettlet | yep mine showed up also, which is why I am testing this. |
15:31 | _rmk_ | I'm currently trying to get to the bottom of all the broadcast/multicast traffic asking for the address of my old firewall... which means I've missed some config changes |
15:32 | jnettlet | internal or external? |
15:32 | _rmk_ | oh, internal |
15:32 | _rmk_ | some of it is ntp clinging on to the address after it was a multicast ntp server |
15:33 | _rmk_ | I think I'm now (just) down to only the new firewall trying to find it |
15:47 | jnettlet | mmc0 got interrupt: 0x00100000 now we are getting somewhere |
15:49 | jmontle | 15:49 * jmontleo likes the sound of that |
16:03 | dv_ | hmm uboot does not have the hdmidet command |
16:04 | jnettlet | so forcing the bus width down to 8-bit has my card booting now. Although I thought the slot only support 4-bit on this board |
16:05 | _rmk_ | "down to 8-bit" ? |
16:05 | jnettlet | _rmk_, that is "max" width |
16:07 | jnettlet | setting it to 4 seems good also. So we need to change the device-tree or figure out why this isn't negotiating properly |
16:08 | jnettlet | oh that may have fixed my interrupt problem as well. weird |
16:09 | jnettlet | but only getting 2 cores coming online |
16:14 | jnettlet | oh that is why this started working. It is not bumping it up to uhs 2 mode. |
16:14 | jnettlet | sdhci-esdhc-imx 2194000.usdhc: could not get ultra high speed state, work on normal mode |
16:16 | jmontleo | i have been seeing that message as well |
16:16 | jmontleo | even when not working |
16:21 | jnettlet | jmontleo, okay so edit the device-tree for your board and add bus-width = "4"; to your usdhc2 section |
16:21 | dv_ | jnettlet: have you tried introducing the hdmidet patch from u-boot-imx into your fork? I'll try it out once I send my patches to otavio |
16:22 | dv_ | it would be nice to have the uEnv.txt script autodetect the highest possible resolution the display supports |
16:22 | jmontleo | jnettlet, just did so, rebooting now :) |
16:23 | jmontleo | i jumped the gun and went and looked how to do it when you said it got it booting for you :) |
16:24 | jnettlet | dv_, I had it in there briefly but it wasn't working for some reason. It is on my list of cleanup things just haven't gotten back to that list |
16:24 | dv_ | that command itself was cleaned up afterwards |
16:24 | dv_ | it didnt support DVI monitors properly |
16:25 | jnettlet | oh that may have fixed my problems. I looked at it and was less than happy with it |
16:26 | jnettlet | dv_, we can test again with the SPL code. Although pushing higher resolutions will also just make the text tiny tiny tiny |
16:27 | dv_ | jnettlet: http://lists.denx.de/pipermail/u-boot/2013-July/159344.html |
16:27 | dv_ | ehm no, I didnt mean the video mode uboot itself uses. |
16:27 | dv_ | I mean what I specify to the kernel |
16:27 | dv_ | with hdmidet, I can try out several modes, and then set the kernel command line accordingly |
16:29 | jnettlet | oh I was going to add that into the kernel regardless, and the DRM driver already does that |
16:29 | dv_ | ah okay. nevermind then. |
16:29 | jnettle | 16:29 * jnettlet ponders his missing 2 cores |
16:37 | jnettlet | jmontleo, you good? |
16:37 | dv_ | otavio: just sent the patch to the meta-fsl mailing list |
16:38 | otavio | dv_: good; I will review them and provide feedback |
16:38 | jmontleo | jnettlet, telling me undefined instruction when I try to boot; probably doing it wrong |
16:39 | jnettlet | well I have no usb now |
16:40 | jmontleo | ya, I've noticed that too; went to boot off a thumb drive for the short term, except it wouldn't show up |
16:42 | jnettlet | yep no usb :-( |
16:43 | jnettlet | jmontleo, do you want my zImage and dtb to test against? |
16:44 | jmontleo | sure |
16:50 | jnettlet | jmontleo, i4pro under https://www.dropbox.com/sh/ck0xsrdjvin16v8/cDYW5G5xWs |
16:50 | otavio | dv_: Daiane's feedback is right; please split it in three patches and for the kernel please use the 'savedefconfig' to generate the minimal defconfig file for use. |
16:53 | jmontleo | thank you - let me give it a try; I think the zImage I was using is bust; something silly; |
16:59 | jmontleo | uggh, I'm just braindead - jnettlet it was me; one minute, your change most likely works |
16:59 | jmontle | 16:59 * jmontleo drinks more coffee and stops doing stupid stuff like appending a dtb to a uImage with a dtb already appended |
16:59 | jnettlet | oh and my missing cores are my mistake. |
17:00 | jnettlet | I need to create a new device-tree that enables the rest of the cores. |
17:01 | jnettlet | that is probably why the usb doesn't work as well |
17:08 | jmontleo | jnettlet, yep, that change worked great; I have partitions listed on mmcblk0 again |
17:08 | jnettlet | great! |
17:09 | jmontleo | and 2 cores and a kernel with all the features I need for my distro to run properly is a good start :) |
17:11 | jnettlet | jmontleo, getting the other 2 cores is easy. Still looking at the usb |
17:11 | jnettlet | oh I have 1 usb port working |
17:11 | jnettlet | I must need to get the config for the usb otg stuff right |
17:12 | jnettlet | but lost my framebuffer |
17:12 | jnettlet | no idea where that went |
17:35 | jnettlet | okay, we have 4 cpus 2 framebuffer and 1 usb port working |
17:35 | jnettlet | under 3.10.17 that is |
17:59 | _rmk_ | jnettlet: hmm, is it not supplied with a rootfs and kernel? |
18:00 | jnettlet | _rmk_, it comes with Android |
18:02 | _rmk_ | so it really needs to be plugged into the tv then |
18:02 | jmontleo | http://download.solid-run.com/pub/solidrun/cubox-i/ |
18:03 | jmontleo | there are some other images; debian, ubuntu, geexbox |
18:03 | MarcusVinter | I'm using the ubuntu |
18:03 | MarcusVinter | its working. |
18:03 | MarcusVinter | Seems a bit slow though |
18:06 | jnettlet | slow in what way? |
18:07 | hste | MarcusVinter: what ubuntu version. The one with armhf? |
18:07 | MarcusVinter | Not sure, got it from that above link a few days ago. |
18:09 | MarcusVinter | Launching apps and stuff is slow. It might be normal to be honest for Ubuntu though. I haven't tested it properly yet for what I plan to use it for anyway. |
18:09 | MarcusVinter | Just inital thoughts were its a bit slower than it should be. |
18:09 | hste | That one is armel and not as fast as the newer one |
18:10 | MarcusVinter | Wheres armhf? |
18:11 | hste | There is one ubuntu with gpu support but not vpu. And a debian jessie with both gpu and vpu support. |
18:12 | MarcusVinter | I might try the Debian one. :D |
18:12 | MarcusVinter | Thank you sir. |
18:13 | hste | You can read about the debian one here http://jas-hacks.blogspot.no/2013/12/imx6-debian-jessie-gpuvpu-3109-100.html |
18:13 | jnettlet | oh this gc2000 really runs nice |
18:15 | hste | jnettlet: so u got the kernel up with all the pieces? |
18:15 | jnettlet | hste, I am working on it. Just got the hardware today :-) |
18:16 | hste | :) |
18:16 | jnettlet | last night in my sleep I realized there was a bug in one of my galcore optimizations I need to fix |
18:17 | hste | so you work in your dreams? :) |
18:18 | _rmk_ | MarcusVinter: if you're running rootfs on the sd card, my experience is that it's painfully slow that way |
18:18 | _rmk_ | because writes take soo long to complete, they block reads |
18:18 | MarcusVinter | Oh yeah rootfs is in mmc |
18:18 | MarcusVinter | Where else could i put it? |
18:18 | jnettlet | that is why it is important to get a card that is really good at 4k random writes |
18:19 | MarcusVinter | Its highest class. |
18:19 | jnettlet | that doesn't matter. Those classes are based on large sequential writes |
18:19 | jnettlet | basically for writing audio and video |
18:19 | MarcusVinter | Oh :( |
18:20 | jnettlet | The Sandisk Ultra cards that claim 30MB/s seem to be some of the best all around performers |
18:20 | MarcusVinter | This is sandisk, came with cubox |
18:21 | MarcusVinter | Where might I put the rootfs otherwise? |
18:24 | jnettlet | esata ssd, nfs, faster sdhc |
18:34 | MarcusVinter | True true, thanks. probs faster card. |
18:34 | hste | but try another rootfs. I think the newer armhf one is faster |
18:40 | MikeSeth | yay stacked on a bunch of microsd cards |
18:42 | MikeSeth | could uboot on the card be configured to initialize esata and load the root fs from it? |
18:54 | MarcusVinter | This debian looks the same as the ubuntu one, it even says ubuntu and runs linaro |
18:54 | MarcusVinter | lol |
18:55 | MarcusVinter | hostname is linaro-ubuntu-desktop |
18:55 | hste | where did u download from? |
18:57 | MarcusVinter | http://download.solid-run.com/pub/solidrun/cubox-i/Debian/Jessi-repackaged-trial/ |
19:00 | MarcusVinter | Am I missing something? Why might the hostname be linaro-ubuntu-desktop if its the Debian release? |
19:00 | MarcusVinter | haha |
19:01 | hste | MarcusVinter: You can try this linux installer script: http://stende.no-ip.info/imx6/solidrun-hb/scripts/mk_jessie-lxde_hb.sh |
19:01 | jnettlet | damn it the irq storms on mmc0 are back. |
19:02 | jnettle | 19:02 * jnettlet shakes fist at IRQ 55 |
19:03 | MikeSeth | MarcusVinter: uhh maybe you plugged the wrong card or didnt actually write to it? the hostname on that image is debian-imx6 |
19:03 | MarcusVinter | Thanks hste. |
19:03 | MarcusVinter | Ill try it again lol |
19:03 | MarcusVinter | There is a huge possibility I was stupid enough to mix some images up. Ill re D/L and try it and let you guys know. |
19:04 | MikeSeth | tell me the md5 on the image you have |
19:04 | MarcusVinter | Its redownloading, i deleted old one. :/ |
19:07 | jas-hacks | jnettlet: wonder if IRQ's are happening because its not using the CD pin correctly |
19:40 | jnettlet | jas-hacks, yeah I debugged that earlier, although _rmk_ wasn't having any problem with his |
19:41 | jnettlet | right now I am at about 416653 interrupts after about 40 minutes of uptime and it not doing much of anything |
19:43 | jas-hacks | jas-hacks: i think something similar happens on the Utilite because the SD slot has not CD pin and looks like its using s/w to determine if the card is present or not. |
19:49 | jas-hacks | you could try setting the equivalent of this '.cd_type = ESDHC_CD_PERMANENT' in the dts |
19:50 | jnettlet | yeah I have tested that. I want to make sure and fix the problem properly. The SDHC port isn't permanent and should learn to behave |
20:09 | jnettlet | hmmm irqbalance doesn't seem to work either |
20:15 | jnettlet | yeah something is very wrong. doing a simple ls is generating 6000 interrupts on mmc0 |
20:15 | jnettlet | _rmk_, I am thinking you may not be seeing this behavior because you are running your rootfs on nfs |
20:16 | jnettle | 20:16 * jnettlet is done for a while. time to watch tv |
20:17 | hste | jnettlet: so u got interrupted :) |
20:18 | jnettlet | my wife just masked the DO_WORK irq |
20:18 | hste | thats not easy fix on |
20:19 | _rmk_ | oh, that's rather crap |
20:20 | _rmk_ | on android, if you move the cursor near the right/bottom edge of the screen, the cursor image compresses |
20:20 | _rmk_ | similar at the top/left but less noticably |
20:20 | _rmk_ | someone's not dealing with the cursor properly... |
20:21 | _rmk | 20:21 * _rmk_ wonders how you cleanly shut android down... or is it the case that it's intended you never shut it down... |
20:22 | jnettlet | you use the power button of course |
20:22 | _rmk_ | power button? |
20:22 | jnettlet | :-P |
20:22 | jnettlet | just pull the plug |
20:23 | _rmk_ | actually... I do have a power button on my logitek keyboard... Fn-F12 |
20:23 | _rmk_ | ah ha. |
20:23 | _rmk_ | apparantly, my tablet will shutdown |
20:23 | _rmk_ | looks more cube-like to me |
20:24 | jnettlet | cubelet? |
20:24 | _rmk_ | hmm, I guess it's done because the display has frozen |
20:25 | _rmk_ | btw, good call about the ballast weight :) |
20:26 | sam_nazarko | my cubox-i arrived today |
20:26 | sam_nazarko | Thank you rabeeh |
21:10 | _dab_ | rabeeh: what did you use for the extra weight in the cubox? more heat diffusing material? |
22:00 | hste | rabeeh: made an installer for stephans yocto xbmc from 20. december http://stende.no-ip.info/imx6/solidrun-hb/scripts/mk_xbmc_hb.sh |
23:53 | newkind | hi |
23:53 | newkind | one small question before I'll order my CuBox-i4Pro ;) |
23:53 | newkind | will it be able to decode the hi10p format ? :) |
23:53 | newkind | i don't care if it's hardware/software - i just want it smooth in xbmc :) |
23:53 | newkind | hehe |