[yocto] gcc reports sysroot is /not/exist!
Hi, I am using Yocto fido (1.8) to generate an SDK for a BeaglBone. I generate the it using the command: $ bitbake core-image-minimal -c populate_sdk Having installed the resulting SDK and sourced /opt/poky/1.8/environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi I find that the sysroot is not set: $ arm-poky-linux-gnueabi-gcc -print-sysroot /not/exist This used to work fine in 1.7 and earlier. It looks like now I have to use $CC in place of arm-poky-linux-gnueabi-gcc, but that messes up many Makefiles which set the compiler with something like CC=$(CROSS_COMPILE)gcc What to do? Why is gcc not configured with a sysroot any more? Chris Simmonds. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gcc reports sysroot is /not/exist!
On 15/09/15 09:58, Paul Eggleton wrote: > Hi Chris, > > On Tuesday 15 September 2015 09:48:34 Chris Simmonds wrote: >> I am using Yocto fido (1.8) to generate an SDK for a BeaglBone. I >> generate the it using the command: >> >> $ bitbake core-image-minimal -c populate_sdk >> >> Having installed the resulting SDK and sourced >> /opt/poky/1.8/environment-setup-cortexa8hf-vfp-neon-poky-linux-gnueabi >> >> I find that the sysroot is not set: >> >> $ arm-poky-linux-gnueabi-gcc -print-sysroot >> /not/exist >> >> This used to work fine in 1.7 and earlier. It looks like now I have to >> use $CC in place of arm-poky-linux-gnueabi-gcc, but that messes up many >> Makefiles which set the compiler with something like >> >> CC=$(CROSS_COMPILE)gcc >> >> What to do? Why is gcc not configured with a sysroot any more? > > AIUI this had to be done in order to have a per-architecture compiler rather > than a per-machine one. I believe if you use make -e then variables set in > the > environment will take precedence over those set in the makefile, which will > allow the CC value set by the SDK's environment setup script to be used. > > (If we haven't documented this somewhere, we definitely ought to.) > > Cheers, > Paul > Well, that works as far as it goes, but it also overrides my CFLAGS, LDFLAGS and so on, so I still have to change my Makefiles, of which there are many. Also, I am not convinced this is a step in the right direction. I expect to be able to compile a simple program using: $ gcc hello.c -o hello But with this new cross compiler setup, this happens: $ arm-poky-linux-gnueabi-gcc hello.c -o hello hello.c:1:19: fatal error: stdio.h: No such file or directory #include ^ compilation terminated. Which violates the law of least astonishment. Chris. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] gcc reports sysroot is /not/exist!
Hi Richard, On 15/09/15 10:45, Richard Purdie wrote: > On Tue, 2015-09-15 at 10:20 +0100, Chris Simmonds wrote: >> >> Also, I am not convinced this is a step in the right direction. I expect >> to be able to compile a simple program using: >> >> $ gcc hello.c -o hello >> >> But with this new cross compiler setup, this happens: >> >> $ arm-poky-linux-gnueabi-gcc hello.c -o hello >> hello.c:1:19: fatal error: stdio.h: No such file or directory >> #include >>^ >> compilation terminated. > > If we hardcode the path to the sysroot into the compiler, we hit several > issues. Firstly, we rely on the relocation code within gcc to get this > relocated correctly at install time. That doesn't work for the way we > currently build the compilers so the default sysroot only works for the > default installation directory. Yes, that one is fixable with some > jumping through hoops. > > However if you don't want to set CFLAGS either, that implies we'd have > to code the flags into the compiler as well. > > So we'd build a compiler per target sysroot and per set of optimisation > flags for said target. That is grossly inefficient. I'll admit that is the model I had in mind. However, I can see that it does not scale well if you are addressing a range of targets as Yocto allows you to do. So it looks like it is time for me to update my modus operandi to match. However, I'll bet that I am not the only one caught out. > We've always had the environment file there and we've always set CFLAGS > this way, even in 1.7. If you used a non-default installation directory > in 1.7, it likely didn't work properly without passing the right flags > to gcc so you just go lucky even there. In 1.8, we poisoned the default > sysroot, so we could clearly identify any software which wasn't using > the CC and CFLAGS in ways we didn't expect. We did this to make our core > builds deterministic. We decided to do the same with the SDK. > > If you really object to having to configure the compiler, I'd suggest > creating some simple wrapper scripts which simply add in the sysroot and > possibly other compiler flag options you need. The main reason we > accepted doing the change to the defaults is that there is a > comparatively simple workaround available for those that feel as you > do. > > We could even have that code in the main repo, I've just felt so far > that letting people see whats going on is better than hiding it behind > more magic scripts. > No, I have no desire to write wrappers, I just wanted to clarify "the right way to do things". Thank you very much for explaining it. Chris. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] VFAT patent EP 0 618 540
Hi
On 10/10/15 17:58, Robert Berger wrote:
> Hi
>
> On 10/09/2015 11:20 PM, Ayoub Zaki wrote:
>> TI Socs Boot Rom code can use Vfat but does not necessarly need it as
>> Bootloaders (spl, u-boot) can be loaded directly from Raw MMC/eMMC.
> I just discovered this recently. Something like:
>
> sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 bs=128k
> sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1 bs=384k
>
> So even my made up scenario where you would need vfat on the first
> partition does not hold anymore.
Usually the need to include vfat support driven by the desire to
read/write removable media such as SD cards and USB mass storage
devices. If you want interoperability with certain legacy operating
systems vfat is the only option.
>
> ... but ...
>
> what about the patent and the on-chip ROMs of SoCs from Ti and Freescale
> (hmm NXP? or whoever bought them lately). Maybe the SoCs are affected
> since they are able to load stuff from vfat, even if we don't need to
> use this feature anymore.
Not a problem for two reasons. First the patent only applies to fat32;
you can do anything you like with fat16. The TI romcode only uses fat16,
I am pretty sure. Second, even with fat32, the patent is only concerned
with updates to the namespace, hence so long as the romcode does not
have the ability to create files it is also OK. Note that you can't get
round the patent just by mounting vfat partitions read-only because the
driver still has the ability to make new files. There was a patch for
the vfat driver which removed the code to create or modify directory
entries, but it seems to have got lost in the mists of time.
>
> Regards,
>
> Robert
>
> ..."Never express yourself more clearly than you think." - Niels Bohr
>
> My public pgp key is available,at:
> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x90320BF1
>
>
--
Chris Simmonds, Consultant, 2net Ltd
http://www.2net.co.uk
+44 (0)1962 869003
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] RFC: Yocto LTS?
Hi, Is there a statement about the period of support for a Yocto release? Looking through the updates, it seems that 12 months is typical, a was the case for 1.4, 1.5 and 1.6 for example, but I cannot see a declaration anywhere that this is the expected norm. Leading on from that, is 12 months enough? Most projects have a lifecycle that is much longer. Is there an argument for an LTS Yocto release, maybe once a year? If not, what is the recommended way for a project developer to keep a distribution up to date in the light of the several well-publicised security flaws that have been discovered over the last year or so and the new ones that will no doubt be discovered in the future? Regards, Chris Simmonds -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Yocto LTS?
Hi, On 14/10/15 14:50, akuster808 wrote: > Chris, > > > On 10/14/2015 06:28 AM, Chris Simmonds wrote: >> Hi, >> >> Is there a statement about the period of support for a Yocto release? >> Looking through the updates, it seems that 12 months is typical, a was >> the case for 1.4, 1.5 and 1.6 for example, but I cannot see a >> declaration anywhere that this is the expected norm. > > There is a release every 6 months. > > https://wiki.yoctoproject.org/wiki/FAQ#What_is_the_release_cycle_of_the_Yocto_Project.3F > >> >> Leading on from that, is 12 months enough? Most projects have a >> lifecycle that is much longer. Is there an argument for an LTS Yocto >> release, maybe once a year? If not, what is the recommended way for a >> project developer to keep a distribution up to date in the light of the >> several well-publicised security flaws that have been discovered over >> the last year or so and the new ones that will no doubt be discovered in >> the future? > > At table of the current supported release can be found at > https://wiki.yoctoproject.org/wiki/Stable_branch_maintenance > > - Armin > Thanks, Armin, that is the kind of thing I was looking for. It doesn't mention a timespan for updates, but there does seem to be an implicit maintenance period of 12 months after release. I am still worried that this is a rather short period of time, though, and encourages device manufacturers to avoid ever updating boxes in the field. >> >> Regards, >> Chris Simmonds >> > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Yocto LTS?
On 14/10/15 17:27, Mark Hatle wrote: > On 10/14/15 8:28 AM, Chris Simmonds wrote: >> Hi, >> >> Is there a statement about the period of support for a Yocto release? >> Looking through the updates, it seems that 12 months is typical, a was >> the case for 1.4, 1.5 and 1.6 for example, but I cannot see a >> declaration anywhere that this is the expected norm. >> >> Leading on from that, is 12 months enough? Most projects have a >> lifecycle that is much longer. Is there an argument for an LTS Yocto >> release, maybe once a year? If not, what is the recommended way for a >> project developer to keep a distribution up to date in the light of the >> several well-publicised security flaws that have been discovered over >> the last year or so and the new ones that will no doubt be discovered in >> the future? > > https://wiki.yoctoproject.org/wiki/FAQ#What_is_the_overall_support_plan_for_the_Yocto_Project.3F > > =What is the release cycle of the Yocto Project?= > Each release of the Yocto Project is subject to its own release schedule > according to the community-maintained Project Planning Guide. It is generally > expected that a new version of the Yocto Project will be released every six > months. > > =What is the overall support plan for the Yocto Project?= > Security patches and critical bug fixes are supplied one release back. No > toolchain or kernel changes are allowed for these updates. Support for longer > periods of time can be supplied by commercial OSVs. > > > > Effectively this means that support is on the last two releases. Releases are > typically released every 6 months. After that point it is usually supported > by > OSVs, or others that offer commercial services. In the past we have done a > few > very late security fixes past the 'last two releases' point, however that has > been for unique situations. > > You should consider keeping current with the Yocto Project releases or > consider > commercial support if you need more then an approx 12 - 18 month support > cycle. > > --Mark > Thanks, that is all clear now. Chris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] RFC: Yocto LTS?
On 15/10/15 16:49, Philip Balister wrote: > On 10/14/2015 12:26 PM, Chris Simmonds wrote: >> >> On 14/10/15 17:27, Mark Hatle wrote: >>> On 10/14/15 8:28 AM, Chris Simmonds wrote: >>>> Hi, >>>> >>>> Is there a statement about the period of support for a Yocto release? >>>> Looking through the updates, it seems that 12 months is typical, a was >>>> the case for 1.4, 1.5 and 1.6 for example, but I cannot see a >>>> declaration anywhere that this is the expected norm. >>>> >>>> Leading on from that, is 12 months enough? Most projects have a >>>> lifecycle that is much longer. Is there an argument for an LTS Yocto >>>> release, maybe once a year? If not, what is the recommended way for a >>>> project developer to keep a distribution up to date in the light of the >>>> several well-publicised security flaws that have been discovered over >>>> the last year or so and the new ones that will no doubt be discovered in >>>> the future? >>> >>> https://wiki.yoctoproject.org/wiki/FAQ#What_is_the_overall_support_plan_for_the_Yocto_Project.3F >>> >>> =What is the release cycle of the Yocto Project?= >>> Each release of the Yocto Project is subject to its own release schedule >>> according to the community-maintained Project Planning Guide. It is >>> generally >>> expected that a new version of the Yocto Project will be released every six >>> months. >>> >>> =What is the overall support plan for the Yocto Project?= >>> Security patches and critical bug fixes are supplied one release back. No >>> toolchain or kernel changes are allowed for these updates. Support for >>> longer >>> periods of time can be supplied by commercial OSVs. >>> >>> >>> >>> Effectively this means that support is on the last two releases. Releases >>> are >>> typically released every 6 months. After that point it is usually >>> supported by >>> OSVs, or others that offer commercial services. In the past we have done a >>> few >>> very late security fixes past the 'last two releases' point, however that >>> has >>> been for unique situations. >>> >>> You should consider keeping current with the Yocto Project releases or >>> consider >>> commercial support if you need more then an approx 12 - 18 month support >>> cycle. >>> >>> --Mark >>> >> >> Thanks, that is all clear now. > > We wouldn't be opposed to a group of people supporting a release for > longer. But they would need to provide the people to do the work. LTS > work is hard. > > Philip > >> >> Chris >> > Indeed, it is hard work. But there is a community out there with the expertise and many very profitable corporations that depend on Yocto Project (in addition to Intel, I mean, since they put a lot of resource in already). It would be really nice if someone neutral - Linux Foundation for example - could bring them together to make LTS work for everybody. Chris. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] is there a recipe for building a ppc-based installer image?
Robert, Have you looked at using existing updaters such as meta-swupdate or swupd or rauc? I'm sure one of those would do what you want. Rgds, Chris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Starting Hardware
Hi Alejandro, There are only a few platforms supported by Android Things, one of which is the Raspberry Pi, so that is the obvious choice. The RPi is well supported by Yocto Project/OpenEmbedded. You will need the meta-raspberrypi layer, which you can find, along with many other meta layers, at http://layers.openembedded.org. The specific one you need is at http://layers.openembedded.org/layerindex/branch/master/layer/meta-raspberrypi/ There are brief instructions on building it at https://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/about/ However, since you are just beginning on your journey with Yocto/OpenEmbedded, I would advise that you start by building the default qemux86 emulator target first, and then move on to building the RPi images. That way you get to learn about adding meta layers and meta layer dependencies after you have built your first Yocto Project image. Enjoy! Chris On 23/04/18 16:00, Alejandro Ariel Fachini wrote: > Hello: > I'm an electronic engineer from argentina and I started to work for a > company which is starting with embedded software. I also want to work > for my self with this technology. I am about certificate android > programing in google and want to start with android things and also > embedded linux. > For these reasons i want to purchase hardware that allows me to test > both environments or at least proper hardware for both Android things > and Linux. > > So If i purchase Raspberry Pi 3 B+, will i be able to work with Yocto? > OR do you recommend another more supported and "fiendly" Hardware for > starting with yocto? I understand that yocto is for A TON of different > hardwares, but im looking for very active and supported hardware with yocto. > > Regards Alejandro.- > > -- Chris Simmonds, Consultant, 2net Ltd http://www.2net.co.uk +44 (0)1962 869003 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto on OnBoard Intel Galileo Flash
Hi Nick, The Galileo board has 8 MiB of NOR flash connected via SPI. That is not enough for any meaningful embedded Linux image created by Yocto Project. Even if you were to build an image less than 8 MiB, it still wouldn't help because the Galileo needs that memory for the UEFI boot loader. There is a very good write up of the way the Quark chip boots here: "Anatomy of the UEFI Boot Sequence on the Intel Galileo" http://blog.hansenpartnership.com/anatomy-of-the-uefi-boot-sequence-on-the-intel-galileo/ And there is a guide on how to write a new UEFI loader to the SPI flash here: "Programming SPI Flash with UEFI Internal Shell for Intel® Galileo Boards" http://www.intel.co.uk/content/www/uk/en/support/boards-and-kits/intel-galileo-boards/06212.html Cheers, Chris On 30/03/2019 22:33, nick wrote: > Greetings All, > > What is the best way to put a image on the 8mb of Yocto onboard flash or is > this not possible with the Yocto Project. > > Nick > -- Chris Simmonds, trainer and consultant at 2net http://www.2net.co.uk Author of "Mastering Embedded Linux Programming" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Displaying buildcfg
Hi, At the start of a bitbake run it displays the current build configuration before it starts to build anything: Build Configuration: BB_VERSION= "1.28.0" BUILD_SYS = "x86_64-linux" [...] This information is useful, especially when you are swapping between multiple projects with different versions. Is there a simple way to get bitbake to print just this information, without going on to do build anything? Regards, Chris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Displaying buildcfg
Hi, On 18/11/17 14:41, cddatemp wrote: > At 2017-11-18 20:45:11, "Chris Simmonds" wrote: >>Hi, >> >>At the start of a bitbake run it displays the current build >>configuration before it starts to build anything: >> >>Build Configuration: >>BB_VERSION= "1.28.0" >>BUILD_SYS = "x86_64-linux" >>[...] >> >>This information is useful, especially when you are swapping between >>multiple projects with different versions. Is there a simple way to get >>bitbake to print just this information, without going on to do build >>anything? > > Try this: > $ bitbake -n base-files > >> >>Regards, >>Chris >>-- Thanks, Thanks, that works. I can't help feeling that there should be a more direct way of dumping the buildcfg though. Anyone have an insight on this? Chris -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] recipe to clean up files from rootfs
Hi Sherif,
Maybe this is a little late, but as been said already, the best solution
is to remove psplash from your image altogether. You can to this quite
simply by adding to your conf/local.conf
IMAGE_FEATURES_remove = "splash"
Rationale: the dependency on the psplash program is (usually) set in the
image recipe. For example, in
meta/recipes-core/images/core-image-base.bb, you see
IMAGE_FEATURES += "splash"
The image class (meta/classes/image.bbclass) matches the list of
features in IMAGE_FEATURES with package names in FEATURE_PACKAGES_*. So,
in meta/classes/image.bbclass, you find
SPLASH ?= "psplash"
FEATURE_PACKAGES_splash = "${SPLASH}"
This causes "psplash" to be added to the image if IMAGE_FEATURES
contains the string "splash".
By using IMAGE_FEATURES_remove, you remove the string "splash" from the
list of features and so psplash will not be included in your image.
HTH,
Chris Simmonds.
On 14/12/17 08:14, Sherif Omran wrote:
> hi Andre
> thank you for your mail. I tried to remove this package but i don't know
> where it is installed from, i can not find it and got lost.
>
> On Thu, Dec 14, 2017 at 9:11 AM, Sherif Omran <mailto:sherifomran2...@gmail.com>> wrote:
>
> hi Martin,
>
> thank you for help .. well done .. it should now work..
>
> On Thu, Dec 14, 2017 at 8:17 AM, Martin Hundebøll
> mailto:martin.hundeb...@prevas.dk>> wrote:
>
> Hi Sherif,
>
> On 2017-12-14 08:06, Sherif Omran wrote:
>
> Here is my recipe, it runs suceeds but does not delete the files
>
> mypostprocesfunction() {
> rm -r ${IMAGE_ROOTFS}/etc/init.d/psplash.sh
> rm -r ${IMAGE_ROOTFS}/usr/bin/psplash*
> }
>
> ROOTFS_POSTPROCESS_COMMAND += "mypostprocessfunction; "
>
>
> Unless you did a copy-paste error, there's a typo in the
> function name:
> mypostprocesfunction
> mypostprocessfunction
>
> // Martin
>
>
> On Wed, Dec 13, 2017 at 2:03 PM, Mike Looijmans
> mailto:mike.looijm...@topic.nl>
> <mailto:mike.looijm...@topic.nl
> <mailto:mike.looijm...@topic.nl>>> wrote:
>
> ${D} won't work here, grep on ROOTFS_POSTPROCESS_COMMAND
> for recipes
> that get it right.
>
> And, much much much better would be to just not install
> psplash into
> your image!
>
> On 13-12-17 09:10, Sherif Omran wrote:
>
> here is my recipe, the aim was to remove some files
> from the
> init.d folder and tweek before creating the image
>
> #
> # This file was derived from the 'Hello World!'
> example recipe
> in the
> # Yocto Project Development Manual.
> #
>
> SUMMARY = "This recipe removes any missing files
> from the
> filesystem before finalinzing it"
> SECTION = "base"
> LICENSE = "MIT"
> LIC_FILES_CHKSUM =
>
>
> "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>
> #SRC_URI = "file://*"
>
> S = "${WORKDIR}"
> BB_STRICT_CHECKSUM ="0"
> ALLOW_EMPTY_${PN}="1"
>
>
> #IMAGE_INSTALL = "packagegroup-core-boot
> packagegroup-base-extended ${CORE_IMAGE_EXTRA_INSTALL}"
> #IMAGE_INSTALL = "${CORE_IMAGE}"
>
> #inherit core-image
>
> my_postprocess_function() {
> rm -r ${D}${bindir}/init.d/psplash.sh
> }
>
> ROOTFS_POSTPROCESS_COMMAND +=
> "my_postprocess_function; "
>
> On Wed, Dec 13, 2017 at 7:22 AM, Mike Looijmans
> <mailto:mike.looijm...@topic.nl>
> <mailto:mike.looijm...@topic.nl
> <mailto:mike.looijm...@topic.nl>>
> <mailto:mike.looijm...@topic.nl
> <mailto:mike.looijm...@topic.nl>
> <mailto:mike.looijm...@topic.nl
> <mailto:mike.looijm...
Re: [yocto] How to build pure initramfs run from ram Yocto with some packages in initramfs?
Hi Andrew, On 30/12/17 20:25, Andrew Stuart wrote: [snip] > > # set the machine type in local.conf > vi /home/ubuntu/poky-rocko-18.0.0/build/conf/local.conf > MACHINE = "qemux86-64" > > # for blank root password in ssh, in local.conf: > vi /home/ubuntu/poky-rocko-18.0.0/build/conf/local.conf > EXTRA_IMAGE_FEATURES = "debug-tweaks" > > #for kernel to run on EC2, in local.conf: > vi /home/ubuntu/poky-rocko-18.0.0/build/conf/local.conf > DISTRO_FEATURES_append=" xen" > > #for ability to boot on cloud servers: > vi /home/ubuntu/poky-rocko-18.0.0/build/conf/local.conf > DISTRO_FEATURES_append = " virtualization" > > #for openssh server, in local.conf: > vi /home/ubuntu/poky-rocko-18.0.0/build/conf/local.conf > CORE_IMAGE_EXTRA_INSTALL += "openssh" > IMAGE_INSTALL_append = " openssh" > > #for ISC dhclient , in local.conf: > vi /home/ubuntu/poky-rocko-18.0.0/build/conf/local.conf > CORE_IMAGE_EXTRA_INSTALL += "dhcp-client" > IMAGE_INSTALL_append = " dhcp-client" > [snip] For initramfs images, you should use PACKAGE_INSTALL in place of your CORE_IMAGE_EXTRA_INSTALL and IMAGE_INSTALL lines: PACKAGE_INSTALL_append = " openssh dhcp-client" (see "Building an Initial RAM Filesystem (initramfs) Image" of the "The Yocto Project Development Tasks Manual": http://www.yoctoproject.org/docs/2.4/dev-manual/dev-manual.html#building-an-initramfs-image) -- Chris Simmonds, Consultant, 2net Ltd http://www.2net.co.uk +44 (0)1962 869003 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Linux-kernel selection
Hi, You don't need the '\'. Try this: PREFERRED_VERSION_linux-ti-staging = "3.14%" HTH, Chris On 05/03/17 18:03, SatyaNarayana Sampangi wrote: > Hi, > > How to select the preferred kernel in yocto, > > I did in local.conf as of now, > > PREFERRED_PROVIDER_virtual/kernel = "linux-ti-staging" > PREFERRED_VERSION_linux-ti-staging = "3.14\%" > > I am using krogoth with meta-ti layer > > > bitbake core-image-minimal > Parsing recipes: 100% > |##| > Time: 00:00:26 > Parsing of 1032 .bb files complete (0 cached, 1032 parsed). 1470 > targets, 71 skipped, 0 masked, 0 errors. > NOTE: Resolving any missing task queue dependencies > NOTE: preferred version 3.14\% of linux-ti-staging not available (for > item virtual/kernel) > NOTE: versions of linux-ti-staging available: > 3.14.49+gitAUTOINC+e9cd4cc819 4.1.18+gitAUTOINC+6b41ca0b94 > 4.4.41+gitAUTOINC+7c580a51af > NOTE: preferred version 3.14\% of linux-ti-staging not available (for > item kernel-base) > NOTE: versions of linux-ti-staging available: > 3.14.49+gitAUTOINC+e9cd4cc819 4.1.18+gitAUTOINC+6b41ca0b94 > 4.4.41+gitAUTOINC+7c580a51af > NOTE: preferred version 3.14\% of linux-ti-staging not available (for > item kernel-image) > NOTE: versions of linux-ti-staging available: > 3.14.49+gitAUTOINC+e9cd4cc819 4.1.18+gitAUTOINC+6b41ca0b94 > 4.4.41+gitAUTOINC+7c580a51af > NOTE: preferred version 3.14\% of linux-ti-staging not available (for > item kernel-devicetree) > NOTE: versions of linux-ti-staging available: > 3.14.49+gitAUTOINC+e9cd4cc819 4.1.18+gitAUTOINC+6b41ca0b94 > 4.4.41+gitAUTOINC+7c580a51af > > > But I am getting the error like this, ho wto rectify. > > -- Chris Simmonds, Consultant, 2net Ltd http://www.2net.co.uk +44 (0)1962 869003 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Intel Galleio Board SSH Minimal Poky Image
Hi Nick, On 16/04/2019 16:36, nick wrote: > Greetings, > > What is the minimal image from the poky yocto recipes that has ssh enabled by > default or is it just better to enable it in the core minimal image on system > startup. core-image-minimal plus dropbear (ssh daemon) comes to 16 MB when installed (BeagleBone Black). This is just the rootfs. Add another 6 to 10 MB for bootloader and kernel. > > Thanks, > > Nick > Cheers, Chris -- Chris Simmonds, trainer and consultant at 2net http://www.2net.co.uk Author of "Mastering Embedded Linux Programming" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Building Out-of-Tree Modules on the BBB Target
Hi Zoran, There are two ways to do this 1. Build using a bb recipe. Take a look at meta-skeleton/recipes-kernel/hello-mod for an example. You just need to add meta-skeleton to your bblaysers.conf and then bitbake hello-mod 2. Build from the SDK: First, add the kernel source to the SDK by adding this to conf/local/conf TOOLCHAIN_TARGET_TASK_append = " kernel-devsrc" Then build the SDK bitbake -c populate_sdk [your image recipe] Once the SDK is installed, generate the kernel headers: sudo -i . /opt/poky/2.6.2/environment-setup-cortexa8hf-neon-poky-linux-gnueabi cd /opt/poky/2.6.2/sysroots/cortexa8hf-neon-poky-linux-gnueabi cd /usr/src/kernel make oldconfig scripts exit Finally, build your module using a Makefile like this obj-m := hello-mod.o all: make -C $(SDKTARGETSYSROOT)/usr/src/kernel M=$(shell pwd) HTH, Chris On 12/05/2019 11:53, Zoran Stojsavljevic wrote: > Hello to the YOCTO community, > > I am using (to build the target for Beagle Bone Black) the following script: > https://github.com/ZoranStojsavljevic/bbb-yocto > https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/bbb-yocto.sh > > The latest kernel I am using from the following repo: > https://github.com/jumpnow/meta-bbb > > Is kernel 5.0.14 . > > Here is the snippet of the boot traces: > Starting kernel ... > > [0.00] Booting Linux on physical CPU 0x0 > [0.00] Linux version 5.0.14-jumpnow (oe-user@oe-host) (gcc > version 8.3.0 (GCC)) #1 Fri May 10 13:12:33 UTC 2019 > [0.00] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=10c5387d > [0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing > instruction cache > [0.00] OF: fdt: Machine model: TI AM335x BeagleBone Black > [0.00] Memory policy: Data cache writeback > [0.00] cma: Reserved 16 MiB at 0x9f00 > [0.00] CPU: All CPU(s) started in SVC mode. > [0.00] AM335X ES2.1 (sgx neon) > [0.00] random: get_random_bytes called from > start_kernel+0xa4/0x460 with crng_init=0 > [0.00] Built 1 zonelists, mobility grouping on. Total pages: 130048 > [0.00] Kernel command line: console=ttyO0,115200n8 > root=/dev/ram0 ip=dhcp > > According to the documentation, the following: > 2.10.1. Building Out-of-Tree Modules on the Target > https://www.yoctoproject.org/docs/latest/kernel-dev/kernel-dev.html > > I tried to find /usr/src/kernels/5.0.14... Directory, since I see > from the build that kernel-dev and kernel-devsrc are included: > [user@fedora29-ssd bbb-yocto]$ bitbake -s | grep kernel > core-image-kernel-dev :1.0-r0 > kernel-devsrc :1.0-r0 > kernel-selftest :1.0-r0 > > THE PROBLEM: But I could not find ob BBB target /usr/src/kernels > directory at all!? > > Two questions here? > [1] Do you have any advice on this problem (what I am missing here)? > [2] Alternative to [1]: how I can use cross compiler from > .../build/tmp to build Out-of-Tree Module for the BBB target on the > host? > > Thank you, > Zoran > ___ > -- Chris Simmonds, trainer and consultant at 2net http://www.2net.co.uk Author of "Mastering Embedded Linux Programming" -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
