**** BEGIN LOGGING AT Fri Nov 04 03:00:00 2016 Nov 04 05:51:26 HI All Nov 04 05:51:52 can we use Mesa instead of sgx binaries in TI jacinto 6 using Yocto Nov 04 10:38:42 any hint Nov 04 10:38:55 regarding using Mesa instead of sgx binaries Nov 04 10:39:36 on a board that needs SGX, mesa won't work Nov 04 10:39:39 as it doesn't have drivers Nov 04 10:54:52 who doesn't have driver Nov 04 10:55:19 Mesa is opensource GL implementaion and insetad of SGX(hardware binaries) I want to use software acceleration Nov 04 10:55:35 @rburton: I didn't get you completely Nov 04 10:56:52 software isn't acceleration, GL won't really be usable Nov 04 10:57:43 if you just need mesa because you need GL but don't care how slow it is then the mesa-gl recipe will build a software-only GL library for you Nov 04 10:57:53 just don't expect it to render very fast or well Nov 04 11:07:22 I am not worried about speed Nov 04 11:07:50 There are 2 recipe one is mesa-gl and another is mesa Nov 04 11:10:10 what is the difference ? another question: can we use Mesa opengl in OMAP Nov 04 11:22:55 are you there rburton Nov 04 11:50:23 nrossi, awake? Nov 04 11:50:41 Crofton|work: yep i am :) Nov 04 11:50:45 hey Nov 04 11:51:16 I'm poking at linux-yocto-4.8 and have it booting on an e300, but the sd card is acting stupid Nov 04 11:51:48 Crofton|work: whats it doing exactly? Nov 04 11:51:52 http://pastebin.com/s7kyCQLw Nov 04 11:52:46 sanjeevs: doesn meta-ti bring the support for omap as far as available? Nov 04 11:53:05 need to figure out how the .config is generated in this case Nov 04 11:53:39 Crofton|work: Interesting, might be bug. I haven't done alot of testing on hardware with 4.8, will see if i can re-produce here on a zybo Nov 04 11:54:13 thanks, I may have done something stupid, but it should be this tricky Nov 04 11:54:53 I'm going to build some random kernels outside OE and seee what happens Nov 04 11:55:24 apparently sometome it reads OK, I did get a prompt after an hour once :) Nov 04 11:55:28 thanks Nov 04 11:56:16 * Crofton|work needs more coffee Nov 04 12:01:55 LetoThe2nd: what do you mean Nov 04 12:07:56 sanjeevs: there is meta-ti. have you looked at it to see what drivers and infrastructure it provides for opengl? Nov 04 12:11:24 I couldn't find any referneces for opengl inside it Nov 04 12:15:01 my first question is : is it possible to use opengl in OMAP Nov 04 12:16:08 sanjeevs: i was having lunch. http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-graphics/libgles/ti-sgx-ddk-um_1.14.3699939.bb is the opengl driver in meta-ti. Nov 04 12:16:21 lunch is not permitted Nov 04 12:16:27 GLES/EGL only, as that's all the hardware supports Nov 04 12:18:06 yes i.e correct but I don't want to use this Nov 04 12:19:49 so use mesa Nov 04 12:19:57 Instead of this I wan to use MESA Nov 04 12:20:07 How I can use MESA ? Any idea Nov 04 12:20:45 is MESA tied up with Kernel OMAP DRM Driver Nov 04 12:21:01 mesa has literally no idea about anything to do with omap Nov 04 12:21:07 it will be entirely in software, and slow Nov 04 12:21:32 I am Ok with it Nov 04 12:21:45 look at meta-ti's machine configuration and you'll see where it sets the preferred provider to ti-sgx-ddk-um. change those back to mesa in your configuration. Nov 04 12:22:03 is MESA use any driver ? Nov 04 12:22:44 Instead of ti-sgx-ddk-um, I used mesa Nov 04 12:22:51 PREFERRED_PROVIDER_virtual/egl      = "mesa" Nov 04 12:22:51 PREFERRED_PROVIDER_virtual/libgles2 = "mesa" Nov 04 12:22:51 PREFERRED_PROVIDER_virtual/libgles1 = "mesa" Nov 04 12:22:51 PREFERRED_PROVIDER_virtual/libgl    = "mesa" Nov 04 12:24:13 These change are made in meta-arago-distro/conf/distro/arago.conf Nov 04 12:26:54 are these sufficient Nov 04 12:28:57 give it a go and see :) Nov 04 12:29:39 silly question id Mesa need any driver Nov 04 12:30:55 Crofton|work: Re-produced on a zybo, looks like it might be related to using sdhci as the rootfs Nov 04 12:31:12 well, I suppose this is good news Nov 04 12:31:29 I'm going to build master and try that today Nov 04 12:31:53 Moritz claims he has seen mainline work, so hopefully I can track down a fix Nov 04 12:32:01 thanks for checking Nov 04 12:32:41 Crofton|work: let me know if you have/find a fix :), i will have a bit of a look myself too Nov 04 12:38:15 sanjeevs: as i said it's all software. no drivers. no acceleration. broken rendering. Nov 04 12:39:57 hmm Nov 04 12:40:04 any references /detail Nov 04 12:43:07 may i ask why you're so against using SGX? if you have a TI board and want GL, the SGX is the answer. Nov 04 12:44:05 if you don't want GL you can generally disable it Nov 04 12:45:15 we can't disable Nov 04 12:46:31 we have requirement where we don't want SGX Nov 04 12:48:38 SGX is tightly coupled in all recipe and instead of using sgx I am using Mesa opengl. I can't run any QT app without SGX, on OMAP for GUI SGX is required but as per my requirement I don't want to use SGX Nov 04 13:36:29 Crofton|work: Looks like it works fine in 4.9-rc3 with arm multi_v7 config, trying 4.8.6 mainline now. Nov 04 13:37:38 I've been picking through commit logs Nov 04 13:38:38 there was a bunch of stuff merged in 4.8 Nov 04 13:39:05 Bruce has queued the update to 4.8.6 Nov 04 13:48:57 Crofton|work: 4.8.6 seems to work, it might be a config thing... gonna trying 4.8.3 Nov 04 13:54:03 any idea why the file I'm installing to /etc/profile.d/ shows up in sysroots but not rootfs? Nov 04 13:56:56 it is also in the recipies package file and image dirs Nov 04 13:57:19 and other files installed from the same recipie do show up in rootfs, just not this one Nov 04 13:58:15 Crofton|work: Hmmm so 4.8.3 works too... makes me think its a config thing Nov 04 13:58:51 so default config built with linux-yocto-4.8 breaks, Nov 04 13:59:03 but armvy multi config basically works? Nov 04 13:59:44 Crofton|work: Will check multi_v7 on linux-yocto and have a look into the configs now Nov 04 14:00:36 thanks, I do not expect linux-yocto-4.8 to work completely out of the box on random zynqs, but booting is importnant :) Nov 04 14:05:26 Crofton|work: I consider functional linux-yocto for Zynq to be a must :), specially since Xilinx don't do LTSI with linux-xlnx and that all current Xilinx kernels are susceptible to dirtyCOW :P Nov 04 14:06:42 ouch :) Nov 04 14:06:53 They need to wash their cow's. Nov 04 14:23:51 Crofton|work: I'm playing with some 433MHz remotes Nov 04 14:24:19 I know what the 0s and the 1s should look like, can I get gqrx to actually decode the bitstream? Nov 04 14:24:34 I do no think gqrx has an digital demods Nov 04 14:24:41 fsk? Nov 04 14:26:01 I'd say it is ook Nov 04 14:26:25 what kind of remote exactly? Nov 04 14:27:53 also ask in #gnuradio, more competent people :) Nov 04 14:30:01 I don't know how you call it, byebyestandby, homeeasy or domia lite Nov 04 14:32:40 https://beastiebytes.com/rf_fun_with_gnuradio.html Nov 04 14:42:59 nice, he is missing hte manchester decoding though, there are only 24 bits with a 2bits preamble Nov 04 14:43:13 I meant 12 bits Nov 04 14:43:22 I'll try gnuradio Nov 04 14:43:30 thanks! Nov 04 15:06:53 nrossi, any idea what option it could be? Nov 04 15:07:18 Crofton|work: Not sure, still trying things .... :| Nov 04 15:07:47 and multiv7 gets something that boots? Nov 04 15:09:11 diffing the one generated during the build and the multi_v7 isn't informative Nov 04 15:10:15 Crofton|work: yep, multiv7 works fine. Looking at boot logs to see the difference, atm it looks like mv7 causes a cpu clk change, so testing that now :) Nov 04 15:10:24 ah Nov 04 15:10:35 there is a commit about clock stuff Nov 04 15:11:08 nope, but i know that multiv7 was using CPUFREQ_DT Nov 04 15:11:59 I believe this brings some resolution to the problems reported before. Nov 04 15:11:59 See the commit 6fc09244d74d ("mmc: sdhci-of-arasan: Revert: Always power Nov 04 15:11:59 the PHY off/on when clock changes"). Nov 04 15:16:00 Crofton|work: Well the cpufreq change aint it... yer there is a bunch of commits that refer to phy stuff. But switching the config makes it work on the linux-yocto kernel so it has to be something that is missing Nov 04 15:17:32 git blame need to show dates :) Nov 04 15:22:35 der it does Nov 04 15:48:49 hi there. is there a log file that tells me which recipe installed a file in the sysroot? Nov 04 15:49:10 ndec: oe-pkgdata-tool can Nov 04 15:49:22 ok, will check.. thx Nov 04 16:08:32 rburton: thanks, it works.. we are trying to build qt5 with eglfs/kms and it turns out that when compiling some plugins, we end up including drm/drm.h instead of libdrm/drm.h. the first one come from the libc header package. have you ever seen any issue like this? Nov 04 16:08:52 we basically have 2 'versions' of the header file.. Nov 04 16:10:43 ndec: kodi sucks on dragon, its using sw decode, any hints how to fix it ? Nov 04 16:11:01 khem: yes, implement the missing features ;-) Nov 04 16:11:07 haha :) Nov 04 16:11:27 turbot on the other hand kicks ass even with s/w decode Nov 04 16:11:34 if it's built properly you should be using ffmpeg/sw for decode and gl/gles/gpu (freedreno) for rendering. Nov 04 16:12:04 it ends up with 100% cpu load Nov 04 16:12:11 so it should do probably until 720p. Nov 04 16:12:24 720p let me try Nov 04 16:13:05 it would be interesting to profile where the 100% cpu load goes Nov 04 16:13:06 rpi can do 1080p with bcm display driver Nov 04 16:13:16 and cpu load is < 10% while doing so Nov 04 16:13:20 but they have h/w acceleration.. Nov 04 16:13:50 we can do 1080p with <10% too, with gstreamer and h/w acceleration. Nov 04 16:13:53 yes they do Nov 04 16:14:10 hmm Nov 04 16:14:18 suihkulokki: they would go in ffmpeg, doing s/w decoding.. Nov 04 16:14:57 kodi uses ffmpeg, not gst. ffmpeg doesn't know (yet) how to use the v4l2 kernel api for h/w accelerated decoder. but we are working on that.. Nov 04 16:15:12 720p works with 73% cpu but no chopping Nov 04 16:15:21 right. that's what I would expect. Nov 04 16:15:54 yeah v4l2 is missing from ffmpeg thats right Nov 04 16:16:11 v4l2 m2m to be exact. Nov 04 16:16:22 zoltan is looking into that these days.. Nov 04 16:16:45 ok, for now I will not torture dragon then :) Nov 04 16:17:05 720p isn't that bad ;-0 Nov 04 16:17:23 probably its same form factor as turbot may be Nov 04 16:18:02 my collection has family videos all of them are 1080p Nov 04 16:18:23 so, I will keep it churning but on the side Nov 04 16:19:17 next time I will give you a dragonboard that you can use for your 4K family videos ;-) Nov 04 16:21:20 no worries. Nov 04 16:21:57 Right now, I use dragon for compiling natively :) Nov 04 16:22:27 but the fact is kodi compiled and worked on it Nov 04 16:22:48 will the latest patches I sent to ml Nov 04 16:27:43 ndec: did you get my mail about X issue ? Nov 04 16:28:13 it seems freedreno driver is having undefined symbols Nov 04 16:28:21 which are in libfb.so Nov 04 16:28:27 X plugin Nov 04 16:33:19 khem: yes. but I was busy with other things today, and couldn't look closely into it. Nov 04 16:33:25 but i will **** BEGIN LOGGING AT Fri Nov 04 18:26:20 2016 Nov 04 18:30:23 there's some emacs/xemacs detection goop in the libidn configure script that results in a packaging failure if you have xemacs installed on the build machine Nov 04 18:30:50 what would be a good fix? rip that out to avoid the build host influencing the package? Nov 04 20:10:40 smurray: yes Nov 04 20:11:02 smurray: if its using autoconf macros to find (AC_FIND_* etc) then you can pre-seed values in EXTRA_OECONF Nov 04 20:12:26 rburton: it's using AC_CHECK_PROGS. Seed it so they're presumed not present, I'm guessing? Nov 04 20:14:32 yeah Nov 04 20:15:56 something like ac_cv_prog_TEST_EMACS=no Nov 04 20:16:01 autoconf does the same Nov 04 20:23:27 rburton: okay, I'll work up a patch Nov 04 22:05:34 hi, I'm building for x86_64, u-boot builds but fails to link when it can't find a 32-bit libgcc, what's the best approach to solving this? Nov 04 22:08:38 khem: about your email, don't we already have 10-preload-modules file? you added it already in meta-qcom. what's missing? Nov 04 22:16:44 adding multilib:lib32 and building lib32-u-boot seems to work, but it seems overkill to have a lib32-variant of all u-boot's deps when all it needs is a few symbols from a 32-bit libgcc Nov 04 22:19:36 zyp: presumably you could add a dep in the recipe on lib32-libgcc, but then the recipe wouldn't build at all without the user setting up MULTILIBS. it'd avoid the need for a lib32 u-boot variant, at least Nov 04 22:19:38 * kergoth shrugs Nov 04 22:20:47 yeah, I thought about trying that as well Nov 04 22:40:40 speaking of MULTILIBS, is there a good reason that belongs in local.conf? I put it in my machine specific conf along with DEFAULTTUNE and that seems to work fine Nov 04 22:40:54 I apologize if that's a stupid question, I'm fairly new to openembedded Nov 04 22:41:36 it just seems to make sense to me that in the machine conf where I pick the main tune, it also makes sense to add additional ones Nov 04 22:44:55 zyp, consider the case building for multiple bsps and wanting to set the tune so that you only build one set of packages for many machines Nov 04 22:47:22 i.e. a nonoptimal but compatible tune? Nov 04 22:48:17 it's up to the user, there are a number of possible configurations Nov 04 22:48:25 i.e. mips has 3 abis last i checked Nov 04 22:49:01 hmm, I don't really see how setting DEFAULTTUNE in machine.conf differs from setting DEFAULTTUNE_virtclass-multilib-lib32 in that regard Nov 04 22:49:20 since I presume overriding it would work just the same in either case Nov 04 22:59:40 configuring multilibs isn't just about setting a tune, it's about enabling/disabling multilibs at all, setting library paths for each, etc. it's as much a distro decision as a machine one. Nov 04 23:46:50 ndec:10-preload-modules is only used on musl systems Nov 04 23:47:30 ndec: for glibc systems it does not use it because for musl we have to preload since dlfcn doesnt exist **** ENDING LOGGING AT Sat Nov 05 03:00:00 2016