| 00:19 | dv_ | _rmk_: you mentioned this line: devmem 0x020e0018 32 0xffffffff |
| 00:19 | dv_ | I have devmem2 here |
| 00:20 | _rmk_ | devmem2 0x020e0018 w 0xffffffff |
| 00:20 | _rmk_ | would be its equivaent |
| 00:26 | dv_ | hmm strange |
| 00:27 | dv_ | the i4pro shows bogomips 790.52 |
| 00:29 | dv_ | and the transcoding pipeline is actually slower. not CPU-wise, it still uses only a few % CPU. but transcoding 30 seconds of h264 high profile 10Mbps data takes ~31 seconds on the hummingboard, but 1 minute on the i4pro |
| 00:32 | _rmk_ | interesting difference |
| 00:33 | dv_ | I'll test this further tomorrow |
| 00:33 | dv_ | gotta go now. ttyl |
| 03:01 | MikeSeth | dv_: I have similar strangeness with bogomips on i1 |
| 06:25 | jnettlet | Marvell likes the cubox design. http://www.miipc.com/ |
| 06:27 | jnettlet | Oh that is actually a startup, using the Marvell Armada 1500 |
| 06:35 | MikeSeth | ooh morning jnettlet |
| 06:42 | jnettlet | MikeSeth, morning |
| 07:47 | MikeSeth | I threw together a vagrant box to compile arm stuff, I wonder if it could be useful to other people |
| 08:41 | DHowett | MikeSeth: does it somehow help with the miserable (yes, in 2014) state of cross-compilation for arbitrary software? |
| 08:46 | DHowett | My solution to that was using qemu-user-arm and binfmt-misc to have an arm *userland* |
| 08:47 | DHowett | with an arm cross compiler as the main compiler |
| 08:47 | DHowett | ... it was, without question, the worst idea |
| 08:47 | DHowett | MikeSeth: (I didn't mean to insinuate that your vagrant box was useless if it didn't do that! sorry if it sounded like that!) |
| 08:48 | dshankar | how come no one's made a nice arm cluster dedicated for compiles? I'd probably pay for something like that |
| 08:52 | jnettlet | dshankar, a lot of the distros have compile clusters. |
| 08:52 | dshankar | jnettlet: I meant for the public. Aren't those reserved for distro packages? |
| 08:53 | dshankar | although iirc didn't launchpad.net offer that? |
| 08:53 | jnettlet | I don't think there are enough ARM developers to need such a thing. Most development is done cross-compiling and only final packages are bulit native |
| 08:53 | jnettlet | s/bulit/built/ |
| 08:54 | dshankar | maybe that'll change since ARM is picking up a lot of steam |
| 08:58 | jnettlet | dshankar, but depending on the boards that come out, there are already a couple of octa-core boards making the rounds. just investing in one of those would be enough to handle large compilation jobs as long as they have fast enough IO and enough RAM |
| 09:00 | jnettlet | generally RAM is still the big limiting factor for large compiles. OLPC had a couple of next-gen "dev" servers that had 4GB's. beyond that we need to wait for armv8, or more armv7's with lpae |
| 09:00 | dshankar | true but that's not very accessible for people who bought their first arm dev board (for example, myself one year ago). first-timers aren't likely to have an octo-core machine with sufficient RAM laying around ;-) |
| 09:01 | dshankar | yeah I just started a cross compile on my desktop, 8gb ram is a painful limitation :/ |
| 09:01 | jnettlet | regardless building something like chromium for ARM is just too much to do natively and cross-compiling on a modern x86-64 desktop with 8+ GB's of RAM is the only option |
| 09:02 | dshankar | true |
| 09:02 | dshankar | I foolishly built chromium natively on the gk802 imx6q with a meager 1gb ram :) |
| 09:03 | jnettlet | and lots and lots of swap I bet |
| 09:03 | dshankar | 3-4gb swap & used uhs-1 disk to try and improve read times |
| 09:04 | jnettlet | does the gk802 support uhs-1 properly? |
| 09:05 | jnettlet | I thought it lacked the 1.8v switchover. |
| 09:06 | dshankar | worked fine in the external slot + class 4 in the internal |
| 09:07 | jnettlet | yeah it will work but will be limited to 50Mhz, so about 20MB/s transfers |
| 09:08 | dshankar | ah i see. still better than the class 4 at least. |
| 09:08 | jnettlet | oh absolutely |
| 09:24 | davorin | huomenta ;-) |
| 09:26 | jnettlet | morning |
| 09:26 | davorin | did i miss something? (o; |
| 09:28 | jnettlet | don't know where you left off. I don't think so |
| 09:41 | davorin | you're not working for solidrun, right? (o; |
| 09:43 | Coolgeek | here, only rabeeh is workink for solid-run |
| 09:45 | davorin | i wouldn't expect that atai or kossay would be here (o; |
| 09:55 | jnettle | 09:55 * jnettlet does not work for solid run, my work is a labor of love |
| 10:21 | davorin | hmm..little higher price those miipc boxes... |
| 10:22 | davorin | seems they only support android... |
| 10:42 | jnettlet | davorin, well they should be able to run linux it depends on how locked down the bootloader is. The armada xp 1500 is just a slightly newer version of the pxa2128/mmp3 in the OLPC XO-4 |
| 10:42 | jnettlet | I think is has a GC1000 vivante GPU rather than the GC2000 |
| 10:43 | davorin | and how open is the gpu/vpu? better then on a10/a20? |
| 10:43 | jnettlet | and only 2 instead of 3 cores. It doesn't have the LITTLE core. |
| 10:43 | jnettlet | vpu is closed binary that runs in userspace but well supported by this community. |
| 10:43 | jnettlet | gpu is the same, although we are working on etnaviv which is an opensource implementation |
| 10:44 | chipi | hi |
| 10:44 | jnettlet | that should be pushing forward in the next couple of months. |
| 10:45 | jnettlet | but again I have no idea about the bootloader |
| 10:45 | chipi | anybody knows if cubox-i4pro can display on tv with ratio 16:10 |
| 10:45 | jnettlet | davorin, the XP 1500 is the same SOC that is used in the new GoogleTV's and Chromecast |
| 10:45 | jnettlet | chipi, what resolution? |
| 10:46 | chipi | 1680x... |
| 10:48 | chipi | 1680x1050 more or less |
| 10:48 | jnettlet | chipi, yeah that would be a vesa resolution in dvi mode. The fb driver won't currently support that let me check the KMS support. |
| 10:48 | jnettlet | of course it would only support video out at that resolution |
| 10:49 | chipi | previous cubox (first) only support 16:9 and other but not 16:10 |
| 10:49 | chipi | thank you so much |
| 10:49 | chipi | =) |
| 10:53 | jnettlet | chipi, the docs claim that it can support that refresh rate. I have not tested it so I can't verify right now. |
| 10:59 | jnettle | 10:59 * jnettlet going to walk the dogs now. |
| 11:00 | dshankar | hm. i just finished building chromium for imx6 with yocto on my PC, but i'm getting an error |
| 11:00 | dshankar | "chromium-32.0.1664.3-r2.cortexa9hf_vfp_neon.rpm is for architecture cortexa9hf_vfp_neon ; the package cannot be built on this system" |
| 11:00 | dshankar | what noob mistake have I made lol? |
| 11:03 | jnettlet | dshankar, dv_ or otavio would be the ones that may be able to help |
| 11:03 | jnettlet | but you would probably be better off asking in the yocto irc channel |
| 11:04 | dshankar | ah ok |
| 11:04 | dshankar | I hope I didn't waste the day building for the wrong arch or something lol |
| 11:09 | davorin | jnettlet: anything done with drm? |
| 12:11 | jnettlet | davorin, there are some drm patches going mainline for 3.14 I believe. I have those backported into my 3.10 kernel for people that want to start testing. |
| 12:11 | jnettlet | I don't believe that XBMC has grown KMS native support yet. |
| 12:11 | jnettlet | maybe through wayland |
| 12:13 | dv_ | dshankar: how did you try to install this? and on what machine? |
| 12:13 | dshankar | dv_: installing on gk802 running debian jessie (from here: jas-hacks.blogspot.com/2013/12/imx6-debian-jessie-gpuvpu-3109-100.html?showComment=1389002947152#c5327544617441869067) |
| 12:13 | dv_ | hmm. gk802 contains an imx6 right? |
| 12:14 | dshankar | yup. |
| 12:14 | dv_ | oh wait. you are trying to install the rpm on a debian system? |
| 12:14 | dshankar | yeah |
| 12:14 | dshankar | it's supposed to be ok...? |
| 12:14 | dv_ | I never did that, and suspect it can open a can of worms |
| 12:15 | dv_ | just try to build the rootfs with yocto |
| 12:15 | dv_ | not on the board please ;) |
| 12:15 | dshankar | lol |
| 12:15 | dshankar | I did |
| 12:15 | dv_ | so, why are you using debian then? |
| 12:16 | dshankar | I used yocto to build on my PC, loosely based on https://github.com/OSSystems/meta-browser and https://github.com/ajayramaswamy/meta-ar802/blob/master/conf/layer.conf |
| 12:16 | dshankar | well I assumed yocto would spit out just a chromium binary/pkg that I could copy over to my existing OS already running on my gk802 |
| 12:17 | dshankar | should I rebuild my SD card with the new uImage that yocto produced? |
| 12:17 | dv_ | its not that simple. the distros have subtle differences. |
| 12:17 | dv_ | you should put the entire rootfs that yocto produced on the sd card |
| 12:17 | dv_ | I do not know what that layer produces, or how it is supposed to be set up for the gk802 |
| 12:17 | dshankar | I see |
| 12:18 | dv_ | for freescale sabre boards and for cubox-i machines you need to copy u-boot (and in case of sabre, also the uImage) directly with dd to the sdcard's first sectors |
| 12:18 | dv_ | that is, outside the partition table |
| 12:18 | davorin | jnettlet: ah nice.... |
| 12:19 | davorin | received access to freescale's i.mx6 widevine drm library... |
| 12:19 | davorin | apparently just for android, but since android runs on top of linux, should be possible to use it without android as well.. |
| 12:19 | dv_ | dshankar: the rootfs is typically produced as a tarball. look up how the sdcard is supposed to be set up for the gk802, and then copy the rootfs to the appropiate section |
| 12:20 | dv_ | you may also have to copy the uImage and the u-boot image somewhere else |
| 12:20 | dv_ | davorin: how is this related to robclark's work then? |
| 12:21 | davorin | who? (o; |
| 12:21 | dv_ | he was working on drm for vivante GPUs as well |
| 12:21 | jnettlet | davorin, it probably won't work on linux, as Android binaries are compiled against bionic not glibc |
| 12:21 | davorin | widevine drm lib is for decrypting iptv, mostly used by upc |
| 12:22 | jnettlet | dv_, yeah I misunderstood as well. DRM digital rights management, not DRM Direct Rendering Manager |
| 12:22 | dv_ | oh. |
| 12:22 | jnettlet | annoying I know |
| 12:22 | dv_ | wait, the upc set top boxes use freescale hardware? |
| 12:22 | davorin | dunno... |
| 12:22 | dshankar | dv_ ok. I previously followed hste 's scripts to dd uboot/uimage/kernel over to my sd card. will try with the new ones here. |
| 12:23 | davorin | widevine provides libs for several chips |
| 12:23 | davorin | also browser plugin |
| 12:23 | davorin | why is abbreviation such a long word? |
| 12:23 | jnettlet | but widevine on android means that theoretically I can use HBO Nordic on the CBi :-) |
| 12:23 | dv_ | dshankar: alright, good luck. the sd card layout unfortunately differs for every platform. |
| 12:23 | dshankar | I think jas & hste had to modify things to get the uboot & such to work on gk802, so I'm not sure if these yocto builds will work |
| 12:23 | davorin | is there a way to just have one app running an android? |
| 12:23 | dv_ | yeah, you may have to do some extra manual steps |
| 12:23 | dshankar | I'm not worried about the dd part, since I've already done that successfully on gk802. just hoping the rootfs & uImage are compatible |
| 12:24 | davori | 12:24 * davorin quickly off... |
| 12:24 | dshankar | maybe jas or hste will make a guide with his yocto setup / bsp & recipes for the gk802 :) |
| 12:38 | dv_ | uh wait. dshankar, so before yocto, you built chromium on the gk802 ? |
| 12:38 | dshankar | dv_: yup |
| 12:38 | dv_ | how did that thing survive? :) I think rabeeh mentioned thermal design problems in the gk802 |
| 12:38 | dv_ | and how long did a full build take to finish? |
| 12:39 | dshankar | it finished overnight |
| 12:39 | dshankar | here's (mostly) what I did https://gist.github.com/drmonty/8104267 |
| 12:40 | dshankar | iirc removed a few bits (debug symbols I think?) that I read would speed up the process |
| 12:41 | dv_ | I'm still amazed it finished at all, considering the huge RAM usage I saw on my PC when building that monster |
| 12:42 | dshankar | lol |
| 12:42 | dv_ | ehm, you didnt build with -j4, unlike that script. right? |
| 12:42 | dshankar | pretty sure I did use -j4, why? |
| 12:42 | dv_ | because.. when I built with -j4, it consumed up to 9 GB RAM on my box |
| 12:43 | dshankar | lol |
| 12:43 | dv_ | component build was lower, but still about 4-5 GB |
| 12:43 | dshankar | I had a 3gb swap fwiw |
| 12:43 | dv_ | and a ton of I/O activity |
| 12:43 | dshankar | and used a uhs-1 disk in the external slot for the actual source + build |
| 12:44 | dshankar | all I know is that it magically worked in the end, even with your VPU patch |
| 12:44 | dv_ | well, alright |
| 12:45 | dshankar | minus the weird issue where the whole display crashes after a minute of VPU decode :( |
| 12:45 | dv_ | perhaps this is overheating? |
| 12:46 | dshankar | likely |
| 12:46 | jnettlet | that should be reported in the logs |
| 12:46 | dv_ | I never saw this problem, and we ran duration tests on the sabre SD and on the customer's own imx6-based hardware |
| 12:47 | dshankar | since that was using CPU for copy, it's probably overheating, but it may be memory related |
| 12:47 | dshankar | stopping the video would bring back the screen almost instantly |
| 12:47 | dv_ | right, zerocopy isnt present yet |
| 12:47 | dv_ | getting that one to work is a lot more involved |
| 12:48 | dshankar | yeah, I'm now 1 month behind schedule so... :-) |
| 12:48 | dshankar | since all I need is webrtc vp8 videos + vpu vp8dec, I might try to skip chromium and work with gstreamer |
| 12:49 | dv_ | the chromium codebase is weird and full of duplicate code paths, making integration difficult. the idea is to add the vivante direct textures for the opengles-based rendering and somehow pass on the DMA buffers directly to it |
| 12:49 | dv_ | but chromium sort of serializes all opengl commands, and does lots of other sandboxing related things |
| 12:49 | dv_ | hmmmm. yes, maybe. |
| 12:50 | dv_ | if you dont need html etc. then it would probably be easier |
| 12:55 | dshankar | dv_: since I've already built chromium on the gk802, your previous vpu patch only took a few minutes to rebuild. can I apply your latest patches in the same way? |
| 12:57 | dv_ | yeah, bitbake should recognize the changes |
| 12:57 | dv_ | but note that you may not be able to use the patches directly. especially the recipe changes might need a bit of adjustment. |
| 12:57 | dv_ | not much though, assuming the version number is the same |
| 13:05 | dshankar | dv_: hm. will give that a shot tomorrow then. 4am, ought to sleep a bit |
| 13:05 | dshankar | thanks for the help! |
| 13:06 | dv_ | np |
| 13:36 | _rmk | 13:36 * _rmk_ wonders if rabeeh has been here since yesterday |
| 13:38 | davorin | he is making documentation for me ;-) |
| 13:40 | _rmk_ | well, I hope he's seen my comments about the hardware bug... |
| 13:40 | davorin | phy stuff? |
| 13:40 | _rmk_ | yep |
| 13:41 | davorin | applies to all models? |
| 13:41 | _rmk_ | we don't know |
| 13:42 | davorin | gonna have to bug solidrun again today when som and hb can be shipped (o; |
| 13:43 | _rmk_ | they posted an update on google+ about backlogs |
| 13:43 | davorin | ah i know...and i don't care about this (o; |
| 13:44 | davorin | is the wandboard quad clocked higher than i4p? |
| 13:44 | davorin | you could fry an egg on the heatsink ;-) |
| 13:44 | _rmk_ | have you tried looking up the specs? |
| 13:45 | davorin | says @1ghz |
| 13:45 | davorin | the i4p runs at 800mhz i think |
| 13:47 | _rmk_ | from that, it seems it does, but rather than "i think" it's easy enough to look it up - imx.solid-run.com and click on the i4pro. |
| 13:48 | davorin | says the same.... |
| 13:48 | _rmk_ | if that's what you want to believe, then fine... |
| 13:52 | dv_ | _rmk_: do you have an i4pro? |
| 13:52 | _rmk_ | yep |
| 13:53 | dv_ | and what distro do you use? |
| 13:53 | _rmk_ | I just copied what I had on the dove cubox, so its still ubuntu 12.04 - at some point I'll see about pulling down something more recent |
| 13:54 | dv_ | could you tell me the bogomips you see in /proc/cpuinfo ? |
| 13:54 | _rmk_ | well... we removed that from /proc/cpuinfo as it really had become bogus with the timer-based delays |
| 13:55 | _rmk_ | Calibrating delay loop... 1572.86 BogoMIPS (lpj=3145728) |
| 13:55 | dv_ | ok so thats what may be going on here |
| 13:55 | _rmk_ | do you have something that reads /proc/cpuinfo? |
| 13:55 | _rmk_ | ... for that? |
| 13:55 | dv_ | no, I just looked it up on my own, and saw 790 bogomips there |
| 13:56 | dv_ | but since this number is bogus, as you said, its not an issue I guess |
| 13:56 | _rmk_ | the kernel I have running on it at the moment is based on Linus' tip |
| 13:57 | _rmk_ | in this case, I don't believe we're using a timer for delays though - I think we're using a software loop |
| 13:57 | _rmk_ | that's something which we need to fix when we start scaling CPU frequencies though |
| 13:58 | dv_ | I am using rabeeh's imx6 kernel 3.0.35 |
| 13:58 | _rmk_ | check what the "Calibrating..." line says |
| 13:58 | _rmk_ | I think it changes when we're using a timer |
| 13:59 | dv_ | Calibrating delay loop... 1581.05 BogoMIPS (lpj=7905280) |
| 13:59 | dv_ | and in cpuinfo: BogoMIPS : 790.52 |
| 13:59 | jnettlet | dv_, that will change depending on workload. The frequency scales from 399 -> 998 |
| 13:59 | _rmk_ | that sounds like it's dropped the cpu clock back |
| 14:00 | jnettlet | maybe the low frequency is wrong, but it is somewhere around there |
| 14:00 | jnettlet | and you will see the bogomips be either 798, 1581, or 1998 |
| 14:00 | dv_ | okay |
| 14:01 | dv_ | indeed. BogoMIPS : 1988.28 when I put full load on a core |
| 14:01 | jnettlet | I think it defaults to the interactive governor, but I usually switch it to ondemand. Although in the 3.10 that introduces a bug I still need to stort out |
| 14:02 | dv_ | hmm is this tied to the VPU performance? |
| 14:02 | jnettlet | yes |
| 14:02 | jnettlet | I found that I had to limit my scaling ranging and remove the lowest frequency or things would get too choppy. |
| 14:04 | jnettlet | really for a media-center we need either a userspace governor and support put in xbmc, or another governor that isn't so aggressive about dropping to the lowest frequency |
| 14:04 | jnettlet | I guess we can also put code in the vpu driver that requires a certain minimum cpu frequency |
| 14:10 | dshankar | dv_: seems to work well at ~480p. 40% CPU |
| 14:11 | dshankar | still hit the weird 'display crashes/blinks' bug but this time it's only occasionally. will trace down that bug tomorrow. need to figure out whether its CPU overheating or VPU memory, etc. |
| 14:37 | jnettlet | it looks like some pm_qos work is definitely going to need to be added to minimize these hiccups in userspace |
| 15:10 | davorin_awa | 15:10 * davorin_away delivering 200 5v/3a power supplies (o; |
| 17:29 | davorin | looks like i4p is mentioned on reprap forum as i get now many hits coming from there (o; |
| 19:12 | davorin | hmm... |
| 19:13 | davorin | missed something in uenv...wants to mount /boot from mmc when i boot into esata drive |
| 19:40 | davorin | ah stupid me... |
| 19:40 | davorin | mmc is always hardcoded in fstab |
| 19:43 | davorin | much better for development (o; |
| 19:43 | davorin | [root@alarm ~]# df -k |
| 19:43 | davorin | Filesystem 1K-blocks Used Available Use% Mounted on |
| 19:43 | davorin | /dev/root 2113721260 684532 2005665876 1% / |
| 19:43 | davorin | devtmpfs 902192 0 902192 0% /dev |
| 19:53 | jnettlet | oh man, utilite just announced a new Android image with enhanced graphics drivers and I got all excited. Android 4.04 :-( |
| 19:54 | davori | 19:54 * davorin is not a big fan of droids... |
| 19:54 | davorin | is the vpu/gpu stuff installed with archlinux? |
| 19:55 | davorin | or do i need to grab the x stuff? |
| 19:56 | davorin | wtf... |
| 19:56 | davorin | [root@alarm proc]# which gcc |
| 19:56 | davorin | which: no gcc in (/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/core_perl) |
| 19:57 | davorin | okay..it's a really bare min. system then |
| 19:57 | davori | 19:57 * davorin gets some food... |
| 21:03 | hste | dv_: I see you are active producing patches to the meta-fsl-arm-extra today :) |
| 21:04 | dv_ | yep |
| 21:04 | dv_ | lets hope they work out |
| 21:04 | hste | :) |
| 21:04 | dv_ | especially the u-boot topic is being debated |
| 21:06 | hste | yes but at least that fork works, and fater to get out |
| 21:06 | hste | +s |
| 21:06 | dv_ | agreed |
| 22:23 | mhoney_work | holy cow the i4 pro gets hot |
| 22:46 | davorin_mbp | that's odd..mine is luke warm... |
| 22:47 | davorin_mbp | wandboard quad gets hot... |
| 22:51 | Bluerise | hm, wow |
| 22:51 | Bluerise | pure sabre lite: hw.sensors.imxtemp0.temp0=57.34 degC (core) |
| 22:51 | Bluerise | utilite: hw.sensors.imxtemp0.temp0=49.20 degC (core) |
| 23:27 | dab_ | jnettlet: Where can I grab a copy of your kernel? |