00:08 | ce3c | eh, I fiddled with /var/lib/dpkg/status to remove the dependency and am now able to install everything. I wonder how long that's gonna take before it bites me in the ass :P |
12:06 | quitte | Hi. I was expecting to get a tracking number, since the FAQ says that ECO post was fully trackable. Do I have to ask for one? |
14:19 | bencoh | hmm ... anyone booting cubox-i with an initrd here ? |
14:20 | bencoh | is it supposed to work (I've found nothing on the wiki), and if it is ... where (in memory) should I load it ? |
14:21 | jnettlet | bencoh, using the latest u-boot it does work. you just need to tell it the name of your initramfs image |
14:21 | bencoh | hmm, how so ? |
14:22 | bencoh | (no fatload+bootm secundary param ?) |
14:22 | bencoh | -u+o |
14:25 | Devrr | my boot.scr when loading an initrd loads in this order: |
14:25 | Devrr | load mmc 0:1 ${loadaddr} zImage |
14:25 | Devrr | load mmc 0:1 ${fdt_addr} imx6q-cubox-i.dtb |
14:25 | Devrr | load mmc 0:1 0x14700000 linux-btrfs.img.uboot |
14:25 | Devrr | bootz ${loadaddr} 0x14700000 ${fdt_addr} |
14:26 | bencoh | is dtb mandatory ? |
14:27 | bencoh | (dtb/fdt) |
14:27 | Devrr | I believe so, but the specifis of it are above my knowledge |
14:28 | bencoh | thx :) |
14:28 | Devrr | And FYI, the info I gave is from an ArchLinux build. Not sure if things are different in other distros |
15:58 | bencoh | Devrr: do you have any specific kernel params ? |
15:59 | Devrr | bencoh, nothing that I believe to be initrd specific. Mostly eSATA & btrfs related |
16:02 | bencoh | hmm okay, thx |
16:02 | Artox | [14:19] hmm ... anyone booting cubox-i with an initrd here ? |
16:02 | Artox | I am using initrds too |
16:02 | Artox | and did nothing special for it |
16:02 | bencoh | either the u-boot I'm using has no complete support for it, or I'm missing something :) |
16:02 | Artox | are you mkimaging your initrd? |
16:02 | bencoh | I am, u-boot loads it |
16:03 | bencoh | but it looks like linux ignores it (or doesnt hear about it) |
16:03 | Artox | http://pastebin.com/YA9jNAuP |
16:04 | Artox | this is ny boot.script |
16:04 | bencoh | thx |
16:04 | Artox | mind the magic numbers :) |
16:04 | Artox | though they dont really matter |
16:05 | Artox | and, this assumes a device.tree kernel |
16:05 | Artox | aka 3.10 or 3.14 |
16:09 | bencoh | which I dont have |
16:10 | Artox | well then |
16:10 | Artox | slight modification, and it'll be non-dt |
16:10 | bencoh | yeah, that's what I tend to think |
16:10 | bencoh | so ... I guess I'm missing an up-to-date uboot ... maybe |
16:10 | Artox | http://pastebin.com/MSzEH5JD |
16:10 | Artox | there, non-dt |
16:11 | bencoh | wait a min |
16:11 | bencoh | root=/dev/mmcblk0p1 |
16:11 | bencoh | this doesnt use initramfs as a first root, does it ? |
16:12 | bencoh | hm, nevermind that |
16:12 | Artox | I think initrds make themselves root autoamtically |
16:12 | Artox | but I cant be sure there |
16:13 | Artox | I dont know anything about initrds except how to laod them in uboot :) |
16:13 | bencoh | :-) |
17:49 | iCEBrkr | 16hrs later. ChromeOS compiled.. But I can't seem to figure out how to get it's uboot to work on this cubox. I assume it's going to be a bit complicated. |
18:01 | jnettlet | iCEBrkr, you need to use our u-boot and kernel. |
18:05 | iCEBrkr | If I get some time tonight maybe I'll revisit this. |
18:05 | iCEBrkr | I was hacking on this awhile ago and don't exactly remember where I left it. |
18:05 | iCEBrkr | But that's a nice 'good to know', thanks |
18:06 | jnettlet | iCEBrkr, well don't know how far you are but you should grab dv_'s chromium repo for your chromiumos build. It has webGL enabled and html5 video playback is done with the VPU |
18:06 | jnettlet | basically it will give you an "optimized" desktop |
18:09 | iCEBrkr | Ahh ok. I couldn't find anyone elses work. All I found was the prototype videos of, forget who did it for CES or whatever expo |
18:09 | dv_ | note that I never tested them with chromium OS |
18:09 | jnettlet | that stuff is nothing. The work dv_ has done is excellent |
18:09 | dv_ | here you go: https://github.com/Freescale/chromium-imx |
18:10 | jnettlet | dv_, chromium OS is just gentoo with chromium :-) |
18:10 | dv_ | welll.... there are a lot of #ifdefs regarding chromium OS in the chromium codebase |
18:11 | jnettlet | fair enough. but I have never seen anything outrageous with a chromium os build. |
18:11 | dv_ | I do assume we are talking about that? |
18:11 | dv_ | yeah |
18:12 | jnettlet | I think building for Ubuntu may be more challenging :-) |
18:12 | dv_ | oh my |
18:13 | iCEBrkr | If I didn't have a 2yr old on my hands all day. I really want to build a 'Command Central' type system on this little guy. |
18:13 | dv_ | looking at the gpu_video_decode_accelerator.cc code again, I see that the chromiumos build normally picks DXVA accel in windows, |
18:13 | dv_ | and openmax in linux |
18:13 | iCEBrkr | I live in FL. So weather maps/notifications are important and loook cool too. :) |
18:13 | dv_ | but, I put my imx #ifdef before the chromeos one, so it should use the VPU patches even then |
18:14 | jnettlet | brilliant |
18:14 | iCEBrkr | Right now I have one of your later Android builds running with a couple of widgets. |
18:14 | jnettle | 18:14 * jnettlet actually hopes to start doing weekly chromiumos builds now that dv_'s repo is out |
18:14 | dv_ | something that always bothered me - but this affects all hw accelerated decoding, not just VPU based - is that web designers tend to play fast and loose with video elements |
18:15 | dv_ | create one, ditch it, create another one |
18:15 | iCEBrkr | Welcome to open source . |
18:15 | dv_ | if these arent deallocated quickly enough by chromium, they might accumulate, and who knows what happens then. but thats a general problem. |
18:15 | jnettlet | I blame that on flash. Everyone wanted to use video for ads and this is where we are. |
18:16 | dv_ | I suppose those who develop mobile versions of web pages do understand that. i hope it at least :) |
18:16 | iCEBrkr | jnettlet: I'd like to try Chromium on this thing. Then I could just build a webpage for all the infor I want to pack on the screen :) |
18:16 | iCEBrkr | jnettlet: hate that crap |
18:16 | dv_ | jnettlet: and, it is very tempting to use these resources on the PC, because everything is fast and easy there |
18:17 | jnettlet | I actually was doing some metric calculations and trying to figure out how much bandwidth and cpu it would take to pre-render pages and when you went to click a link it would warn you based on the content |
18:17 | iCEBrkr | dv_: I hate sites that don't take smaller/lesser machines into consideration along with lack of bandwidth. |
18:17 | dv_ | iCEBrkr: agreed |
18:17 | jnettlet | I was going to call it pre-meditate |
18:17 | iCEBrkr | nice |
18:17 | dv_ | iCEBrkr: several sites which use parallax backgrounds are like that |
18:17 | dv_ | animated parallax background, even |
18:18 | iCEBrkr | It's like "Um, hello, I'm on a mobile device. I'm lucky to have a connection and you want to throw pop-ups, ads and whatever else at me?!!?" |
18:18 | iCEBrkr | Get that from new readers that require you to be redirected to the source. |
18:19 | dv_ | jnettlet: what would also really help is to try out chromium/chromiumos in wayland |
18:19 | dv_ | actually ... hste__ , you were talking about that build machine |
18:20 | hste__ | dv_: yes its up now if u want to build |
18:20 | jnettlet | dv_, That is on my todo for the V5 drivers. I will see how far Vivante has brought their Wayland support and then gauge if it is worth more of my time |
18:21 | dv_ | hste__: chromium builds are demanding |
18:21 | dv_ | hste__: sounds like a case for your box |
18:21 | dv_ | one x11 build and one wayland build |
18:22 | iCEBrkr | dv_: demanding? That's putting it lightly. |
18:22 | iCEBrkr | I really thought it'd take 8-9 hours.. |
18:22 | iCEBrkr | x2 that |
18:22 | dv_ | it takes me about 1-2 hours |
18:22 | dv_ | one important trick is to enable component build |
18:23 | dv_ | oh, and to have at least 16 GB RAM |
18:23 | iCEBrkr | Yeah well, I only had a Core-Duo available. |
18:23 | dv_ | oooh boy |
18:23 | iCEBrkr | lol |
18:23 | dv_ | quadcore is an absolute minimum |
18:23 | iCEBrkr | It's my fileserver. It's really not meant for that stuff |
18:23 | dv_ | well it could be more extreme |
18:23 | iCEBrkr | Fileserver/Plex Media |
18:24 | dv_ | I learned that archlinuxarm devs build on target. yes, they build chromium on the embedded devices. |
18:24 | dv_ | takes them a day or so |
18:25 | iCEBrkr | ahh yes, Intel(R) Core(TM)2 Duo CPU E6750 @ 2.66GHz with 8G Ram. :( |
18:25 | iCEBrkr | RAM |
18:25 | iCEBrkr | But whatever.. |
18:25 | deniska | Crosscompilation makes your keyboard hairy |
18:26 | dv_ | cross compilation is one the few cases where the CPU really makes a difference |
18:26 | dv_ | in most other situations, you are more than well off with an i5 or some quadcore athlon for instance |
18:27 | iCEBrkr | I'm just a web guy. This low level stuff... You'd think building the OS for something that doesn't have much horsepower wouldn't take much to do.. lol |
18:27 | dv_ | ha, the age old misconception |
18:28 | iCEBrkr | Sort of discovered this when I first build Android. I'm like. uh. All this to fit a 300meg image on my phone?? |
18:28 | dv_ | tbh, the complexity of c++ is largely responsible for chromium's demands |
18:28 | dv_ | during the majority of the build it actually doesnt need that much ram |
18:29 | dv_ | but then it starts with the webkit/blink stuff that uses template metaprogramming. thats when it gets really wild |
18:33 | jnettlet | yeah linking in C++ is retarded |
18:33 | deniska | <...> C++ is retarded |
18:33 | dv_ | nah, I kinda like C++11 |
18:33 | dv_ | but parts of it are just plain stupid |
18:34 | dv_ | for instance, I understand why C still uses #include , but not C++. also, its syntax is ugly at times, particularly when doing metaprogramming |
18:34 | jnettlet | and all the boilerplate |
18:34 | jnettlet | blech |
18:35 | jnettlet | I actually really like Vala, but unfortunately GNOME and by association gtk are really failing in a major way |
18:38 | dv_ | vala is a nightmare for cross compilation |
18:38 | dv_ | thanks to the broken GObject introspection |
18:38 | dv_ | read this for an explanation why: https://github.com/Guacamayo/meta-gir/blob/master/README.md |
18:39 | dv_ | you actually have to generate the C code on the PC and cross compile this instead |
18:39 | bencoh | welcome to hell |
18:41 | dv_ | ey, since you guys love complicated c++ , here is a nice example: https://pbs.twimg.com/media/Blh4qsFIgAEqYrw.png:large |
18:42 | jnettlet | dv_, yes. while GIR is a cool technology it has completely stalled. It is basically only useful on x86 (it is horribly slow on ARM) and only supports languages tightly bound to GTK3 |
18:43 | bencoh | dv_: I think some people are sick. |
18:43 | bencoh | like, really sick. |
18:43 | dv_ | bencoh: rule of thumb regarding generic programming in c++: if you are writing a library, which shall be adaptable to custom datatypes, and you dont use generic programming, you should rethink this. |
18:44 | dv_ | if you write an *application*, and you use generic programming, you should rethink this. |
18:44 | bencoh | :-) |
18:44 | deniska | if you're writing in C++, you should rething this |
18:45 | bencoh | anyway ... why would openembedded not build this fsckin uImage and stop at zImage ... |
18:46 | iz | if you're writing in C++, you should rethink *this |
18:46 | bencoh | haha |
18:49 | dv_ | but if you use c++ , i strongly encourage you to use c++11 |
18:49 | dv_ | its like a million times better than the typical c++98 code |
22:30 | iCEBrk | 22:30 * iCEBrkr chuckles at C++ scrollback. |
22:33 | zhando | hello all. I've recently got my cubox to bring up bluetooth and I can see and pair devices... |
22:33 | zhando | Now the challenge is to enable audio over bt in both directions.. Any suggestions? |
22:34 | R0nd | zhando: which distro? I've been struggling with BT on debian |
22:34 | zhando | Well it's a hybrid of Arch kernel/modules with Ubuntu.. |
22:36 | zhando | scratch that.. it's actually cbxbiker's 3.10.53 with the archlinuxarm packaged bt firmware.. |
22:36 | R0nd | did you use brcm_patchram_plus? |
22:37 | zhando | R0nd: yes indeed.. |
22:37 | R0nd | it gives me an error when I try to upload the firmware, "can't set hci protocol" |
22:38 | zhando | hmmm.. is your hardware 4330? |
22:38 | R0nd | yes |
22:38 | zhando | edit out --enable_lpm from the patch command.. |
22:40 | R0nd | sudo broadcom-bluetooth-53e35d81e01a/brcm_patchram_plus --patchram /lib/firmware/brcm/bcm4330.hcd --no2bytes --scopcm=0,2,0,0,0,0,0,0,0,0 --baudrate 3000000 --use_baudrate_for_download --tosleep=50000 /dev/ttymxc3 -d --enable_hci |
22:40 | R0nd | does that look about right? |
22:40 | zhando | actually no hold on a sec.. |
22:41 | FoXMaN | hi |
22:41 | R0nd | FoXMaN: hello |
22:42 | FoXMaN | i'm struggling with cubox-i ir functionality and i think i need some help |
22:43 | zhando | this is in the script: /usr/bin/brcm_patchram_plus --patchram $HCD --baudrate 3000000 --use_baudrate_for_download $TTY $OPTIONS |
22:43 | zhando | $HCD is the firmware |
22:44 | zhando | $TTY is what you have there. |
22:45 | zhando | OPTIONS="$OPTIONS --bd_addr $MAC_ADDR" |
22:46 | zhando | I'll point you to the script in the package just a sec.. |
22:48 | zhando | https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/firmware-brcm43xx/brcm43xx-firmware-update |
22:51 | zhando | ok this is the command that's ultimately used on my cubox: |
22:51 | zhando | /usr/bin/brcm_patchram_plus --patchram /lib/firmware/brcm/bcm4330.hcd --baudrate 3000000 --use_baudrate_for_download /dev/ttymxc3 --no2bytes --tosleep=50000 --bd_addr 43:29:B1:54:21:80 |
22:52 | R0nd | hmm, okay, it didn't throw any errors (probably because it doesn't use --enable_hci) |
22:53 | zhando | FoXMaN: I tried to go down that route getting a remote to work with XBMC and gave up. CEC worked out great for me. I use my tv remote to navigate xbmc. It rocks. |
22:53 | R0nd | am I supposed to be able to start bluetoothd now? |
22:54 | zhando | R0nd: trying to remember. No you need to run something in the background. use nohup or tmux.. |
22:54 | zhando | hold on... |
22:56 | zhando | R0nd: did you run the script? |
22:56 | R0nd | zhando: just the command you posted |
22:57 | zhando | ok first you do: ln -sr "$TTY" /dev/brcm43xx |
22:57 | zhando | then this has to run in the background: /usr/sbin/hciattach -n /dev/brcm43xx any 3000000 |
22:58 | zhando | it might /usr/bin for you.. |
22:59 | zhando | then "hcitool" dev should show the hci0 device.. |
22:59 | R0nd | Can't set device: Protocol not supported |
22:59 | R0nd | Can't initialize device: Invalid argument |
22:59 | R0nd | when running hciattach |
23:00 | zhando | hmmm.. perhaps the brcm modules aren't loaded? |
23:00 | zhando | brcmfmac |
23:01 | zhando | brcmutil |
23:01 | zhando | that $TTY should be /dev/ttymxc3.. |
23:02 | R0nd | yeah, I got the tty right |
23:02 | R0nd | not sure about the modules tbh |
23:02 | zhando | lsmod | grep brcm |
23:02 | R0nd | nothing |
23:03 | zhando | then they should be there is all I can think of.. |
23:03 | zhando | insmod brcmfmac |
23:03 | zhando | insmod brcmutil |
23:12 | zhando | gtg for a bit.. |
23:20 | FoXMaN | eh, looks like one of the usb ports in my hummingboard is dead |
23:22 | R0nd | hmm, I think I need to upgrade my kernel |
23:22 | zhando | I'm back.. Anyone know anything about running audio through a bt device in either or both directions.. |
23:22 | zhando | R0nd: are you running headless? been there done that.. It was mildly interesting.. |
23:23 | zhando | I've been able to get bt to work on both the 3.10.30 arch kernel and cbxbiker's 3.10.53.. |
23:24 | R0nd | I'm on debian 3.0.35 |
23:25 | R0nd | running through ssh right now, once I've sorted everything out I'm going to hook the cubox to my tv |
23:25 | zhando | OMG.. That's one I haven't played with.. The forum does say good things about Debian's support for arm though.. |
23:30 | zhando | I'm curious if Debian stable or unstable or whatever is tracking the ongoing development of kernels with cubox support.. |
23:34 | R0nd | debian testing (jessie) |
23:36 | zhando | R0nd: ok that's the one I see everyone talking about.. It doesn't sound like they are keeping up like arch and cbxbiker but I could be wrong. Look for kernel images with "cubox" in the name.. If they exist, then you should go with them. |
23:37 | zhando | gtg again.. If anyone has got audio to work through bt please chime in.. |