05:09 | aplund | I'm having some trouble with the BSP and ldconfig. It keeps trying to make libEGL.so and friends point to libEGL-x11.so when I want it to be libEGL-fb.so. And the package manager runs ldconfig each time a package with libraries is installed or updated. Is there any sane way to make ldconfig stop doing this? |
06:03 | jnettlet | aplund, there are symlinks pointing libEGL.so* to libEGL-x11.so you need to change show and the libGAL.so* symlinks to point to the -fb.so variants. |
06:03 | jnettlet | does that make sense? |
06:07 | aplund | jnettlet: sure. but what to do about ldconfig? |
06:07 | aplund | it just rewrites whatever I set |
06:07 | jnettlet | which distro are you using? ldconfig should not be changing symlinks to libraries, just resolving symbols |
06:08 | jnettlet | unless one of the distros added some fancy script to do this. |
06:08 | aplund | arch |
06:09 | aplund | I don't think that's true. It is a stated features of ldconfig that it sets up links from the soname to the library itself |
06:10 | aplund | pacman runs ldconfig every time a package installs or upgrades libraries |
06:12 | jnettlet | aplund, those are links as in linking the code of the libraries to resolve symbols, not symbolic links on the filesystem. |
06:12 | aplund | jnettlet: surely that's ld-linux |
06:14 | jnettlet | that is the execution time linker. To speed up it's job it uses the cache created by ldconfig |
06:15 | aplund | but surely when the manpage for ldconfig says "creates the necessary links and cache" they mean the symbolic links from the soname to the library itself |
06:15 | jnettlet | if you don't have any symlinks for the symbol ldconfig will create the symlink. That is why most distros create those symlinks at packaging time. |
06:15 | aplund | and indeed when I set the links manuually for libEGL and friends and run ldconfig manually it resets the links back to the -x11 versions |
06:16 | aplund | jnettlet: The soname of the libEGL and friends libraries are the same. so at least one always doesn't have a link to it from the soname. |
06:17 | aplund | and hence the one that I make gets overwritten |
06:17 | aplund | I see that other ppl just don't use ldconfig. like Geexbox |
06:18 | jnettlet | aplund, I think you need to take this up on an Arch irc list. I have been using these libraries for 2+ years now on multiple distros and have never seen this problem you are describing. |
06:19 | aplund | jnettlet: have you used arch? |
06:19 | jnettlet | never full time but I have looked at it briefly. Had many debug sessions with people using it. |
06:20 | aplund | but you'd install the BSP libraries into /usr/lib ? (that's what I did) |
06:21 | jnettlet | no I never do that. I install all my proprietary libraries in subdirectories to /usr/lib and then add a conf file in /etc/ld.so.conf.d/ |
06:22 | aplund | so you would run ldconfig |
06:22 | jnettlet | it makes things neater and much easier to distinguish the proper libraries are being linked rather than system mesa libraries and such |
06:22 | jnettlet | yees |
06:22 | jnettlet | which is why I said I have never seen this problem |
06:22 | aplund | and it doesn't create symlinks into that directory |
06:23 | jnettlet | no because I created the symlinks I want before hand, and any packages I create create those symlinks. |
06:24 | aplund | the code in glibc would suggest that it should override them in just the same way... so I'm not sure if moving the libraries would help |
06:25 | aplund | I'll ask on archlinuxarm forums to see if anyone else has this |
06:26 | jnettlet | I think that is the best way to find an answer |
07:05 | aplund | actually... I guess I could copy the file instead of doing a symlink |
07:05 | aplund | bit of a hack.. |
07:16 | jnettlet | aplund, can you show me the output of ls -al /usr/lib/libEGL* |
07:36 | hste | aplund: Here is jas-hacks script for changing to fb http://pastebin.com/geMFeUQm |
07:38 | hste | aplund: Here is jas-hacks script for changing to x11 http://pastebin.com/eY2igDw3 |
07:39 | hste | jnettlet: how does barebox work? do u dd a file to sdcard the same way as uboot? |
07:41 | jnettlet | hste, yeah. That is a function of the SOC. |
07:42 | jnettlet | There are fuses that you burn to tell the SOC what devices to look at to bootstrap from. |
07:44 | hste | jnettlet: so u dd barebox-solidrun-imx6dl-hummingboard.img instead of uboot.img/imx |
07:44 | jnettlet | the dd command is different because the image is built differently. |
07:45 | jnettlet | but the current barebox support won't bootstrap, as it is using old DDR settings. |
07:47 | hste | jnettlet: I found that it has a barebox-gk802.img , so it looks like my gk802 has some sort of support for it also:) |
07:48 | jnettlet | hste, yeah I don't know how much of this is tested, vs just initial placeholder implementations. |
07:49 | jnettlet | things are a little slow right now because most the core developers are at FOSEM |
07:49 | jnettlet | FOSDEM |
07:49 | jnettle | 07:49 * jnettlet wanted to make it but just couldn't fit it into the schedule |
09:09 | aplund | hste: thanks. but that's what I do manually anyway, still gets wiped out by ldconfig |
09:51 | jnettlet | anyone have any idea what the most used disto is right now? |
10:04 | zaher | it would be a good idea for rabeeh to create a poll on the forum, to see how many use what. |
10:11 | MikeSeth | jnettlet: probably debian, it was published first |
10:12 | MikeSeth | hste_: is gk802 a good toy to play with? |
10:12 | jnettlet | and desktop? XFCE, LXDE, GNOME, KDE? |
10:12 | MikeSeth | no guess, I am afraid |
10:17 | hste_ | MikeSeth: it has its faults, but its ok thanks to some of the devs that started on getting the kernel/uboot on to it. But design is poor. It gets hot if u dont modify it with a heatsink |
10:21 | hste_ | jnettlet: http://distrowatch.com/ , but its hard to find a united distro. The *nix community isn't like the apple community :) |
10:21 | jnettlet | hste_, I am more interested in just the Cubox/Cubox-i communities. |
10:21 | hste_ | :) |
10:22 | hste_ | Even there it will be hard to find :) |
10:25 | hste_ | I guess for the regular user that buy this and think it can run windows they would jump to ubuntu because thats what they have heard about |
10:30 | hste_ | jnettlet:Mabye take a look on whats popular on Raspberry Pi like Raspbian |
10:31 | davorin | cuboxian? cububuntu? |
10:32 | davorin | cubuntu (o; |
10:35 | jnettlet | at a glance cubuntu can be mistaken for a less than optimal marketing word, although probably quite accurate |
10:35 | jnettlet | :-) |
10:35 | davorin | well..there's hummingboard left out... |
10:36 | davorin | in-som-nian ;-) |
10:37 | jnettlet | Ultimately once the kernel and barebox are done, my next step is getting SolusOS-2 ported to ARM. It was really the best looking XFCE based desktop until the guy working on it got too busy |
10:40 | jnettlet | but ultimately I think getting a simple os that can run docker containers will make long term support much easier. |
10:44 | jnettlet | creating a docker app for xbmc will mean any distro that has aufs and LXC will be able to easily install an optimized XBMC for the cubox-i without someone porting/compiling/packaging it separately. |
10:44 | jnettlet | it will also make sure that we don't run into XBMC/fsl library incompatibility |
10:52 | MikeSeth | jnettlet: I was thinking |
10:53 | MikeSeth | jnettlet: a tiny bootable installer image that you write to the card; it boots off and stays in initramfs, connects to the internet, queries a remote host for the list of images, you select an image, it downloads it and writes it to the card, and then restarts the box |
10:53 | MikeSeth | suicide installer |
10:55 | jnettlet | MikeSeth, that is kind of what the original cubox installer did. |
10:55 | MikeSeth | there isn't a good reason to -not- do this now, is there? |
10:56 | jnettlet | that could be done simply with an image containing u-boot pieces, kernel and initramfs with your install program. The only real limitation checking you would need would be RAM to store the disk image. |
10:57 | MikeSeth | or you could do something less sane like streaming decompression |
10:58 | MikeSeth | btw any guess what could be causing this: http://imx.solid-run.com/forums/download/file.php?id=17 |
10:59 | jnettlet | yeah, I wouldn't recommend that but you could do something tricky like download and write in 200MB chunks, depending on the image and compression used |
11:00 | jnettlet | MikeSeth, the phy error? |
11:00 | MikeSeth | yeah |
11:00 | jnettlet | it generally means there is no link on the cable. Bad cable could do it. |
11:01 | MikeSeth | hm |
11:01 | jnettlet | I did have an instance on my HB1 where a cheap cable connector had bent one of the pins, and was causing a phy error. Putting on a new connector and bending it backed sorted things back out. |
11:02 | jnettlet | are they using latest u-boot/kernel combos? |
11:02 | jnettlet | some pinmux settings could also effect this. |
11:02 | MikeSeth | I don't know, the guy is a bit new, there's been a number of reports about ethernet issues like this |
11:06 | jnettlet | you could have him inspect the pins inside the ethernet adapter, maybe take a picture if he could. Make sure something hasn't happened there before we start digging into software. |
11:23 | MikeSeth | jnettlet: you mean the ethernet connector pins, from the outside? |
12:06 | jnettlet | MikeSeth, yeah the pins inside the connector of the cubox. Just to double check |
13:15 | hste_ | Linux 3.14 is Not a Piece of Pi :) |
13:17 | _rmk_ | No Pi? |
13:18 | jnettlet | I am surprised that nothing special was down for the 3.14 kernel version. |
13:37 | dv__ | jnettlet: is your kernel available on github? |
13:38 | jnettlet | dv__, not yet. My weekend was very unproductive ;\ |
13:39 | jnettlet | dv__, I am back working on it this afternoon. Just finishing doing administrative work |
13:42 | dv__ | cool |
13:42 | dv__ | btw I have noticed strange freezes when I use the vivante direct textures and the IPU deinterlacer at the same time |
13:43 | dv__ | they didnt happen if I used the IPU sink |
13:43 | dv__ | is there something going on between GPU and IPU? |
13:43 | jnettlet | they should be completely independent. |
13:44 | dv__ | hm I will try to build the kernel with more verbose output |
13:45 | jnettlet | is it a hardware hang, or a freeze and then recovery like a timeout? |
13:46 | dv__ | sometimes it was just ioctl errors |
13:46 | dv__ | but sometimes the entire box freezes |
13:47 | jnettlet | if you are passing buffers direct to the GPU then you want to make sure the offset and pitch are aligned. the Vivante hardware is very particular about that. |
13:47 | dv__ | they should be, since the IPU also expects that |
13:48 | jnettlet | dv__, are you testing on the CBi now or still using your WandBoard or whatever other platform you had been developing on. |
13:49 | dv__ | nah, i havent been using the sabre sd for a long time |
13:49 | dv__ | testing on i4pro and on the HB |
13:49 | jnettlet | okay great |
14:27 | heap | rabeeh: and all the kernel drivers works fine for that esata + sata port multiplier? |
14:27 | heap | btw how many cores has the cubox pro? the old model. |
14:29 | sickness | heap: I think 1 =_) |
16:20 | heap | the worst thing is the all models are out of stock. |
16:23 | davorin | need i1? (o; |
16:42 | dv__ | heap ? |
16:42 | dv_ | heap: where did you read that? or did rabeeh tell you? |
17:05 | heap | what do you mean? |
17:05 | heap | look at their website, they are goin to ship on end of the march |
17:11 | davorin | that's for orders placed now as i understood... |
18:04 | jnettlet | dv_, did you say you had VPU decoding patches for chrome/chromium floating around in some state? |
18:04 | dv_ | yeah |
18:05 | dv_ | need a lot more work, but they are usable |
18:05 | jnettlet | just h264 or also vp8? |
18:05 | dv_ | I tested with vp8 |
18:06 | dv_ | I couldnt get h264 to work, because the chromium build disables mp4 container support |
18:06 | dv_ | (its one of the differences between chromium and chrome) |
18:06 | jnettlet | I am wondering if I can do a demo of chromium os on the cubox |
18:06 | dv_ | thats actually on my todo list |
18:06 | dv_ | well, not chromium OS, but chromium |
18:06 | dv_ | dshankar was also toying with my patches |
18:06 | dv_ | he was running them on the GK802 |
18:07 | jnettlet | is he building chromium with webgl enabled also? |
18:09 | dv_ | I guess so. the patches do that. |
18:09 | dv_ | one important feature is missing though: frame zerocopy |
18:10 | dv_ | this could be done using vivante direct textures, because the patches enable chromium's aura GUI toolkit, which renders everything with opengl ES |
18:10 | dv_ | its far from trivial though |
18:29 | heap | davorin: yes, i still didnt buy one. so if i place order now... it takes almost 3 months. |
18:29 | heap | so im not sure if i have to buy the old model cubox pro or wait for the new one.. |
19:54 | jnettlet | heap depends what you plan on using it for. |
21:18 | heap | jnettlet: NAS with esata and dmcrypt |
21:18 | heap | jnettlet: + xbmc |
21:18 | sickness | dmcrypt? on which distro? |
21:19 | heap | sickness: idk, the one which will work fine with cubox |
21:19 | heap | :) |
21:19 | sickness | eheheh |
21:19 | sickness | ok |
21:20 | heap | have any experience? |
21:23 | jnettlet | heap, I am not sure where we are with the dmcrypt support on the CBi yet. I know the hwrng is working but not sure about the AES acceleration. |
21:24 | jnettlet | the original Cubox does support that. |
21:24 | heap | jnettlet: cuboxpro does support aes with hw? |
21:25 | heap | but the onec cpu core is not the problem? |
21:25 | jnettlet | well both do, but the cuboxpro has been out longer and I am quite certain it has full cryptodev support |
21:27 | heap | is it possible to find more info about it somewhere? |
21:27 | jnettlet | the one cpu core is mostly a limiting factor for multi-tasking. |
21:27 | heap | well so then if cbi does support it... its maybe only take of the short time. |
21:27 | jnettlet | Check out the original cubox forums. There is lots of info there. |
21:28 | heap | thats why i wanted cbi, like not to buying old pro version |
21:28 | jnettlet | heap, also check the Arch mailing list/forums/wiki they actually have some pretty good documentation on the original cubox. |
21:29 | heap | ok thanks a lot |