[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

Re: [yocto] cortexa9t2hf instead of cortexa9hf

Hello Arno, Your question, per say, has little to do with YOCTO forum. But I'll try (as my best) to answer your question. Cortexa9hf should be armv7 A9 Hard Floating (it contains HW FP unit). Cortexa9t2hf is by analogy armv7 A9 T2 Hard Floating. Now, the question is what is T2? T2 is addition

Re: [yocto] cortexa9t2hf instead of cortexa9hf

Hello Arno, Let me try to explain my point of view. Since here (my best guess) we have some asynchronous bitbake code which went South upon introducing T2 HW extension. Point [1]: as far as I understand arm, cortexa9t2hf is is just a superset of previous cortexa9hf (HW wise). NEON HW extension

Re: [yocto] cortexa9t2hf instead of cortexa9hf

Hello Zoran, thanks. As far as I understand is thumb2 another mode of coding, that might create more compact code. But I want to keep all compatible to my previous tool-chain and settings. The only file where I can found this "cortexa9t2hf" is ./meta/conf/machine/include/tune-cortexa9.inc but I

[yocto] General Question: Device specific value store

Hi! I have a general, maybe dumb question. 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)

Re: [yocto] [meta-swupdate] failed update leads to kernel panic

Hi Zoran On 17.06.19 12:55, Zoran Stojsavljevic wrote: I have a feeling that I misunderstand something about the ramdisk. To my understanding this is the microcode.cpio file which is invoked lastly in the grub entry. Being you, I would for the starters exclude swupdate layer and see if

Re: [yocto] Share SSTATE_DIR between instances

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

[yocto] cortexa9t2hf instead of cortexa9hf

I switched from Yocto 2.5 to 2.7 and recognised a new architetcure name. Instead of cortexa9hf it is now build for cortexa9t2hf? Did I do something wrong or what exactly does this t2 mean? Target system is a Zynq7020 system. -- ___ yocto mailing list

Re: [yocto] [meta-swupdate] failed update leads to kernel panic

> I have a feeling that I misunderstand something about the ramdisk. > To my understanding this is the microcode.cpio file which is invoked > lastly in the grub entry. Being you, I would for the starters exclude swupdate layer and see if everything works without swupdate: does normally work with

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

[yocto] Bash-based build tool/environment u2up-yocto

Hi, I am new to the yocto mailing list and i would like to share my bash-based tool/environment to build a yocto-based linux distribution. The tool/environment is called u2up-yocto and can be found here: https://github.com/spog/u2up-yocto Using u2up-yocto, i tried to achieve a few goals: 1)

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on the triage page under the appropriate heading:

[yocto] devshell env in warrior

I'm trying to figure out why when running devshell in Warrior CC/CFLAGS are not the same as do_compile for a recipe. For example. devshell printenv yields: CC=aarch64-poky-linux-gcc -fuse-ld=bfd

Re: [yocto] [meta-swupdate] failed update leads to kernel panic

> I see the bundle_initramfs task being executed if I do any > changes. The boot process works without swupdate in the > image. If anything was wrong with the initramfs the whole > system shouldn't be able to boot properly. I don't get what > you suggest me to try. It is just Divide and Conquer

[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

Re: [yocto] cortexa9t2hf instead of cortexa9hf

See this oe-core commit (from 2.6 Thud): commit c88304a78e528596ca481cabe273749c286c352a Author: Andre McCurdy Date: Fri May 18 15:50:40 2018 -0700 arch-armv7a.inc: default to Thumb2 instruction set for armv7a and above which enabled Thumb2 by default, if you want to disable it as it was

Re: [yocto] cortexa9t2hf instead of cortexa9hf

Thanks for explaining this. I take some time to read about thumb/thumb2. The feedback is mixed. It seems to generate more compact code, but some say it speeds up, others it slows down because of reduced function set - and it can cause strange effects. And mixing this causes time to switch

Re: [yocto] cortexa9t2hf instead of cortexa9hf

> Because of that I copied Alex and Ross to CC: into email, so they > should unveil this mystery (I would prefer "armv7" to stay in bitbake > 1.42, since A8 and A9 belongs to armv7, A15 belongs to armv8 (IIRC). Sorry, my bad. A15 still belongs to armv7. And now I see/understand why you removed

Re: [yocto] Running Yocto inside Docker

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,

[yocto] Am not getting udev-extraconf automount to work

I'm building for a RPi3B using the Qt supplied boot2qt framework on SUMO. I've added udev-extraconf to pull in automount.rules. When I plug in a USB thumb drive I get /dev/SDA & /dev/SDA1. I also get /tmp/.automount-sda1 with the time of insertion. I also get /run/media/sda1, and the

Re: [yocto] [meta-swupdate] failed update leads to kernel panic

Hi Stefano On 17.06.19 09:19, Stefano Babic wrote: Hi Moritz, On 17/06/19 08:23, Moritz Porst wrote: Hello Stefano, Thanks very much for your answer On 14.06.19 14:14, Stefano Babic wrote: Hi Moritz, On 14/06/19 12:19, Moritz Porst wrote: (Sorry, the answer should go to everyone) Thanks

Re: [yocto] [update-rc.d][PATCH V3] update-rc.d: support enable/disable options

ping On 5/28/19 8:59 AM, Changqing Li wrote: ping On 4/30/19 2:56 PM, changqing...@windriver.com wrote: From: Changqing Li Add support of enable/disable options, refer https://manpages.debian.org/wheezy/sysv-rc/update-rc.d.8.en.html With support of these options, the usr can never change

Re: [yocto] [meta-swupdate] failed update leads to kernel panic

Hello Stefano, Thanks very much for your answer On 14.06.19 14:14, Stefano Babic wrote: Hi Moritz, On 14/06/19 12:19, Moritz Porst wrote: (Sorry, the answer should go to everyone) Thanks for your response, unfortunately it didn't work out for me. Because I am not 100% sure whether I did the

Re: [yocto] [meta-swupdate] failed update leads to kernel panic

Hi Moritz, On 17/06/19 08:23, Moritz Porst wrote: > Hello Stefano, > Thanks very much for your answer > > On 14.06.19 14:14, Stefano Babic wrote: >> Hi Moritz, >> >> On 14/06/19 12:19, Moritz Porst wrote: >>> (Sorry, the answer should go to everyone) >>> Thanks for your response, unfortunately