Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build
Thanks for all the help so far, I have a working recipe which installs the whole
toolchain to /usr/bin and uses that from another recipe :)
> On Thu, 2019-10-24 at 08:55 +, Richard Purdie wrote:
> You can probably do that by extending SYSROOT_DIRS in the recipe.
I'm still having issues here: I've tried to extend SYSROOOT_DIRS and even used a
path relative to the existing entrys (so I don't get caught by some hidden
extension mechanism), but my files still don't end up in the sysroot.
I've also tried both, SYSROOOT_DIRS and SYSROOT_DIRS_NATIVE, with the same
result.
A (hopefully) last tip would be appreciated to make a nice recipe from a
working one.
GCC_ARM_NONE_EXTRA_PATH="/${PN}"
SYSROOOT_DIRS += "${bindir}/../opt"
do_install() {
# old and working to install to /usr/bin/
# install -d ${D}${bindir}${GCC_ARM_NONE_EXTRA_PATH}
# cp -r ${S}/* ${D}${bindir}${GCC_ARM_NONE_EXTRA_PATH}
# new, but no files in the sysroots of recipes using the toolchain
install -d ${D}${bindir}/../opt${GCC_ARM_NONE_EXTRA_PATH}
cp -r ${S}/* ${D}${bindir}/../opt${GCC_ARM_NONE_EXTRA_PATH}
}
Best regards, Olli
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build
> On Thu, 2019-10-24 at 04:01 +, Richard Purdie wrote:
> If its a native recipe, there are no packages and therefore FILES
> doesn't make sense.
Oh, I have to admit I'm pretty new to the concept of the native packages.
Where can I find the list of files that are considered to be installed into
a "native" packages sysroot?
An good option for me would be to eg. install the toolchain into the native
sysroots /opt/ dir for usage by other recipes.
> Can you confirm that recipe does work?
For the TI recipe, no, I can't. I found it online and used it as a guide for
my first steps on the topic.
> If you install the binaries into ${bindir} they will. If you place them
> somewhere else which the system doesn't know about, they probably
> won't.
>
> There are ways to make alternative locations work but I don't see any
> of that in the above recipe.
Can you point me to these ways? :)
> There isn't anything that special about a baremetal compiler except it
> sets some different default flags and is missing the library support.
I agree, though using linaro has the benefit that we would use the same
toolchain in yocto as in "regular development" of the m4 functionality.
Best regards, Olli
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Issues adding bare meta toolchain to yocto build
> On Thu, 2019-10-24 at 04:01 +, Richard Purdie wrote:
> If its a native recipe, there are no packages and therefore FILES
> doesn't make sense.
Oh, I have to admit I'm pretty new to the concept of the native packages.
Where can I find the list of files that are considered to be installed into
a "native" packages sysroot?
An good option for me would be to eg. install the toolchain into the native
sysroots /opt/ dir for usage by other recipes.
> Can you confirm that recipe does work?
For the TI recipe, no, I can't. I found it online and used it as a guide for
my first steps on the topic.
> If you install the binaries into ${bindir} they will. If you place them
> somewhere else which the system doesn't know about, they probably
> won't.
>
> There are ways to make alternative locations work but I don't see any
> of that in the above recipe.
Can you point me to these ways? :)
> There isn't anything that special about a baremetal compiler except it
> sets some different default flags and is missing the library support.
I agree, though using linaro has the benefit that we would use the same
toolchain in yocto as in "regular development" of the m4 functionality.
Best regards, Olli
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [EXTERNAL] Re: Issues adding bare meta toolchain to yocto build
>On Wed, 2019-10-23 at 15:34 +, Richard Purdie wrote:
>>On Wed, 2019-10-23 at 11:23 +, Westermann, Oliver wrote:
>> Hey,
>> [...]
>> Any suggestions on what I'm doing wrong or how to debug this further?
>Sounds like the sysroot filtering code doesn't know about this
>directory and therefore doesn't pass it through to the recipe sysroot?
Sorry to ask dumb questions, but what do you mean by "this directory"?
The toolchain directory created by the TI recipe? Shouldn't that be handled
by FILES_${PN}?
>The recipe you link to is for an on target compiler, not one in the
>sysroot.
Again, might be a stupid missunderstanding on my side: The recipe I linked
extracts a precompiled toolchain that is suitable only for x86_64 systems and
allows a "native" package. From my current understanding, a native package is
to be used on the build host, which is what I'm intending to do here.
I managed to sucessfully add a native recipe for the NXP code signing tool
(which is only provided as a precompiled binary as well) which works as
expected.
>I'm actually a little surprised you can't use our standard cross
>compiler assuming this M4 core is on an ARM chip? It should be a case
>of passing the right options to the compiler to target the M4?
I'm totally up for any infos on how to do this! I did google around for recipes
or examples that build a non-linux binary using yocto, but I couldn't really
find
anything or any documentation. But maybe my searchterms (along "build baremetal
arm binary using yocto") were off target. Can you point me at documentation,
examples,
searchterms..?
>Cheers,
>
>Richard
Thanks for the help!
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Issues adding bare meta toolchain to yocto build
Hey,
I'm having issues adding a build for a bare metal target to my yocto toolchain.
I've a NXP SoC with a M4 core and I would like to integrate the M4 binary build
into yocto.
My M4 binary has a CMAKE file that depends on ARMGCC_DIR being set to locate
the toolchain and everything works fine locally.
I've create a recipe for the toolchain that is heavily inspired by a TI recipe
for the gcc-arm-none-eabi (available here:
http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-ti/devtools/gcc-arm-none-eabi_7-2018-q2-update.bb?h=master).
I've made sure that GCC_ARM_NONE_TOOLCHAIN_RECIPE is set.
After calling bitbake -cpopulate-sysroot gcc-arm-none-eabi-native the
image/${GCC_ARM_NONE_TOOLCHAIN_RECIPE} path contains the complete toolchain.
My M4 recipe looks like this (plus SUMMARY, LICENSE, SRC_URI, ...):
inherit pkgconfig cmake
DEPENDS = "gcc-arm-none-eabi-native"
S = "${WORKDIR}/git "
EXTRA_OECMAKE = '-DCMAKE_TOOLCHAIN_FILE="../armgcc.cmake" \
-G "Unix Makefiles" \
-DCMAKE_BUILD_TYPE=release'
>From my understanding depending on gcc-arm-none-eabi-native should result in
>the native toolchain being installed into the m4's recipe-sysroot-native
>folder.
The sysroot-providers in the recipe-sysroot-native folder does list
gcc-arm-none-eabi-native, but I don't get the files and therefore have no
toolchain.
Any suggestions on what I'm doing wrong or how to debug this further?
Best regards, Olli
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Transfer meta-data between recipes
Hey, I'm trying to implement a bootloader-signing mechanism within yocto for extended secure-boot support. The bootloader and it's recipes are provided by NXP (in this case it's the imx-boot_*.bb recipe from meta-freescale) and I want to use a secondary recipe which I am creating to sign the resulting boot binary. My issue is that the NXP code signing tool needs some info about the binary to sign. These details are send to stdout by imx-mkimage tool, which is called by the imx boot makefile (used here: https://github.com/Freescale/meta-freescale/blob/master/recipes-bsp/imx-mkimage/imx-boot_0.2.bb#L104). I can override the compile step of imx-boot to save stdout into a file, deploy this file and later parse it to extract the offset dump, but that feels "ugly" and the file is by no means a output of the imx-boot recipe for the target system, but for another step. Is there any recommended way to parse such variable metadata between recipes? Olli -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Debugging deployment of kernel image
Hey, I'm currently in the process of updating our yocto (sumo) with a new kernel version from a supplier (NXP) and I'm having some issues, we somehow broke deployment of the linux kernel: I get the Image & symlink in my images folder, but it does not end up in my rootfs. It SHOULD end up at /boot. My system boots u-boot and searches for the kernel (and fails ofc). If I manually place my kernel, everything is fine. I would like to find out where in my recipes this goes south: I've checked build//tmp/work/-poky-linux/linux-imx/4.14.78-r0/deploy-linux-imx and the kernel and the expected kernel Image and symlink is there alongside the .dtb files. The dtb files get deployed as expected, but my kernel does not. I've also checked build//tmp/work/-poky-linux/linux-imx/4.14.78-r0/deploy-rpms// , where I've got a kernel-image-image-4.14.78-+-4.14.78-r0..rpm, which contains the kernel and the symlink. Which brings me into an area of yocto I'm not used to, since usually THAT part worked for me ;-) So if a RPM is generated, but not properly installed, where do I continue my debugging efforts? I've already checked the output of bitbake -e linux-imx, but I only used -e only to debug my recipes (how stuff expands), so this was more of a "random looking at stuff" to figure things out. Any help appreciated. - Olli -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Defining group of machines
> > is that what you were after? > override is the first thing that crossed my mind... Thanks both of you, an additional machine override was exactly what we needed. Best regards, Olli -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Defining group of machines
Hey,
We've a product group with different devices, each having their machine-conf, eg
Device_a
Device_a_mini
Device_b
Device_b_mini <- Upcoming
Device_c <- Upcoming
Since device_a and device_a_mini share a lot of code, for them we use one of
the machine overrides, describing the processor family, so I use
RDEPENDS_${PN}_append_device_a if I just need it for device_a and
RDEPENDS_${PN}_append_am57x for device_a and device_a_mini.
Now I'm in the situation that device_c will use the same CPU as device b, so I
need something like a "group" of devices for family b.
How can I define a MACHINE_GROUP_device_b_group = "device_b device_b_mini" so I
can do
RDEPENDS_${PN}_append_device_b_group or do_install_append_device_b_group()?
Best regards, Olli
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
