Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
> On Nov 4, 2019, at 4:26 PM, Steve Pavao wrote:
>
>> On Nov 4, 2019, at 11:32 AM, Steve Pavao wrote:
>>>
>>> On Nov 4, 2019, at 11:16 AM, Steve Pavao wrote:
>>>>
>>>> On Nov 4, 2019, at 11:11 AM, Adrian Bunk wrote:
>>>>
>>>> On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:
>>>>>
>>>>>> On Nov 3, 2019, at 1:25 PM, Adrian Bunk wrote:
>>>>>>
>>>>>> On Sun, Nov 03, 2019 at 05:56:45PM +, Andrei Gherzan wrote:
>>>>>>> On 3 November 2019 13:18:53 GMT, Khem Raj wrote:
>>>>>>>> On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan
>>>>>>>> wrote:
>>>>>>>>> I was thinking about this. The erratum seems to show that this
>>>>>>>> applies
>>>>>>>>> to all revisions of a53. So it sounds like we should add it in
>>>>>>>>> `tune-cortexa53.inc`.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Up to r0b4 only so maybe not all a53 implementations are impacted
>>>>>>>>
>>>>>>>
>>>>>>> As far as I know that is the latest revision. Do you mean that newer
>>>>>>> revision might come up with this fixed?
>>>>>>
>>>>>> It is fixed in some r0p4 implementations, indicated in REVIDR[8].
>>>>>
>>>>> I am closer to understanding why I experience an error when building with
>>>>> the ARM errata switches.
>>>>>
>>>>> I believe it is related to 32-bit app support in my poky Linux 64-bit
>>>>> build (I add this to support vcgencmd and vcdbg 32-bit apps.)
>>>>>
>>>>> When I remove the 32-bit support, the build completes OK. As of now,
>>>>> adding the following seems to work fine to acheive this:
>>>>>
>>>>> TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419
>>>>> -mfix-cortex-a53-835769”
>>>>>
>>>>> Something in the following block seems to be the culprit.:
>>>>>
>>>>> # for vcgencmd and vcdbg 32-bit executable support in the OS image
>>>>> (comment out for -c populate_sdk)
>>>>> require conf/multilib.conf
>>>>> MULTILIBS = "multilib:lib32"
>>>>> DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
>>>>> IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc
>>>>> lib32-libstdc++ vcdbg rpi-setup \
>>>>> “
>>>>>
>>>>> I will post again when I have localized the build problem further. Maybe
>>>>> there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a
>>>>> default tune switch for 32-bits is colliding with the errata switches.
>>>>
>>>> The errata switches are only valid for aarch64, not for armv7a.
>>>> There is likely some kind of "invalid option" earlier in your build.
>>>
>>> To conitnue to be able to use the 32-bit app support, perhaps I must do
>>> this:
>>>
>>> DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419
>>> -mno-fix-cortex-a53-835769”
>>
>> This doesn’t work.
>>
>> If I wish to keep the 32-bit app support in my build, I’ll need to devise a
>> way to make sure those ARM errata flags are only applied to the aarch64
>> portion of the compile/link for the target, not to the multilib 32-bit app
>> support portion.
>
> Andrei and/or Khem,
>
> Could you advise an approach that allows to use the ARM errata switches for
> the aarch64 portion of the build for the target, but which will NOT specify
> the ARM errata switches for our supplementary 32-bit portion of the build for
> the target? (This supplementary 32-bit portion of the build is to support
> the 32-bit vcgencmd app, and contains multilib and some additional 32-bit
> libraires. Please see earlier post for the syntax we use in our local.conf.)
I've been able to rebuild 64-bit Linux code with the ARM errata switches, by
adding the following line to the end of
/meta/conf/machine/include/arm/arch-arm64.inc,
TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "aarch64", "
-mfix-cortex-a53-843419 -mfix-cortex-a53-835769", "" ,d)}”
Please let me know if you have any thoughts about this approach.
Steve Pavao
Korg R
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
> On Nov 4, 2019, at 11:32 AM, Steve Pavao wrote: > >> >> On Nov 4, 2019, at 11:16 AM, Steve Pavao > <mailto:ste...@korgrd.com>> wrote: >> >>> >>> On Nov 4, 2019, at 11:11 AM, Adrian Bunk >> <mailto:b...@stusta.de>> wrote: >>> >>> On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote: >>>> >>>>> On Nov 3, 2019, at 1:25 PM, Adrian Bunk >>>> <mailto:b...@stusta.de>> wrote: >>>>> >>>>> On Sun, Nov 03, 2019 at 05:56:45PM +, Andrei Gherzan wrote: >>>>>> On 3 November 2019 13:18:53 GMT, Khem Raj >>>>> <mailto:raj.k...@gmail.com>> wrote: >>>>>>> On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan >>>>>> <mailto:and...@gherzan.ro>> >>>>>>> wrote: >>>>>>>> I was thinking about this. The erratum seems to show that this >>>>>>> applies >>>>>>>> to all revisions of a53. So it sounds like we should add it in >>>>>>>> `tune-cortexa53.inc`. >>>>>>>> >>>>>>> >>>>>>> Up to r0b4 only so maybe not all a53 implementations are impacted >>>>>>> >>>>>> >>>>>> As far as I know that is the latest revision. Do you mean that newer >>>>>> revision might come up with this fixed? >>>>> >>>>> It is fixed in some r0p4 implementations, indicated in REVIDR[8]. >>>> >>>> I am closer to understanding why I experience an error when building with >>>> the ARM errata switches. >>>> >>>> I believe it is related to 32-bit app support in my poky Linux 64-bit >>>> build (I add this to support vcgencmd and vcdbg 32-bit apps.) >>>> >>>> When I remove the 32-bit support, the build completes OK. As of now, >>>> adding the following seems to work fine to acheive this: >>>> >>>> TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769” >>>> >>>> Something in the following block seems to be the culprit.: >>>> >>>> # for vcgencmd and vcdbg 32-bit executable support in the OS image >>>> (comment out for -c populate_sdk) >>>> require conf/multilib.conf >>>> MULTILIBS = "multilib:lib32" >>>> DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a" >>>> IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc >>>> lib32-libstdc++ vcdbg rpi-setup \ >>>> “ >>>> >>>> I will post again when I have localized the build problem further. Maybe >>>> there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a >>>> default tune switch for 32-bits is colliding with the errata switches. >>> >>> The errata switches are only valid for aarch64, not for armv7a. >>> There is likely some kind of "invalid option" earlier in your build. >> >> To conitnue to be able to use the 32-bit app support, perhaps I must do this: >> >> DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 >> -mno-fix-cortex-a53-835769” > > This doesn’t work. > > If I wish to keep the 32-bit app support in my build, I’ll need to devise a > way to make sure those ARM errata flags are only applied to the aarch64 > portion of the compile/link for the target, not to the multilib 32-bit app > support portion. Andrei and/or Khem, Could you advise an approach that allows to use the ARM errata switches for the aarch64 portion of the build for the target, but which will NOT specify the ARM errata switches for our supplementary 32-bit portion of the build for the target? (This supplementary 32-bit portion of the build is to support the 32-bit vcgencmd app, and contains multilib and some additional 32-bit libraires. Please see earlier post for the syntax we use in our local.conf.) Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
> On Nov 4, 2019, at 11:16 AM, Steve Pavao wrote: > >> >> On Nov 4, 2019, at 11:11 AM, Adrian Bunk > <mailto:b...@stusta.de>> wrote: >> >> On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote: >>> >>>> On Nov 3, 2019, at 1:25 PM, Adrian Bunk >>> <mailto:b...@stusta.de>> wrote: >>>> >>>> On Sun, Nov 03, 2019 at 05:56:45PM +, Andrei Gherzan wrote: >>>>> On 3 November 2019 13:18:53 GMT, Khem Raj >>>> <mailto:raj.k...@gmail.com>> wrote: >>>>>> On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan >>>>> <mailto:and...@gherzan.ro>> >>>>>> wrote: >>>>>>> I was thinking about this. The erratum seems to show that this >>>>>> applies >>>>>>> to all revisions of a53. So it sounds like we should add it in >>>>>>> `tune-cortexa53.inc`. >>>>>>> >>>>>> >>>>>> Up to r0b4 only so maybe not all a53 implementations are impacted >>>>>> >>>>> >>>>> As far as I know that is the latest revision. Do you mean that newer >>>>> revision might come up with this fixed? >>>> >>>> It is fixed in some r0p4 implementations, indicated in REVIDR[8]. >>> >>> I am closer to understanding why I experience an error when building with >>> the ARM errata switches. >>> >>> I believe it is related to 32-bit app support in my poky Linux 64-bit build >>> (I add this to support vcgencmd and vcdbg 32-bit apps.) >>> >>> When I remove the 32-bit support, the build completes OK. As of now, >>> adding the following seems to work fine to acheive this: >>> >>> TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769” >>> >>> Something in the following block seems to be the culprit.: >>> >>> # for vcgencmd and vcdbg 32-bit executable support in the OS image (comment >>> out for -c populate_sdk) >>> require conf/multilib.conf >>> MULTILIBS = "multilib:lib32" >>> DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a" >>> IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ >>> vcdbg rpi-setup \ >>> “ >>> >>> I will post again when I have localized the build problem further. Maybe >>> there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a >>> default tune switch for 32-bits is colliding with the errata switches. >> >> The errata switches are only valid for aarch64, not for armv7a. >> There is likely some kind of "invalid option" earlier in your build. > > To conitnue to be able to use the 32-bit app support, perhaps I must do this: > > DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 > -mno-fix-cortex-a53-835769” This doesn’t work. If I wish to keep the 32-bit app support in my build, I’ll need to devise a way to make sure those ARM errata flags are only applied to the aarch64 portion of the compile/link for the target, not to the multilib 32-bit app support portion. Thanks to all of you for your thoughts so far. Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
> On Nov 4, 2019, at 11:11 AM, Adrian Bunk wrote: > > On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote: >> >>> On Nov 3, 2019, at 1:25 PM, Adrian Bunk wrote: >>> >>> On Sun, Nov 03, 2019 at 05:56:45PM +, Andrei Gherzan wrote: >>>> On 3 November 2019 13:18:53 GMT, Khem Raj wrote: >>>>> On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan >>>>> wrote: >>>>>> I was thinking about this. The erratum seems to show that this >>>>> applies >>>>>> to all revisions of a53. So it sounds like we should add it in >>>>>> `tune-cortexa53.inc`. >>>>>> >>>>> >>>>> Up to r0b4 only so maybe not all a53 implementations are impacted >>>>> >>>> >>>> As far as I know that is the latest revision. Do you mean that newer >>>> revision might come up with this fixed? >>> >>> It is fixed in some r0p4 implementations, indicated in REVIDR[8]. >> >> I am closer to understanding why I experience an error when building with >> the ARM errata switches. >> >> I believe it is related to 32-bit app support in my poky Linux 64-bit build >> (I add this to support vcgencmd and vcdbg 32-bit apps.) >> >> When I remove the 32-bit support, the build completes OK. As of now, adding >> the following seems to work fine to acheive this: >> >> TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769” >> >> Something in the following block seems to be the culprit.: >> >> # for vcgencmd and vcdbg 32-bit executable support in the OS image (comment >> out for -c populate_sdk) >> require conf/multilib.conf >> MULTILIBS = "multilib:lib32" >> DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a" >> IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ >> vcdbg rpi-setup \ >> “ >> >> I will post again when I have localized the build problem further. Maybe >> there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a >> default tune switch for 32-bits is colliding with the errata switches. > > The errata switches are only valid for aarch64, not for armv7a. > There is likely some kind of "invalid option" earlier in your build. To conitnue to be able to use the 32-bit app support, perhaps I must do this: DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769” I’ll give it a try. - Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
> On Nov 3, 2019, at 1:25 PM, Adrian Bunk wrote: > > On Sun, Nov 03, 2019 at 05:56:45PM +, Andrei Gherzan wrote: >> On 3 November 2019 13:18:53 GMT, Khem Raj wrote: >>> On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan >>> wrote: >>>> I was thinking about this. The erratum seems to show that this >>> applies >>>> to all revisions of a53. So it sounds like we should add it in >>>> `tune-cortexa53.inc`. >>>> >>> >>> Up to r0b4 only so maybe not all a53 implementations are impacted >>> >> >> As far as I know that is the latest revision. Do you mean that newer >> revision might come up with this fixed? > > It is fixed in some r0p4 implementations, indicated in REVIDR[8]. > I am closer to understanding why I experience an error when building with the ARM errata switches. I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.) When I remove the 32-bit support, the build completes OK. As of now, adding the following seems to work fine to acheive this: TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769” Something in the following block seems to be the culprit.: # for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk) require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a" IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \ “ I will post again when I have localized the build problem further. Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches. - Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified
poky linux build fails when ARM erratum mfix linker switch is specified in local.conf: TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419” causes build failure. Please advise how to use this switch successfully. I am synced current in master branch in all layers as of today. The switch causes libtool link to fail due to missing libbz2.so. If I don’t specify the switch, the build completes without errors. It is important to be able to build poky linux with this switch to avoid certain crash conditions as described in the ARM errata document. Steve Pavao Korg R-- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] issue booting image containing alternate kernel
Hello, Sometimes, I need to build an image containing the raspberrypi / linux kernel as specified by the meta-raspberrypi layer recipes. Other times, I need to build an image containing the ipipe-arm64 kernel instead. This alternate kernel builds fine outside of Yocto and boots, so it should also build fine from within Yocto and boot, too. I have a recipe to build this alternate kernel, and it works fine. I simply tweaked the machine’s metadata for the device tree handling differences, and then specify PREFERRED_PROVIDER_virtual_kernel in local.conf. The build completes just fine. Easy peasy. The problem occurs when I try to boot this alternate system. (BTW, for this alternate build, I am using kernel=u-boot.bin with a boot.scr that specifies the proper dtb and has the same bootargs as my cmdline.txt) During the boot process, after many messages are output to the console, the following message is displayed, and the boot appears delayed/hung: [3.270764] random: crng init done After that time, the USB devices (keyboard and mouse) will regulary disconnect/reconnect after some number of minutes pass. The boot never finishes. Does anyone have any ideas what I can do in my Yocto configuration so I can rebake and not experience this problem? Booting my system with the regular raspberrypi /linux kernel completes OK and finishes with an X11 terminal on the HDMI. - Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] core-image-minimal for raspberrypi3-64 manifest/sdimg contains no kernel modules
Hello, > On Aug 15, 2018, at 4:27 PM, Khem Raj wrote: > > On Wed, Aug 15, 2018 at 1:25 PM Steve Pavao wrote: >> I would like to state my opinion though that to unconditionally warn the >> user to use core-image-minimal instead of rpi-hwup-image (which definitely >> packages kernel modules if they are there) is not often the best advice to >> give. > > This should be fixed in meta-raspberrypi, care to submit a patch > to use core-image-base instead ? Sure, I’ll submit a patch. Should it unconditionally recommend core-image-base, or should it still recommend core-image-minimal if the kernel modules list is empty? (Could that condition possibly happen if the user cleared it in local.conf?) Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] core-image-minimal for raspberrypi3-64 manifest/sdimg contains no kernel modules
Hello, > On Aug 15, 2018, at 11:54 AM, Khem Raj wrote: > > On Tue, Aug 14, 2018 at 11:48 PM Steve Pavao <mailto:ste...@korgrd.com>> wrote: >> >> There seems to be a problem with the core-image-minimal bitbake for >> raspberrypi3-64 target at head of sumo in all repos. I wonder if it’s also >> a problem for the raspberrypi3 target. >> >> No kernel modules appear in the .manifest, and no kernel modules are put >> into the sdimg. It’s hard to believe it’s true, but that’s what I'm seeing. > > please build core-image-base and see if that helps Khem - that does help. It also provides some other packages that aren’t in the deprecated rpi-hwup-image, but that doesn’t seem to hurt. Max - thanks for the explanation about adding that package to the image as a possible solution. In this case, I’m trying to avoid multiple manual steps and just use a single bitbake target to acheive the build I need, though. Andre - I have since read about core-image-minimal since receiving the warning message that "rpi-hwup-image is deprecated - use core-image-minimal instead” and having problems due to the missing modules. You are technically correct. I would like to state my opinion though that to unconditionally warn the user to use core-image-minimal instead of rpi-hwup-image (which definitely packages kernel modules if they are there) is not often the best advice to give. Thanks to you all for the useful replies. Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] custom linux kernel recipe fails
On Jul 26, 2018, at 12:56 PM, Steve Pavao wrote: > > I’m trying to build using a custom 64-bit kernel at head of sumo, but I get > an error. It seems that SRCPV cannot be resolved.Please send any ideas > you may have about how I may adapt my recipe to get it to work. [snip portion of recipe] > SRC_URI = > "http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1 > > <http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1>" > SRCREV = "133bbf97672ff6e72fc21784b8ae44b194b76626" I was able to avoid the error by using the following line for the SRC_URI instead: SRC_URI = "git://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http ” - Steve -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] custom linux kernel recipe fails
> On Jul 26, 2018, at 9:57 PM, ChenQi wrote:
>
> On 07/27/2018 12:56 AM, Steve Pavao wrote:
>> Hello -
>>
>> I’m trying to build using a custom 64-bit kernel at head of sumo, but I get
>> an error. It seems that SRCPV cannot be resolved.Please send any ideas
>> you may have about how I may adapt my recipe to get it to work.
>>
>> Normally, I use the default meta-raspberrypi kernel, but for this build, I
>> am using PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom” in my
>> local.conf
>>
>> My simple kernel recipe is in linux-yocto-custom.bb. (It is based on the
>> example recipe).
>>
>> inherit kernel
>> require recipes-kernel/linux/linux-yocto.inc
>>
>> PV = "${LINUX_VERSION}+git${SRCPV}"
>> PR = "r0"
>>
>> LINUX_VERSION ?= "4.14.4"
>> LINUX_VERSION_EXTENSION_append = "-xenomai-ipipe-arm64"
>>
>> SRC_URI =
>> "http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1;
>>
>> <http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1>
>> SRCREV = "133bbf97672ff6e72fc21784b8ae44b194b76626"
>
> Try:
> SRC_URI =
> "http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1;name=machine;
>
> <http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1>
> SRCREV_machine = "133bbf97672ff6e72fc21784b8ae44b194b76626"
> Best Regards,
> Chen Qi
Thanks for the idea, Chean Qui. I tried it, but I still got the same WARNINGS
and ERROR.
- Steve
>
>> SRC_URI[md5sum] = "a5cb3babd85a94fda2905cc3db5e7825"
>>
>> COMPATIBLE_MACHINE = "raspberrypi3-64"
>>
>> the error:
>>
>> WARNING:
>> /data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb:
>> Exception during build_dependencies for PKG_kernel-base
>> WARNING:
>> /data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb:
>> Error during finalise of
>> /data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb
>> ERROR: ExpansionError during parsing
>> /data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb
>> Traceback (most recent call last):
>> bb.data_smart.ExpansionError: Failure expanding variable PKG_kernel-base,
>> expression was
>> kernel-${@legitimize_package_name('${@get_kernelversion_headers('/data/development/lfs/yocto/build/spark/raspberrypi3-64/tmp/work/raspberrypi3_64-poky-linux/linux-yocto-custom/4.14.4+git${SRCPV}-r0/linux-raspberrypi3_64-standard-build')}')}
>> which triggered exception SyntaxError: invalid syntax (PKG_kernel-base,
>> line 1)
>>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] custom linux kernel recipe fails
Hello -
I’m trying to build using a custom 64-bit kernel at head of sumo, but I get an
error. It seems that SRCPV cannot be resolved.Please send any ideas you
may have about how I may adapt my recipe to get it to work.
Normally, I use the default meta-raspberrypi kernel, but for this build, I am
using PREFERRED_PROVIDER_virtual/kernel = "linux-yocto-custom” in my local.conf
My simple kernel recipe is in linux-yocto-custom.bb. (It is based on the
example recipe).
inherit kernel
require recipes-kernel/linux/linux-yocto.inc
PV = "${LINUX_VERSION}+git${SRCPV}"
PR = "r0"
LINUX_VERSION ?= "4.14.4"
LINUX_VERSION_EXTENSION_append = "-xenomai-ipipe-arm64"
SRC_URI =
"http://gitlab.denx.de/Xenomai/ipipe-arm64;protocol=http;branch=master;nocheckout=1;
SRCREV = "133bbf97672ff6e72fc21784b8ae44b194b76626"
SRC_URI[md5sum] = "a5cb3babd85a94fda2905cc3db5e7825"
COMPATIBLE_MACHINE = "raspberrypi3-64"
the error:
WARNING:
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb:
Exception during build_dependencies for PKG_kernel-base
WARNING:
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb:
Error during finalise of
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb
ERROR: ExpansionError during parsing
/data/development/lfs/yocto/poky/meta-korg-spark/recipes-kernel/linux/linux-yocto-custom.bb
Traceback (most recent call last):
bb.data_smart.ExpansionError: Failure expanding variable PKG_kernel-base,
expression was
kernel-${@legitimize_package_name('${@get_kernelversion_headers('/data/development/lfs/yocto/build/spark/raspberrypi3-64/tmp/work/raspberrypi3_64-poky-linux/linux-yocto-custom/4.14.4+git${SRCPV}-r0/linux-raspberrypi3_64-standard-build')}')}
which triggered exception SyntaxError: invalid syntax (PKG_kernel-base, line 1)
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] dtb mising from raspberrypi3-64.conf
Would you please add the bcm2710-rpi-cm3.dtb to the KERNEL_DEVICETREE listing in raspberrypi3-64.conf in sumo branch? It’s missing. - Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] raspberrypi3 at head of sumo has broken console
I just built raspberrypi3 at head of sumo. The attached keyboard and mouse don’t work in the console, although a window and the prompt is displayed. The mouse and keyboard work fine when booting Raspbian or other raspberrypi3 images I’ve built in other branches in the past. Build info below: parallels@ubuntu:/data/development/lfs/yocto/build/spark/raspberrypi3$ bitbake core-image-minimal Parsing recipes: 100% |##| Time: 0:01:15 Parsing of 1935 .bb files complete (0 cached, 1935 parsed). 2790 targets, 120 skipped, 0 masked, 0 errors. NOTE: Resolving any missing task queue dependencies Build Configuration: BB_VERSION = "1.37.0" BUILD_SYS= "x86_64-linux" NATIVELSBSTRING = "ubuntu-16.04" TARGET_SYS = "arm-poky-linux-gnueabi" MACHINE = "raspberrypi3" DISTRO = "poky" DISTRO_VERSION = "2.5" TUNE_FEATURES= "arm armv7ve vfp thumb neon vfpv4 callconvention-hard cortexa7" TARGET_FPU = "hard" meta meta-poky meta-yocto-bsp = "sumo:f0ec7c8b2dc1797ba22c45653a5f182b63354092" meta-oe meta-python meta-multimedia = "sumo:a19aa29f7fa336cd075b72c496fe1102e6e5422b" meta-raspberrypi = "sumo:f2e2a4376e84dec6e5efeabaa86a4406fddf7dcd" NOTE: Fetching uninative binary shim from http://downloads.yoctoproject.org/releases/uninative/1.9/x86_64-nativesdk-libc.tar.bz2;sha256sum=c26622a1f27dbf5b25de986b11584b5c5b2f322d9eb367f705a744f58a5561ec Initialising tasks: 100% |###| Time: 0:00:03 NOTE: Executing SetScene Tasks NOTE: Executing RunQueue Tasks WARNING: libdaemon-0.14-r0 do_fetch: Failed to fetch URL http://0pointer.de/lennart/projects/libdaemon/libdaemon-0.14.tar.gz, attempting MIRRORS if available WARNING: libnss-mdns-0.10-r7 do_fetch: Failed to fetch URL http://0pointer.de/lennart/projects/nss-mdns/nss-mdns-0.10.tar.gz, attempting MIRRORS if available WARNING: apt-1.2.24-r0 do_fetch: Failed to fetch URL http://archive.ubuntu.com/ubuntu/pool/main/a/apt/apt_1.2.24.tar.xz, attempting MIRRORS if available NOTE: Tasks Summary: Attempted 5203 tasks of which 5 didn't need to be rerun and all succeeded. Summary: There were 3 WARNING messages shown. - Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [Yocto][meta-raspberrypi] troubling warning "postinstall intercept hook 'update_gio_module_cache-nativesdk' failed"
I am trying to build for raspberrypi3 near head of sumo. I get the following troublesome warning fairly often since I started doing some builds in sumo and master the past week.: WARNING: core-image-minimal-1.0-r0 do_populate_sdk: The postinstall intercept hook 'update_gio_module_cache-nativesdk' failed, details in /data/development/lfs/yocto/build/spark/raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_populate_sdk Here is the detail of the warning is. It basically reports "Invalid ELF image for this architecture": NOTE: > Executing update_gio_module_cache-nativesdk intercept ... WARNING: The postinstall intercept hook 'update_gio_module_cache-nativesdk' failed, details in /data/development/lfs/yocto/build/spark/raspb errypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-minimal/1.0-r0/temp/log.do_populate_sdk NOTE: Exit code 255. Output: /data/development/lfs/yocto/build/spark/raspberrypi3/tmp/work/raspberrypi3-poky-linux-gnueabi/core-image-minimal/1.0-r0/sdk/image/opt/poky/2 .5/sysroots/x86_64-pokysdk-linux/usr/libexec/nativesdk-gio-querymodules: Invalid ELF image for this architecture Question: How serious is this warning, and what should I do about it? - Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] -c populate_sdk question
Hello, Is there an easy way to exclude a section of my local conf when I am building with -c populate_sdk option? Long story short, I have some multilib-related entries in my local.conf which I need when building only the OS image, but which cause errors when building the SDK. It’s be easiest if I could put a conditional around the multilib-related entries in my local.conf. Then when I build with the -c populate_sdk option, they would be excluded from that build. I noticed there are many SDK* variables in the Bitbake system, but I’m not so sure what are the best one/ones to use for my purpose, and what is the recommended syntax to achieve this conditional exclusion in my local.conf. Thanks in advance for any ideas. - Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [meta-raspberrypi] Compute Module 3 machine .conf questions
Hi Andrei, We were able to verify that we could directly use the raspberrypi3-64.conf for the cm3 as 64-bit, as you had suggested. Thanks for that suggestion. It just seemed a bit confusing that there is only one cm3 machine conf, and it tunnels through to a rpi2. All the online doc about the cm3 mentions the rpi3. A colleague wonders if there are any differences that someone was planning to eventually use that cm3 conf to enumerate, otherwise - having a cm3 conf seems like unnecessary duplication. Thanks again for your help! - Steve Pavao Korg R > On May 1, 2018, at 9:39 AM, Andrei Gherzan <and...@gherzan.ro> wrote: > > Hi Steve, > > On Tue, May 1, 2018 at 12:40 AM, Steve Pavao <ste...@korgrd.com > <mailto:ste...@korgrd.com>> wrote: > Hello, > > My company has bought a Raspberry Pi Compute Module 3 for evaluation, and I > have a 2 questions about the supplied machine .conf files for it. > > 1. Should the supplied raspberrypi-cm3.conf file internally refer to the > Raspberry Pi 3 instead of the Raspberry Pi 2, since the RPi3 is the hardware > basis of the Compute Module 3? > > RaspberryPi 3 is currently almost the same as RaspberryPi 2 in terms of > configuration. What is the problem you are facing? > > 2. Should there also be an additional .conf file supplied in the > meta-raspberry pi layer for a 64-bit version of poky Linux for the Compute > Module 3, just as there is a raspberrypi3-64 machine .conf for the RPi3? > > You can use directly raspberrypi3-64 as far as I am aware. The cm confs are > used as aliases right now. They point to one of the Raspberrypi 2 or 3 > machine configurations. > > -- > Andrei G. -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] Compute Module 3 machine .conf questions
Hello, My company has bought a Raspberry Pi Compute Module 3 for evaluation, and I have a 2 questions about the supplied machine .conf files for it. 1. Should the supplied raspberrypi-cm3.conf file internally refer to the Raspberry Pi 3 instead of the Raspberry Pi 2, since the RPi3 is the hardware basis of the Compute Module 3? 2. Should there also be an additional .conf file supplied in the meta-raspberry pi layer for a 64-bit version of poky Linux for the Compute Module 3, just as there is a raspberrypi3-64 machine .conf for the RPi3? Thanks in advance for your thoughts about this. - Steve Pavao Korg R . -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] ARM CPU version question
Hi Andre,
> On Mar 19, 2018, at 5:32 PM, Andre McCurdy <armccu...@gmail.com> wrote:
>
> On Mon, Mar 19, 2018 at 9:49 AM, Steve Pavao <ste...@korgrd.com> wrote:
>> What’s the recommended way to be able to propogate target-specific
>> compile-time CPU tune information to affect the build of a source file in my
>> own custom layer?
>>
>> For example, if I’m building for an arm6-based target, I’d like to be able
>> to have the __ARM_ARCH_6__ symbol be available when the Yocto system builds
>> my custom layer. The BSP for such a target obviously defines this symbol
>> when building its files for such a target. Is there an easy way to
>> propagate this information to my own custom layer, to affect my own sources?
>> Maybe my recipe needs to include certain conf files from other layers such
>> as meta or the BSP layer?
>
> This kind of macro is typically defined internally by gcc, depending
> on the -mcpu etc options passed on the gcc command line, ie options
> which are included in the ${CC} definition setup by OE.
>
> Therefore all you normally need to do is ensure that the Makefiles etc
> for the components in your custom layer all correctly respect OE's
> definition of ${CC}.
>
> A typical bug in handcrafted Makefiles is to force CC to (e.g. CC =
> "$(CROSS_COMPILE)gcc") and lose the original value passed via the
> environment.
>
>> Currently, I notice that architecture-level symbols are available to my
>> custom layer at compile time, such as __aarch64_ and __arm__, but not CPU
>> tune information, such as __ARM_ARCH_6__.
>
> The exact set of macros defined by gcc will vary depending on exactly
> which ARMv6 CPU you are targeting (and to some extent, which version
> of gcc you are using). If you have code which needs to be enabled for
> any ARMv6 target then you may have to test multiple macros. For
> example see the way in which openssl defines __ARM_ARCH__
>
> https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h
> <https://github.com/openssl/openssl/blob/master/crypto/arm_arch.h>
Thank you very much for your insight, Andre !
I think I may have discovered a specific situation which is causing the problem
to occur for me. It seems it occurs because I am trying to build a kernel
module under the recipes-kernel directory in my custom layer. A colleague
pointed out to me that meta/classes/module.bbclass explicitly unsets CFLAGS and
a bunch of other macros in this situation.
Maybe I need to put in some custom shell syntax in my recipe, to export
__ARM_ARCH_6__ or to directly define the compiler macro when needed, based on
the value of the TARGET variable. I wonder if there is a better recommended
solution than this, though.
BTW, my kernel module contains conditionally-compiled code for initializing the
ARM PMU correctly for each CPU case.
- Steve
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] how to know Poky kernel version before running it
Is there a definitive way to know at/after build time what kernel version is being built via a particular bitbake of Poky? I don’t have the board on hand to boot the result of my work right now; it is a scout build for a board I’m getting soon. I’m trying to figure it out by browsing the console-latest.log and looking for the highest kernel version I can observe from the recipes used. Is there a better way to find this out at build time? Knowing the kernel version would help me decide what version of a patch to apply to go along with it. Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [meta-raspberrypi] errors in tools-testapps when targeting raspberrypi3
Hello, When I target raspberrypi3 and have tools-testapps listed in EXTRA_IMAGE_FEATURES in my local.conf, build errors occur. The errors come from the building of mesa-demos and gst-player. If I remove those targets from packagegroup-core-tools-testapps.bb, I don’t get errors. The errors seem to relate to required settings of these variables in local.conf to match available packages: PREFERRED_PROVIDER_virtual/egl PREFERRED_PROVIDER_virtual/libgles1 PREFERRED_PROVIDER_virtual/libgles2 PREFERRED_PROVIDER_virtual/libgl PREFERRED_PROVIDER_virtual/mesa I tried setting these all to the value “mesa”, but then the gstreamer build seemed to demand a value of “userland” for at least one of the variables. I wasn’t able to resolve the conflict. Could someone please reply with the proper value of these and other configuration variables possibly needed to complete this build without having to hack packagegroup-core-tools-testapps.bb like I did, or else supply a proper fix? Here are my local.conf settings of interest. I’m building in pyro branch for everything, at current head. MACHINE ??= “raspberrypi3" IMAGE_INSTALL_append = " apt gdbserver perfcnt-enable mdns" EXTRA_IMAGE_FEATURES ?= "debug-tweaks x11-base tools-debug tools-testapps ssh-server-dropbear package-management" - Steve Pavao Korg R -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] advice on recipe for shared lib mDNSResponder
Hello,
Thanks so much for the great and useful information from you and Ross.
I was unable to successfully build that recipe here, though. I’ll check with
the maintainers to ask why.
All I did was clone the meta-intel-iot-middleware repo, add that layer to
bblayers.conf, and add mdns to IMAGE_INSTALL_append to get this far.
- Steve Pavao
Korg R
Build Configuration:
BB_VERSION= "1.34.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS= "aarch64-poky-linux"
MACHINE = "raspberrypi3-64"
DISTRO= "poky"
DISTRO_VERSION= "2.3.2"
TUNE_FEATURES = "aarch64"
TARGET_FPU= ""
meta
meta-poky
meta-yocto-bsp= "pyro:072430b9b3a78b318b66371c36e2986d2ed5cba4"
meta-oe
meta-python
meta-multimedia = "pyro:5e82995148a2844c6f483ae5ddd1438d87ea9fb7"
meta-intel-iot-middleware = "master:fc8eabfa4fb54802d3f97123b9d2954450175e33"
meta-raspberrypi = "pyro:c981f01a2cdb3299eb57920cffbb5dfd4248209a"
Initialising tasks: 100%
|#|
Time: 0:00:10
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
ERROR: mdns-544-r1 do_compile: oe_runmake failed
ERROR: mdns-544-r1 do_compile: Function failed: do_compile (log file is located
at
/data/development/lfs/yocto/poky/build/tmp/work/aarch64-poky-linux/mdns/544-r1/temp/log.do_compile.10472)
ERROR: Logfile of failure stored in:
/data/development/lfs/yocto/poky/build/tmp/work/aarch64-poky-linux/mdns/544-r1/temp/log.do_compile.10472
Log data follows:
| DEBUG: Executing shell function do_compile
| NOTE: make os=linux DEBUG=0
| ERROR: oe_runmake failed
| make: cc: Command not found
| Makefile:494: recipe for target 'objects/prod/PosixDaemon.c.o' failed
| make: *** [objects/prod/PosixDaemon.c.o] Error 127
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at
/data/development/lfs/yocto/poky/build/tmp/work/aarch64-poky-linux/mdns/544-r1/temp/log.do_compile.10472)
ERROR: Task
(/data/development/lfs/yocto/poky/meta-intel-iot-middleware/recipes-connectivity/mdns/mdns_544.bb:do_compile)
failed with exit code '1'
> On Sep 27, 2017, at 7:17 PM, Andre McCurdy <armccu...@gmail.com> wrote:
>
> On Wed, Sep 27, 2017 at 3:58 PM, Steve Pavao <ste...@korgrd.com> wrote:
>> Hello,
>>
>> I am fairly new to Yocto, yet have been able to successfully add a custom
>> kernel object to my Yocto poky build, no problem. However, I am having some
>> difficulty adding a shared library, namely mDNSResponder.
>>
>> Right now, my recipe is very simple and does not use autotools. There are
>> just a few tweaks for cross-building which I’ve added to the supplied
>> mDNSResponder Makefile for mDNSPosix, in order to target 64-bit ARM
>> hardware. Here is the build error I encounter. Obviously the environment
>> is not being set 100% correctly, because it can not find stdio.h. Is there
>> an easy way to avoid this problem?
>
> You need to ensure that the Makefiles etc for the package you are
> building respect the ${CC} environment variable defined by OE. It
> includes not only the name of the cross compiler but also important
> command line options, e.g. tuning for the correct target CPU and the
> correct --sysroot option. From your build log the --sysroot option is
> missing, therefore the compiler can not find standard include files
> etc.
>
> Unfortunately packages with build with custom Makefiles are so diverse
> that there's no single approach to making them work. Sometimes you can
> force CC=${CC} etc via the make command line to over-ride incorrect
> defaults in the Makefile, sometime the Makefile needs to be patched,
> etc. Even if the build succeeds it's wise to carefully check the build
> log to ensure that all calls to the compiler, linker, etc contain the
> flags defined by OE.
>
> Note however that according to the layer index there does already seem
> to be at least one recipe for mDNSResponder. It includes a Makefile
> patch which looks like it will address your issue (and some others):
>
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-intel-iot-middleware/tree/recipes-connectivity/mdns/mdns_544.bb?h=master
>
>>
>> - Steve Pavao
>> Korg R
>>
>> Log data follows:
>> | DEBUG: Executing shell function do_compile
>> | NOTE: make -j 4
>> | ERROR: oe_runmake failed
>> | make os=EmbeddedLinuxAarch64 Daemon libdns_sd -C mDNSPosix
>> | make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent
>> make rule.
>> | make[1]: En
[yocto] advice on recipe for shared lib mDNSResponder
Hello, I am fairly new to Yocto, yet have been able to successfully add a custom kernel object to my Yocto poky build, no problem. However, I am having some difficulty adding a shared library, namely mDNSResponder. Right now, my recipe is very simple and does not use autotools. There are just a few tweaks for cross-building which I’ve added to the supplied mDNSResponder Makefile for mDNSPosix, in order to target 64-bit ARM hardware. Here is the build error I encounter. Obviously the environment is not being set 100% correctly, because it can not find stdio.h. Is there an easy way to avoid this problem? - Steve Pavao Korg R Log data follows: | DEBUG: Executing shell function do_compile | NOTE: make -j 4 | ERROR: oe_runmake failed | make os=EmbeddedLinuxAarch64 Daemon libdns_sd -C mDNSPosix | make[1]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. | make[1]: Entering directory '/data/development/lfs/yocto/poky/build/tmp/work/aarch64-poky-linux/mDNSResponder/333.10-r0/mDNSPosix' | aarch64-poky-linux-gcc -I../mDNSCore -I../mDNSShared -Iobjects/prod/EmbeddedLinuxAarch64 -fwrapv -W -Wall -DPID_FILE=\"/var/run/mdnsd.pid\" -DMDNS_UDS_SERVERPATH=\"/var/run/mdnsd\" -DNOT_HAVE_SA_LEN -DUSES_NETLINK -DHAVE_LINUX -DTARGET_OS_LINUX -fno-strict-aliasing -Os -DMDNS_DEBUGMSGS=0 -c -o objects/prod/EmbeddedLinuxAarch64/PosixDaemon.c.o PosixDaemon.c | PosixDaemon.c:31:19: fatal error: stdio.h: No such file or directory | #include |^ | compilation terminated. | Makefile:553: recipe for target 'objects/prod/EmbeddedLinuxAarch64/PosixDaemon.c.o' failed | make[1]: *** [objects/prod/EmbeddedLinuxAarch64/PosixDaemon.c.o] Error 1 -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
