| 00:34 | xraxor | anyone know geexbox? |
| 00:35 | xraxor | i would like to know if i can install couchpotato and transmission |
| 06:43 | TimSmith2015 | hi |
| 10:32 | jnettlet | okay 3.10.17-beta is now booting but needs more fixes to get everything running. |
| 10:42 | rabeeh | jnettlet: i wonder if edid is working also on that kernel? |
| 10:42 | rabeeh | today in the 3.0.35 kernel edid is detect but X isn't configured to match the preferred resolution |
| 11:59 | jnettlet | let me check the logs |
| 12:00 | jnettle | 12:00 * jnettlet is finally done running errands for new years. |
| 12:02 | jnettlet | rabeeh, any idea what would turn on the "okay" led on the C1 board? |
| 12:14 | jnettlet | Anyway this is the magic that was hanging boot. Still not sure exactly why. http://git.freescale.com/git/cgit.cgi/imx/linux-2.6-imx.git/commit/?h=imx_3.10.17_1.0.0_beta&id=ce224e3c4fc3c1b00a94641c28724be2adcd78be |
| 12:17 | jnettlet | rabeeh, yes edid config under hdmi does appear to work okay. http://fpaste.org/65103/13884886/ |
| 12:18 | jnettlet | although under the last driver 24bpp caused drawing corruption. We would either need to patch the driver to use 32bpp if 24bpp is selected, or hopefully this latest build fixes the 24bpp problem |
| 12:19 | rabeeh | jnettlet: the okay led is negated USB OTG EN :) |
| 12:19 | rabeeh | a bug :) |
| 12:19 | rabeeh | so you can either enable the LED or enabled the USB OTG power current limiter. |
| 12:19 | jnettlet | rabeeh, well it was that hdmi unmask overflow interrupter patch that was causing it to come on. That is one serious bug. |
| 12:19 | rabeeh | jnettlet: any idea how to tell the kernel to configure the screen resolution to best match the preferred mode in EDID |
| 12:20 | rabeeh | what are those interrupts? |
| 12:20 | jnettlet | rabeeh, with the latest driver just don't pass it a video mode |
| 12:20 | jnettlet | rabeeh, no idea yet. Haven't delved into it. Just did a git bisect to figure out what was breaking |
| 12:21 | jnettlet | It was completely hanging the hardware though. |
| 12:21 | jnettlet | perhaps something in device-tree that needs to be tweaked. |
| 12:26 | jnettlet | rabeeh, actually the mode is being setup by the device-tree default right now. Same with default_bpp. I can easily add the code from my pxa168 hdmi driver that says if no default then setup the edid default, if not do 1080p if not do 720p |
| 12:27 | jnettlet | if none of those fall back to the best resolutions that can be supported. |
| 12:30 | _rmk_ | or just use drm which tends to get it right anyway |
| 12:32 | jnettlet | _rmk_, except you can't use drm for android support |
| 12:33 | _rmk_ | drm exports a fbdev so you should be able to, though its only basic |
| 12:34 | jnettlet | yep, and the drm guys have already said they are getting rid of it. |
| 12:35 | _rmk_ | shrug. I just find - like the drm guys - that I just can't care about fbdev crap anymore. drm is the future and android better get with it. |
| 12:36 | jnettlet | that would be fine if the drm group wasn't slow as hell to accept changes and new submissions |
| 12:36 | bencoh | then they'll probably be slow getting rid of fbdev too :> |
| 12:36 | _rmk_ | strange, I've been pushing bug fixes for armada without any problem since it went in |
| 12:37 | _rmk_ | as for imx-drm, that's really all down to pengutronix |
| 12:38 | jnettlet | at some point they will need to realize that the biggest userbase of Linux is Android. If they push too hard then Google, Samsung, etc will fork permanently and do it their way, and there goes half a billion users. |
| 12:38 | jnettlet | and the community has lost any sort of control it once held. |
| 12:39 | _rmk_ | so what - the kernel has to carry a crappy interface for all eternity because of android? |
| 12:39 | _rmk_ | and the kernel can't move forward ever because of that? |
| 12:39 | _rmk_ | I don't buy that argument |
| 12:39 | jnettlet | why not? it doesn't hurt anything. |
| 12:39 | jnettlet | they can deprecate it just don't remove it, and don't be jerks about patches submitted for it. |
| 12:42 | jnettlet | deprecating the fbdev interface for drm is basically a power play trying to force these companies to do things differently faster. The drm guys will lose that and just cause more pain in the long run due to schisms in contributions. |
| 12:43 | _rmk_ | yes, of course it is, and it's got nothing to do with every drm driver needing extra code to support fbdev |
| 12:43 | jnettlet | _rmk_, and no offense but your patches carry a bit more weight than *random developer* from Samsung does. |
| 12:44 | jnettlet | I have seen how long some of the Marvell patches have sat in limbo until somebody else stepped up to try and get something moving on them. That is a big problem right now. |
| 12:45 | _rmk_ | yea... what about armada-drm support for mmp :) |
| 12:45 | jnettlet | and the world is a better place because of it |
| 12:46 | _rmk_ | I've seen *nothing* since doing the work to make that easier |
| 12:46 | jnettlet | I know I am sitting on a backlog of work a mile long. |
| 12:47 | _rmk_ | ... that's the real problem - every kernel developer has that problem |
| 12:47 | jnettlet | a bunch of it sitting in email queues waiting for lawyers to okay bits of irrelevant code. |
| 12:48 | jnettlet | and that is a major problem. |
| 12:49 | MarcusVinter | Good morning everyone. |
| 12:52 | MikeSeth | waaaaant to haaaaaaack |
| 13:22 | jnettlet | otavio, how long does freescale usually take to spit out binaries for new kernel releases? |
| 13:44 | jnettlet | hmmm, with the new kernel and the GPU code removed to work with the old binaries I have lost 25 fps on es2gears |
| 13:45 | hste | jnettlet: Is that with your added patches? |
| 13:47 | jnettlet | hste, yep. down to about 250fps |
| 13:47 | jnettlet | xbmc at 720p just doing the ticker is at about 70-90fps |
| 13:47 | hste | still ok for c1 I think |
| 13:48 | jnettlet | oh and xbmc is using way more cpu. something is up. |
| 13:49 | hste | maybe better to stay on the old one till they go from beta to rc |
| 13:50 | jnettlet | the cpu utilization is because it is staying at the lowest cpufreq more. |
| 13:50 | jnettlet | they may have tweaked something in the mx6 cpufreq driver. |
| 13:51 | jnettlet | looks like their MMC patches have fixed some of the lag I was seeing accessing the sdhc card. |
| 13:52 | jnettlet | xbmc seems to have less lag waiting for IO |
| 13:55 | jnettlet | hste, actually with the debug overlay off I am seeing betweeeing 98 and 178fps depending on the cpufreq of the soc. I think that is better. |
| 13:55 | jnettlet | soc temp is hanging out at about 60C |
| 13:56 | hste | jnettlet: have u tried turn off cpufreq? |
| 13:57 | jnettlet | hste, I could but no reason to. Seems to be managing things quite nicely. Really I would like to lock xbmc down to 60fps no reason to play higher than that. |
| 13:57 | jnettlet | still need to test on 1080p |
| 13:59 | hste | jnettlet: how does your dogs behave when the rockets bangs around? |
| 13:59 | jnettlet | hste, one doesn't care the other used to freak out pretty badly but seems to be chill right now. |
| 14:00 | jnettlet | he has been getting better with loud noises recently. Perhaps he is losing his hearing :-) |
| 14:00 | hste | mine didn't care last year, so hope he stay that way today too |
| 14:01 | jnettlet | oh interesting switching to 1080p has thoroughly upset things. looks like mmc commands are timing out. |
| 14:01 | jnettlet | perhaps ipu is hogging the AXI bus |
| 14:02 | jnettlet | reboot fixed it. don't like that so much |
| 14:08 | jnettlet | hste 1080p is rocking between 50-70fps depending on the cpu frequency. |
| 14:08 | jnettle | 14:08 * jnettlet can live with that. |
| 14:09 | hste | jnettlet: Do u have a uImage to share? |
| 14:10 | jnettlet | zImage and .dtb |
| 14:10 | jnettlet | although vpu and audio still aren't working yet. |
| 14:11 | hste | still the version problem? |
| 14:11 | jnettlet | I fixed that, something else is broke. It may be how I fixed the version. haven't had much time to poke at it more. |
| 14:15 | jnettlet | running glmark2-es2 is really not pushing the soc at all now. galcore daemon is literally only doing about .5-1% cpu. That is about all I could ask for. |
| 14:16 | dv__ | jnettlet: be aware that fps is a nonlinear metric, so you cannot compute deltas with it |
| 14:16 | dv__ | thats why I generally prefer milliseconds |
| 14:17 | hste | jnettlet: what about temp when running glmark? |
| 14:17 | dv__ | I'm referring to sentences like "200 fps less" . these dont mean anything. |
| 14:17 | hste | dv__: How is it going with gstreamer? |
| 14:17 | jnettlet | just got the black screen effect, either temp or axi bus starvation |
| 14:18 | jnettlet | imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_10 = 0x00080000 |
| 14:18 | jnettlet | imx-ipuv3 2400000.ipu: IPU Warning - IPU_INT_STAT_5 = 0x00800000 |
| 14:18 | jnettlet | mmc0: Card removed during transfer! |
| 14:18 | jnettlet | mmc0: Resetting controller. |
| 14:18 | jnettlet | axi bus starvation is the winner!!! ding ding ding |
| 14:18 | dv__ | hste: its slow, because I am in holidays, so I only do development occasionally. I recently pushed a rewritten eglvivsink which should work better. |
| 14:18 | dv__ | with it, you can do fullscreen with gst-launch for example |
| 14:19 | dv__ | its also designed in a way that adding support for wayland and FB rendering backends is simple |
| 14:20 | dv__ | jnettlet: what is that IPU_INT_STAT_10 thing? I have seen it sometimes |
| 14:21 | jnettlet | dv__, axi bus is not pushing data through fast enough. rabeeh gave me a devmem tweak that bumps the ipu up to a higher qos priority on the bus. |
| 14:21 | dv__ | and STAT_5 ? |
| 14:21 | jnettlet | however that starvation causing the mmc to reset is new and annoying |
| 14:21 | jnettlet | dv__, symptom of same problem. Just caught at two different stages I believe. |
| 14:22 | dv__ | well, it makes sense then that I saw STAT_10 in my tests. I was pushing 1080p content at 30 fps from VPU through IPU to GPU |
| 14:22 | jnettlet | dv__, on a C1? |
| 14:23 | dv__ | jnettlet: yes |
| 14:23 | dv__ | rabeeh told me the C1 ram has a 32 bit bandwidth, which explains the bottleneck |
| 14:24 | dv__ | the data isn't copied in between the stages at all, it just DMA-transferred from the VPU to the DMA buffers, then into the IPU, then out etc. in short, zerocopy |
| 14:24 | jnettlet | yep |
| 14:25 | jnettlet | dv__, devmem 0x020e0018 32 0xffffffff is the command you want. |
| 14:25 | dv__ | so it gets the maximum out of the system, and ram happens to be the bottleneck then. I have seen this also with transcoding. on the c1, I am at ~99-101% CPU usage for transcoding to h264 baseline. |
| 14:25 | dv__ | err not CPU usage. 99-101% of realtime |
| 14:26 | dv__ | so it can transcode in realtime, but is at its limit |
| 14:26 | dv__ | source data format did not influence much. I got more or less the same figures with mpeg2, h264 baseline, h264 high profile source data. which is why I dont think the VPU is the limiting factor. |
| 14:27 | dv__ | yes, I'll try that line in a few days. I am also curious about how the i4pro performs. |
| 14:27 | jnettlet | dv__, yes me also. Need to test that gpu out to see where we are with performance. |
| 14:28 | dv__ | gpu out? |
| 14:28 | dv__ | you mean, video output with the gpu? |
| 14:28 | jnettlet | that gpu out, |
| 14:28 | jnettlet | test out that gpu is better I guess :-) |
| 14:28 | dv_ | heh, yes. there is a piglit fork for gles |
| 14:29 | dv_ | but overall, there is a strange lack of benchmark tools for gles, compared to desktop systems. |
| 14:30 | jnettlet | okay, with the devmem command I lost the display again but it didn't reset my mmc card |
| 14:30 | jnettle | 14:30 * jnettlet wonders if it is thermal now |
| 14:32 | jnettlet | hmmm, switching vt's fixed things. gpu didn't hiccup. |
| 14:35 | jnettlet | glmark2-es2 of 76 at 1080p that has dropped. Wonder if a clock has changed somewhere. |
| 14:35 | hste | jnettlet: do you run with stock ram settings? |
| 14:35 | jnettlet | hste, for now yes. |
| 14:52 | jnettlet | hste, nevermind it was the cpu scaling that dropped the glmark2-es2 score down. I will have to see what has changed in regards to scaling. Just ran through glmark2-es2 again with the performance governor and pulled a score of 92 which is closer to where I was at with the old kernel. |
| 15:24 | MMlosh | Lame question : what is the simples way of getting X11 with ABI version 14 to work? When trying plain recompile, it complains about missing "mibstore.h". Those includes can be removed and it'll compile.... but then fail during loading/using the resulting .so - symbol not found or something (even worse, it results in turned-off screen) |
| 15:25 | MMlosh | or I'd be better to migrate to 3.13 + the shiny armada driver? |
| 15:25 | dv_ | mibstore.h is ancient. typically, distros keep around an empty mibstore.h file around to make the old codebases compile |
| 15:26 | dv_ | for example, I know of several OE recipes that contain such empty mibstore.h files and copy them into the codebase prior to compiling |
| 15:26 | dv_ | as for the new driver, I dont know. might want to ask jnettlet or _rmk_ about it |
| 15:28 | MMlosh | interesting... this time there was no error in xorg logfile.. but the last message is "dovefb(0): Render extension subpixel order is RGB".. |
| 15:28 | MMlosh | shouldn't it be "server closing down" in case of success? |
| 15:37 | jnettle | 15:37 * jnettlet is making is new years resolution to get all his 3.10 lts kernel work out by the end of Jan. |
| 16:05 | MMlosh | finally.. welcome back, #cubox |
| 16:05 | MarcusVinter | That's strange MMlosh. |
| 16:06 | MarcusVinter | Its probably spewing errors somewhere. |
| 16:07 | MarcusVinte | 16:07 * MarcusVinter is making a new years resolution to get the bloody thing booting. |
| 16:07 | MarcusVinter | haha |
| 16:09 | MMlosh | MarcusVinter, it could be a simple render / buffer pointer setup error |
| 16:10 | MMlosh | (i.e. that switching VTs sets the "place where the HDMI could read pixels from" pointer correctly, which X11 itself borks it) |
| 16:10 | MarcusVinter | Nah its much simpler. I'm just doing something wrong and I'm going to keep trying different methods with jnettlet's help hopefully until I stop being a plonker. |
| 16:11 | MMlosh | I mean - my issue |
| 16:11 | MMlosh | no idea about yours |
| 16:11 | MMlosh | so.. not even the u-boot is booting? |
| 16:13 | MarcusVinter | u-boot is booting, but its not booting linux for some fudging reason. It will be my own error, just need to find out where since the whole this is seemingly a simple process. |
| 16:17 | MMlosh | ooh.. I remember spending quite a lot of time making u-boot boot linux as well |
| 16:17 | MMlosh | where does it fail? |
| 16:17 | MarcusVinter | loading the kernel :( |
| 16:18 | MMlosh | like.. the last message is u-boot's "starting kernel" ? |
| 16:18 | MMlosh | or whatever it prints before it executes it? |
| 16:19 | MarcusVinter | http://s23.postimg.org/zc9tz1knv/IMG_0386_1.jpg |
| 16:20 | MMlosh | oh.. it did not find the kernel at all |
| 16:20 | MMlosh | can you do "printenv" in uboot and post that? |
| 16:22 | MarcusVinter | I can try, I'm just formatting as ext2 at the moment to try that. |
| 16:24 | MMlosh | it just prints u-boot configuration (environment variables) |
| 16:27 | MarcusVinter | I cant type the command in anyway, it doesnt seem to recognise any of my usb keyboards. |
| 16:27 | MMlosh | d'oh |
| 16:27 | MarcusVinter | And it doesnt detect the hardware when i try a serial connection. |
| 16:27 | MMlosh | you need to type to the serial console |
| 16:27 | MMlosh | what? |
| 16:27 | MMlosh | I thought you are using a serial console to read those u-boot messages |
| 16:27 | MMlosh | but you got them on your screen.. oh.. I got it |
| 16:28 | MMlosh | you need to establish a serial connection if you want to "talk" to u-boot I think |
| 16:28 | MMlosh | does your cubox also come with built-in serial-to-usb converter? |
| 16:30 | MarcusVinter | It appears to come with one of a different version to the V1. I have the drivers but if I plug the USB cable in my laptop wont detect it as hardware. |
| 16:30 | MMlosh | strage |
| 16:30 | MMlosh | what does lsusb say? |
| 16:30 | MMlosh | or dmesg? |
| 16:30 | MarcusVinter | Yeah its really quite frustrating. |
| 16:32 | MarcusVinter | I'm using windows to debug. |
| 16:32 | MMlosh | oh.. I am not used to that |
| 16:33 | MMlosh | I remember there was some driver that could be downloaded for windows.. |
| 16:33 | MMlosh | but if it's not recognizing any device at all.. |
| 16:33 | MMlosh | are you sure you cable is allright? |
| 16:33 | MarcusVinter | Its not in device manager at all. |
| 16:34 | MMlosh | can you try another cable, shorter if possible? |
| 16:34 | MarcusVinter | Not posistive, I'm looking around my office now for another but we have piles of everything so it'll take a while lol |
| 16:35 | MMlosh | btw: looks like they moved the debug microusb below the eSata? |
| 16:40 | MarcusVinter | Yeah thats right. |
| 16:40 | MarcusVinter | its under the esata |
| 16:41 | MarcusVinter | my voltmeter wont fit in this cable so I cant test it that way lol. now looking around office for other devices that use microusb |
| 16:41 | MarcusVinter | lol |
| 16:42 | MarcusVinter | The power in the cable is working, I booted an rpi with it |
| 16:43 | MMlosh | unfortunately that's not really the part of the cable you need |
| 16:43 | MMlos | 16:43 * MMlosh is a bit surprised that you don't have a microusb-equipped phone lying around |
| 16:46 | MarcusVinter | i know :/ |
| 16:47 | MarcusVinter | Found another cable and it worked. I think the case might protrude too much for the other cable. |
| 16:48 | MMlosh | in v1 there is a big square hold cut into the cover just to allow a cable to connect |
| 16:49 | MMlosh | *hole |
| 16:49 | MMlosh | btw: what is the software one uses as serial terminal on windows? |
| 16:51 | MarcusVinter | I'm using putty |
| 16:51 | MarcusVinter | i have a serial connection now. |
| 16:51 | MMlosh | congrats |
| 16:51 | MMlosh | it shall let you press Esc during startup and let you issue u-boot commands |
| 16:53 | MarcusVinter | Yup. at least this is a bonus lol. |
| 16:54 | MMlosh | which will let you make it printenv to see what it's actually trying to do |
| 16:54 | MarcusVinter | ** File not found boot.scr ** |
| 16:54 | MarcusVinter | ** Unrecognized filesystem type ** |
| 16:54 | MarcusVinter | ** File not found uEnv.txt ** |
| 16:54 | MarcusVinter | ** Unrecognized filesystem type ** |
| 16:54 | MarcusVinter | ** File not found uImage ** |
| 16:54 | MarcusVinter | ** Unrecognized filesystem type ** |
| 16:55 | MMlosh | I'd call that normal |
| 16:55 | MMlosh | you imo always get a bunch of errors for not-present media |
| 16:55 | MarcusVinter | Thisis my printenv |
| 16:55 | MarcusVinter | http://pastebin.com/LR20kFTB |
| 16:59 | MMlosh | bootcmd hold the command that would be executed at boot (if you didn't abort using escape) |
| 16:59 | MMlosh | or perhaps it did and since it failed you ended up in console anyway |
| 16:59 | MMlosh | one can run such commands like "run bootcmd" |
| 16:59 | MMlosh | (it just takes a variable as a string and executes it as if it was typed) |
| 17:01 | MMlosh | tracing it's progress will allow you to figure out where did each error come from |
| 17:01 | MMlosh | and most importantly - which commands actually succeeded |
| 17:07 | MarcusVinter | Thanks, I'll give that a shot now. |
| 17:08 | MMlosh | It took me quite a while to beautify the boocmd command |
| 17:09 | MMlosh | http://pastebin.com/3sc2c6qf , so it doesn't come to waste |
| 17:10 | MMlosh | bootscript is a variable that will be set by boot.scr or uEnv.txt on your card |
| 17:13 | MMlosh | it seems to be looking at mmc device 0 partition 1 ext2/fat /boot.scr OR /uEnv.txt |
| 17:13 | MarcusVinter | I have /boot/boot.scr |
| 17:14 | MMlosh | first tries ext2+boot.scr, then fat+boot.scr, then ext2+uEnv.txt, then fat+uEnv.txt |
| 17:14 | MMlosh | hmm |
| 17:14 | MMlosh | try moving it to root |
| 17:15 | MMlosh | or just setenv script=/boot/boot.scr |
| 17:15 | MMlosh | and then run bootscript |
| 17:15 | MMlosh | (script is the variable that holds the filename of the boot.scr, it can include a path too.. ) |
| 17:16 | MMlosh | correction: run bootcmd (that re-tries booting... if no device's state was broken that is.. sometimes that works, sometimes it does not) |
| 17:16 | MMlosh | on my system I wasn't able to "run bootcmd" twice in a row |
| 17:16 | MMlosh | (i.e. , my changes, run bootcmd didn't work |
| 17:17 | MMlosh | while , my changes, run bootcmd did ) |
| 17:17 | MarcusVinter | ## Error: illegal character '='in variable name "script=/boot/boot.scr" |
| 17:19 | MMlosh | oops, no "=", just a space |
| 17:19 | MMlosh | (setenv script /boot/boot.scr) |
| 17:21 | MarcusVinter | CuBox-i U-Boot > run bootscript |
| 17:21 | MarcusVinter | Running bootscript from mmc ... |
| 17:21 | MarcusVinter | ## Executing script at 10800000 |
| 17:21 | MarcusVinter | Wrong image format for "source" command |
| 17:22 | MMlosh | hmm.. no idea |
| 17:22 | MMlosh | did you stop u-boot by esc or let it run? |
| 17:23 | MMlosh | (unfortunately I am due to leave for a new year's traditions things soon) |
| 17:23 | MMlosh | hmm.. I guess it didn't like your boot.scr |
| 17:23 | MMlosh | what's in / how did you make it? |
| 17:23 | MarcusVinter | damn :/ |
| 17:24 | MarcusVinter | i just coped /boot/ from a ubuntu image made for the Carrier-one |
| 17:24 | MarcusVinter | copied |
| 17:24 | MMlosh | aww.. windows... which means you can't "file boot.scr" |
| 17:25 | MMlosh | it should be a text file with some binary garbage at the beginning |
| 17:26 | _rmk_ | MarcusVinter: iminfo 0x10800000 might show you what type it is after that error message |
| 17:27 | MarcusVinter | yeah it said "Wrong image format for "source" command". I have no idea what that means, lol. |
| 17:27 | MMlosh | MarcusVinter, run what rmk told you to |
| 17:27 | _rmk_ | it means it thinks it isn't a script |
| 17:27 | MMlosh | it shall provide aditional info |
| 17:27 | MMlosh | yup.. "it doesn't like his boot.scr" |
| 17:30 | _rmk_ | which will finish first... the kernel build for the hummingboard running on the laptop, or the apt-get upgrade running on the hummingboard |
| 17:30 | MarcusVinter | Anyone else got boot.scr and uimage and stuff that works for I2U? |
| 17:33 | _rmk_ | apt-get won |
| 17:33 | MarcusVinter | Haha |
| 17:34 | MarcusVinter | Is there any PR on the hummingboard, im curious what it is. |
| 18:18 | _unreal_ | ? |
| 18:20 | MarcusVinter | Any press release or anything. |
| 18:20 | MarcusVinter | I cant seem to find a single bit of info about it. |
| 18:37 | MarcusVinter | Happy New Year to you all from everyone at i-Virtuals! Have a good one! |
| 22:54 | xraxor | hi guys |
| 22:54 | xraxor | i have a cubox-i4pro if you guys need any tests done |
| 22:54 | xraxor | but im a linux novice |