[yocto] Explicitly Adding Common Packages (ie Java) and Creating Users
All, First time submitter here. Overall, I feel that the Yocto documentation has gotten me extremely far very quickly. I'm working on a Sugarbay image that successfully boots my Sandybridge Mini-ITX computer! The first image I made even supported my Ethernet adaptor out of the box! Very cool. Thank you to all the contributors - this project is really sweet! I'd like to ask two specific questions: Question 1: The ADT manual instructs you to install the Target Management (RSE) framework into Eclipse. Presumably, one would want to use these tools to do remote debugging on their Yocto target. Unfortunately, the primary vehicle to doing streamlined remote debugging with Target Management is to run the rseserver and this requires java. Many of Yocto's base images don't come with java support (for example core-image-minimal). So I set out to figure out how to add this into my project. Makes sense right? I was never able build an image that contains the meta-oracle-master layer using the config files only. (The documentation on how to do this is sparse. Even the readme file in the layer's download is a one-liner on how to use it... why?) I was able to get an image to build using hob though. When I boot the image I have two new folders now; "/usr/java/" and "/usr/jdk1.7.0_02/" both of which contain a "/bin" folder with "java" in it. The problem is I can't seem to execute any of them what-so-ever. I just need to be able to call "java -version" and I just can't get er' to go no matter what I do! I've tried adding various locations to my $PATH and I've also tried navigating to the folder directly and calling "./java" to no avail. What folder should I expect my java executable to be in? Why can't I use it? The jdk is clearly there - I must be missing something very obvious. There really should be some documentation on this because Java is so common as it's a requirement for the tools suggested in the ADT manual. Documentation on this topic would fit really well with other common first-timer question of "How do I explicitly add a package to my Yocto image, such as OpenSSH, GDB, or Java?" The brief sections about this topic in the official guides are not very clear to me. It seems like explicitly adding a custom package might even fit in the quick start guide. Question 2: I was able to get the OpenSSH package added to my Yocto build using hob (when I can't get things to work by editing the .conf files I try hob and it feels like cheating... but it seems to work much better for me.) All I want to do now is set it up but I can't make new users! The default Yocto login account on my target is "root" but I can't call "useradd andy" because useradd is not included in my core-image-minimal build. This makes configuring sshd quite a bit harder. Any ideas? Is there a way to add user accounts at build time or do I have to add the "useradd" package? Once I understand some of these issues better I'm going to make a sweet video for beginners. There are really a lot of pitfalls that I've hurdled and I wish I could share them with everyone. But, I've got to get my feet under me first. Thanks for your time! ~Andy Gikling Electrical Engineer LasX Industries Inc. agikl...@lasx.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto 1.2 Beta Testing Report
Responses to Yocto 1.2 Beta Test: Q: Which architecture did you choose to build? A: sugarbay Q: How easily were you able to build an image and boot an image? A: I followed the QS step by step. I've done it before so it was easier this time around. I had no problem building core-image-minimal. And it ran out of the box. No hang-ups. Q: Is there any surprise to you in the process of doing this Beta testing? If so, would you please describe it and tell us how you expected it to work? A: There were no surprises for me. However, I didn't add anything outside of the meta-intel and meta-intel-sugarbay layers. Q: How do you like our HOB interface? Please provide us with your thoughts and suggestions on HOB interface and functionality. A: This was by far what I was MOST impressed with. I've used hob in 1.1 extensively and I found the new version to be very well put together. The little "I" buttons were a cool touch. Some of the information in the "I" buttons could easily be elaborated on though. For example, the "I" next to the Layers interface points you at the manual. But why not point out the fact that there are also many layers that are useful and already made out on the net? Then link to that too maybe. Also, for another example, in the settings dialog, the "other" tab has an info button that simply says this is where you specify more key/value pairs - but why not then list say a dozen common options that people might want to use. Or point at a list somewhere that has some examples with descriptions and help. I was very surprised to see that once my image built in hob the bottom right corner has a deploy button. It then lets you specify a usb drive to write the image to. I was excited about this because it would be an amazingly useful feature if you don't know how to format usb drives in ZIP mode to get hardware to boot. However, after trying this feature out it seems the script simply writes the root folders to the usb drive. (ie. /bin /lib /usr etc...) Unfortunately, this didn't boot my hardware - normally my working usb sticks have the contents of the .hddimg on it (initrd, syslinux.cfg, vmlinz etc...). After checking again it seems you can't even select the .hddimg file from this deploy gui either. I needed to go back and setup my thumb drive for ZIP mode again and run syslinux on it again. I might have missed something here though - I only tried the deploy feature once. Overall I was very pleased with the new hob. Because you can easily save configurations I feel like I might find myself using this tool in the future exclusively. It's just so much faster and intuitive than scrolling through configuration files. I'm sure it has bugs but I haven't encountered any yet. Q: Was it easy to find the support you needed to build and boot an image? A: The documentation is really quite good. However, if you run into any sort of errors during build - which is easy to do - the documentation isn't much help. There's so many things that can go wrong it makes sense that there wouldn't be documentation for many types of errors. That said, it would be nice to see a more robust "troubleshooting errors" section in the docs. Q: Which Bugzilla reports did you submit? A: None. I find it hard to tell if what I'm looking at is actually a bug or if I'm simply misunderstanding or missing something. I will in the future though. Q: Did you try anything else with Yocto 1.2? A: I tried added shadow, tcf-agent, openssh and gdb to my hob build it worked great - first try. Interestingly though, when I went to boot this image the username "root" didn't work anymore. I know it has to do with adding shadow, but why would adding that package "break" my "root" login with no password. I've added shadow before in 1.1 and this didn't happen - root still worked as a login with no password. Might this be a bug? Or do I need to configure shadow before I bake? Q: What would you like to have in Yocto Project for future releases? A: More options for the "deploy" feature in hob would be nice. It would be sweet it you could just drop your build right onto your boot media directly from hob gui - be it a usb drive, sata hard drive or otherwise. I've also noticed hob used to put some of it generated config files in the /build/conf/ folder. It seems that they are gone now. It would be nice to allow the hob user to go and see exactly what configuration file changes have been made by using the gui. This functionality would be an invaluable tool to teach new users about how it all works. Best, ~Andy Gikling LasX Industries Inc. agikl...@lasx.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Eclipse-ADT-build-error (Lu, Lianhao)
Lu, Lianhao, I've recently confirmed the same type/class of error(s). I've had all the ADT building working before which is the interesting thing. I tried to move from Yocto 1.1 to Yocto 1.1.1 and that's when it started happening. I believe it has to do with a mis-version of Yocto ADT and the prebuilt toolchain you down download from the site - or something of that nature. This evening I'll probably have a chance to explore further exactly what's happening and what I've tested. Thanks, ~Andy Gikling ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Eclipse-ADT-build-error (Lu, Lianhao)
Lianhao, I've looked into this more deeply and I'm pretty sure I've followed the directions in the ADT manual correctly as I've gotten this to work before in ADT v1.1. I'm having the same problem Lu seems to be having. To answer your questions: 1. Host OS? - Ubuntu 11.10 - 32bit VM 2. Which version of eclipse? 3.7.2 3. Which version of Yocto eclipse plugin? 1.2.0.2x - I just tried to get it as per the manual but the link on the ADT manual for the plugin is broken. I was able to use the update feature from within Ecplise - this brought me from 1.1 to 1.2.0.2x 4. Which image do you use as sysroot? core-image-sato or core-image-sato-sdk? - Core-image-minimal 5. Which version of metadata do you use to build the image? Sugarbay - is that what you're looking for? 6. How do you install the toolchain? Using adt-installer or extracting meta-toolchain tarball? If using meta-toolchain tarball, which version do you use? - used the premade tarball from: http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain/i686/poky-eglibc-i686-arm-toolchain-gmae-1.1.1.tar.bz2<http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain/i686/poky-eglibc-i686-arm-toolchain-gmae-1.1.1.tar.bz2> - once extracted, in Ecplise, I point at /opt/poky/1.1.1 for my Toolchain Root and /opt/poky/1.1.1/sysroots/ for my Sysroot Location. Following the ADT manual closely, I've sourced the ADT env vars with $source /opt/poky/1.1.1/environment-setup-x86_64-poky-linux Now, I've opened a new C Hello World template project and use Project -> Reconfigure Project. Unfortunately this fails. The console reads "> configure: error: C compiler cannot create executables" as Lu has seen. All the other Eclipse requirements from the ADT manual have been installed as well. The config.log shows this snippet as the culprit: ... Thread model: posix gcc version 4.6.1 20110627 (prerelease) (GCC) configure:2413: $? = 0 configure:2402: x86_64-poky-linux-g++ -V >&5 x86_64-poky-linux-g++: error: unrecognized option '-V' x86_64-poky-linux-g++: fatal error: no input files compilation terminated. configure:2413: $? = 1 configure:2402: x86_64-poky-linux-g++ -qversion >&5 x86_64-poky-linux-g++: error: unrecognized option '-qversion' x86_64-poky-linux-g++: fatal error: no input files compilation terminated. configure:2413: $? = 1 configure:2433: checking whether the C++ compiler works ... So interestingly, I went ahead and tried to run autogen.sh directly from the terminal with "sh autogen.sh" and this also gives me the same error: "configure: error: C compiler cannot create executables" However, when I run this with sudo in the terminal it works. I can then call "sudo ./configure" from the terminal and that also works. Now I have a Makefile in my src directory as expected. Unfortunately, this project still doesn't build in Eclipse. I keep getting "no rule for make target 'all' " I've done all of the above again, fresh, after calling "chmod -R 777 /home/userName/workspace" so it might not be a permissions problem. I've run through these ADT steps in the 1.1 version of the ADT manual without any problems. What changed? Do I submit a bug? Regards, ~Andy Gikling LasX Industries Inc. agikl...@lasx.com ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ADT Manual v1.1.1 Issues - 1 of 3
All, There's a broken link in the ADT manual. In section 4.1.3.1, the path "http://downloads.yoctoproject.org/releases/eclipse-plugin/1.1.1"; does not exist. I think this is the desired path but the files aren't there... Just an FYI - not sure if this merits filing a bug really. ~Andy Gikling LasX Industries Inc. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ADT Manual v1.1.1 Issues - 2 of 3
All, I've had very mixed results during the three or four times I've run through the ADT manual from scratch. There seems to be a real problem I keep encountering that I'd like to describe to the community with the hope that someone understands why I keep getting stuck. I'm running a 32bit Ubuntu 11.10 VM and trying to build for a x86_64 sugarbay target machine. The issue is that no matter which "route" I take to setup my toolchain (be it via the installer script or a premade toolchain I've downloaded) I always get "configure: error: C compiler cannot create executables" when I try to use Project->Reconfigure Project after starting a new HelloWorld example in Eclipse. The ADT manual explicitly steps the user through to this point but using the Reconfigure Project feature (that puts together your Makefile for you) never completes. When looking closer at the config.log I always find something that looks like this: configure:3285: $? = 0 configure:3274: x86_64-poky-linux-gcc -v >&5 Using built-in specs. COLLECT_GCC=x86_64-poky-linux-gcc COLLECT_LTO_WRAPPER=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.6.3/lto-wrapper Target: x86_64-poky-linux Configured with: /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/work-shared/gcc-4.6.2+svnr181430-r17/gcc-4_6-branch/configure --build=x86_64-linux --host=i686-pokysdk-linux --target=x86_64-poky-linux --prefix=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr --exec_prefix=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr --bindir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/bin/x86_64-poky-linux --sbindir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/bin/x86_64-poky-linux --libexecdir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/libexec/x86_64-poky-linux --datadir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/share --sysconfdir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/etc --sharedstatedir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/com --localstatedir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/var --libdir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/lib/x86_64-poky-linux --includedir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/include --oldincludedir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/include --infodir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/share/info --mandir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/share/man --disable-silent-rules --with-libtool-sysroot=/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/sysroots/i686-pokysdk-linux-nativesdk --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=x86_64-poky-linux- --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libgomp --disable-libmudflap --enable-cheaders=c_global --with-local-prefix=/opt/poky/1.1.1/sysroots/x86_64-poky-linux/usr --with-gxx-include-dir=/usr/include/c++ --with-build-time-tools=/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/sysroots/x86_64-linux/usr/x86_64-poky-linux/bin --with-sysroot=/opt/poky/1.1.1/sysroots/x86_64-poky-linux --with-build-sysroot=/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/sysroots/qemux86-64 --disable-libunwind-exceptions --disable-libssp --disable-libgomp --disable-libmudflap --with-mpfr=/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/sysroots/i686-pokysdk-linux-nativesdk --with-mpc=/srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/build/build/tmp/sysroots/i686-pokysdk-linux-nativesdk --enable-nls --enable-__cxa_atexit Thread model: posix gcc version 4.6.3 2017 (prerelease) (GCC) configure:3285: $? = 0 configure:3274: x86_64-poky-linux-gcc -V >&5 x86_64-poky-linux-gcc: error: unrecognized option '-V' x86_64-poky-linux-gcc: fatal error: no input files compilation terminated. configure:3285: $? = 1 configure:3274: x86_64-poky-linux-gcc -qversion >&5 x86_64-poky-linux-gcc: error: unrecognized option '-qversion' x86_64-poky-linux-gcc: fatal error: no input files compilation terminated. I've tried to figure out what this error means but haven't had any luck. People have made some suggestions that I've tried and they haven't worked either. So, I've been told to file a bug about this but I wasn't sure which category it goes under and I've never filed a bug in the Yocto project before. I'll try to get to it this week. In the meantime, if anyone has tried to get through the ADT manual and is cross compiling I'd love to hear about how it went for you. Thanks, ~Andy Gikling LasX Industries Inc. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] ADT Manual v1.1.1 Issues - 3 of 3
All, I ran through the ADT manual and ran into some goofynees in section 2.1.1.2. Configuring and Running the ADT Installer Script. My adt_installer.conf contains: YOCTOADT_REPO="http://adtrepo.yoctoproject.org/1.1.1"; YOCTOADT_TARGETS="x86_64" YOCTOADT_QEMU="Y" YOCTOADT_NFS_UTIL="Y" YOCTOADT_ROOTFS_x86_64="minimal" YOCTOADT_TARGET_SYSROOT_IMAGE_x86_64="minimal" YOCTOADT_TARGET_SYSROOT_LOC_x86_64="$HOME/Desktop/ADT_Try2/sysroot" Which should all be just fine. When you run the installer script with these settings you will come to a 404 Not Found Error. The image that was supposed to be downloaded to the /download_image/ folder is not there and eventually you will get an error from the script when it tries to extract the sysroot image it thought it downloaded. I've found the sysroot file it's looking for in the Yocto downloads and put it in /download_image/ folder manually. Once that's done the ADT installer script will then complete successfully. There's a broken link there. Does the YOCTOADT_REPO="http://adtrepo.yoctoproject.org/1.1.1"; need to contain a more exact path. I'll try again with YOCTOADT_REPO="http://adtrepo.yoctoproject.org/1.1.1/adt-ipk/x86_64/"; or something like that... Just an FYI, ~Andy Gikling LasX Industries Inc. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ADT Manual v1.1.1 Issues - 2 of 3 (Resolved)
Lianhao, Thank you for the insight. I felt like this wasn't a bug! I wasn't ever sure about where you are supposed to point for your sysroot. Looking back through the ADT manual I see now what it's getting at. Obviously it makes sense now. Ahhh growing pains... Thanks for your time - it works. ~Andy Gikling -Original Message- From: Lu, Lianhao [mailto:lianhao...@intel.com] Sent: Tuesday, April 10, 2012 8:35 AM To: Andy Gikling; yocto@yoctoproject.org Subject: RE: ADT Manual v1.1.1 Issues - 2 of 3 Andy, I checked the config.log. I think you might set the incorrect sysroot directory in Eclipse. The "/opt/poky/1.1.1/sysroots/" is incorrect, in your case it should be /opt/poky/1.1.1/sysroots/x86_64-poky-linux/. Please select your helloworld project, then select " Project -> Change Yocto Project Settings". Make sure you've set the correct sysroot directory. Then select "Project -> Reconfigure Project" to regenerate the configure sciprt. I also recommend you pointing your sysroot location to where you've extracted core-image-sato-sdk. The sysroot under /opt/poky/1.1.1/sysroots/ x86_64-poky-linux/ contains only very limited header files and libraries. -Lianhao Andy Gikling wrote on 2012-04-10: > Lianhao, > > Attached is the config.log and the environment setup file. > > I hope this gives us some insight. Thank you for your time. > > ~Andy Gikling > > -Original Message- > From: Lu, Lianhao [mailto:lianhao...@intel.com] > Sent: Tuesday, April 10, 2012 12:08 AM > To: Andy Gikling; yocto@yoctoproject.org > Subject: RE: ADT Manual v1.1.1 Issues - 2 of 3 > > Andy, > > Could you please attach both the config.log file and the environment file > under the directory /opt/poky/1.1.1/ ? > > Andy Gikling wrote on 2012-04-10: >> All, >> >> >> >> I've had very mixed results during the three or four times I've run >> through the ADT manual from scratch. There seems to be a real >> problem I keep encountering that I'd like to describe to the >> community with the hope that someone understands why I keep getting >> stuck. I'm running a 32bit Ubuntu 11.10 VM and trying to build for a >> x86_64 sugarbay target machine. >> >> >> >> The issue is that no matter which "route" I take to setup my >> toolchain (be it via the installer script or a premade toolchain I've >> downloaded) I always get "configure: error: C compiler cannot create >> executables" >> when I try to use Project->Reconfigure Project after starting a new >> HelloWorld example in Eclipse. The ADT manual explicitly steps the >> user through to this point but using the Reconfigure Project feature >> (that puts together your Makefile for you) never completes. When >> looking closer at the config.log I always find something that looks >> like this: >> >> >> >> configure:3285: $? = 0 >> >> configure:3274: x86_64-poky-linux-gcc -v >&5 >> >> Using built-in specs. >> >> COLLECT_GCC=x86_64-poky-linux-gcc >> >> COLLECT_LTO_WRAPPER=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/l >> i bex ec/x86_64-poky-linux/gcc/x86_64-poky-linux/4.6.3/lto-wra pper >> >> Target: x86_64-poky-linux >> >> Configured with: >> /srv/home/pokybuild/yocto-autobuilder/yocto-slave/nightly-x86-64/buil >> d /bu ild/tmp/work-shared/gcc-4.6.2+svnr181430-r17/gcc-4_6-branc >> h/configure --build=x86_64-linux --host=i686-pokysdk-linux >> --target=x86_64-poky-linux >> --prefix=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr >> --exec_prefix=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr >> --bindir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/bin/x86_64-p >> o >> ky- >> linux >> --sbindir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/bin/x86_64- >> p >> oky >> -linux >> --libexecdir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/libexec/ >> x >> 86_ >> 64-poky-linux >> --datadir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/share >> --sysconfdir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/etc >> --sharedstatedir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/com >> --localstatedir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/var >> --libdir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/lib/x86_64-p >> o >> ky- >> linux >> --includedir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/include >> --oldincludedir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr/inclu >> d e >> --infodir=/opt/poky/1.1.1/sysroots/i686-pokysdk-linux/usr
Re: [yocto] configure: error: C compiler cannot create executables when
Jack, I've been burned by this same type of issue several times during different trial runs of the Yocto quick start and when running through the ADT Manual. Here are a few things to try / things I've done wrong in the past / common pitfalls: 1. Be very sure your tool chain is correct for your target. You need to know if you are "cross compiling" or not! Look up what that means if you are unfamiliar. For example, if you have 32Bit host and a 64bit target the pre-built toolchain you should download is "poky-eglibc-i686-x86_64-toolchain-gmae-1.1.1.tar.bz2" - these premade toolchains can be found at http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/toolchain/ As another example, if you are trying to run the quick start with qemux86 as the target emulator you should get "poky-eglibc-i686-i586-toolchain-gmae-1.1.1.tar.bz2" from the above site. Or see the ADT Manual for details on other ways to get and configure your build tools. 2. Once you get a toolchain, make sure it's contents end up in /opt/poky/version/ folder where version is the Yocto version your using. v1.1.1 is the latest and 1.2 is coming soon. It is important to know what version of Yocto you are trying to use! (Obviously... but note in the steps below that it's easy to get the wrong version of the Eclipse plugin for Yocto.) 3. When downloading the Eclipse Yocto plugin I have found it's easiest to simply download the ...archive.zip version of the Yocto v1.1.1 plugin from this address: http://downloads.yoctoproject.org/releases/yocto/yocto-1.1.1/eclipse-plugin/indigo/ - then in Eclipse, when adding that plugin, don't enter a software site address, simply click the "Archive" button (the dialog will look for a .zip file) then point at the plugin's .zip file you download. 4. It's easy to miss the step in the ADT manual about how to configure the Yocto plugin once you've installed it. (Also make sure you've correctly installed all the other add-on software described in the Eclipse setup procedure at the end of the ADT manual. Note the WinCE software on that list doesn't seem to ever install correctly. I haven't needed it though - should be able to skip it.) The ADT Manual tell you to go to Window->Preferences and you'll see the Yocto ADT settings on the bottom of the column on the left. You should chose Standalone pre-built tollchain if you downloaded it like I described above. "Toolchain Root Location" should be "/opt/poky/1.1.1" and "Sysroot Location" should be "/opt/poky/1.1.1/targetSysrootFolder" where targetSysrootFolder will change depending on what toolchain you've downloaded. This is supposed to be a folder that mimic's what's going to be available on the target when the software you're developing is running there. It includes headers, libraries etc... Pointing at the right sysroot location is very important. It will own you if you don't! 5. There's a nice 1 liner in the quick start manual after you've opened a new hello world template that's easily missed! One you've open your Yocto hello world template you need to run the autotools, but this is not supposed to be done from the command line. If your Yocto ADT plugin is setup correctly, and you've selected the new hello world project in Eclipse's Project Explorer, you will be able to get to the menu option Project->Reconfigure Project. This runs the autotools for you. In the console you should see that this completed successfully. Once it's completed successfully, you should see a Makefile in hello world's /src/ folder. It was not there before and was generated by calling Reconfigure Project. Now you should be able to right click your project and build it. Hope this helps! Let us know. ~Andy Gikling LasX Industries Inc. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] FR2 BSP Documentation On Website Error
The Fish River Island 2 documentation on the Yocto Project website has an error (BSP version 9.0.0 "Dylan"). Specifically, the first section "Building the meta-fri2 BSP layer" describes a step where you are to add a LICENSE_FLAGS_WHITELIST entry to your local.conf when trying to enable the EMGD graphics driver. The website says to add: LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin_1.10" But in the README found in the download it says to use: LICENSE_FLAGS_WHITELIST = "license_emgd-driver-bin" The latter is correct. This burned me for about 2 hours. If this could be fixed I'd appreciate it! Thanks, ~Andy Gikling ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] yocto Digest, Vol 38, Issue 29
Brian, Yes the meta-intel x86-64 should work. I wouldn't count on the infrared working out of the box though. Chances are getting the appropriated graphics drivers to work with Yocto will also be difficult and probably won't work out of the box. All the NUC's peripherals might work if you install Ubuntu - but I'd even give that a 40% chance of failing to support everything you need for your home theater computer. If this is your first go at Yocto, I'd try getting the build system to run on an older x86 computer that you're not interested in using as your home theater PC. Otherwise you're going to probably get frustrated if/when Yocto doesn't totally support the NUC... But if you're not planning on this being a home theater PC, by all means, have at it! If Yocto has issues now, many of them will get fixed eventually as more of the NUC devices come online. Just my 2 cents. ~Andy Gikling -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of yocto-requ...@yoctoproject.org Sent: Wednesday, November 06, 2013 4:07 PM To: yocto@yoctoproject.org Subject: yocto Digest, Vol 38, Issue 29 Send yocto mailing list submissions to yocto@yoctoproject.org To subscribe or unsubscribe via the World Wide Web, visit https://lists.yoctoproject.org/listinfo/yocto or, via email, send a message with subject or body 'help' to yocto-requ...@yoctoproject.org You can reach the person managing the list at yocto-ow...@yoctoproject.org When replying, please edit your Subject line so it is more specific than "Re: Contents of yocto digest..." Today's Topics: 1. Re: FW: curious about ref manual, sec 6.1.11, oe-init-build-env-memres (Saul Wold) 2. Re: FW: curious about ref manual, sec 6.1.11, oe-init-build-env-memres (Robert P. J. Day) 3. Bitbake Commander Content Assist on bbappend files (Jate Sujjavanich) 4. My first Yocto Project (Brian Duffy) 5. Changing Config for linux-raspberrypi (John Whitmore) 6. Re: Changing Config for linux-raspberrypi (Robert P. J. Day) 7. Re: My first Yocto Project (Sean Liming) -- Message: 1 Date: Wed, 06 Nov 2013 12:38:13 -0800 From: Saul Wold To: "Rifenbark, Scott M" , Yocto discussion list Subject: Re: [yocto] FW: curious about ref manual, sec 6.1.11, oe-init-build-env-memres Message-ID: <527aa8b5.8060...@linux.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed On 11/06/2013 11:11 AM, Rifenbark, Scott M wrote: > Anyone know this? > >> -Original Message- >> From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] >> Sent: Wednesday, November 06, 2013 10:48 AM >> To: Rifenbark, Scott M >> Subject: curious about ref manual, sec 6.1.11, >> oe-init-build-env-memres >> >> >> i've never used that memory-resident version of bitbake -- it's not >> clear from that section whether you need to start bitbake running >> before you run that script. >> Running that scripts will start the server at the default port of 12345 and setup the default "build" directory. >> that is, it's not really *explicitly* explained whether running >> that script with a port number *starts* the bitbake server. does it? >> Yes, running the script with a port number will start the server using that port number. The bitbake -m command will Stop the server. Sau! >> rday > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- Message: 2 Date: Wed, 6 Nov 2013 15:41:02 -0500 (EST) From: "Robert P. J. Day" To: Saul Wold Cc: Yocto discussion list Subject: Re: [yocto] FW: curious about ref manual, sec 6.1.11, oe-init-build-env-memres Message-ID: Content-Type: TEXT/PLAIN; charset=US-ASCII On Wed, 6 Nov 2013, Saul Wold wrote: > On 11/06/2013 11:11 AM, Rifenbark, Scott M wrote: > > Anyone know this? > > > > > -Original Message- > > > From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > > > Sent: Wednesday, November 06, 2013 10:48 AM > > > To: Rifenbark, Scott M > > > Subject: curious about ref manual, sec 6.1.11, > > > oe-init-build-env-memres > > > > > > > > > i've never used that memory-resident version of bitbake -- it's > > > not clear from that section whether you need to start bitbake > > > running before you run that script. > > > > Running that scripts will start the server at the default port of > 12345 and setup the default
Re: [yocto] My first Yocto Project
>> Brian, >> >> Yes the meta-intel x86-64 should work. I wouldn't count on the infrared >> working out of the box though. Chances are getting the appropriated >> graphics drivers to work with Yocto will also be difficult and probably >> won't work out of the box. All the NUC's peripherals might work if you >> install Ubuntu - but I'd even give that a 40% chance of failing to support >> everything you need for your home theater computer. >> >> If this is your first go at Yocto, I'd try getting the build system to run >> on an older x86 computer that you're not interested in using as your home >> theater PC. Otherwise you're going to probably get frustrated if/when Yocto >> doesn't totally support the NUC... >> >Or you could try the Yocto NUC BSP: >http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel/tree/meta-nuc >I don't know about IR, but everything else works fine out of the box, >including graphics. >Tom First of all, sorry for top-posting in my last response! Tom, I had no idea there was a NUC BSP - very cool. Brian, if you get a NUC Yocto should have full support for it with the NUC BSP - try it out! ~Andy >> But if you're not planning on this being a home theater PC, by all means, >> have at it! If Yocto has issues now, many of them will get fixed eventually >> as more of the NUC devices come online. >> >> Just my 2 cents. >> >> ~Andy Gikling ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Prescribed way to make global variables in recipes?
Dear Yocto,
First of all, I love this project. Thanks for all your hard work.
Question: What is the prescribed way to allow image recipes to make global
configuration variables that other recipes can use?
After extensive research and educating myself on how bitbake works, it seems
that what I'm asking for is technically not possible. This issue is discussed
previously without a clear conclusion in the mailing list:
https://lists.yoctoproject.org/pipermail/yocto/2012-February/004552.html
Another work around is to setup a BB_ENV_EXTRAWHITE variable as described here:
http://stackoverflow.com/questions/17366984/is-it-possible-to-pass-in-command-line-variables-to-a-bitbake-build
However, this doesn't seem like the right approach either.
If there's no way to make global variables in an image recipe it seems one of
two things are true: Either bitbake lacks this powerful feature for some
reason or there's some other "prescribed" way to accomplish what I need and I
just don't know what that is. I suspect the latter is true.
Let me give a simple example of why I need this feature. We are deploying an
application with Yocto called "faux-app." Once this product is live, I would
like to use our continuous integration build mechanism to build images for
faux-app that contain the latest version of the user space application code.
We have a meta-faux-app layer with a hand full of recipes that are gracefully
customizing our image. One of the recipes is an "image recipe" that pulls in
core-image and builds the output deploy binaries called faux-app_0.1.bb.
Another recipe is essentially a bbappend that is in charge of applying a patch
to u-boot. This patch configures u-boot to behave in a "debug" fashion vs a
"release" fashion (ie, defaulting to network boot for debug and sdcard boot for
release).
Ideally, for CI purposes we would like to allow our CI server to simply call
"bitbake faux-app" to make a release build and then "bitbake faux-app-debug" to
make a debug build. The thought process is I could have a variable defined in
both "faux-app_0.1.bb" and "faux-app-debug_0.1.bb" called FAUX_RELEASE_MODE.
In faux-app_0.1.bb this variable would be set to "release" and in
faux-app-debug_0.1.bb it would be set to "debug."
Then, in the "u-boot_2014.04.bbappend" file found in our layer, we could append
the correct patch to the SRC_URI variable using inline python logic for example:
SRC_URI += "${@base_contains('FAUX_RELEASE_MODE', 'release',
'file://u-boot-mode-release.patch', ' file://u-boot-mode-debug.patch ', d)}"
So in this way I have my image recipe setting a value that tells other recipes
how to behave. This seems like a perfectly reasonable use case so I'm at a
loss as to why bitbake doesn't support this (I understand the environment
variables is "scrubbed" between recipes - it makes sense). Is there another
mechanism I'm not aware of? Can someone give me an example of a different way
to accomplish my use case described above?
Any guidance would be much appreciated! Thanks,
~Andy Gikling
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Prescribed way to make global variables in recipes?
Ross, Perfect thank you so much. That makes total sense now. I like the idea of just having two different recipes and then use IMAGE_INSTALL. However, in the u-boot example I’m actually just using a bbappend to the u-boot recipe provided with our target SOM’s bsp. Can I select different bbappend files in my image recipe with IMAGE_INSTALL? I don’t think so but I’ll try though. So what do I do in that case? Just make two of my own versions of the u-boot_2014.04.bb file, and give them different names? For example “u-boot-faux_2014.04.bb” and “u-boot-faux-debug_2014.04.bb” ? That should work but does that make sense to do? Thanks again, ~Andy Gikling From: Burton, Ross [mailto:ross.bur...@intel.com] Sent: Friday, April 08, 2016 9:44 AM To: Andy Gikling Cc: yocto@yoctoproject.org Subject: Re: [yocto] Prescribed way to make global variables in recipes? On 8 April 2016 at 15:30, Andy Gikling mailto:agikl...@minnetronix.com>> wrote: Dear Yocto, First of all, I love this project. Thanks for all your hard work. Question: What is the prescribed way to allow image recipes to make global configuration variables that other recipes can use? You can't. The basic reason being that images are built from packages, and the packages have already been built when the image is built. Ideally, for CI purposes we would like to allow our CI server to simply call “bitbake faux-app” to make a release build and then “bitbake faux-app-debug” to make a debug build. The thought process is I could have a variable defined in both “faux-app_0.1.bb<http://faux-app_0.1.bb>” and “faux-app-debug_0.1.bb<http://faux-app-debug_0.1.bb>” called FAUX_RELEASE_MODE. In faux-app_0.1.bb<http://faux-app_0.1.bb> this variable would be set to “release” and in faux-app-debug_0.1.bb<http://faux-app-debug_0.1.bb> it would be set to “debug.” In your view, what would happen if you did "bitbake faux-app faux-app-debug"? There are several ways to fix this that don't involve breaking how OE works. Either have a rootfs-time postprocess command in the debug image recipe that manipulates the installed file system, or have two recipes for the thing that changes (in this case u-boot) where one includes the other and makes the changes required, and the image install the relevant package (u-boot vs u-boot-debug). Ross -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Prescribed way to make global variables in recipes?
This doesn’t seem to be a viable option. I’m still missing something I think.
We are adding our own layer on top of our soc vendor’s layer. In their layer
there is a specialized u-boot recipe for the imx6 we are using.
So I try to make a recipe for uboot
(u-boot-faux_2014.04.bb<http://u-boot-faux_2014.04.bb>) that includes the
vendor’s uboot recipe with “include recipes-bsp/u-boot/u-boot_2014.04.bb” as
suggested and try to build an image that is going to IMAGE_INSTALL my
customized version of u-boot instead of the soc vendor’s. However, I get an
error at bitbake parse time saying:
ERROR: Multiple .bb files are due to be built which each provide u-boot
This makes sense because bitbake sees that yes, in fact now there are two
recipes that provide u-boot. I suppose I can do something like use
“PREFERRED_PROVIDER_u-boot” in my local.conf, but now I need to change my
local.conf any time I want to build a different image (ie bitbake faux-app and
bitbake faux-app-debug). I really want a workflow that doesn’t require me to
change configuration files, instead just bitbake different image recipes.
In this project I also need to conditionally patch the kernel and I’m going to
have this same problem with multiple kernel providers as well. Also, I don’t
want to remove our soc vendor’s layer to get around this error. Their layer
sets up the machine and all sorts of other things. If I got rid of it I would
need to build all that functionality into my project’s layer… or is this what
I’m going to need to do?
Thoughts?
~Andy
From: Burton, Ross [mailto:ross.bur...@intel.com]
Sent: Friday, April 08, 2016 10:10 AM
To: Andy Gikling
Cc: yocto@yoctoproject.org
Subject: Re: [yocto] Prescribed way to make global variables in recipes?
On 8 April 2016 at 16:05, Andy Gikling
mailto:agikl...@minnetronix.com>> wrote:
So what do I do in that case? Just make two of my own versions of the
u-boot_2014.04.bb<http://u-boot_2014.04.bb> file, and give them different
names? For example “u-boot-faux_2014.04.bb<http://u-boot-faux_2014.04.bb>” and
“u-boot-faux-debug_2014.04.bb<http://u-boot-faux-debug_2014.04.bb>” ? That
should work but does that make sense to do?
As the stock u-boot appears to be sufficient I'd say use that and then add a
u-boot-faux-debug_2014.04.bb<http://u-boot-faux-debug_2014.04.bb> recipe that
just does "include u-boot-${PV}.bb" and then whatever SRC_URI changes you want
in that version.
Hopefully you don't need to make any fiddly changes to the recipe as PN is now
different.
Ross
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
