**** BEGIN LOGGING AT Mon Jun 30 03:00:00 2014 Jun 30 07:10:57 good morning Jun 30 07:16:26 gm Jun 30 07:22:22 Hi yocto Jun 30 07:27:40 I working in beaglebone black development board, For that i compiled u-boot and kernel and filesystem using meta-ti layer with minimal image core-image-minimal. If i boot this image in my board it hangs on the starting kernel..please check the link and help me to solve this issue. http://pastebin.com/idXv2pc2 Jun 30 07:53:37 Hi please any one help me to resolve this problem.. Please Jun 30 08:33:07 <[Sno]> elinuxer: smells as if youre loadaddr is wrong Jun 30 08:46:38 This kernel load address is 80008000. Is it need to update anywhere. Jun 30 09:01:42 elinuxer, how does your uEnv.txt look like? There seems to be an issue with the U-Boot environment. Jun 30 09:01:54 elinuxer, Look at the line "Unknown command 'console=ttyO0,115200n8' - try 'help' Jun 30 09:02:11 elinuxer, in our pastebin. Jun 30 09:02:46 console=... should have been appended to bootargs in u-boot, not evaluated. Jun 30 09:04:36 AndersD: please check my uEnv.txt file http://pastebin.com/89q08Cib Jun 30 09:05:22 elinuxer, the line "loadkernel=run bootargs;mmc rescan; fatload mmc 0 0x80200000 uImage-beaglebone.bin" is wrong Jun 30 09:05:36 You shouldn't have the "run bootargs" part in it Jun 30 09:06:23 AndersD:please tell me how to modify this.. Jun 30 09:06:24 As you're not evaluating variables in your bootargs line, just remove that part from loadkernel. Jun 30 09:08:17 You could also quite likely remove the loadaddr statement from uEnv.txt. Jun 30 09:09:55 Or skip the last part about loadaddr, I didn't look close enough on your uEnv.txt. Jun 30 09:09:55 AndersD:Shall i write like this http://pastebin.com/zKVZcS93 Jun 30 09:10:31 Almost, make it "loadkernel=mmc rescan; fatload mmc 0 0x80200000 uImage-beaglebone.bin" Jun 30 09:11:38 Though, you should change 0x80200000 to ${loadaddr}, to be more consistent with how you're starting the kernel. Jun 30 09:14:23 AndersD:thank you so much now it's booting. Jun 30 09:19:07 elinuxer, Good! Jun 30 09:20:20 The issue was the likely that the kernel didn't get your console=... arguments (though I would have thought it would get it anyway). Thus, the kernel didn't know where to put it's logging. Jun 30 10:37:10 AndersD: I HAVE ANOTHER PROBLEM. I want to compile meta-beagleboard layer with my poky distro if i try to add this layer with poky disto its showing error mentioned in patedbin http://pastebin.com/YB1JAqGs Jun 30 10:37:26 what is problem. Jun 30 10:43:18 AndersD.. Jun 30 10:50:15 elinuxer, which version of poky are you using, and which versin of meta-beagleboard? Jun 30 10:52:56 elinuxer, you have a spelling error in bblayers.conf. It should be common-bsp... Jun 30 10:58:13 AndersD: i have followed the web mentioned link http://pastebin.com/5hd80SX6 Jun 30 10:58:25 i cant see the version.. Jun 30 10:59:08 All are from dylan branch.. Jun 30 11:04:19 elinuxer, like I said, you have a typo in bblayers.conf Jun 30 11:05:07 The branch info (i.e. dylan) is good enough for hte moment regarding the versions. Though, I think it should work once you fix the typo. Jun 30 11:06:02 sorry..I am not understanding about typo. Jun 30 11:07:24 Ok, have line " /home/tamilarasi/beagle/poky/meta-beagleboard/comman-bsp \" in your bblayers.conf., comman-bsp should be common-bsp Jun 30 11:23:06 AndersD: oh. It's my error. Now it's working.. Jun 30 11:59:07 hi while do_install i get ERROR: cannot stat bb-example, no such file or directory, i guess something is missing, how can i get more infos about what is missing? Jun 30 12:59:50 Hi all, I am not sure but I think PACKAGECONFIG = ${@base_contains('DISTRO_FEATURES','systemd','systemd','consolekit',d)}" is not working if systemd is put in DISTRO_FEATURES_append = " systemd" and not directly in DISTRO_FEATURES ?= "systemd". Could you confirm that please? Jun 30 13:26:01 TuTizz: that should not be the case, no Jun 30 13:33:35 <[Sno]> in which order yocto finds receipes? Jun 30 13:35:30 <[Sno]> given a bblayers.conf where sources/meta-openembedded/meta-oe is before sources/meta-stef - and both have a libcec-git - which one is choosen? Jun 30 13:37:45 If a have a "some-recipe_%.bbappend", what is the recommended way of extending FILESEXTRAPATHS? Jun 30 13:38:17 [Sno]: generally, it depends upon the layer priority (higher is picked first); then if they are the same, which version is higher Jun 30 13:38:46 likewise: as always, FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" Jun 30 13:43:40 <[Sno]> bluelightning: that's enlightening - all layers (meta-oe, meta-stef, mete-me) were at 6 Jun 30 13:44:54 bluelightning: When is "files" used instead of ${PN} ? Jun 30 13:45:16 <[Sno]> so a BUILDDIR/conf/bblayers.conf should probably tweak it per project ... Jun 30 13:46:00 likewise: it's up to your preference - it just has to match up with where you actually place the files you're adding / overriding Jun 30 13:46:39 likewise: (for the bbappend that is) Jun 30 13:47:17 Hello, I'm having troubles building yocto for my baytrail platform Jun 30 13:47:36 bluelightning: thanks Jun 30 13:47:48 I'm using the latest from git dora, as wel as from meta-intel Jun 30 13:48:09 If I do a bitbake of core-image-sato, it fails on bzip2-native Jun 30 13:48:18 log on http://pastebin.com/mD7ug3F4 Jun 30 13:48:29 can somebody tell me what's wrong? Jun 30 14:33:36 hello everybody Jun 30 14:33:56 i have a bbappend file Jun 30 14:34:34 is there a way to extend a let's say do_compile task that is already defined in the original .b bfile? Jun 30 14:35:40 my bbappend's do_compile overwrites my do_compile defined in the .bb Jun 30 14:35:51 i'd like to have both executed Jun 30 14:47:19 Hi All, I'm currently having trouble with getting my current hardware (meta-valleyisland) on the network, whenever I boot the board up or try ifup/dhclient/udhcpc eth0 I'm getting no offers from the network. I would believe this would be network side apart from booting the board into windows connects fine to the network. Does anyone have any ideas on how to solve this? Jun 30 14:48:52 stuartw, and you do have a eth0? Jun 30 14:49:34 yes, the driver wasn't originally enabled in the kernel so after a menuconfig it appeared, could I have missed an option out somewhere? Jun 30 14:52:09 stuartw_ that was what I was going to ask, if you enabled the kernel driver :) Jun 30 14:52:39 I'm out of options then (besides a network problem) Jun 30 14:52:48 did you try to enable the network manually? Jun 30 14:53:02 (ifconfig eth0 192.168.xxx etc)? Jun 30 14:54:30 well, the eth0 driver is i210 which seems to link to the IGB drivers in Yocto, the following is what i enabled through menuconfig: Jun 30 14:54:36 CONFIG_IGB=y Jun 30 14:54:44 CONFIG_IGB_HWMON=y Jun 30 14:54:50 CONFIG_IGBVF=y Jun 30 14:54:57 CONFIG_IXGBEVF=y Jun 30 14:55:10 and those were all i could find relating to the IGB Jun 30 14:55:41 hm, no further ID, sorry Jun 30 14:55:45 yes, i tried setting manually, but still wouldn't connect (i.e. ping from target and to target) Jun 30 14:56:12 well thanks anyway, at least I know I haven't missed something silly! Jun 30 14:56:15 alright, found it Jun 30 14:56:42 and you're sure there is a good cable in between? and they're plugged in correctly? Jun 30 14:56:52 Blinking led on your pc side, also enabled there? Jun 30 14:56:57 (these are the silly things ;)) Jun 30 14:57:14 but verry common :-D Jun 30 14:57:55 I'll say yes as when booting windows on the board it connects perfectly (unfortunately) Jun 30 14:59:09 I missed out that infact, whenever I boot windows first then reboot into linux, the board is configured and able to connect to the network??? Jun 30 14:59:29 so it sounds to me more like a driver issue? Jun 30 15:04:38 stuartw_: avb? Jun 30 15:05:48 what does avb stand for? sorry for the lack of knowledge :P Jun 30 15:08:12 stuartw_: just wondering if you were playing with Audio Video Bridging (i210 seems nice for that) Jun 30 15:09:21 not that i currently know of, it's just what was on the board that i was given Jun 30 15:27:33 Rephrasing: If we have a some-recipe_%.bbappend, and package-version specific patches, FILESEXTRAPATHS_prepend := "${THISDIR}/${PV}" will have the ${PV} part set to "%" in the search path. How to get back the desured behaviour where ${PV} was taken from the package-version .bb file? Jun 30 15:27:51 ^s/desured/desired/ Jun 30 15:42:22 likewise: i expect you could force thisdir to be immediately expanded, but let PV be expanded later as it should be, when it has the correct value. e.g. THISDIR := "${THISDIR}"; FILESEXTRAPATHS_prepend = "${THISDIR}/${BP}:" or somesuch, but thats obviously untested Jun 30 17:49:23 question about the finer points of PREFERRED_PROVIDER Jun 30 17:49:33 I have a recipe that I want to reuse for a lot of cases. The differences I want to do is changing two variables: a path and a projectname. Jun 30 17:49:54 how do I do this the best? Creating a .inc file which I use via "require" and then only changing the two variables? Jun 30 17:50:27 I hate to blurt out my question at the same time as volker's but I shall continue typing mine anyway Jun 30 17:50:34 all in one folder with multiple .bb files or is there a way to do this across folders Jun 30 17:51:06 suppose recipes A and B both PROVIDE "X" and B is the PREFERRED_PROVIDER Jun 30 17:51:29 but A is depended upon directly by another recipe that's included in the build, so it will always be built anyway Jun 30 17:51:44 does that mean B doesn't get built? Jun 30 17:52:01 or could you end up with A and B both being built? Jun 30 17:52:01 most likely both will get sucked in, and bitbake will display an error about it Jun 30 17:52:17 hmm Jun 30 17:52:42 how would I achieve that behavior then? Jun 30 17:53:12 CONFLICTS? Jun 30 17:53:14 you'd set preferred provider to A, or fix the the recipe that depends on it explicitly Jun 30 17:53:34 no, conflicts would do nothing, bitbake knows two providers of a thing shouldnt' be built, but you ahven't told it what to do to address the situation Jun 30 17:54:40 what I want is for package A to not be built if package B is built, and vice versa Jun 30 17:54:57 if PROVIDES is not going to do that, is there another mechanism? Jun 30 17:58:00 I mean, the caveman way would be to have people manually put one or the other in IMAGE_INSTALL but I was hoping for something better Jun 30 18:01:30 that's never going to happen Jun 30 18:01:36 because that would make your builds completely nondeterministic Jun 30 18:02:28 kergoth: any opinions about reusable recipes that only differ in two variables? Jun 30 18:02:48 use a .inc, seems trivial enough to me Jun 30 18:03:18 kergoth: yes, are there alternative ways? Jun 30 18:03:30 is there a problem with using a .inc? I don't see the problem Jun 30 18:03:38 .bbappend would be nice, but from my understanding it won't work in the same layer Jun 30 18:03:40 you could use a class, but that seems pointless for two recipes Jun 30 18:03:47 bbappend wouldnt' make any sense Jun 30 18:03:54 bbapepnd modifies an existing recipe, it doesn't create two recipes Jun 30 18:05:18 kergoth: ok. I was looking for different ways where the folder would be called foo-project and not foo to make it more obvious. while foo-project uses the files from another recipe folder Jun 30 18:06:03 just brainstorming about different options. I hear already the "that package does not have its own foldername" Jun 30 18:07:08 is it possible to construct a recipe that will install extra files if something is *not* in IMAGE_FEATURES? Jun 30 18:07:28 that would also do what I want Jun 30 18:08:11 that wouldn't make sense either, image features can only affect images. if you modify how ar ecipe builds for it, then it'd be impossible to use the binary package that recipe prdouces in two different images which use two different IMAGE_FEATURES Jun 30 18:08:45 you can't modify how things are built based on what image you happen to be building at this exact moment, considering you could 'bitbake oneimage twoimage threeimage forty-two-other-images' Jun 30 18:10:16 kergoth: but isnt readonly image option such a case where it is sometimes inside of the recipe? Jun 30 18:10:23 no Jun 30 18:10:33 any recipe doing something based on a read only image feature is a broken recipe Jun 30 18:10:46 why not splitting the extra files in an additional recipe Jun 30 18:15:27 volker-: first of all, image features are recipe variables, you dont have to set them in local.conf, but can set them in the image, in which case it'd be impossible for the other recipe to know that it was set at all :) Jun 30 18:15:41 second, what would happen if you 'bitbake some-read-write-image some-read-only-image'? Jun 30 18:15:49 it just wouldn't make any sense Jun 30 18:16:41 kergoth: true, didn't think about that bitbake line. You could argue now that bitbake is the perfect tool and should be able to identify image differences to move the modularity into the recipe ;) Jun 30 18:16:54 that wouldn't make sense Jun 30 18:17:05 you're not thinking about the fact that recipe emit binary packages, and then those binary packages can go into any number of images Jun 30 18:17:15 in fact, the image can be created in an entirely separate build from the build which produced the binary package feed Jun 30 18:17:19 I just looked into the openssh recipe, I personaly find it ugly to have readonly labled files in regular recipes Jun 30 18:17:33 either the read onlyw orkarounds ahve to be implemented in the image, or you can do something like split off additional packages which do the per-recipe read-only workarounds and then install those extra packages in the image the way we handle -dev/-dbg/-doc. i've done that in meta-read-only-rootfs in the past, but it proved to no longer really be necessary Jun 30 18:20:07 kergoth: you can have DISTRO_FEATURES in the recipe but not IMAGE_FEATURES, I think that can raise confusion Jun 30 18:20:14 not really Jun 30 18:20:17 a distro is global Jun 30 18:20:20 an image is a recipe Jun 30 18:20:26 they're not even comparable Jun 30 18:20:36 by definition a distro affects multiple recipes, and by definition an image does not Jun 30 18:20:54 one involves configuration metadata, one is recipe metadata Jun 30 18:20:59 the former flows into the latter, not vice versa Jun 30 18:21:04 I get the logic behind it, still, as external user it can be somewhat confusing. Jun 30 18:21:05 its not possibel for one recipe to inspect another recipe's metadata Jun 30 18:21:07 nor will it ever be Jun 30 18:21:26 if the external user doesn't grasp the difference between a distro and an image and a machine, then they need to go back to the docs, or we need better docs Jun 30 18:21:44 its a basic fundamental concept without which they're not likely to get very far Jun 30 18:22:27 FILES_${PN}-sshd += [...] Jun 30 18:22:42 FILES_${PN}-sshd += "[...] ${sysconfdir}/ssh/sshd_config_readonly [...]" Jun 30 18:23:41 i really don't think including a tiny config file in a main recipe is that harmful, but as i said, there are other options, you could split that out into as eparate package which is only installed when the read only feature is enabled for a given image Jun 30 18:23:58 I can end up in a read-only labled file in a read-only image Jun 30 18:24:10 oh no, a 5k file, the horror Jun 30 18:24:16 (possibly smaller) Jun 30 18:24:28 it's not about the size, it is more a confusion point Jun 30 18:24:42 regardless, this is how it works, a recipe that goes based on an image feature is a bug Jun 30 18:24:48 if yo udont like how we're doing it, patches are welcome Jun 30 18:25:11 I can live with it, just my feedback :) Jun 30 18:25:25 I got through some learning curves (and am sure miss some other ones) in yocto :) Jun 30 18:26:52 it's a tradeoff. to do it differently without fundametally breaking how bitbake works would be rather more complex, so we keep a file that *might* cause user confusion, in theory, possibly ,in favor of a simpler implementation Jun 30 18:28:25 Tomorrow is July, the yocto book release is expected for July Jun 30 18:30:32 what is the yocto book release? a book about yocto? Jun 30 18:31:21 http://www.packtpub.com/embedded-linux-development-with-yocto-project/book Jun 30 18:31:22 yes Jun 30 18:31:34 for me as a complete yocto beginner it seems central to understand bitbake first, right? Jun 30 18:31:40 still no table of content Jun 30 18:31:55 volker-: 10x Jun 30 18:32:15 vroomfondel: yes, somewhat, bitbake is huge and powerful. I think the basics are important. Jun 30 18:33:18 is there also a build process for bootloaders in yocto? Jun 30 18:34:06 bootloaders are recipes like anything else. the recipes are marked so bitbake doesn't try to build the wrong one for a given machine, and it's appropriately pulled into image builds for machines that need them Jun 30 18:34:07 vroomfondel: the image comes with a boot loader, you can dd it and boot from it. For grub I haven't found seen one, but you can install grub Jun 30 18:34:38 I am on an ARM Jun 30 18:35:17 Cortex-A9 Jun 30 18:35:32 no hands on experience with ARM, but as I said, the default image I worked with always came with a working bootloader Jun 30 18:36:03 I assume you can take a image and dd it to an SDcard and boot from it Jun 30 18:37:14 support for sd card images varies with the machine/bsp, there's no standard mechanism for construction of a full disk image from a kernel+rootfs+bootloader in yocto at this time, but options do exist, it just depends on your hardware Jun 30 18:45:13 We are going to have 15-20 second bugzilla outage in a moment. Jun 30 18:46:01 Done. Jun 30 20:30:44 gidday there, I'm having some difficulty building a kernel module as a package within daisy. Jun 30 20:31:05 I have followed a couple of patterns already present, but I'm uncertain if they are going to be generally valid Jun 30 20:31:23 My current problem is a missind scripts/basic/fixdep Jun 30 20:31:40 There seems to be others who have encountered this. Jun 30 20:31:48 https://github.com/Freescale/meta-fsl-arm/commit/5b3b6618426ad06e4fb6a3a77c4a53dfb47f0556 Jun 30 20:34:38 nice new feature: The following packages could not be configuredoffline and rootfs only: ['mypackage'] Jun 30 20:36:13 is there a 'canonical' complete example of a recipe for building an out-of-kernel module? Jun 30 20:38:55 sorry, the correct string is " The following packages could not be configuredoffline and rootfs is read-only" **** ENDING LOGGING AT Tue Jul 01 03:00:01 2014