**** BEGIN LOGGING AT Wed Jan 08 02:59:59 2014 Jan 08 09:22:53 rburton: ping Jan 08 09:31:06 good morning Jan 08 13:12:48 RP: You broke "bitbake-diffsigs --task " with b6b6d923a6f81c96590d091cd9eebd1bd2031045. Jan 08 13:19:58 Saur: what error are you seeing? Jan 08 13:21:51 RP: Well, the problem is that before it found the two last sigdata files and compared them. However, with your change, bb.siggen.find_siginfo() returns both a sigdata and siginfo file for the same state. Then the files are ordered in chronological order, and thus the sifgdata and siginfo for the same state is compared, which obviously results in nothing being displayed. Jan 08 13:22:29 Saur: ah, right :/ Jan 08 13:24:27 RP: If I change the lambda function in bitbake-diffsigs to use [-3:] instead of [-2:] then it works. But I think that is more of a coincident than a proper solution... Jan 08 13:25:09 RP: Bah, that's not in the lambda function, but on the same line. Whatever... Jan 08 13:55:40 how to tell recipe file to understand variavble ${KERNEL_VERSION} Jan 08 14:05:32 U-boot question: Can I use 2 parallel NOR-flashes with 1 bus? Jan 08 14:05:40 (same CS) Jan 08 14:07:40 tijs_: 2x16 bit on 32bit bus is a classic setup of the early 2000 Jan 08 14:08:07 see ipaq h3600/hx4700 and zaurus collie Jan 08 14:08:21 I'm debugging some kernel issues about that setup :/ Jan 08 14:08:50 Nice! but I could not find a good example with the u-boot standard cfi-driver. Do you know one? Jan 08 14:08:52 searching th eweb, I've found references to u_boot so, yes, u_boot supports that Jan 08 14:09:50 thanks Jan 08 14:09:51 see http://lxr.free-electrons.com/source/drivers/mtd/chips/cfi_cmdset_0002.c#L450 Jan 08 14:10:06 TN-13-07: Patching the Linux Kernel and U-Boot for M29 Flas Jan 08 14:10:34 fwiw I'm on cfi_cmdset_0001 Jan 08 14:11:28 tijs_: ping me if by chance you get word-write working but buffer-write borking the fs...I'm there ;) Jan 08 14:12:10 s/by chance/unluckily/ Jan 08 14:12:16 ;) Jan 08 14:12:20 wtf.. I still have 2 days to get this working, so that would be really bad luck ;) Jan 08 14:25:20 ant_work: Okay I am really trying, but I failed to find the u-boot source tree for both boards ;( Jan 08 14:25:39 what a faillure... Jan 08 15:21:45 RP: You broke bitbake with 854daab404a23e4ebb6107d737d9cfd5a0e5548b. There is an url argument too many in the definition of GitANNEX:supports()... Jan 08 15:23:23 Saur: otavio's patch was probably against an old bitbake :/ Jan 08 15:23:34 RP: Probably... Jan 08 15:27:44 Saur: fix pushed Jan 08 17:03:18 JaMa: so when are you open-sourcing meta-webos-tv? Jan 08 17:15:53 rburton: JaMa is it confirmed that the webos TV stuff is built with OE? Jan 08 17:17:42 well it's using meta-webos as one of layers :) Jan 08 17:17:50 hasn't webos pretty much always been using OE in some form? Jan 08 17:18:10 JaMa: beers on me if you accidently put the UI layer on github Jan 08 17:18:24 "in some form" :) Jan 08 17:18:39 but I suspect that JaMa helped sort out that Jan 08 17:18:42 rburton: yes, very old version of it Jan 08 17:18:58 and highly customized Jan 08 17:19:24 jackmitchell, is that still the case? Jan 08 17:21:06 JaMa: cheeky, plain face deceived me at ELCE when I asked you if the webos stuff was going a TV :P Jan 08 17:21:20 haha Jan 08 17:21:40 jackmitchell: didn't LG basically say that was why they bought it? Jan 08 17:21:40 "No, I don't know what you're talking about" ;) Jan 08 17:21:52 rburton: yeah, that's why I asked Jan 08 17:22:56 stop trolling JaMa, I'm sure we could all have loads of akward conversations :) Jan 08 17:24:06 i'd love to have awkward conversations about the future intel quark products, but i'd genuinely heard nothing about the edison product we announced at CES. :/ Jan 08 17:29:02 rburton: officially not, it was all rumors Jan 08 17:29:22 jackmitchell: :) Jan 08 17:32:28 rburton: don't feel bad nobody tells me anything :P Jan 08 17:33:21 rburton: do you still maintain mesa in oe-core? Jan 08 17:46:59 JaMa: i guess :) Jan 08 17:47:36 rburton: http://lists.openembedded.org/pipermail/openembedded-core/2014-January/088072.html Jan 08 17:48:03 rburton: I know you were working with upstream on this, so maybe you have better info than Valentin Jan 08 17:54:28 JaMa: you'd be better addressing your email to ross as valentin is away for a few weeks Jan 08 17:55:13 ah OK, I've used valentin as author of that commit Jan 08 18:37:24 kergoth: might be today :) Jan 08 18:42:30 is there an official description of the current defined recipes-* categories, and what goes in which? what exactly goes in 'recipes-tools' vs 'recipes-utils' vs 'recipes-extended'? what makes something 'support'? why are filesystems like e2fsprogs in 'devtools'? Jan 08 18:48:47 kergoth: there is meta/recipes.txt that is supposed to do that Jan 08 18:48:55 (broadly) Jan 08 18:49:12 as I think we've talked about before, some of the categorisations are fairly arbitrary Jan 08 18:49:20 i think that's being generous :) Jan 08 18:49:27 perhaps yes :) Jan 08 19:43:28 JaMa: oh, *that*. noted, will re-open that can of worms tomorrow. Jan 08 19:43:40 the upstream solution was effectively "use pkgconfig" Jan 08 19:58:57 hmm checking if .pc really has that flag :) Jan 08 20:00:26 rburton: it's there for gl.pc, but not in gles*.pc, but that doesn't mean it has to be there Jan 08 20:00:57 I need to check what that failing build was using in qtbase/qtwebkit Jan 08 20:03:51 JaMa: if you can mail the build log of what failed, that would be great Jan 08 20:04:58 I'll have to simulate that with public layers first :) Jan 08 20:05:45 heh, yes :) Jan 08 20:07:35 looking at qtbase/config.tests/x11/opengl/opengl.pro it just doesn't use pkg-config at all to read gl.pc Jan 08 20:08:27 so as soon as -DMESA_EGL_NO_X11_HEADERS was removed from mesa header it can try to load xlib.h Jan 08 20:09:34 that entire platform thing is mostly arse Jan 08 20:09:53 somewhere in ./src/platformsupport/glxconvenience it loads some mesa header which in turn loads xlib.h and fails Jan 08 20:10:33 http://patchwork.openembedded.org/patch/60673/ this is basically the same Jan 08 20:28:52 kergoth: ping Jan 08 20:53:22 I am new to yocto and wondering if anyone in here might be able to help me as I am having issues getting console output for core-image-base and core-image-minimal when I build them for the imx6dl system Jan 08 20:53:59 I have been following all the instructions so don't know where I am going wrong Jan 08 20:59:49 anyone? Jan 08 21:01:31 newell: which mx6dl device is this? or generic? Jan 08 21:01:45 by default it sets console to /dev/ttymxc0 Jan 08 21:02:04 (UART1) .. if you do not have that wired, you're going to get squat,. Jan 08 21:02:44 WarheadsSE, okay let me see if LTIB was using the same /dev node Jan 08 21:03:14 This is the sabresdp board (I think that tells you which one). Jan 08 21:04:50 i'd have to go looking it up Jan 08 21:05:07 better channel might be #imx6-dongle Jan 08 21:05:39 they do most of the fsl-arm layer work and are very familiar with the imx6 specifics in yocto/bb Jan 08 21:05:51 okay, on freenode as well? Jan 08 21:06:18 looks like it is...thanks Jan 08 21:08:02 np Jan 08 21:12:47 kergoth: since you were the one interested https://bitbucket.org/WarheadsSE/dockbake Jan 08 21:49:17 Anyone know how to enable real time patch on yocto kernel? Jan 08 22:33:54 anyone here done RT patch with yocto? Jan 08 22:34:09 newell, that would be me Jan 08 22:34:55 dvhart, okay I just got yocto to build and now I would like to enable RT_PREEMPT in the kernel but when I do a menuconfig I don't see that option so I assume I need to set something somewhere in order to get that option. Hints? Jan 08 22:36:10 newell, there is a recipe "linux-yocto-rt", you'll need to enable support for your machine (which machine?), and you select that kernel by specifying PREFERRED_PROVIDER_virtual/kernel="linux-yocto-rt" Jan 08 22:36:15 in your local.conf or similar. Jan 08 22:36:51 okay so sounds like I only need to update my local.conf with the PREFFERED_PROVIDER that you listed above and I should be good to go when I rebuild? Jan 08 22:37:19 Does that automatically compile the kernel with that option or do I still need to manually set it using menuconfig (or similar)? Jan 08 22:37:35 dvhart, thanks for you help by the way...really appreciate it Jan 08 22:37:41 Same goes to WarheadsSE Jan 08 22:38:30 the machine I am using is the i.MX6 Dual SABRE-SDP Jan 08 22:38:43 the linux-yocto-rt recipe will add the various PREEMPT_RT_FULL options and such Jan 08 22:38:54 okay great Jan 08 22:38:56 will try now Jan 08 22:39:02 you will need to have support for your machine in the meta-data though Jan 08 22:39:05 have you done that? Jan 08 22:39:48 not sure where would I look to find that out? Jan 08 22:40:29 I am fairly new to this (1-2 days playing with yocto and fsl) Jan 08 22:41:06 OK - which kernel are you building now? Jan 08 22:41:21 what is the value of PREFERRED_PROVIDER_virtual/kernel now? Jan 08 22:41:40 bitbake virtual/kernel -e | grep PREFERRED_PROVIDER_virtual/kernel= Jan 08 22:41:45 dvhart, the PREFFERED_PROVIDER is not present in my conf/local.conf file Jan 08 22:41:52 try the above please Jan 08 22:42:01 the kernel version I am using now is 3.0.35-4.1 Jan 08 22:43:38 okay modified local.conf and bitbaking again Jan 08 22:44:16 newell, hrm, which kernel recipe? Jan 08 22:44:24 the instructions I'm giving you are only for linux-yocto Jan 08 22:44:33 I did: Jan 08 22:44:36 if fsl uses a different kernel for their BSPs, you'll have to discuss with them. Jan 08 22:44:39 $ bitbake core-image-base Jan 08 22:44:45 is core-image-base the recipe? Jan 08 22:44:50 * newell is newer to this jargon Jan 08 22:44:52 no, that's the image recipe Jan 08 22:44:58 I'm refering to the kernel recipe Jan 08 22:45:04 please run the command above Jan 08 22:45:09 bitbake virtual/kernel -e | grep PREFERRED_PROVIDER_virtual/kernel= Jan 08 22:46:13 when I ran the command you just listed (^ ^) I got this: Jan 08 22:46:24 PREFFERED_PROVIDER_virtual/kernel="linux-yocto-rt" Jan 08 22:46:29 that was the output from that Jan 08 22:47:07 was that the expected result? Jan 08 22:49:04 dvhart, yeah I guess I will have to see if there is an fsl kernel for yocto that also supports the RT patch Jan 08 22:50:18 that is because you set it in local.conf :-) Jan 08 22:50:28 We need to know what it was before that :-) Jan 08 22:50:37 okay let me take it out...one second Jan 08 22:50:38 So comment out the preferred provider in local.conf, and try again. Jan 08 22:51:06 nothing was returned when I comment it out Jan 08 22:51:57 OK, now try: bitbake virtual/kernel Jan 08 22:52:08 does a linux recipe start building? Jan 08 22:52:37 yes Jan 08 22:53:07 and it finishes Jan 08 22:53:16 what was the name of the recipe? Jan 08 22:54:39 http://pastebin.com/DPzXQd4p Jan 08 22:55:09 what would the recipe name be for this? Jan 08 22:55:18 I used https://github.com/Freescale/fsl-community-bsp-platform Jan 08 22:59:15 dvhart, does that tell me the recipe...b/c I couldn't gather it from the output of that command Jan 08 22:59:46 Unfortunately the log you pasted was taken after the 2 tasks were run, so they don't appear. Jan 08 23:01:26 that github url is listed as temporarily unavailable Jan 08 23:01:33 look in your fsl-community-bsp-platform Jan 08 23:01:44 look under something like meta/recipes-kernel/linux/*bb Jan 08 23:01:54 are there any linux related bb files in such a path? Jan 08 23:02:01 sorry, I have no experience with fsl Jan 08 23:02:46 dvhart, looking now. No worries, I appreciate the help. Jan 08 23:03:24 dvhart, yes there are *.bb files in there Jan 08 23:03:47 can you list them please? Jan 08 23:04:28 linux-fslc_3.12.bb linux-imx_3.0.35.bb linux-timesys_3.0.15.bb linux-imx_2.6.35.3.bb linux-imx_3.10.9.bb Jan 08 23:05:31 OK, one or more of those likely contains a "COMPATIBLE_MACHINE" string which includes your machine. You are most likely building that recipe. You'll need to work with the auhtor of those recipes to get RT support. Jan 08 23:05:59 You can do this yourself by adding the patch to the SRC_URI as with any recipe and changing the config they use accordingly. Jan 08 23:06:37 These recipes are not using the linux-yocto classes though, so the linux-yocto kernel dev documentation don't really apply here. Jan 08 23:07:14 I believe fsl is not using linux-yocto to build their kernels Jan 08 23:07:27 newell: what is your target ? Jan 08 23:08:20 abelloni, if you mean which dev board are we using we are using the imx6qsabresd Jan 08 23:08:37 MACHINE=imx6qsabresd Jan 08 23:09:05 abelloni, if you mean what is my goal, my current goal is to get a RT linux kernel running on this development board Jan 08 23:09:22 yeah, I meant the machine Jan 08 23:09:30 k Jan 08 23:09:54 anyone from fsl that could help me out here or comment on this? Jan 08 23:10:34 newell, I'd send an email to whomever is listed as the maintainer for the layer you are using Jan 08 23:10:47 newell, then try adding the preempt_rt patch to the relevant recipe Jan 08 23:10:59 newell: the maintainer is on this channel, this is otavio Jan 08 23:11:18 yeah I already pinged otavio in #imx6-dongle Jan 08 23:11:22 no response yet Jan 08 23:11:39 but basically, you'll want to add the preempt_rt patch to linux-imx_3.0.35.bb Jan 08 23:11:50 k thanks Jan 08 23:12:11 easiest way would be to use a bbappend I guess Jan 08 23:12:39 don't know what that is Jan 08 23:12:57 you mean just append the bb file in the SRC_URI section like dvhart mentioned? Jan 08 23:13:29 newell, the bbappend is how you modify the meta-data without changing the original sources Jan 08 23:13:35 it's the preferred way to make customizations Jan 08 23:13:42 newell, I suggest you read through the developers guide Jan 08 23:13:51 it will get you acquainted with the lingo :-) Jan 08 23:14:05 yeah at this point it looks like I am going to have to get my hands dirty Jan 08 23:14:39 http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html Jan 08 23:14:52 anyone in here used LTIB before? Just wondering if most people here (maybe biased) like yocto more or not? Jan 08 23:14:59 dvhart: BTW, I'm not sure I understand the advantages of using linux-yocto vs inheriting kernel directly Jan 08 23:15:06 thx dvhart Jan 08 23:15:12 newell: LTIB is crap Jan 08 23:15:32 and I used to do a lot of support with it Jan 08 23:16:07 it is not maintained at all, a lot of packages are badly integrated Jan 08 23:16:09 abelloni, there is a lot of scalability advantages to the linux-yocto model Jan 08 23:16:13 Okay. The dev board from fsl was shipped with it and everything...I wish they would have mentioned yocto better in their documentation. Jan 08 23:16:21 if you are only doing one BSP, it doesn't make much difference Jan 08 23:16:30 and it is hell to get X with HW accel running Jan 08 23:16:35 for details though, I wrote the kernel-dev manual which you might care to read Jan 08 23:16:45 http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html Jan 08 23:17:14 In particular, the configuration fragments can be really powerful Jan 08 23:17:19 newell: they just switched over to yocto officially a few month ago, all the materials coming woth your board predates that Jan 08 23:17:26 ah Jan 08 23:17:35 good to know Jan 08 23:17:59 dvhart: thanks for the pointer Jan 08 23:19:17 yup - feedback welcome! Jan 08 23:19:47 dvhart: how about feedback loops? Jan 08 23:20:03 * dvhart has filters for such things.... ;-) **** ENDING LOGGING AT Thu Jan 09 02:59:58 2014