Re: [yocto] Final DISTRO_FEATURES value
Ciao, you can inspect the testdata file located next to the generated image, under deploy floder. Best regards, Gabriele Il giorno mer 21 ago 2019 alle ore 08:25 Mauro Ziliani < ma...@faresoftware.it> ha scritto: > Hi all. > > How can I inspect the final value of DISTRO_FEATURES when bitbake has > completed the parse all recipes? > > > Best regards, > >MZ > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Opencv headers
Hi,
you need to add
DEPENDS = "opencv"
to your recipe. This will import the needed header in your recipe sysroot.
Best regards,
Gabriele
Il giorno lun 19 ago 2019 alle ore 13:09 Ekaterini Voulgari <
sdi1100...@di.uoa.gr> ha scritto:
> Hello all,
> I'm trying to add a program to my image that uses opencv (#include
> ), but I get compile error "fatal error:
> opencv2/opencv.hpp: No such file or directory"
>
> The file opencv.hpp exists in workdir
> /build/tmp/work/cortexa7t2hf-neon-vfpv4-poky-linux-musleabi/opencv/3.4.5-r0/image/usr/include/opencv2/opencv.hpp.
>
> Can anyone help on where are the headers located in crossbuilds? Any
> help appreciated.
> The recipe:
>
> SRC_URI = "file://capture.cpp"
>
> do_compile () {
> ${CC} capture.cpp -lopencv_core -lopencv_imgproc -lopencv_highgui
> -lopencv_videoio
> }
>
> do_install () {
>
> install -d -m 0755 ${D}/${bindir}
> install -m 0755 prog_kameras ${D}/${bindir}/prog_kameras
> }
>
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to specify a different kernel for an image
Hi Patrick,
Do I have to replicate (and maintain) all of the references to
> mymachine to also refer to my newly defined "installationmachine"? Or
> can I tell Bitbake that "installationmachine" is the same as
> "mymachine", and just add/change new stuff for "installationmachine"?
>
I would approach in this way: in my meta-something/conf/machine:
- machine_base.inc where I put all the standard machine configuration for
production
- mymachine.conf
require conf/machine/machine_base.inc
- myinstallationmachine.conf
require conf/machine/machine_base.inc
PREFERRED_PROVIDER_virtual/kernel = "some-linux-provider"
Then in something.bbappend:
- If the property is common to both machines:
SRC_URI_append = " file://modifications.patch"
- if the property is machine specific:
SRC_URI_append_ = " file://machinespec.patch"
In this way you have to maintain only the differences between your
machines, without redundancy.
2. My new image going to be used as an installation image for my
> production image. So I need to include the production image (for
> MACHINE="mymachine")) deploy products in the image for my installation
> image. How can I do that if I define a new MACHINE for the production
> image?
>
This is not clear to me. With 'installation image' do you mean a full image
(bootloader, kernel, rootfs etc)?
Can you give me some more details about this use case?
Best regards,
Gabriele
Il giorno ven 19 lug 2019 alle ore 14:49 Patrick Doyle
ha scritto:
> On Fri, Jul 19, 2019 at 1:58 AM Gabriele Zampieri
> wrote:
> >
> > Hi,
> >
> > you could define two machines, where the manufacturing one is just an
> overlay of the production one. If the two kernels differs only for their
> config, you can specify different defconfig based on machine. If you need a
> completely different kernel, just specify
> PREFERRED_PROVIDER_virtual/kernel in manufacturing overlay
>
> Hi Gabriele,
> I wondered about that, but I get confused about the MACHINE concept in
> Yocto/OE/bitbake...
>
> 1. If I define a new machine, but I have a lot of recipes conditioned
> on the old machine, how do I say "This is the same as machine A, but
> with these differences"? I have defined a machine now ("mymachine")
> and have recipes and .bbappend files with things like this in them:
>
> SRC_URI_mymachine += "file:/blah/blah/blah"
> do_install_append_mymachine() {
> do_stuff()
> }
>
> Do I have to replicate (and maintain) all of the references to
> mymachine to also refer to my newly defined "installationmachine"? Or
> can I tell Bitbake that "installationmachine" is the same as
> "mymachine", and just add/change new stuff for "installationmachine"?
>
> I hope my confusion here makes sense, but since it's confusion, it's
> tough to tell :-)
>
> 2. My new image going to be used as an installation image for my
> production image. So I need to include the production image (for
> MACHINE="mymachine")) deploy products in the image for my installation
> image. How can I do that if I define a new MACHINE for the production
> image?
>
> Thank you so much for the suggestion... it confirms that I am looking
> in the right places and thinking about the right things... I just
> don't know how to solve this problem.
>
> I'm also surprised that it's not a more general problem... which leads
> me to believe that I must be thinking about this the wrong way.
>
> Thanks again.
>
> --wpd
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to specify a different kernel for an image
Hi, you could define two machines, where the manufacturing one is just an overlay of the production one. If the two kernels differs only for their config, you can specify different defconfig based on machine. If you need a completely different kernel, just specify PREFERRED_PROVIDER_virtual/kernel in manufacturing overlay Best regards, Gabriele Il giorno gio 18 lug 2019 alle ore 23:27 Patrick Doyle ha scritto: > Hello All, > I have a situation where I need to build an image for my machine with > a different kernel than is specified by > PREFERRED_PROVIDER_virtual/kernel. But I also need to build the > default kernel. This is for a "manufacturing" image which will > include the full production image, and then some (and, possibly, > without some). The kernel configuration needs to be different for the > manufacturing image. > > What is the recommended mechanism to override the value of > PREFERRED_PROVIDE_virtual/kernel in my manufacturing-image.bb recipe? > > --wpd > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] eSDK: python3.5.real: No such file or directory
Hi all, I just created my first eSDK for a custom image. It installs just fine. When I try to run "devtool --help" (after sourcing the env setup), I got this output: /home/user/poky_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/python3: line 5: /home/user/poky_sdk/sysroots/x86_64-pokysdk-linux/usr/bin/python3.5.real: No such file or directory I have python3.5 installed on my host. Thanks in advance, Gabriele -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Different installation path in SDK
Hi all,
for legacy reason I need to install some libraries in a non-standard path
(/opt/custom/lib). I achieved this quite easily via cmake. However, when I
generate the SDK, those libraries and headers are installed in
/sysroot/arm/opt/custom/[lib|include] and this is quite annoying.
Is there a way to recognize when bitbake builds the SDK and when it
doesn't? something like class-nativesdk ann class-target, so I can change
the installation path to ${libdir} & co.
Thanks,
Gabriele
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Patching a file in $WORKDIR
Hi Jeffrey,
the extension "ptch" is not treated as patchfile by Yocto (only *.diff and
*.patch). You have two options:
- Rename your patch in inputrc.patch
- Adding the apply switch:
SRC_URI_append =" file://inputrc.ptch;apply=yes"
In this way you are telling yocto that 'inputrc.ptch' is a patch file
In both cases you can remove your append.
This should be enough.
Best regards,
Gabriele
Il giorno mar 16 lug 2019 alle ore 18:44 Siegel, Jeffrey (Nokia - US/Murray
Hill) ha scritto:
> Hi,
>
> I am trying to use a bbappend file to patch a file in $WORKDIR. To my
> understanding, the native Yocto patching process only works for patching
> files in $S.
>
> I have come up with a solution:
>
>
>
> FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
>
> SRC_URI_append =" file://inputrc.ptch"
>
> do_patch_append () {
>
> cmd="patch
> (exitstatus, output) = oe.utils.getstatusoutput(cmd)
>
> if exitstatus != 0:
>
>raise bb.process.CmdError(cmd, output)
>
> return output
>
> }
>
>
>
> It does work. But I think this is line is not very elegant: cmd="patch
> being executed is the one from the Yocto environment
> ($BUILDDIR/tmp-glibc/hosttools), not the build host. But I still suspect
> there is a better way. Any suggestions?
>
>
>
> Regards,
>
> Jeff
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where to add U-Boot argements bootargs and bootcmd?
Hi JH, wks is the extension used by wic to generate different kind of flashable (partitioned) images. I never used it, but looking around ( https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#command-bootloader ) I see two relevant arguments: - *--append * - *--configfile* Check them in the link above. Here is an example for --append: https://github.com/openembedded/openembedded-core/blob/master/scripts/lib/wic/canned-wks/directdisk-multi-rootfs.wks#L22 Digging a bit deeper it seems that you cannot feed a custom config to uboot via wic (and again, correct me if I'm wrong), but only for extlinux (see: https://github.com/openembedded/openembedded-core/blob/master/scripts/lib/wic/plugins/source/bootimg-partition.py#L110 ) I do not have time to replicate your environment, so I'm just giving you suggestions. Best regards, Gabriele Il giorno lun 15 lug 2019 alle ore 14:45 JH ha scritto: > Thanks Gabriele and Maciej, I use meta-freescale for imx6. The u-boot > argements seem defined in wks files such as imx-uboot-mxs.wks, > imx-uboot-bootpart.wks, not quite sure how to extend or overwrite it. > Sorry still learning the Yocto. > > Thank you. > > Kind regards, > > - jh > > On 7/15/19, Gabriele Zampieri wrote: > > Yes, thanks Maciej for pointing that out! It may be a good starting point > > for JH. > > > > Gabriele > > > > Il giorno lun 15 lug 2019 alle ore 10:29 Maciej Pijanowski < > > maciej.pijanow...@3mdeb.com> ha scritto: > > > >> > >> On 15.07.2019 08:45, Gabriele Zampieri wrote: > >> > >> Hi, > >> > >> as far as I know, there is no mechanism to add custom bootargs and/or > >> bootcmd to uboot via Yocto (correct me if I'm wrong). I usually patch > the > >> upstream uboot to achieve this task. > >> > >> I also haven't heard of any standardized way. It may depend on the > target > >> hardware > >> and the BSP layer you are using. Apart from patching the U-Boot, there > >> also might > >> be boot.cmd script to modify or the config.txt in case of the RPI, for > >> example. > >> > >> > >> Best regards, > >> Gabriele > >> > >> Il giorno lun 8 lug 2019 alle ore 22:43 JH ha > >> scritto: > >> > >>> Hi, > >>> > >>> Which Yocto files and which statement can I add my own U-Boot bootargs > >>> and bootcmd? > >>> > >>> Thank you. > >>> > >>> - jupiter > >>> -- > >>> ___ > >>> yocto mailing list > >>> yocto@yoctoproject.org > >>> https://lists.yoctoproject.org/listinfo/yocto > >>> > >> > >> -- > >> Maciej Pijanowski > >> Embedded Systems Engineerhttps://3mdeb.com | @3mdeb_com > >> > >> -- > >> ___ > >> yocto mailing list > >> yocto@yoctoproject.org > >> https://lists.yoctoproject.org/listinfo/yocto > >> > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where to add U-Boot argements bootargs and bootcmd?
Yes, thanks Maciej for pointing that out! It may be a good starting point for JH. Gabriele Il giorno lun 15 lug 2019 alle ore 10:29 Maciej Pijanowski < maciej.pijanow...@3mdeb.com> ha scritto: > > On 15.07.2019 08:45, Gabriele Zampieri wrote: > > Hi, > > as far as I know, there is no mechanism to add custom bootargs and/or > bootcmd to uboot via Yocto (correct me if I'm wrong). I usually patch the > upstream uboot to achieve this task. > > I also haven't heard of any standardized way. It may depend on the target > hardware > and the BSP layer you are using. Apart from patching the U-Boot, there > also might > be boot.cmd script to modify or the config.txt in case of the RPI, for > example. > > > Best regards, > Gabriele > > Il giorno lun 8 lug 2019 alle ore 22:43 JH ha > scritto: > >> Hi, >> >> Which Yocto files and which statement can I add my own U-Boot bootargs >> and bootcmd? >> >> Thank you. >> >> - jupiter >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> > > -- > Maciej Pijanowski > Embedded Systems Engineerhttps://3mdeb.com | @3mdeb_com > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where to add U-Boot argements bootargs and bootcmd?
Hi, as far as I know, there is no mechanism to add custom bootargs and/or bootcmd to uboot via Yocto (correct me if I'm wrong). I usually patch the upstream uboot to achieve this task. Best regards, Gabriele Il giorno lun 8 lug 2019 alle ore 22:43 JH ha scritto: > Hi, > > Which Yocto files and which statement can I add my own U-Boot bootargs > and bootcmd? > > Thank you. > > - jupiter > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to extrac rootfs.wic in Ubuntu?
Hi, in your machine conf add: (or just overload it, if you need only tar.gz images, this will speedup the image generation process) IMAGE_FSTYPES += " tar.gz" The list of (standard) available image types can be found here: https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-IMAGE_TYPES Gabriele Il giorno ven 5 lug 2019 alle ore 14:23 JH ha scritto: > Hi, > > I know I can use dd to write wic to a device such as a SD card, but I > need to extract rootfs.wic then repack it by tar.gz in Ubuntu machine. > Is it possible? How can I do it. > > Thank you. > > - jupiter > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Poky build errors, help is needed
Hi Chad, why are you checking out such an old version? As the tutorial said, try: git checkout tags/yocto-2.7 -b my-yocto-2.7 Probably some URLs are no longer available. Gabriele Il giorno mar 2 lug 2019 alle ore 14:53 Chad Gong ha scritto: > Hi, > > > > I am new to Yocto project and try to build my first yocto project by > following instructions on > https://www.yoctoproject.org/docs/current/brief-yoctoprojectqs/brief-yoctoprojectqs.html. > I checked out branch yocto-2.5.3, and tried to build targets, such as > core-image-minimal, meta-toolchain, but always get some fetch errors or > checksum errors, such as: > > > > ERROR: libmpc-native-1.1.0-r0 do_fetch: Checksum failure fetching > https://ftp.gnu.org/gnu/mpc/mpc-1.1.0.tar.gz > > WARNING: quilt-native-0.65-r0 do_fetch: Failed to fetch URL > http://download.savannah.gnu.org/releases/quilt/quilt-0.65.tar.gz, > attempting MIRRORS if available > > WARNING: m4-native-1.4.18-r0 do_fetch: Failed to fetch URL > http://ftp.gnu.org/gnu/m4/m4-1.4.18.tar.gz, attempting MIRRORS if > available > > > > I am running Ubuntu 18.04 virtual box on Windows 7. > > > > Chad Gong > > Electrical Engineer > > > > Trijicon, Inc. > > | P.O. Box 930059 > > Wixom, Michigan 48393 US > > cg...@trijicon.com | > > > > -- > This electronic message contains information that may be confidential, > privileged, proprietary, or subject to the export control laws of the > United States, including the Arms Export Control Act (22 U.S.C. 2571 et > seq.), the International Traffic in Arms Regulations (22 C.F.R. Part 120 > et seq.), and/or the Export Administration Regulations (15 C.F.R. Part 730 > et seq.). This information is intended for the use of the addressee only, > and if you are not the intended recipient, any disclosure, copying, > distribution, printing, or any other use of, the contents of this message > is prohibited. Any transfer, retransfer, or disclosure of this data to a > Foreign Person without United States Government authorization is also > prohibited. If you have received this message in error, please notify the > sender and destroy the original message. > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Getting a package PV from another
Hi Mike, thank you for your reply. The meta-layer that we use are locked (they won't be changed once in production, so the git hash won't tell much about). I need that information for tracking/distribution purposes, since I already have a way to get it at runtime. Gabriele Il giorno lun 1 lug 2019 alle ore 15:23 Mike Looijmans < mike.looijm...@topic.nl> ha scritto: > The version of your OE layer is all the version that you'll ever > (technically) > need. That version (usually a git hash) dictates all other versions. > > When asked for version numbers of included packages, I always just dump > the > manifest file into their lap. > > You can also ask and report the version numbers at runtime (e.g. using > opkg or > dpkg). That also prevents lying to your users :) > > On 01-07-19 11:28, Gabriele Zampieri wrote: > > Up, with more details: > > > > I have a top recipe that depends on *my-image:do_build*. I'd like to > retrieve > > the PV of a couple of packages (from that top recipe) that are used to > mark > > our custom software. Any suggestions? > > > > Gabriele > > > > Il giorno ven 28 giu 2019 alle ore 11:25 Gabriele Zampieri > > mailto:gabbla.mal...@gmail.com>> ha scritto: > > > > Hi all, > > > > is there a way to get a specific package version from another? > > > > Best regards, > > Gabriele > > > > > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Allow choose of U-Boot config for machine
Since UBOOT_CONFIG is a standard property, I suggest you to read the following links: - https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-UBOOT_CONFIG - https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-UBOOT_MACHINE Please not that the links I provided refers to the latest documentation, you should check the docs for your YP version. About testing, I have no idea about how to test uboot without the target board. If you are planning to use a commercial solution which is supported by Yocto, you should be safe enough for now. Gabriele Il giorno mar 2 lug 2019 alle ore 09:40 JH ha scritto: > Thanks Gabriele, you are right, it did not work in command line but it > did not complain after UBOOT_CONFIG = "nand" to local.conf, how can I > am sure it is built to boot from nand? I don't have a board to try > yet. > > Thank you very much. > > Kind regards, > > - jh > > > On 7/2/19, Gabriele Zampieri wrote: > > Hi, > > > > you must use double quotes around nand, so: > > UBOOT_CONFIG = "nand" > > > > However I cannot guarantee this line will be the solution, I usually use > a > > customized uboot. > > > > Gabriele > > > > Il giorno mar 2 lug 2019 alle ore 04:07 JH ha > > scritto: > > > >> Hi, > >> > >> The imx6ullevk.conf defined sdcard for booting on imx6 EVK: > >> > >> imx6ullevk.conf > >> > >> UBOOT_CONFIG ??= "sd" > >> UBOOT_CONFIG[sd] = "mx6ull_14x14_evk_config,sdcard" > >> UBOOT_CONFIG[mfgtool] = "mx6ull_14x14_evk_config" > >> > >> I need to change it for a customized board referenced from imx6 EVK > >> but booting from NAND, there are some blogs said it can be done to add > >> UBOOT_CONFIG=nand either in local.conf or command line. I tried it did > >> not work: > >> > >> ERROR: Unable to start bitbake server (None) > >> --- Starting bitbake server pid 2673 at 2019-07-02 11:54:24.011086 --- > >> ERROR: local.conf:34: unparsed line: 'UBOOT_CONFIG=nand' > >> > >> What should be a proper process to overwrite imx6ullevk.conf > >> UBOOT_CONFIG from sdcard to nand? > >> > >> Thank you. > >> > >> Kind regards, > >> > >> - JH > >> -- > >> ___ > >> yocto mailing list > >> yocto@yoctoproject.org > >> https://lists.yoctoproject.org/listinfo/yocto > >> > > > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Allow choose of U-Boot config for machine
Hi, you must use double quotes around nand, so: UBOOT_CONFIG = "nand" However I cannot guarantee this line will be the solution, I usually use a customized uboot. Gabriele Il giorno mar 2 lug 2019 alle ore 04:07 JH ha scritto: > Hi, > > The imx6ullevk.conf defined sdcard for booting on imx6 EVK: > > imx6ullevk.conf > > UBOOT_CONFIG ??= "sd" > UBOOT_CONFIG[sd] = "mx6ull_14x14_evk_config,sdcard" > UBOOT_CONFIG[mfgtool] = "mx6ull_14x14_evk_config" > > I need to change it for a customized board referenced from imx6 EVK > but booting from NAND, there are some blogs said it can be done to add > UBOOT_CONFIG=nand either in local.conf or command line. I tried it did > not work: > > ERROR: Unable to start bitbake server (None) > --- Starting bitbake server pid 2673 at 2019-07-02 11:54:24.011086 --- > ERROR: local.conf:34: unparsed line: 'UBOOT_CONFIG=nand' > > What should be a proper process to overwrite imx6ullevk.conf > UBOOT_CONFIG from sdcard to nand? > > Thank you. > > Kind regards, > > - JH > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Getting a package PV from another
Up, with more details: I have a top recipe that depends on *my-image:do_build*. I'd like to retrieve the PV of a couple of packages (from that top recipe) that are used to mark our custom software. Any suggestions? Gabriele Il giorno ven 28 giu 2019 alle ore 11:25 Gabriele Zampieri < gabbla.mal...@gmail.com> ha scritto: > Hi all, > > is there a way to get a specific package version from another? > > Best regards, > Gabriele > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Getting a package PV from another
Hi all, is there a way to get a specific package version from another? Best regards, Gabriele -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] General Question: Device specific value store
Hi Matthias, an easier solution may be write those data during production. I don't think that having a custom partition for each device is a good idea. You could start the device in "production mode" and inject into the device specific data through serial or USB. Obviously you must have some piece of software running on the device that can read/write that partition. In my opinion Yocto does not mention anything about this procedure probably because this is not the standard way. Gabriele Il giorno mar 25 giu 2019 alle ore 10:53 Matthias Schoepfer < matthias.schoep...@googlemail.com> ha scritto: > Hi Morné, > > thanks for you answer. Maybe, I will explain more: we have a Dragonboard > 410c based hardware. We use a read-only rootfs in one partition > (actually two with A/B approach) and we have a data partition for user > data as well as device specific data. We can partition and flash the > device through fastboot. So, if we can prepare ext4 filesystems (maybe > through yocto instead of hand-crafted scripting) for each device, > commissioning will be an easy task for the manufacturer. > > I guess, we are not the only ones that need to store device specific > information besides the rootfs, and I do not find a whole lot about it > in the yocto manuals. I wonder, if there are best practices, how to > protect the data from getting corrupted (intentionally by an attacker or > by accident through ... flash corruption or whatever). > > Regards, > > Matthias > > On 6/24/19 9:08 AM, Morné Lamprecht wrote: > > On Mon, Jun 17, 2019 at 05:25:56PM +0200, Matthias Schoepfer wrote: > >> Is there a smart, recommended way to deal with device specific data > >> (i.e. serial number, credentials for backend access, you name it), > >> that is specific for *one* device, and hence does not belong into the > >> rootfs. I know, that there are (safe) hardware stores for it, but > >> what, if your device does not have one. > > > > Not sure if I'm misunderstanding your question, but this should be > > part of your device commissioning process, i.e. like injecting > > specific security keys etc...so basically this will part of your image > > install / flash process, and not really part of the Yocto build > > process. The specifics of such a process would depend on your specific > > commissioning process. > > > > - Morné > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Running Yocto inside Docker
Hi all, thank you for your suggestions! I googled a bit more and found this guide: https://docs.gitlab.com/ce/ci/ssh_keys/README.html#ssh-keys-when-using-the-docker-executor That is exactly what I was looking for! In this way I can avoid storing keys in the containers and feeding it only when the pipe is triggered. Best regards, Gabriele Il giorno sab 22 giu 2019 alle ore 22:37 Benjamin ha scritto: > Hej, > > I use for this secret variables and store the access tokens or ssh keys in > in one of this. A script running inside of the docker container uses sed > magic for replacing string, when ever the direct usage of the secret > variables is not possible. The ssh key is then written in a first step with > something like > > echo "$SECRET_PRIVATE_SSH" > ~/.ssh/id_ecdsa && chmod 600 ~/.ssh/id_ecdsa > > gitlab will not print the secret variables in clear format. > > https://docs.gitlab.com/ee/ci/variables/#via-the-ui > > Whenever possible you should use a deploy token, best would be to add this > as well as the above mentioned ui variables. With the protected feature you > can even prevent non privileged developers from stealing this secrets. > > > https://docs.gitlab.com/ee/user/project/deploy_tokens/#creating-a-deploy-token > > > Am 17.06.19 um 20:00 schrieb Rudolf Streif: > > That's more of a Gitlab than Yocto question. I am doing this all the time > with my GL server on AWS. You need to add deploy a key to the repo you want > to access and then push the key to your Docker instance from gitlab-ci.yaml > from the repo that you are using with GL CI. > > :rjs > > On Mon, Jun 17, 2019, 07:20 Gabriele Zampieri > wrote: > >> Hi all, >> >> does anyone have a guide on how to setup Yocto to run inside docker? >> Right now I managed to trigger the build from GitLab, but I'm facing an >> issue related to ssh keys (some recipes from my meta layer are hosted on a >> privare repository). Probably this is not the best mailing list to ask this >> kind of question, but it may worth a try. >> >> Thank you, >> Gabriele >> -- >> ___ >> yocto mailing list >> yocto@yoctoproject.org >> https://lists.yoctoproject.org/listinfo/yocto >> > > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Running Yocto inside Docker
Hi all, does anyone have a guide on how to setup Yocto to run inside docker? Right now I managed to trigger the build from GitLab, but I'm facing an issue related to ssh keys (some recipes from my meta layer are hosted on a privare repository). Probably this is not the best mailing list to ask this kind of question, but it may worth a try. Thank you, Gabriele -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Share SSTATE_DIR between instances
Cool, thanks! Gabriele Il giorno lun 17 giu 2019 alle ore 14:03 Burton, Ross ha scritto: > It's always a good idea to share sstate between builds. > > Ross > > On Mon, 17 Jun 2019 at 12:32, Gabriele Zampieri > wrote: > > > > Hi all, > > > > is it a good idea to share the SSTATE_DIR between a docker container > (used with GitLab pipelines) and the local bitbake instance? They both work > on the same MACHINE. > > > > Gabriele > > -- > > ___ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Share SSTATE_DIR between instances
Hi all, is it a good idea to share the SSTATE_DIR between a docker container (used with GitLab pipelines) and the local bitbake instance? They both work on the same MACHINE. Gabriele -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] arm yocto-linux custom defconfig not working
Hi Pierluigi,
just to be clear, have you specified your defconfig in the SRC_URI of your
kernel recipe? You can write an append file (that I guess you already did)
and add:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
SRC_URI_append= " file://defconfig"
The above snippet assume that you are placing defconfig in files/
Gabriele
Il giorno gio 6 giu 2019 alle ore 15:47 Bruce Ashfield <
bruce.ashfi...@gmail.com> ha scritto:
> On Thu, Jun 6, 2019 at 9:38 AM Pierluigi Greto
> wrote:
> >
> > Hi,
> >
> > I have to create a custom 4.14.49 linux kernel. In my recipe I have
> added my defconfig, but yocto it's not taking in consideration the
> defconfig. Instead it's building the kernel using the default values. Also
> the compilation task is to fast for building the kernel. My target system
> is an arm architecture (DEFAULTTUNE ?= "cortexa9").
> > I have tried also to append this on my recipe but the result does not
> change:
>
> Can you share your kernel recipe and layer(s) + defconfig ? Things are
> working fine for me, but if I can see (and build) your recipes perhaps
> something can be spotted.
>
> Bruce
>
> >
> > do_compile_prepend() {
> > cp ${WORKDIR}/defconfig ${B}/defconfig
> > cp ${WORKDIR}/defconfig ${B}/.config
> > oe_runmake -C ${B} ARCH=${ARCH} ${S}/defconfig
> > }
> >
> > If i try to "cheat" and add cp ${WORKDIR}/defconfig ${S}/.config on the
> do_compile_prepend obviously make will not work: "kernel-source is not
> clean, please run 'make mrprop' ".
> >
> > Any suggestions is very welcome.
> >
> > Thank you,
> > Pierluigi
> >
> > --
> > ___
> > yocto mailing list
> > yocto@yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
>
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Static gcc library in SDK
Hi all, I need to link some applications with "--static" flag. To do so I need to add some static libraries in the SDK, that I've added with SDKIMAGE_FEATURES_append = " staticdev-pkgs" However, I still miss "libgcc_s.a" and I cannot find a way to add it. Any suggestions? Thanks, Gabriele -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using a native tool from another recipe
I found the problem, I was installing the package in the wrong location, so
it wasn't shown in the output SDK.
Thanks,
Gabriele
Il giorno lun 20 mag 2019 alle ore 23:55 Khem Raj ha
scritto:
> On Mon, May 13, 2019 at 11:17 PM Gabriele Zampieri
> wrote:
> >
> > Hi Khem,
> >
> > what do you mean with "build bpkg as a native recipe"? I though that the
> DEPENDS = "build2-native" will achieve this task. Thanks to pointing out
> the hosttool option.
>
> yes DEPENDS = "build2-native" should have added the needed tool to build.
>
> >
> > Best regards,
> > Gabriele
> >
> > Il giorno lun 13 mag 2019 alle ore 17:59 Khem Raj
> ha scritto:
> >>
> >> You need to either build bpkg as a native recipe or install and make it
> available as a hosttool from build machine distribution itself
> >>
> >> On Mon, May 13, 2019 at 6:07 AM Gabriele Zampieri <
> gabbla.mal...@gmail.com> wrote:
> >>>
> >>> Hi all,
> >>>
> >>> I need to add a couple of tools to my build system (build2 and odb).
> The second one depends on the first. Following a snippet of the build2
> recipe:
> >>>
>
> >>> DEPENDS = "openssl-native"
> >>> SRC_URI = "
> https://download.build2.org/${PV}/build2-toolchain-${PV}.tar.gz;
> >>> SRC_URI[sha256sum] =
> "42a254c46b59109b764afade0d50819b3d793a9167f46759fc6aa9d6d8a6ff37"
> >>>
> >>> S = "${WORKDIR}/build2-toolchain-${PV}"
> >>>
> >>> # build.sh located inside the tarball cannot be used to configure,
> compile and
> >>> # install in different steps. This task is misleading, but I didn't
> find any
> >>> # other way to make it works
> >>> do_compile_prepend() {
> >>> ./build.sh --timeout 600 --sudo false \
> >>> --make ${MAKE} ${PARALLEL_MAKE} \
> >>> --trust yes \
> >>> --install-dir ${prefix} g++
> >>> }
> >>>
> >>> FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
> >>> FILES_${PN} = "${D}${prefix}/*"
> >>>
> >>> BBCLASSEXTEND = "native nativesdk"
> >>>
>
> >>>
> >>> Then the odb-compiler recipe
> >>>
> >>>
>
> >>> SECTION = "devtools"
> >>> DEPENDS = "build2-native"
> >>> CONFIG_NAME = "odb-gcc-X"
> >>> do_configure() {
> >>> cd ${B}
> >>> bpkg create -d ${CONFIG_NAME} cc\
> >>> config.cxx=g++ \
> >>> config.cc.coptions=-O3 \
> >>> config.bin.rpath=/usr/lib \
> >>> config.install.root=/usr\
> >>> config.install.sudo=false
> >>>
> >>> }
> >>> BBCLASSEXTEND = "native nativesdk"
> >>>
>
> >>>
> >>> When I try to build odb-compiler, bitbake complete the build2-native
> recipe, but fails on do_configure due to 'bpkg command not found'.
> >>>
> >>> Are my recipes correct?
> >>>
> >>> Thanks,
> >>> Gabriele
> >>>
> >>> --
> >>> ___
> >>> yocto mailing list
> >>> yocto@yoctoproject.org
> >>> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Unable to install additional tools in SDK
Hi all,
I need to include in my native sdk the ODB compiler in order to produce
some sources. Since it is a nativesdk- only package, I wrote the following
nativesdk-odb-compiler_2.5.0.bb
inherit nativesdk
CONFIG_NAME = "odb-gcc-X"
B = "${WORKDIR}/build2"
# We must have a valid configuration before fetching
do_fetch_prepend() {
install -d ${B}
bpkg create -d ${B}/${CONFIG_NAME} cc \
--wipe \
config.cxx=g++ \
config.cc.coptions=-O3 \
config.install.root=${D}/usr
}
do_fetch() {
bpkg fetch --trust-yes \
--directory ${B}/${CONFIG_NAME} https://pkg.cppget.org/1/beta
}
do_compile() {
bpkg build odb -y ${PARALLEL_MAKE} --directory ${B}/${CONFIG_NAME}
}
do_install() {
bpkg install odb --verbose 3 --directory ${B}/${CONFIG_NAME}
}
FILES_${PN}_append = " ${SDKPATHNATIVE}"
FILES_${PN}_append = " /usr/*"
Then added the following line in my custom image recipe:
TOOLCHAIN_HOST_TASK_append = " nativesdk-odb-compiler"
Then I run bitbake -c populate_sdk and the SDK is build. Once
installed, there is no trace about ODB. I digged in the bitbake output
directories (image/, package/ and package-split/) and the file tree is
correct, also the rpm packages are generated (however the main package is
1/10th of the ODB installed tree). Maybe I'm missing something?
Thanks in advance,
Gabriele
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Using a native tool from another recipe
Hi Khem,
what do you mean with "build bpkg as a native recipe"? I though that the
DEPENDS = "build2-native" will achieve this task. Thanks to pointing out
the hosttool option.
Best regards,
Gabriele
Il giorno lun 13 mag 2019 alle ore 17:59 Khem Raj ha
scritto:
> You need to either build bpkg as a native recipe or install and make it
> available as a hosttool from build machine distribution itself
>
> On Mon, May 13, 2019 at 6:07 AM Gabriele Zampieri
> wrote:
>
>> Hi all,
>>
>> I need to add a couple of tools to my build system (build2 and odb). The
>> second one depends on the first. Following a snippet of the build2 recipe:
>>
>>
>> DEPENDS = "openssl-native"
>> SRC_URI = "
>> https://download.build2.org/${PV}/build2-toolchain-${PV}.tar.gz;
>> SRC_URI[sha256sum] =
>> "42a254c46b59109b764afade0d50819b3d793a9167f46759fc6aa9d6d8a6ff37"
>>
>> S = "${WORKDIR}/build2-toolchain-${PV}"
>>
>> # build.sh located inside the tarball cannot be used to configure,
>> compile and
>> # install in different steps. This task is misleading, but I didn't find
>> any
>> # other way to make it works
>> do_compile_prepend() {
>> ./build.sh --timeout 600 --sudo false \
>> --make ${MAKE} ${PARALLEL_MAKE} \
>> --trust yes \
>> --install-dir ${prefix} g++
>> }
>>
>> FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
>> FILES_${PN} = "${D}${prefix}/*"
>>
>> BBCLASSEXTEND = "native nativesdk"
>>
>>
>>
>> Then the odb-compiler recipe
>>
>>
>>
>> SECTION = "devtools"
>> DEPENDS = "build2-native"
>> CONFIG_NAME = "odb-gcc-X"
>> do_configure() {
>> cd ${B}
>> bpkg create -d ${CONFIG_NAME} cc\
>> config.cxx=g++ \
>> config.cc.coptions=-O3 \
>> config.bin.rpath=/usr/lib \
>> config.install.root=/usr\
>> config.install.sudo=false
>>
>> }
>> BBCLASSEXTEND = "native nativesdk"
>>
>>
>>
>> When I try to build odb-compiler, bitbake complete the build2-native
>> recipe, but fails on do_configure due to 'bpkg command not found'.
>>
>> Are my recipes correct?
>>
>> Thanks,
>> Gabriele
>>
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Using a native tool from another recipe
Hi all,
I need to add a couple of tools to my build system (build2 and odb). The
second one depends on the first. Following a snippet of the build2 recipe:
DEPENDS = "openssl-native"
SRC_URI = "https://download.build2.org/${PV}/build2-toolchain-${PV}.tar.gz;
SRC_URI[sha256sum] =
"42a254c46b59109b764afade0d50819b3d793a9167f46759fc6aa9d6d8a6ff37"
S = "${WORKDIR}/build2-toolchain-${PV}"
# build.sh located inside the tarball cannot be used to configure, compile
and
# install in different steps. This task is misleading, but I didn't find any
# other way to make it works
do_compile_prepend() {
./build.sh --timeout 600 --sudo false \
--make ${MAKE} ${PARALLEL_MAKE} \
--trust yes \
--install-dir ${prefix} g++
}
FILES_${PN}_append_class-nativesdk = " ${SDKPATHNATIVE}"
FILES_${PN} = "${D}${prefix}/*"
BBCLASSEXTEND = "native nativesdk"
Then the odb-compiler recipe
SECTION = "devtools"
DEPENDS = "build2-native"
CONFIG_NAME = "odb-gcc-X"
do_configure() {
cd ${B}
bpkg create -d ${CONFIG_NAME} cc\
config.cxx=g++ \
config.cc.coptions=-O3 \
config.bin.rpath=/usr/lib \
config.install.root=/usr\
config.install.sudo=false
}
BBCLASSEXTEND = "native nativesdk"
When I try to build odb-compiler, bitbake complete the build2-native
recipe, but fails on do_configure due to 'bpkg command not found'.
Are my recipes correct?
Thanks,
Gabriele
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to define and build device tree in Yocto?
Hi all,
Bas' defconfig trick (do_set_custom_defconfig) is already implemented by
Yocto itself: just add a file called defconfig to SRC_URI and the system
will apply it for you (you can read kernel_do_configure in kernel.bbclass)
. For more information check
https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#changing-the-configuration
> how did you do the defconfig usually?
The link I put above asks this question too.
>> # The first patch simply appends my custom DTS to the list of DTD files
in the Makefile
and
>> I usually don't need to make large modifications to the kernel source,
>> so I don't need to clone the kernel, but use the default kernel for the
>> SoC with some patches.
How do you generate that patches?
I know that the kernel repo is huge, but having a local kernel tree can be
very useful and allows you to do all the patchworks easily. It also speeds
up the test if you are planning to upgrade some part of it.
Best regards,
Gabriele
Il giorno mar 7 mag 2019 alle ore 02:14 JH ha
scritto:
> Hi Bas and Gabriele,
>
> Thank you so much for you advice.
>
> > My usual way of doing it is as follows:
> >
> > I usually don't need to make large modifications to the kernel source,
> > so I don't need to clone the kernel, but use the default kernel for the
> > SoC with some patches.
>
> So do I.
>
> > I use a platform support layer and add a .bbappend file for the (arm)
> > kernel to add a custom dts and .config files, together with some small
> > patches:
> >
> > *** File meta-/recipes-kernel/linux/linux-_%.bbappend:
> >
> > THISAPPENDFILESDIR := "${THISDIR}/files"
> > FILESEXTRAPATHS_prepend := "${THISDIR}/files:"
> >
> > require linux-set-custom-defconfig.inc
> > require linux-add-custom-dts.inc
> >
> > # The first patch simply appends my custom DTS to the list of DTD files
> > in the Makefile
> > SRC_URI += \
> > "file://add-custom-dts.patch \
> > file://some_other.patch \
> > file://another_driver_patch.patch \
> > "
> >
> > *** File meta-/recipes-kernel/linux/linux-add-custom-dts.inc
> >
> > do_add_platform_dts() {
> > cp -f "${THISAPPENDFILESDIR}/custom.dts" \
> > "${WORKDIR}/git/arch/arm/boot/dts"
> > }
>
> That is exactly I am looking for the proper location of the dts files,
> thank you so much.
>
> > addtask add_platform_dts before do_preconfigure after do_patch
> >
> > *** File
> > meta-/recipes-kernel/linux/linux-set-custom-defconfig.inc
> >
> > do_set_custom_defconfig() {
> > cp -f "${THISAPPENDFILESDIR}/defconfig" "${WORKDIR}/defconfig"
> > }
> >
> > addtask set_custom_defconfig before do_preconfigure after do_patch
>
> Good advice, I missed that one, how did you do the defconfig usually?
> Compile it in kernel source like using following command?
>
> make ARCH=arm imx_v6_v7_defconfig
>
> > It is maybe a bit complex, but it saves cloning the kernel for the sake
> > of just adding a single DTS with defconfig and a few patches.
>
> That is procedure I was looking for.
>
> > Hope this helps,
>
> Great helps, thank you so much.
>
> - jupiter
>
> > Bas.
> >
> --
> ___
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Multiple ubifs partition
Perfect, thank you!
Gabriele
Il giorno lun 6 mag 2019 alle ore 14:15 Ulrich Ölmann <
u.oelm...@pengutronix.de> ha scritto:
> Hi Gabriele,
>
> On Mon, May 06 2019 at 13:32 +0200, Gabriele Zampieri <
> gabbla.mal...@gmail.com> wrote:
> > thank you very much for your explanation. The provided genimage.config
> > looks similar to mine, so I guess it is ok. I will try when I come back
> to
> > the office. The point I missed was that I need to call: bitbake
> > your-customized-ubi and not bitbake my-custom-image, right?
>
> correct - "my-custom-image" will indirectly become a dependency via the
> variable GENIMAGE_ROOTFS_IMAGE, see [1].
>
> Best regards
> Ulrich
>
>
> [1]
> https://github.com/pengutronix/meta-ptx/blob/master/classes/genimage.bbclass#L88
>
> > Thank you again,
> > Gabriele
> >
> >
> > Il giorno ven 3 mag 2019 alle ore 07:59 Ulrich Ölmann <
> > u.oelm...@pengutronix.de> ha scritto:
> >
> >> Hi Gabriele,
> >>
> >> On Thu, May 02 2019 at 13:25 +0200, Gabriele Zampieri <
> >> gabbla.mal...@gmail.com> wrote:
> >> > ok, I guess I miss-understand how that class works. I thought that I
> >> > had to add the customization on my own image recipe.
> >> > So the correct way is to write a 'customization recipe' and install
> >> > via IMAGE_INSTALL? Can you provide an example?
> >>
> >> use your custom image recipe as before to just produce your root-
> >> filesystem which results in a (compressed) tar-file in ${DEPLOY_DIR_
> >> IMAGE}. It will be referenced from the genimage recipe without any file
> >> extension via GENIMAGE_ROOTFS_IMAGE. Now your UBI-recipe (e.g. 'your-
> >> customized-ubi.bb') could look like
> >>
> >> inherit genimage
> >> LICENSE = "MIT"
> >> LIC_FILES_CHKSUM =
> >>
> "file://${COREBASE}/meta/files/common-licenses/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
> >>
> >> SRC_URI += "file://genimage.config"
> >>
> >> # to not confuse the flashable UBI-image ('ubi')
> >> # with the UBI-filesystems ('ubifs') it contains
> >> GENIMAGE_IMAGE_SUFFIX = "ubi"
> >>
> >> # the name of the root-filesystem genimage should use
> >> GENIMAGE_ROOTFS_IMAGE = "your-customized-rootfs"
> >>
> >> with the accompanying 'genimage.config' for example as follows
> >>
> >> #
> >> # Manufacturer ID: 0x2c, Chip ID: 0xda
> >> # -> Micron MT29F2G08ABAEAWP
> >> # 256 MiB, SLC
> >> #
> >> flash nand {
> >> pebsize = 131072
> >> lebsize = 126976
> >> numpebs = 2044
> >> minimum-io-unit-size = 2048
> >> sub-page-size = 2048
> >> }
> >>
> >> image @IMAGE@ {
> >> flashtype = "nand"
> >> ubi {
> >> }
> >>
> >> partition rootfs {
> >> image = rootfs.ubifs
> >> size = 64MiB
> >> }
> >>
> >> partition opt {
> >> image = opt.ubifs
> >> size = 32MiB
> >> }
> >>
> >> partition data {
> >> image = data.ubifs
> >> autoresize = true
> >> }
> >> }
> >>
> >> image rootfs.ubifs {
> >> flashtype = "nand"
> >> ubifs {
> >> extraargs = "-x lzo"
> >> max-size = 64MiB
> >> }
> >> mountpoint = "/"
> >> }
> >>
> >> image opt.ubifs {
> >> flashtype = "nand"
> >> ubifs {
> >> extraargs = "-x lzo"
> >> max-size = 32MiB
> >> }
> >> mountpoint = "/opt"
> >> }
> >>
> >> image data.ubifs {
> >> flashtype = "nand"
> >> ubifs {
> >> extraargs = "-x lzo"
> >> max-size = 192MiB
> >> }
> >> mountpoint = "/data"
> >> }
> >>
> >> In a UBI-image almost all UBI-volumes need to have a fixed size and only
> >>
Re: [yocto] Multiple ubifs partition
Hi Ulrich,
thank you very much for your explanation. The provided genimage.config
looks similar to mine, so I guess it is ok. I will try when I come back to
the office. The point I missed was that I need to call: bitbake
your-customized-ubi and not bitbake my-custom-image, right?
Thank you again,
Gabriele
Il giorno ven 3 mag 2019 alle ore 07:59 Ulrich Ölmann <
u.oelm...@pengutronix.de> ha scritto:
> Hi Gabriele,
>
> On Thu, May 02 2019 at 13:25 +0200, Gabriele Zampieri <
> gabbla.mal...@gmail.com> wrote:
> > ok, I guess I miss-understand how that class works. I thought that I
> > had to add the customization on my own image recipe.
> > So the correct way is to write a 'customization recipe' and install
> > via IMAGE_INSTALL? Can you provide an example?
>
> use your custom image recipe as before to just produce your root-
> filesystem which results in a (compressed) tar-file in ${DEPLOY_DIR_
> IMAGE}. It will be referenced from the genimage recipe without any file
> extension via GENIMAGE_ROOTFS_IMAGE. Now your UBI-recipe (e.g. 'your-
> customized-ubi.bb') could look like
>
> inherit genimage
> LICENSE = "MIT"
> LIC_FILES_CHKSUM =
> "file://${COREBASE}/meta/files/common-licenses/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
>
> SRC_URI += "file://genimage.config"
>
> # to not confuse the flashable UBI-image ('ubi')
> # with the UBI-filesystems ('ubifs') it contains
> GENIMAGE_IMAGE_SUFFIX = "ubi"
>
> # the name of the root-filesystem genimage should use
> GENIMAGE_ROOTFS_IMAGE = "your-customized-rootfs"
>
> with the accompanying 'genimage.config' for example as follows
>
> #
> # Manufacturer ID: 0x2c, Chip ID: 0xda
> # -> Micron MT29F2G08ABAEAWP
> # 256 MiB, SLC
> #
> flash nand {
> pebsize = 131072
> lebsize = 126976
> numpebs = 2044
> minimum-io-unit-size = 2048
> sub-page-size = 2048
> }
>
> image @IMAGE@ {
> flashtype = "nand"
> ubi {
> }
>
> partition rootfs {
> image = rootfs.ubifs
> size = 64MiB
> }
>
> partition opt {
> image = opt.ubifs
> size = 32MiB
> }
>
> partition data {
> image = data.ubifs
> autoresize = true
> }
> }
>
> image rootfs.ubifs {
> flashtype = "nand"
> ubifs {
> extraargs = "-x lzo"
> max-size = 64MiB
> }
> mountpoint = "/"
> }
>
> image opt.ubifs {
> flashtype = "nand"
> ubifs {
> extraargs = "-x lzo"
> max-size = 32MiB
> }
> mountpoint = "/opt"
> }
>
> image data.ubifs {
> flashtype = "nand"
> ubifs {
> extraargs = "-x lzo"
> max-size = 192MiB
> }
> mountpoint = "/data"
> }
>
> In a UBI-image almost all UBI-volumes need to have a fixed size and only
> one is allowed to use the autoresize mechanism which blows it up to use
> the remaining space when it is UBI-attached for the first time. Distinct
> from that is the UBI-filesystem's max-size parameter which prescribes
> the maximum size of an UBI-volume that shall be addressable by this
> filesystem. This means that if you would re-use 'data.ubifs' in a volume
> that has been autoresized to e.g. 1024MiB the filesystem would not be
> able to make use of it.
>
> I neither tested the recipe nor the genimage.config, so please give some
> feedback.
>
> Best regards
> Ulrich
>
>
> > Thanks,
> > Gabriele
> >
> > Il giorno mer 24 apr 2019 alle ore 15:15 Ulrich Ölmann <
> > u.oelm...@pengutronix.de> ha scritto:
> >
> >> Hi Gabriele,
> >>
> >> On Wed, Apr 24 2019 at 14:06 +0200, Gabriele Zampieri <
> >> gabbla.mal...@gmail.com> wrote:
> >> > I'm now testing genimage via meta-ptx in my Yocto workflow, but I
> found a
> >> > problem: I cannot set a SRC_URI in my custom image recipe (that
> inherit
> >> > from core-image which in turn inherit from image) because do_fetch and
> >> > do_unpack tasks have noexec set to 1. If I specify the SRC_URI with my
> >> > genimage.config, bitbake exits, complaining about LIC_FILE_CHECKSUM
> (that
> >> > is correctly specified). If I hack image.bbclass and commen
Re: [yocto] How to define and build device tree in Yocto?
Hi,
> but there is no imx6ull-14x14-evk.dts
it is located in arch/arm/boot/dts/imx6ull-14x14-evk.dts and it is compiled
(among others dts) while building virtual/kernel task.
Setting KERNEL_DEVICETREE = "imx6ull-14x14-evk.dtb" simply tells to
bitbake to put a copy of imx6ull-14x14-evk.dtb inside your image deploy
directory. You can dig through meta/classes/kernel-devicetree.bbclass to
see how KERNEL_DEVICETREE is used.
If you do not need to modify the dts, you will find all the image related
stuff in poky/build/tmp/deploy/images//.
If you need to patch the dts (or any other kernel related file):
- Clone you kernel source tree locally
- Checkout the correct branch
- Do your edits, then commit
- Get a patch with the customization through git format-patch (or any other
way)
Now, in your meta layer:
- create recipes-kernel/linux/.bbappend file
- create recipes-kernel/linux/files// directory
Then:
- Copy your patch in recipes-kernel/linux/files/
- Edit the bbappend file with:
FILESEXTRAPATHS_prepend := "${THISDIR}/files:" # Add files to the search
paths
SRC_URI_append_ = " file://0001-your-commit-message.patch"
bitbake will apply the patch after the kernel unpack automatically, then
build the tree with the patch(es) applied.
You can also add a completely new dts via patch, then add it to
KERNEL_DEVICETREE.
Best regards,
Gabriele
Il giorno lun 6 mag 2019 alle ore 09:36 JH ha
scritto:
> Thanks Gabriele,
>
> Yes, I have already added KERNEL_DEVICETREE = "imx6ull-14x14-evk.dtb"
> to generate an image running on imx6 EVK. What I don't understand is
> how that imx6ull-14x14-evk.dtb was compiled? I thought all dtb are
> compiled from dts files, but there is no imx6ull-14x14-evk.dts, the
> imx6ullevk.conf defined the EVK but there is no detail in that file.
>
> My second question is my new hardware based on imx6ull MCU now has a
> dts file, since I could not see any samples how is the dtb compiled
> from a dts file, I have no idea where to put the dts file, how to link
> that dts file to generate a dtb file in recipe. Appreciate more
> clarification.
>
> Thank you.
>
> - jh
>
> On 5/6/19, Gabriele Zampieri wrote:
> > Hi,
> >
> > The easiest way is to add them via patches. You can write a recipe that
> > patch the Linux tree and put it in your meta layer (usually in
> > meta-xxx/recipes-kernel/linux). Then you need to tell Yocto to export the
> > dtb via KERNEL_DEVICETREE variable (
> >
> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-KERNEL_DEVICETREE
> ).
> > I usually put this variable in my machine configuration.
> >
> > Gabriele
> >
> > Il giorno dom 5 mag 2019 alle ore 14:04 JH ha
> > scritto:
> >
> >> Hi,
> >>
> >> I think the device tree blob is build from device tree source, but I
> >> could not find any dts files in recipe source directory, there are
> >> many dts files in build directory and there are dtb in build
> >> directory.
> >>
> >> If I have a device tree source, where I should put it and how to
> >> define the recipe to built it?
> >>
> >> Thank you.
> >>
> >> Kind regards,
> >>
> >> - jupiter
> >> --
> >> ___
> >> yocto mailing list
> >> yocto@yoctoproject.org
> >> https://lists.yoctoproject.org/listinfo/yocto
> >>
> >
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] How to define and build device tree in Yocto?
Hi, The easiest way is to add them via patches. You can write a recipe that patch the Linux tree and put it in your meta layer (usually in meta-xxx/recipes-kernel/linux). Then you need to tell Yocto to export the dtb via KERNEL_DEVICETREE variable ( https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#var-KERNEL_DEVICETREE). I usually put this variable in my machine configuration. Gabriele Il giorno dom 5 mag 2019 alle ore 14:04 JH ha scritto: > Hi, > > I think the device tree blob is build from device tree source, but I > could not find any dts files in recipe source directory, there are > many dts files in build directory and there are dtb in build > directory. > > If I have a device tree source, where I should put it and how to > define the recipe to built it? > > Thank you. > > Kind regards, > > - jupiter > -- > ___ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Multiple ubifs partition
Hi Ulrich, ok, I guess I miss-understand how that class works. I thought that I had to add the customization on my own image recipe. So the correct way is to write a 'customization recipe' and install via IMAGE_INSTALL? Can you provide an example? Thanks, Gabriele Il giorno mer 24 apr 2019 alle ore 15:15 Ulrich Ölmann < u.oelm...@pengutronix.de> ha scritto: > Hi Gabriele, > > On Wed, Apr 24 2019 at 14:06 +0200, Gabriele Zampieri < > gabbla.mal...@gmail.com> wrote: > > I'm now testing genimage via meta-ptx in my Yocto workflow, but I found a > > problem: I cannot set a SRC_URI in my custom image recipe (that inherit > > from core-image which in turn inherit from image) because do_fetch and > > do_unpack tasks have noexec set to 1. If I specify the SRC_URI with my > > genimage.config, bitbake exits, complaining about LIC_FILE_CHECKSUM (that > > is correctly specified). If I hack image.bbclass and comment out > > > > #do_fetch[noexec] = "1" > > > > > > #do_unpack[noexec] = "1" > > > > The process start correctly. Is there a way to avoid touching > image.bbclass > > and install my configuration from the image recipe? > > > > Thanks, > > Gabriele > > you need one or more recipe(s) that construct(s) your filesystem(s) and > a separate one that makes a flashable image out of that (see the > introductory documentation in 'genimage.bbclass'). In the former you > inherit 'core-image' and only in the latter which inherits 'genimage' > you have to set the SRC_URI to point to your 'genimage.config'. > > Best regards > Ulrich > > > > Il giorno mer 13 mar 2019 alle ore 16:14 Gabriele Zampieri < > > gabbla.mal...@gmail.com> ha scritto: > > > >> Hi all, > >> > >> thank you very much for the suggestion, I will check genimage and test > it. > >> > >> Gabriele > >> > >> Il giorno gio 7 mar 2019 alle ore 16:23 Ulrich Ölmann < > >> u.oelm...@pengutronix.de> ha scritto: > >> > >>> Hi there, > >>> > >>> On Thu, Mar 07 2019 at 15:11 +0100, Stelling2 Carsten < > >>> carsten.stelli...@goerlitz.com> wrote: > >>> > Have you seen https://github.com/pengutronix/genimage? > >>> > >>> you can find it included within > https://github.com/pengutronix/meta-ptx > >>> with an accompanying genimage.bbclass. > >>> > >>> Best regards > >>> Ulrich > >>> > >>> > Regards, > >>> > > >>> > Carsten > >>> > > >>> > Von: yocto-boun...@yoctoproject.org [mailto: > >>> yocto-boun...@yoctoproject.org] Im Auftrag von Gabriele Zampieri > >>> > Gesendet: Montag, 4. März 2019 12:17 > >>> > An: yocto@yoctoproject.org > >>> > Betreff: [yocto] Multiple ubifs partition > >>> > > >>> > Hi all, > >>> > > >>> > I'm trying to build a distribution that has multiple partitions. The > >>> desiderata is something like: > >>> > > >>> > - rootfs.ubifs mounted on / > >>> > - data.ubifs mounted on /data > >>> > - opt.ubifs mounted on /opt > >>> > > >>> > I was wondering if there is a standard way to achieve the goal. I see > >>> that there is a tool called wic, but it does not seems to support > ubifs. I > >>> could post process the tarball image and doing stuff with my scripts, > but > >>> I'd prefer doing this in a single bitbake run. Can you suggest > something? > >>> > > >>> > Thanks, > >>> > Gabriele > >>> > >>> > >>> -- > >>> Pengutronix e.K. | Ulrich Ölmann >| > >>> Industrial Linux Solutions | > http://www.pengutronix.de/ > >>> | > >>> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 > | > >>> Amtsgericht Hildesheim, HRA 2686 | Fax: > +49-5121-206917- | > >>> > >> > > > -- > Pengutronix e.K. | Ulrich Ölmann | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Multiple ubifs partition
Hi again, I'm now testing genimage via meta-ptx in my Yocto workflow, but I found a problem: I cannot set a SRC_URI in my custom image recipe (that inherit from core-image which in turn inherit from image) because do_fetch and do_unpack tasks have noexec set to 1. If I specify the SRC_URI with my genimage.config, bitbake exits, complaining about LIC_FILE_CHECKSUM (that is correctly specified). If I hack image.bbclass and comment out #do_fetch[noexec] = "1" #do_unpack[noexec] = "1" The process start correctly. Is there a way to avoid touching image.bbclass and install my configuration from the image recipe? Thanks, Gabriele Il giorno mer 13 mar 2019 alle ore 16:14 Gabriele Zampieri < gabbla.mal...@gmail.com> ha scritto: > Hi all, > > thank you very much for the suggestion, I will check genimage and test it. > > Gabriele > > Il giorno gio 7 mar 2019 alle ore 16:23 Ulrich Ölmann < > u.oelm...@pengutronix.de> ha scritto: > >> Hi there, >> >> On Thu, Mar 07 2019 at 15:11 +0100, Stelling2 Carsten < >> carsten.stelli...@goerlitz.com> wrote: >> > Have you seen https://github.com/pengutronix/genimage? >> >> you can find it included within https://github.com/pengutronix/meta-ptx >> with an accompanying genimage.bbclass. >> >> Best regards >> Ulrich >> >> > Regards, >> > >> > Carsten >> > >> > Von: yocto-boun...@yoctoproject.org [mailto: >> yocto-boun...@yoctoproject.org] Im Auftrag von Gabriele Zampieri >> > Gesendet: Montag, 4. März 2019 12:17 >> > An: yocto@yoctoproject.org >> > Betreff: [yocto] Multiple ubifs partition >> > >> > Hi all, >> > >> > I'm trying to build a distribution that has multiple partitions. The >> desiderata is something like: >> > >> > - rootfs.ubifs mounted on / >> > - data.ubifs mounted on /data >> > - opt.ubifs mounted on /opt >> > >> > I was wondering if there is a standard way to achieve the goal. I see >> that there is a tool called wic, but it does not seems to support ubifs. I >> could post process the tarball image and doing stuff with my scripts, but >> I'd prefer doing this in a single bitbake run. Can you suggest something? >> > >> > Thanks, >> > Gabriele >> >> >> -- >> Pengutronix e.K. | Ulrich Ölmann | >> Industrial Linux Solutions | http://www.pengutronix.de/ >> | >> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| >> Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | >> > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] shared cmake modules
Hi,
yes, following:
- cmake-modules.bb https://pastebin.com/5VqN9msS
- xxx-log.bb : https://pastebin.com/LYcPW3hc
The first one install the modules, thus is a dependency of many libraries,
the second one is a simple logger library that uses first's module
Thanks for your help,
Gabriele
Il giorno lun 8 apr 2019 alle ore 19:05 Henrik Lindblom <
henriklindbloms...@gmail.com> ha scritto:
> FILES_${PN}-dev = "${MODULES_DEST_PATH}/*"
>>
>
> Does your library recipe explicitly depend on -dev? Can you
> share the failing recipe?
>
> Cheers,
> Henrik
>
> On Wed, Apr 3, 2019 at 1:18 PM Gabriele Zampieri
> wrote:
>
>> Hi all,
>>
>> I'm setting up a layer that will compile our applications and libraries.
>> All the applications are based on cmake and they share modules. Before
>> using yocto I kept the modules in /cmake (under version control)
>> alongside applications and libraries. With yocto I wrote a recipe that
>> checkout the module repo and install them in
>> "${STAGING_DATADIR}/cmake/Modules/". I took this path from
>> "meta/classes/cmake.bbclass". If i build the module target, I get the files
>> installed in the target recipe datadir. If I want to build a library (that
>> depends also on my modules recipe) the task do_configure fails because
>> cmake cannot find none of my include. Digging around I found that the
>> toolchain.cmake file points to a module location that doesn't exist in the
>> library workdir, but in module recipe (${STAGING_DATADIR}/cmake/Modules/).
>>
>> The module recipe looks like as follow:
>>
>> MODULES_DEST_PATH = "${STAGING_DATADIR}/cmake/Modules"
>> FILES_${PN}-dev = "${MODULES_DEST_PATH}/*"
>>
>> do_install() {
>> DEST_DIR=${MODULES_DEST_PATH}
>>
>> # Create the destination folder
>> install -d $DEST_DIR
>> install -m 0444 ${S}/my/module.cmake $DEST_DIR
>> ..
>> }
>>
>> So my question is: where should I install the shared modules
>> (MODULE_DEST_PATH int the above snippet)? and how to update the
>> CMAKE_MODULE_PATH properly to append that location?
>>
>> Thanks,
>> Gabriele
>> --
>> ___
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>>
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] shared cmake modules
bump
Il giorno mer 3 apr 2019 alle ore 12:07 Gabriele Zampieri <
gabbla.mal...@gmail.com> ha scritto:
> Hi all,
>
> I'm setting up a layer that will compile our applications and libraries.
> All the applications are based on cmake and they share modules. Before
> using yocto I kept the modules in /cmake (under version control)
> alongside applications and libraries. With yocto I wrote a recipe that
> checkout the module repo and install them in
> "${STAGING_DATADIR}/cmake/Modules/". I took this path from
> "meta/classes/cmake.bbclass". If i build the module target, I get the files
> installed in the target recipe datadir. If I want to build a library (that
> depends also on my modules recipe) the task do_configure fails because
> cmake cannot find none of my include. Digging around I found that the
> toolchain.cmake file points to a module location that doesn't exist in the
> library workdir, but in module recipe (${STAGING_DATADIR}/cmake/Modules/).
>
> The module recipe looks like as follow:
>
> MODULES_DEST_PATH = "${STAGING_DATADIR}/cmake/Modules"
> FILES_${PN}-dev = "${MODULES_DEST_PATH}/*"
>
> do_install() {
> DEST_DIR=${MODULES_DEST_PATH}
>
> # Create the destination folder
> install -d $DEST_DIR
> install -m 0444 ${S}/my/module.cmake $DEST_DIR
> ..
> }
>
> So my question is: where should I install the shared modules
> (MODULE_DEST_PATH int the above snippet)? and how to update the
> CMAKE_MODULE_PATH properly to append that location?
>
> Thanks,
> Gabriele
>
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] shared cmake modules
Hi all,
I'm setting up a layer that will compile our applications and libraries.
All the applications are based on cmake and they share modules. Before
using yocto I kept the modules in /cmake (under version control)
alongside applications and libraries. With yocto I wrote a recipe that
checkout the module repo and install them in
"${STAGING_DATADIR}/cmake/Modules/". I took this path from
"meta/classes/cmake.bbclass". If i build the module target, I get the files
installed in the target recipe datadir. If I want to build a library (that
depends also on my modules recipe) the task do_configure fails because
cmake cannot find none of my include. Digging around I found that the
toolchain.cmake file points to a module location that doesn't exist in the
library workdir, but in module recipe (${STAGING_DATADIR}/cmake/Modules/).
The module recipe looks like as follow:
MODULES_DEST_PATH = "${STAGING_DATADIR}/cmake/Modules"
FILES_${PN}-dev = "${MODULES_DEST_PATH}/*"
do_install() {
DEST_DIR=${MODULES_DEST_PATH}
# Create the destination folder
install -d $DEST_DIR
install -m 0444 ${S}/my/module.cmake $DEST_DIR
..
}
So my question is: where should I install the shared modules
(MODULE_DEST_PATH int the above snippet)? and how to update the
CMAKE_MODULE_PATH properly to append that location?
Thanks,
Gabriele
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Fwd: Trimming BOOST libraries installed
Forgot to include the mailing list -- Forwarded message - Da: Gabriele Zampieri Date: gio 28 mar 2019 alle ore 13:38 Subject: Re: [yocto] Trimming BOOST libraries installed To: Burton, Ross Thank you for the fast reply. So I just specify the dependencies in my recipes, and then remove IMAGE_INSTALL_append = " boost". Am I right? Which name should I use with DEPEND? Thanks, Gabriele Il giorno gio 28 mar 2019 alle ore 13:15 Burton, Ross ha scritto: > On Thu, 28 Mar 2019 at 10:59, Gabriele Zampieri > wrote: > > I'm building a custom image that install boost libraries: > > > > IMAGE_INSTALL_append = " boost" > > > > How can I trim the installed libraries? I see inside > meta/recipes-support/boost/boost.inc a variable called BOOST_LIBS that > lists all the boost components, so in my custom-image.bb I tried: > > The easy solution is to not do that. The application you're building > should DEPEND on boost and then the RDEPENDS will be populated for > you, and be the required set not the full set. > > If you really want to explicitly install some packages, then don't > install "boost" which is a meta-package depending on all boost > libraries. The sub-libraries are called eg boost-atomic. > > Ross > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Trimming BOOST libraries installed
Hi all, I'm building a custom image that install boost libraries: IMAGE_INSTALL_append = " boost" How can I trim the installed libraries? I see inside meta/recipes-support/boost/boost.inc a variable called BOOST_LIBS that lists all the boost components, so in my custom-image.bb I tried: BOOST_LIBS_remove = " atomic" but the produced image still integrate the libboost_atomic. My layer have an higher priority (11) than meta (5). Any tips? Thanks, Gabriele -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Multiple ubifs partition
Hi all, thank you very much for the suggestion, I will check genimage and test it. Gabriele Il giorno gio 7 mar 2019 alle ore 16:23 Ulrich Ölmann < u.oelm...@pengutronix.de> ha scritto: > Hi there, > > On Thu, Mar 07 2019 at 15:11 +0100, Stelling2 Carsten < > carsten.stelli...@goerlitz.com> wrote: > > Have you seen https://github.com/pengutronix/genimage? > > you can find it included within https://github.com/pengutronix/meta-ptx > with an accompanying genimage.bbclass. > > Best regards > Ulrich > > > Regards, > > > > Carsten > > > > Von: yocto-boun...@yoctoproject.org [mailto: > yocto-boun...@yoctoproject.org] Im Auftrag von Gabriele Zampieri > > Gesendet: Montag, 4. März 2019 12:17 > > An: yocto@yoctoproject.org > > Betreff: [yocto] Multiple ubifs partition > > > > Hi all, > > > > I'm trying to build a distribution that has multiple partitions. The > desiderata is something like: > > > > - rootfs.ubifs mounted on / > > - data.ubifs mounted on /data > > - opt.ubifs mounted on /opt > > > > I was wondering if there is a standard way to achieve the goal. I see > that there is a tool called wic, but it does not seems to support ubifs. I > could post process the tarball image and doing stuff with my scripts, but > I'd prefer doing this in a single bitbake run. Can you suggest something? > > > > Thanks, > > Gabriele > > > -- > Pengutronix e.K. | Ulrich Ölmann | > Industrial Linux Solutions | http://www.pengutronix.de/ | > Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| > Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | > -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Recipe require kernel headers
Hi all,
I have a custom recipe that builds and installs a C program that include:
#include
#include
#include
I can compile it with TI prebuilt SDK, but when I try to build it with
yocto the compiler is unable to find those headers.
In the recipe do_compile I simply execute:
${CC} ${CFLAGS} ${S}/program.c -o program
(as I do with the prebuild SDK). But the compilation fails due to the
missing headers. I could a list of include paths to ${CC}, pointing to the
location in the kernel tree, but I don't really like it as solution. The
prebuild SDK install those file in
/sysroots//usr/include (and append that
path to CFLAGS through the env setup script). Moreover, if I build the
image without my recipe and I look for the headers I find them in rootfs,
but not in recipe-sysroot. The Yocto system I'm using is based on TI arago
customization.
How can I add the sanitized kernel heders to the recipe-sysroot or use them
to build my tool?
Thanks in advance,
Gabriele
--
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Multiple ubifs partition
Hi all, I'm trying to build a distribution that has multiple partitions. The desiderata is something like: - rootfs.ubifs mounted on / - data.ubifs mounted on /data - opt.ubifs mounted on /opt I was wondering if there is a standard way to achieve the goal. I see that there is a tool called wic, but it does not seems to support ubifs. I could post process the tarball image and doing stuff with my scripts, but I'd prefer doing this in a single bitbake run. Can you suggest something? Thanks, Gabriele -- ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
