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 it
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 fo
> 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 i
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.yoctop
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
yo
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 M
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 d
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
everythi
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 to
> 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 st
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 ca
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 (N
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 thi
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
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)
hardwar
> 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 "ar
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 process
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 /var/log/me
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,
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) being
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:
https://wiki.yoctoproject.org/wiki/Bug_Triage#N
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
-fmacro-prefix-map=/home/matt/rdk_warrior/build/tmp/work/7271-poky-linux/brcm/18.3+AUTOINC+0a6fb7430f-
22 matches
Mail list logo
