Re: [yocto] Memory requirements for building images with different architectures

[Leon Woestenberg]

> My oldest NVME dedicated for OE builds, bought 2019-11-24
> https://www.gigabyte.com/SSD/AORUS-NVMe-Gen4-SSD-2TB#kf
> with 3600TBW, shows 60% Estimated Remaining Life after around 21K running
hours and started disconnecting under heavy load (not necessary issue
caused by wear) about a year ago and recently became completely unusable
for builds.
>
> 2nd one I bought when the issues started on 2022-05-16 has 8400 hours and
> Data Units Read:87,481,897 [44.7 TB]
> Data Units Written: 210,637,555 [107 TB]
>

For partitions with ext4 filesystems on SSD, I use this so I can see the
TBW cycles of my SSD, on login. It is assuming PART is the most heavily
used work partition. (Of course SMART is the better approach, but not
always available or not always correct.)

I just realized this may need /bin/bash rather than /bin/sh...


$ cat /etc/update-motd.d/01-ssd-health
#!/bin/sh

for PART in nvme0n1p4; do
  # size of partition in kiB
  SIZE=`df -BKB /dev/$PART | grep -e "^/dev/$PART" | awk '{print $2}' | sed
-e 's/[^0-9]//g'`
  # size of partition in kiB
  USED=`df -BKB /dev/$PART | grep -e "^/dev/$PART" | awk '{print $3}' | sed
-e 's/[^0-9]//g'`

  WRITTEN=`cat /sys/fs/ext4/$PART/lifetime_write_kbytes`
  echo "SSD $PART is $(($(($WRITTEN + $SIZE - 1)) / $SIZE)) times written
round. TBW 1200."
done

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60950): https://lists.yoctoproject.org/g/yocto/message/60950
Mute This Topic: https://lists.yoctoproject.org/mt/101231469/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Memory requirements for building images with different architectures

[Leon Woestenberg]

Hello Mohammed,

On Fri, 8 Sep 2023 at 09:18, MOHAMMED HASSAN 
wrote:

> My builds on an average take 15-20 mins with the build folder intact.
> How much time do you think it will take on average with rm_work enabled?
>

Depends on what changed. If nothing changed, time remains the same, except
for maybe the final image build.

But what is your goal? Reduce development/test cycle time? There are
ways to do that, sometimes.

Cheers, Leon


> Regards,
> Hassan
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#60948): https://lists.yoctoproject.org/g/yocto/message/60948
Mute This Topic: https://lists.yoctoproject.org/mt/101231469/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] OTA Updates

[Leon Woestenberg]

Hello,

we have implemented OTA based on OSTree, in a non-commercial
no-license-fee setting, to update OTA over mobile (3G/4G) data
connections.

I remember the OTA server was really easy to setup.

We let Yocto deploy directly to the OTA server, using CI/CD.

Basically the server worked out of the box, running a few ostree
commands. We added a GUI to have visual version management, deployment
branches, rollbacks etc. with a few PHP scripts.

If you go this route, just run the ostree from the command line on
both the client and server, and you will quickly understand how it
works, and how you would like to wrap it up.

Regards,

Leon.

On Thu, May 11, 2023 at 6:59 PM Stefano Babic  wrote:
>
> Hi,
>
> On 11.05.23 16:33, MOHAMMED HASSAN wrote:
> > Hi all,
> > So I am referring this page for OTA updates
> > https://wiki.yoctoproject.org/wiki/System_Update
> > 
> >
> > However are these all paid or free services. Any more info about these
> > services is welcomed.
> > Also are there any tutorials, YouTube videos on ota updates for yocto? I
> > couldn’t find any though.
> >
>
> I and DENX offer services around SWUpdate as OTA service -
> https://swupdate.org/services. Layers and documentation can be retrieved
> at https://sbabic.github.io/swupdate/.
>
> Regards,
> Stefano Babic
>
> --
> =
> DENX Software Engineering GmbH,Managing Director: Erika Unter
> HRB 165235 Munich,   Office: Kirchenstr.5, 82194 Groebenzell, Germany
> Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
> =
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59995): https://lists.yoctoproject.org/g/yocto/message/59995
Mute This Topic: https://lists.yoctoproject.org/mt/98828664/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] OTA updates for Application Software

[Leon Woestenberg]

On Fri, Apr 21, 2023 at 5:53 AM MOHAMMED HASSAN
 wrote:
>
> I wanted to know if it is possible to update your application through OTA 
> updates.
> If yes, then please share some documentation or some steps in achieving it.
>

Also note "ostree", which allows incremental updates and is especially
suited if you want to minimize data usage (for example, over cellular
networks).

https://ostree.readthedocs.io/en/stable/manual/introduction/

Basically OSTree is GIT for filesystems.

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59750): https://lists.yoctoproject.org/g/yocto/message/59750
Mute This Topic: https://lists.yoctoproject.org/mt/98403981/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Give access token to yocto build. (pass environment variable to bitbake)

[Leon Woestenberg]

On Fri, Apr 14, 2023 at 9:24 AM Mikko Rapeli 
wrote:

>
> The environment variables and thus secrets are easily leaking into build
> logs so I would not use them.
>
> Instead, I would use .netrc for git and anything using curl (http
> fetcher). subversion caches passwords into ~/.subversion directory once
> the password has been given once.
>
> In CI, these can be deployed automatically using ansible etc and
> developers should setup these for their own machines.
>
> Hope this helps,
>
> I think this is wrong advice, we switched away from this years ago as with
docker and CI/CD, as the security implications are easily exposable.
There is not enough info in OP and I persist this is off-topic here, so no
answer can be good. See:

docker secret

https://blog.gitguardian.com/how-to-handle-secrets-in-docker/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59712): https://lists.yoctoproject.org/g/yocto/message/59712
Mute This Topic: https://lists.yoctoproject.org/mt/98248615/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Give access token to yocto build. (pass environment variable to bitbake)

[Leon Woestenberg]

Hello Philippe,

On Thu, Apr 13, 2023 at 9:54 PM Philippe Lafontaine via
lists.yoctoproject.org 
wrote:

> I have a recipe that fetch a pre-built binary from a build machine using an 
> access token. Every developer will have different access token, for obvious 
> reason. Therefore, the token cannot be hard coded in the recipe.
>
The question seems off-topic and CI/CD related, but unrelated to Yocto
Project in general. Although you may find experience here, I would
search on StackOverflow or the support forums on your CI/CD of choice.

GitLab supports (project) group access tokens. I have used those
instead of user access tokens in projects.

> While this strategy does work. We were wondering if there was a better way of 
> doing this.
>
I think recent CI/CD tools have support for secrets that are not
exposed, also for during docker based builds.

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59709): https://lists.yoctoproject.org/g/yocto/message/59709
Mute This Topic: https://lists.yoctoproject.org/mt/98248615/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Importance of ECC RAM on the build computer

[Leon Woestenberg]

Hello,

Interesting question, and I especially would like to hear on the MTBF
*measured* through the ECC detection algorithm. It can usually detect
more errors than it can correct, and I wonder if the systems admin are
notified when bitflips where detected.


Regards,

Leon.

-- 
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Fri, Feb 17, 2023 at 3:14 PM Alexandre Belloni via
lists.yoctoproject.org
 wrote:
>
> On 17/02/2023 10:41:37+0100, Alexander Kanavin wrote:
> > On the other hand, I'm yet to hear an actual case of a broken build
> > due to non-ECC. It's not impossible, but it seems exceedingly rare.
> > You're far more likely to spend 100x as much time on logical errors or
> > out-of-resources problems.
>
> It actually happened in one of our build, were we had a bitflip in the
> final binary which was then not working as expected.
>
> We also had multiple cases of headers/source file corruption after the
> tarball is extracted but usually those are either caught by the compiler
> or don't matter at all.
>
> >
> > Alex
> >
> > On Fri, 17 Feb 2023 at 09:31, Yoann Congal  wrote:
> > >
> > > Hi!
> > >
> > > Le ven. 17 févr. 2023 à 06:08,  a écrit :
> > >>
> > >> Is there generally suggested advice regarding the importance of ECC on 
> > >> the build computer? I'm very new to Yocto so I'm not sure if there is a 
> > >> chance the final build image could experience some corruption due to 
> > >> flipped bits in RAM or if I'm totally overthinking this.
> > >
> > >
> > > Last time I checked. The ECC vs non-ECC price difference was not worth 
> > > the time you may spend in case of a RAM bitflip.
> > > Here, we put ECC RAM in our build systems and I guess it's quite the 
> > > industry standard.
> > >
> > >> It is also possible that Yocto does some kind of CRC checking of its own 
> > >> that makes this a non-issue. Any guidance would be appreciated. Thank 
> > >> you!
> > >
> > >
> > > Yocto does source integrity checks (the stuff it downloads from the 
> > > internet) but it can't do much more after that.
> > >
> > > I've yet to debug a RAM bitflip but I guess it may trigger any kind of 
> > > weird behavior which may be hard to debug and time consuming.
> > >
> > > My advice is : keep your time and sanity, use ECC RAM.
> > >
> > > Regards,
> > > --
> > > Yoann Congal
> > > Smile ECS - Expert technique
> > >
> > >
> > >
>
> >
> >
> >
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#59242): https://lists.yoctoproject.org/g/yocto/message/59242
Mute This Topic: https://lists.yoctoproject.org/mt/97022997/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Disabling SSH by default (but keeping the service)

[Leon Woestenberg]

Hello Maik,

On Thu, Oct 13, 2022 at 3:17 PM Maik Vermeulen
 wrote:
> We tried two things to disable SSH by default in our image recipe:
> However, both methods don't seem to work.

Hmm, something else might override it elsewhere? I don't know.

Seems like a similar question came up in stackoverflow, where some
potential solutions are given that you might want to give a try:

https://stackoverflow.com/questions/50651371/disable-a-standard-systemd-service-in-yocto-build

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#58331): https://lists.yoctoproject.org/g/yocto/message/58331
Mute This Topic: https://lists.yoctoproject.org/mt/94303163/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] OS-less SDK

[Leon Woestenberg]

Hello Alessio,

> On Fri, 29 Apr 2022, 13:52 Alessio Igor Bogani,  
> wrote:
>> Is there a way to generate an SDK which contains the toolchain for
>> bare-metal systems (i.e. MCU without operating system)?

Good question. I know Xilinx has put effort to support their MCUs with Yocto.

However, define what you mean by SDK? Which libraries or programming
languages are you thinking of beyond the C library for example?

On Fri, Apr 29, 2022 at 1:58 PM Laurent Gauthier
 wrote:
> Have you had a look at crosstool-ng?
>
crosstool-ng is mostly the toolchain, I would not consider this an SDK
beyond that.

This might help:

https://elinux.org/images/e/e6/ELC-Yocto-Crosstool-ng.pdf

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56960): https://lists.yoctoproject.org/g/yocto/message/56960
Mute This Topic: https://lists.yoctoproject.org/mt/90774037/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Yocto Zeus -docker/PREEMPT_RT

[Leon Woestenberg]

Hello Steven,

> Last entry, from July 2021, in this blog says not supported;
>> Docker for RTOS? - General Discussions / Feature Requests - Docker Community 
>> Forums

No, that remark is completely wrong and is mixing up things.
"RTLinux" has nothing to do with the mainstream Linux kernel (except
that RTLinux can run the Linux kernel underneath)
Forget about those remarks.


Mainstream Linux is now almost fully-featured with the PREEMPT_RT work
merged, and the Linux kernel can be configured as an RTOS capable
kernel.
There is more to hard real-time than just the kernel, but that is the
kernel part.

I would see *no reason* why Docker should not run on Linux, even when
preemptive realtime is enabled.
In contrast when searching for the PREEMPT_RT / Docker combination I
see successful results.

What is probably the cause for Docker not working, is that the kernel
configuration for the PREEMPT_RT a.k.a. "-rt" kernel in Yocto does not
enable all name space support and other capabilities that Docker
depends on.

I would start comparing .config files at this point, together with the
debug/log output of Docker.
Especially first learn which CONFIG_ options Docker depends on.

Regards,

--
Leon Woestenberg
l...@sidebranch.com
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Wed, Feb 16, 2022 at 1:15 PM Monsees, Steven C (US) via
lists.yoctoproject.org
 wrote:
>
>
>
> I have 2 platforms one with a standard kernel the other using PREEMPT_RT 
> kernel… both work as expected.
>
>
>
> All things being equal, when I add docker container support to both 
> platforms, the standard kernel works just fine, but on the
>
> PREEMPT_RT kernel docker does not appear to initialize/work correctly…
>
>
>
> I have also tested using both ARM & Intel based HW, and appear tosee the same 
> behavior on both.
>
>
>
> Checking online it appears there is chatter about whether docker will run 
> correctly under a PREEMPT_RT kernel.
>
> Example:
>
>
>

>>
>
> Under Yocto, will docker & PREEMPT_RT kernels function correctly, is this 
> combination supported ?
>
>  >
> I am currently running zeus based platforms, docker is at version 19.03.2-ce.
>
>
>
> Is there a patch to correct for the compatibility issues being seen ?, or
>
> Is there a yocto version I might move to which supports both correctly ?
>
>
>
> Any input on this would be greatly appreciated.
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56208): https://lists.yoctoproject.org/g/yocto/message/56208
Mute This Topic: https://lists.yoctoproject.org/mt/89183692/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] is there a viable YP-friendly risc-v dev kit?

[Leon Woestenberg]

Hello Robert, Alexander,

On Fri, 4 Feb 2022 at 23:04, Robert P. J. Day  wrote:

>
> Quoting Alexander Kanavin :
>
> > I think the best option at this point is qemu. Why does the 'friend' need
> > physical hardware? :)
>
>he's a hacker and just likes the feel of circuit boards, but
> qemu does look like the only feasible option at the moment.
>

No. There is a sweet middle ground called FPGAs. You buy a board, with an
IC on it, that is expensive as hell, empty like air, but fully
re-configurable with almost any RISC-V SoC you can think of.

For example the Rocket 64 bit RISC-V.

Regards, Leon

>
> rday
>
>
> 
>
> --
-- 
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#56081): https://lists.yoctoproject.org/g/yocto/message/56081
Mute This Topic: https://lists.yoctoproject.org/mt/88917825/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] preempt-rt

[Leon Woestenberg]

Hello Steve,

On Wed, 3 Nov 2021 at 13:44, Monsees, Steven C (US) via
lists.yoctoproject.org 
wrote:

>
>
> I have a platform based off a aarm64 Xilinx based kernel, which is not a
> compliant mainline kernel… so, I will need to go the preemp-rt patch route.
>

Depends, no mainline kernel? Vendor kernel?

Can you share the machine name? Might be supported already in a layer with
-rt.

Regards,

Leon
-- 
-- 
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55224): https://lists.yoctoproject.org/g/yocto/message/55224
Mute This Topic: https://lists.yoctoproject.org/mt/86789691/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] yocto preempt-rt

[Leon Woestenberg]

On Tue, Nov 2, 2021 at 5:26 PM Bruce Ashfield  wrote:
>
> Correct.
>
> The rt patches are already integrated on the branches that that recipe will 
> build out of the linux-yocto repository.
>
And adding to that, besides the Yocto maintained kernel,  meta-intel
has it's own kernel GIT repo/branch for the kernel and -rt kernel
maintained by Intel.

(There might be some overlap in the maintainers, I am not aware of the
differences between those.).

I used the latter with success on Intel Atom 3950 for hard real-time purposes.

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55217): https://lists.yoctoproject.org/g/yocto/message/55217
Mute This Topic: https://lists.yoctoproject.org/mt/86770123/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] yocto meta-intel preempt-rt

[Leon Woestenberg]

Hello Steve,

I have been running the PREEMPT_RT for Intel platforms for a few
releases, I remember it fetched sources from a GIT branch for -rt
(PREEMPT_RT). So it does not need to apply separate patches in that
case.

Could you check if this is the case for you as well?

Regards,

Leon.

p.s. Slightly off-topic, I moved away from PREEMPT_RT in favor of task
isolation mode, where we use one CPU core in isolated single task
mode, for *much* lower latencies than PREEMPT_RT can provide.


-- 
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Tue, Nov 2, 2021 at 12:30 PM Monsees, Steven C (US) via
lists.yoctoproject.org
 wrote:
>
>
>
> I have an Intel based platform, and was looking to implement preempt-rt on it 
> to test.
>
>
>
> For Intel, the meta-intel component recipe appears to supports 
> “linux-intel-rt”, and I can build my intel based platform with this  and it 
> boots…  My platform kernel is currently 4.19 based under the meta-inteI 
> component I do not see the rt patch/patches being applied…
>
>
>
> Is meta-intel component recipe building the full preempt-rt support ?, or do 
> I still need to apply the patch ?
>
>
>
> Thanks,
>
> Steve
>
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55212): https://lists.yoctoproject.org/g/yocto/message/55212
Mute This Topic: https://lists.yoctoproject.org/mt/86763507/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] bbappend usage

[Leon Woestenberg]

Hello Steve,

Is the approach where you remove the recipes from the image an option?
Is there a reason why you want to build the recipes that you do not
want to appear in your image?

Regards,

Leon.


-- 
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Mon, Oct 25, 2021 at 2:55 PM Monsees, Steven C (US) via
lists.yoctoproject.org
 wrote:
>
>
>
> Hello:
>
>
>
> If I am building an image “image-ABC”, and it is composed of a number 
> recipes, and for some of these recipes I may NOT want to install their final 
> components within my image…
>
>
>
> Which is the best place to modify the build with bbappend ?
>
>
>
> Would I modify a recipe’s do_install (do_install_append-recipe_xyz) ?, or 
> would I modify the image recipe (do_install_append-image_ABC) I am leaning 
> this way to avoid cases where the component recipes might have bbappends in 
> place already ?
>
>
>
> Looking for the proper Yocto way…
>
>
>
> Thanks,
>
> Steve
>
>
>
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#55138): https://lists.yoctoproject.org/g/yocto/message/55138
Mute This Topic: https://lists.yoctoproject.org/mt/86576092/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Yocto build isnot Booting up on board zc702 #gatesgarth #linux #yocto

[Leon Woestenberg]

Hello,

>
> i have tried to build yocto image.  And it compiled successfully without any 
> error but when am trying to BOOT them it didnt prompt any error message
> what should i do to BOOT my yocto build image on zc702 board

What is your output from the ZC702 (USB) serial console?


I had similar issue on ZCU102 and debugged my issue:

"the U-Boot not showing anything I have debugged to be an issue where
DEVICE_TREE does not propagate from the BitBake recipe into the U-Boot
build (both for upstream and Xilinx). I have reported this on
meta-xilinx but will make it a separate bug report."

I can imagine the same problem would occur on ZC702 (single-core Zynq).

I have posted a few messages with meta-xilinx in the subject on how I
had to bring Yocto to the ZCU102.

Regards,

Leon.


--
Leon Woestenberg
l...@sidebranch.com
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Tue, Jun 29, 2021 at 8:02 AM shoaib akhtar
 wrote:
>
>
>
>
> i have tried to build yocto image.  And it compiled successfully without any 
> error but when am trying to BOOT them it didnt prompt any error message my 
> BBlayer.conf is shown below
>
> # POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
> # changes incompatibly
> POKY_BBLAYERS_CONF_VERSION = "2"
>
> BBPATH = "${TOPDIR}"
> BBFILES ?= ""
>
> BBLAYERS ?= " \
>   /media/vmnrtc/Drive/poky/meta \
>   /media/vmnrtc/Drive/poky/meta-poky \
>   /media/vmnrtc/Drive/poky/meta-yocto-bsp \
>   /media/vmnrtc/Drive/poky/meta-xilinx/meta-xilinx-bsp \
>   /media/vmnrtc/Drive/poky/meta-openembedded/meta-oe \
>   /media/vmnrtc/Drive/poky/meta-openembedded/meta-python \
>   /media/vmnrtc/Drive/poky/meta-xilinx/meta-xilinx-standalone \
>   /media/vmnrtc/Drive/poky/meta-xilinx-tools \
>   /media/vmnrtc/Drive/poky/build/meta-networking \
>   "
>
> MY files in image directories
>
>
> boot.bin
> boot.bin-zc702-zynq7
> boot.bin-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0
> boot.scr
> core-image-minimal-zc702-zynq7-20210629031233.qemuboot.conf
> core-image-minimal-zc702-zynq7-20210629031233.rootfs.cpio
> core-image-minimal-zc702-zynq7-20210629031233.rootfs.cpio.gz.u-boot
> core-image-minimal-zc702-zynq7-20210629031233.rootfs.manifest
> core-image-minimal-zc702-zynq7-20210629031233.rootfs.tar.gz
> core-image-minimal-zc702-zynq7-20210629031233.testdata.json
> core-image-minimal-zc702-zynq7.cpio
> core-image-minimal-zc702-zynq7.cpio.gz.u-boot
> core-image-minimal-zc702-zynq7.manifest
> core-image-minimal-zc702-zynq7.qemuboot.conf
> core-image-minimal-zc702-zynq7.tar.gz
> core-image-minimal-zc702-zynq7.testdata.json
> modules--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.tgz
> modules-zc702-zynq7.tgz
> pxeboot
> pxelinux.cfg
> u-boot.elf
> u-boot.img
> u-boot-xlnx-AUTOINC+bb4660c33a.elf
> u-boot-xlnx-initial-env
> u-boot-xlnx-initial-env-zc702-zynq7
> u-boot-xlnx-initial-env-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0
> u-boot-zc702-zynq7.elf
> u-boot-zc702-zynq7.img
> u-boot-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0.img
> u-boot-zynq-scr--1.0-r0.scr
> uEnv.txt
> uImage
> uImage--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.bin
> uImage-zc702-zynq7.bin
> zImage
> zImage--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.bin
> zImage-zc702-zynq7.bin
> zynq-zc702--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.dtb
> zynq-zc702.dtb
> zynq-zc702-zc702-zynq7.dtb
>
>
>
> what should i do to BOOT my yocto build image on zc702 board
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#54004): https://lists.yoctoproject.org/g/yocto/message/54004
Mute This Topic: https://lists.yoctoproject.org/mt/83863010/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #linux:https://lists.yoctoproject.org/g/yocto/mutehashtag/linux
Mute #gatesgarth:https://lists.yoctoproject.org/g/yocto/mutehashtag/gatesgarth
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Use of SDK for building images?

[Leon Woestenberg]

Hello all,

In some other build systems the generated SDK can be used to also
generate an image. Thus the SDK allows development against the target
sysroot using the prebuilt host and target tools, as well as
(re)generate the target images in quick iteration cycles.

What approaches are recommended with Yocto to achieve the same benefits?

My need is to regenerate an initramfs as well as compose this into an
image using WIC.

I am aware of shared state, and using prebuilt toolchains, but my
question is whether the prebuilt SDK allows to generate images?

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53899): https://lists.yoctoproject.org/g/yocto/message/53899
Mute This Topic: https://lists.yoctoproject.org/mt/83602600/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] PREEMPT_RT patches

[Leon Woestenberg]

Hello Steven,

Yocto does support switching kernels and configurations, so yes Yocto does
"support" it.

However, providing a well-tested PREEMPT_RT kernel might be more an
architectural meta layer topic.

We have been using the Intel provided PREEMPT_RT kernel for x86 with good
success in a system with hard real-time requirements.
In the end we chose full task isolation approach, where one task runs in
user-space task isolation, reducing latencies even further than what
PREEMPT_RT can provide, as we did not need kernel services in our main
processing loop (after setup).

Regards,

Leon.

On Wed, May 19, 2021 at 12:53 PM Monsees, Steven C (US) via
lists.yoctoproject.org 
wrote:

>
>
> Recently I heard somewhere that newer versions of the Linux Kernel will
> include the PREEMPT_RT patches, and configuration settings would be used to
> set how the Linux would operate in a specific system.
>
>
>
> Does Yocto support “PREEMPT_RT”, and what versions of Yocto have this
> option ?
>
>
>
> Is there documentation on this feature/option ?
>
>
>
> Thanks,
>
> Steve
>
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#53582): https://lists.yoctoproject.org/g/yocto/message/53582
Mute This Topic: https://lists.yoctoproject.org/mt/82933290/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] how often would one use "VAR_someoverride_append = ..."?

[Leon Woestenberg]

Hello Robert, all,

On Tue, Mar 9, 2021 at 3:39 PM Robert P. J. Day  wrote:
> is there an actual practical usage of, say:
>
>   VAR_x86_append = "huh"
>
$grep -re '[A-Z_]\+_[a-z0-9]\+_append' poky/meta*
poky/meta/recipes-support/gmp/gmp_6.2.0.bb:EXTRA_OECONF_mipsarchr6_append
= " --disable-assembly"
poky/meta/recipes-core/images/build-appliance-image_15.0.0.bb:IMAGE_CMD_ext4_append
() {
poky/meta/recipes-devtools/python/python3_3.8.2.bb:RDEPENDS_libpython3_append_libc-glibc
= " libgcc"
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdb_append_linux
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdb_append_linux-gnueabi
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdbserver_append_linux
= " glibc-thread-db "
poky/meta/recipes-devtools/gdb/gdb-common.inc:RRECOMMENDS_gdbserver_append_linux-gnueabi
= " glibc-thread-db "

which is appending an override variable conditionally with another
override condition. (If I put this correctly.) Is this a valid use
case where += would not work?

Other appearances without an override condition:
$ grep -re '[A-Z_]\+_[a-z0-9]\+_append' meta-*
meta-openembedded/<..>/libnma_1.8.28.bb:EXTRA_OEMESON_mipsarchn32_append
= " -Dvapi=false"
meta-openembedded/<..>/libnma_1.8.28.bb:EXTRA_OEMESON_riscv32_append =
" -Dvapi=false"

Could these have been replaced with the following?

EXTRA_OEMESON_mipsarchn32 += "-Dvapi=false"
EXTRA_OEMESON_riscv32 += "-Dvapi=false"

Seems like a good test case indeed.

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52626): https://lists.yoctoproject.org/g/yocto/message/52626
Mute This Topic: https://lists.yoctoproject.org/mt/81202306/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [meta-virtualization]: dunfell docker run issues

[Leon Woestenberg]

Marek,

This might indeed indicate a configuration mismatch. Lots of stuff
comes up on Google that you might want to check.

One is a change in systemd that affects this. Sorry I don't have a
link ready anymore.

Regards,

Leon.




--
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Thu, Feb 4, 2021 at 4:04 PM Marek Belisko  wrote:
>
> Hi,
>
> I'm trying to run docker containers on orangepi and use
> meta-virtualization layer to add docker. I've installed the docker-ce
> package and everything seems to be fine.
>
> But docker service seems fails to start with:
> Feb 04 15:00:01 orange-pi-zero dockerd[495]: failed to start daemon:
> Devices cgroup isn't mounted
>
> I was trying to add various options to kernel command line like
> described here: https://github.com/docker/cli/issues/2104
>
> but it doesn't work. My command-line looks like:
> ...systemd.unified_cgroup_hierarchy=0 cgroup_enable=memory
> cgroup_memory=1 swapaccount=1 cgroup_no_v1=all
>
> Any other ideas what to check? Thanks a lot.
>
> BR,
>
> marek
>
> --
> as simple and primitive as possible
> -
> Marek Belisko - OPEN-NANDRA
> Freelance Developer
>
> Ruska Nova Ves 219 | Presov, 08005 Slovak Republic
> Tel: +421 915 052 184
> skype: marekwhite
> twitter: #opennandra
> web: http://open-nandra.com
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52252): https://lists.yoctoproject.org/g/yocto/message/52252
Mute This Topic: https://lists.yoctoproject.org/mt/80381272/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Appropriate patch posting location?

[Leon Woestenberg]

Hi Kent,

On Fri, Feb 5, 2021 at 5:14 PM Kent Dorfman  wrote:
>
> Is there not a separate list address to post patches, so as to keep
> discussion and patch lists separate?
>
> It can be an issue for folks who are on web mailers that make you
> delete messages one-at-a-time ie "traditional frames based gmail
> interface"
>

Most of these providers provide an IMAP interface as well, such as gmail.

Also, in gmail you can tag messages to move into a separate folder for
easy delete.
For devs and users, the patches are useful info as to what gets
changed, I like them to be intermixed.

Regards,


Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52247): https://lists.yoctoproject.org/g/yocto/message/52247
Mute This Topic: https://lists.yoctoproject.org/mt/80409256/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto CORE_IMAGE_EXTRA_INSTALL Where can I find a list of valid package names?

[Leon Woestenberg]

Hello,

On Fri, Feb 5, 2021 at 5:27 PM Yi Fan Yu  wrote:
>
> new here, pointing out of the obvious? website
>
> https://layers.openembedded.org/
>
What's obvious? There are no package names there, only recipe names
that I am aware of.

So for the non-obvious packages it still is a bit of guesswork, or the
responses in this thread.

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52246): https://lists.yoctoproject.org/g/yocto/message/52246
Mute This Topic: https://lists.yoctoproject.org/mt/80375312/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Building eSDK fails #sdk

[Leon Woestenberg]

Hello Alexander,

On Thu, Feb 4, 2021 at 6:43 PM  wrote:
>
> <...> trying to build the eSDK with bitbake core-image-base -c 
> populate_sdk_ext results in this error:
> Collected errors:
>  * opkg_prepare_url_for_install: Couldn't find anything to satisfy 
> 'cppzmq-dev'.
>
> The listed Packeges are set in the TOOLCHAIN_TARGET_TASK variable. I tryed 
> using IMAGE_INSTALL_append but this didn't help.
> Does someone have an idea?
>
I have two ideas that might get you closer.

1) First, I noticed that using TOOLCHAIN_HOST_TASK += "xxx" is broken
on Yocto dunfell for me (non-extensible SDK). The issue is that even
when using += in local.conf, only "xxx" would end up in
TOOLCHAIN_HOST_TASK, removing the existing tasks.

I can test/prove this by running:
bitbake core-image-base -c populate_sdk -e | grep -e '^TOOLCHAIN_'

My local.conf thus look like this to work around this:

# @TODO Broken
#TOOLCHAIN_HOST_TASK += "nativesdk-cmake"
TOOLCHAIN_HOST_TASK_append = " nativesdk-cmake nativesdk-make"

TOOLCHAIN_TARGET_TASK_append = " concurrencykit-staticdev musl-staticdev"

2) There is something special with ''cppzmq-dev'; it is a header-only
package without libraries. Not sure if that has any impact for the
dependency resolution.

Probably useless info for you, but might trigger someone to help you further.

I minimal test case would be nice, against plain Yocto, so that devs
can investigate easier.

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52240): https://lists.yoctoproject.org/g/yocto/message/52240
Mute This Topic: https://lists.yoctoproject.org/mt/80385790/21656
Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Can't Build Read-Only RootFS

[Leon Woestenberg]

Hello Dave,

On Fri, Jan 15, 2021 at 10:40 PM Dave Tucker  wrote:

> ERROR: core-image-minimal-1.0-r0 do_rootfs: The following packages could
> not be configured offline and rootfs is read-only: ['sysvinit-inittab']
> I've not been able to find any information on this issue and am not sure
> how to proceed.  Could someone please point me in the right direction?
>
> I copied that error report into Google. Maybe you are hitting a similar
case to this?

https://www.yoctoproject.org/pipermail/meta-xilinx/2018-January/003638.html

Regards,

Leon,

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52017): https://lists.yoctoproject.org/g/yocto/message/52017
Mute This Topic: https://lists.yoctoproject.org/mt/79713931/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] cpio issues

[Leon Woestenberg]

Hello Damien,

On Fri, Jan 15, 2021 at 3:48 PM Damien LEFEVRE  wrote:
>
> How can I keep the initramfs with cpio, but disable cpio archiving for the 
> rootfs which I don't need or use for anything?
>
I have this in my local.conf:

IMAGE_FSTYPES = "tar ext4"
INITRAMFS_FSTYPES = "cpio.xz"

It does depend a bit on your image recipes and classes if this works for you.

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#52014): https://lists.yoctoproject.org/g/yocto/message/52014
Mute This Topic: https://lists.yoctoproject.org/mt/79702974/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #yocto #sdk How to add *-dev packages to sdk installer and not to target rootfs

[Leon Woestenberg]

Hello Henrik,

On Mon, Oct 5, 2020 at 8:18 AM Henrik Haugaard Jensen 
wrote:

>
> It would be nice if *-dev packages could be specified to included in the
> sdk sysroots only since we do not need them in the taget rootfs.
>
> As far as I known:
- The -dev packages do not end up in target rootfs, unless you specify them
in your target image.
- The -dev packages end up in the standard SDK target sysroot if you have a
DEPENDS on them.

So maybe in your case you do not have a DEPENDS in your image for the
packages you want a -dev for in SDK?
Could it be you specify -dev manually for the target image?

I am not sure what happens if "myapp" mentions a DEPENDS on (say) "libpng"
but not really links against it.
I am not sure if the libpng-dev ends up in the SDK (but I will try this
tomorrow).

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50925): https://lists.yoctoproject.org/g/yocto/message/50925
Mute This Topic: https://lists.yoctoproject.org/mt/77257238/21656
Mute #yocto:https://lists.yoctoproject.org/g/yocto/mutehashtag/yocto
Mute #sdk:https://lists.yoctoproject.org/g/yocto/mutehashtag/sdk
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] SIGINT Issues with Zeus Migration

[Leon Woestenberg]

Hello Aashik,

I recognize the issue that CTRL-C does not pass from the console, but only
with *very* minimal configurations.

How does your local.conf look like, or better yet how can we reproduce your
case?

Regards, Leon

On Fri, 25 Sep 2020 at 12:46, Aashik Aswin  wrote:

> Hi Leon, Zoran
>
> I am using Ctrl+C to kill the Ping command.
>
>
> Thanks.
>
> On Fri, Sep 25, 2020 at 3:56 PM Zoran Stojsavljevic <
> zoran.stojsavlje...@gmail.com> wrote:
>
>> Hello Leon,
>>
>>
>>
>>
>>
>> > Aashik, how are you sending the signal? Using CTRL-C or
>>
>>
>> > using the "kill" command?
>>
>>
>>
>>
>>
>> This is a good suggestion for the test. To open another terminal and
>>
>>
>> issue: kill -SIGINT .
>>
>>
>>
>>
>>
>> I should add that this MUST work: kill -SIGKILL , since
>>
>>
>> SIGKILL handler is un-preemptable.
>>
>>
>>
>>
>>
>> If it does not, something is very wrong... I suggest, Aashik, you
>>
>>
>> write YOCTO bugzilla for Zeus.
>>
>>
>>
>>
>>
>> > Zoran, are you suggesting that the program will change the signal
>>
>>
>> > handler to default even after it has exited, and for the subsequent
>>
>>
>> > ping command?
>>
>>
>>
>>
>>
>> Yes, I do. Then, the ping command should be issued again, and my best
>>
>>
>> guess is, it should terminate the ping process.
>>
>>
>>
>>
>>
>> Leon, you should try to write another C f-n and to install other
>>
>>
>> SIGINT handler (replacing SIG_DFL), then test it with my original C:
>>
>>
>>
>>
>>
>> void  myhandler(int signum) {
>>
>>
>> if (SIGINT == signum)
>>
>>
>> printf("\nHey, I got SIGINT: %d\n\n",signum);
>>
>>
>> }
>>
>>
>>
>>
>>
>> Zoran
>>
>>
>> ___
>>
>>
>>
>>
>>
>> On Fri, Sep 25, 2020 at 10:54 AM Leon Woestenberg 
>> wrote:
>>
>>
>> >
>>
>>
>> > Hi Aashik, Zoran,
>>
>>
>> >
>>
>>
>> >
>>
>>
>> > On Fri, Sep 25, 2020 at 10:02 AM Zoran 
>> wrote:
>>
>>
>> > >
>>
>>
>> > > > ...that I am not able to send SIGINT to commands such as Ping, tail
>> etc.\
>>
>>
>> >
>>
>>
>> > Aashik, how are you sending the signal? Using CTRL-C or using the
>>
>>
>> > "kill" command?
>>
>>
>> >
>>
>>
>> > >
>>
>>
>> > > Please, do the following: issue in zeus xterm the command: man signal
>>
>>
>> > > and read it.
>>
>>
>> > >
>>
>>
>> > That reads to use sigaction() instead of signal() I would assume.
>>
>>
>> >
>>
>>
>> > > Then execute the following code (ad-hoc from the top of my head):
>>
>>
>> > > <...>
>>
>>
>> > > This program serves the double purpose:
>>
>>
>> > > [1] Gives you the address of the old SIGINT handler which was executed
>>
>>
>> > > prior execution of this code;
>>
>>
>> > > [2] After execution, repeat the routine (ping) and see if 
>>
>>
>> > > terminates the ping process.
>>
>>
>> > >
>>
>>
>> >
>>
>>
>> > Zoran, are you suggesting that program will change the signal handler
>>
>>
>> > to default even after it has exited, and for the subsequent ping
>>
>>
>> > command?
>>
>>
>> >
>>
>>
>> > Regards,
>>
>>
>> >
>>
>>
>> > Leon.
>>
>>
>>
>
> --
-- 
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50825): https://lists.yoctoproject.org/g/yocto/message/50825
Mute This Topic: https://lists.yoctoproject.org/mt/77073508/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] SIGINT Issues with Zeus Migration

[Leon Woestenberg]

Hi Aashik, Zoran,


On Fri, Sep 25, 2020 at 10:02 AM Zoran  wrote:
>
> > ...that I am not able to send SIGINT to commands such as Ping, tail etc.\

Aashik, how are you sending the signal? Using CTRL-C or using the
"kill" command?

>
> Please, do the following: issue in zeus xterm the command: man signal
> and read it.
>
That reads to use sigaction() instead of signal() I would assume.

> Then execute the following code (ad-hoc from the top of my head):
> <...>
> This program serves the double purpose:
> [1] Gives you the address of the old SIGINT handler which was executed
> prior execution of this code;
> [2] After execution, repeat the routine (ping) and see if 
> terminates the ping process.
>

Zoran, are you suggesting that program will change the signal handler
to default even after it has exited, and for the subsequent ping
command?

Regards,

Leon.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#50814): https://lists.yoctoproject.org/g/yocto/message/50814
Mute This Topic: https://lists.yoctoproject.org/mt/77073508/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] #sdk #yocto Appears SDK searching host for files that are only present on target side

[Leon Woestenberg]

Hello Steven,

you mention you use CMake with the Yocto (standard) SDK.

After you sourced the SDK environment script, what is the output of
"which cmake" ?

Do you use the cmake toolchain configuration file provided by the SDK?
(CMAKE_TOOLCHAIN_FILE)

In my conf/local.conf I make sure I have a native cmake included in the SDK:

# Does not work, will destroy TOOLCHAIN_HOST_TASK
#TOOLCHAIN_HOST_TASK += "nativesdk-cmake"
# This is a work-around (we need to extra space here because _append
will not add it for us).
TOOLCHAIN_HOST_TASK_append = " nativesdk-cmake"

And this is how I compile an application using SDK and CMake:

(source /tmp/oe-sdk-cmake/environment-setup-core2-64-oe-linux-musl && \
cd myapp-cmake && \
mkdir -p build_sdk && \
cd build_sdk && \
cmake 
-DCMAKE_TOOLCHAIN_FILE=$$OECORE_NATIVE_SYSROOT/usr/share/cmake/OEToolchainConfig.cmake
-DCMAKE_VERBOSE_MAKEFILE=1 . .. && \
make)

(I am using gcc, I I will verify this setup if I switch to clang.)

Regards,
-- 
Leon Woestenberg
l...@sidebranch.com
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com

On Thu, Sep 10, 2020 at 12:53 PM Monsees, Steven C (US) via
lists.yoctoproject.org
 wrote:
>
>
> fyi...
>
> I am using CMake with GNU, that is what is required for the build.
>
> I do source the SDK environment script prior to attempting build.
>
> Here is my current environment-setup-corei7-64-poky-linux script created by 
> SDK:
>
> # Check for LD_LIBRARY_PATH being set, which can break SDK and generally is a 
> bad practice
> # http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80
> # http://xahlee.info/UnixResource_dir/_/ldpath.html
> # Only disable this check if you are absolutely know what you are doing!
> if [ ! -z "$LD_LIBRARY_PATH" ]; then
> echo "Your environment is misconfigured, you probably need to 'unset 
> LD_LIBRARY_PATH'"
> echo "but please check why this was set in the first place and that it's 
> safe to unset."
> echo "The SDK will not operate correctly in most cases when 
> LD_LIBRARY_PATH is set."
> echo "For more references see:"
> echo "  
> http://tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html#AEN80;
> echo "  http://xahlee.info/UnixResource_dir/_/ldpath.html;
> return 1
> fi
> export SYSROOTS=/ede/smonsees/yocto/testSDK/sysroots
> export 
> SDKTARGETSYSROOT=/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux
> export 
> PATH=/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/sbin:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/bin:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/sbin:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/../x86_64-pokysdk-linux/bin:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux:/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/bin/x86_64-poky-linux-musl:/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux/usr/lib/../lib/:/disk0/scratch/smonsees/yocto/testSDK/sysroots/corei7-64-poky-linux/usr/lib/../lib/x86_64-poky-linux/7.3.0/:$PATH
> export PKG_CONFIG_SYSROOT_DIR=$SDKTARGETSYSROOT
> export 
> PKG_CONFIG_PATH=$SDKTARGETSYSROOT/usr/lib/pkgconfig:$SDKTARGETSYSROOT/usr/share/pkgconfig
> export 
> CONFIG_SITE=/disk0/scratch/smonsees/yocto/testSDK/site-config-corei7-64-poky-linux
> export 
> OECORE_NATIVE_SYSROOT="/disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux"
> export OECORE_TARGET_SYSROOT="$SDKTARGETSYSROOT"
> export OECORE_ACLOCAL_OPTS="-I 
> /disk0/scratch/smonsees/yocto/testSDK/sysroots/x86_64-pokysdk-linux/usr/share/aclocal"
> unset command_not_found_handle
> export CC="x86_64-poky-linux-gcc  -v -m64 -march=corei7 -mtune=corei7 
> -mfpmath=sse -msse4.2 --sysroot=$SDKTARGETSYSROOT"
> export CXX="x86_64-poky-linux-g++  -v -m64 -march=corei7 -mtune=corei7 
> -mfpmath=sse -msse4.2 --sysroot=$SDKTARGETSYSROOT"
> export CPP="x86_64-poky-linux-gcc -v -E  -m64 -march=corei7 -mtune=corei7 
> -mfpmath=sse -msse4.2 --sysroot=$SDKTARGETSYSROOT"
> export AS="x86_64-poky-linux-as  "
> export LD="x86_64-poky-linux-ld  --sysroot=$SDKTARGETSYSROOT"
> export GDB=x86_64-poky-linux-gdb
> export STRIP=x86_64-poky-linux-strip
> export RANLIB=x86_64-poky-linux-ranlib
> export OBJCOPY=x86_64-poky-linux-objcopy
> export OBJDUMP=x86_64-poky-linux-objdump
> export AR=x86_64-poky-linux-ar
> export NM=x86_64-p

Re: [yocto] meta-intel: Override SERIAL_CONSOLES variable

[Leon Woestenberg]

Hi all,

On Fri, Apr 10, 2020 at 8:56 AM Marek Belisko  wrote:
>
> Hi,
>
> in meta-intel in machine configuration SERIAL_CONSOLES are defined as
> : SERIAL_CONSOLES = "115200;ttyS0 115200;ttyS1 115200;ttyS2"
>
For a more generic solution, could this be made  a weak assignment?

I am on a SMARC x86-64 module which only one serial is useful, so I
would like to downtune this variable as well.

Regards,

Leon.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#49113): https://lists.yoctoproject.org/g/yocto/message/49113
Mute This Topic: https://lists.yoctoproject.org/mt/72915847/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] dev-manual: differing versions of same recipe in different priority layers?

[Leon Woestenberg]

Hello Robert,

On Thu, Feb 13, 2020 at 3:14 PM rpj...@crashcourse.ca
 wrote:
>   in the YP dev manual, section 3.1.6, there is a maddeningly vague
> note:
>
> "It is possible for a recipe with a lower version number PV in a layer
> that has a higher priority to take precedence."
>
>   so does it take precedence or not? just saying it's "possible"
> doesn't clarify it for the reader.
>
Yes, this should be re-worded. This is actually a FAQ.
(I remember more sentences like this exist, that especially for
non-English speakers might be difficult to interpret.)

My proposal would be:

If a recipe exists in multiple layers, the recipe with highest PV
*from the layer with the highest priority* is selected.
Be aware that recipes with the same PN in lower priority layers are
thus not selected, *even if their PV is higher*.

Regards,

Leon.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48393): https://lists.yoctoproject.org/g/yocto/message/48393
Mute This Topic: https://lists.yoctoproject.org/mt/71242216/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] clarifying "PROVIDES =" versus "PROVIDES +=" (pedantic stuff)

[Leon Woestenberg]

Hello Robert,

>   i am *assuming* that, in the absence of a compelling reason, the use
> of "+=" instead of "=" in this context is harmless, but unnecessary,
> correct?
>
My understanding is that:

> meta/recipes-support/libpcre/libpcre_8.43.bb:PROVIDES += "pcre"

means "I provide both "libpcre" as well as "pcre". I am assuming that
PROVIDES = "${PN}" is already set by a core BitBake rule somewhere.
(Didn't check...)

So I think it might be harmful to replace it with "=", as it would no
longer provide libpcre.

Regards,
-- 
Leon Woestenberg
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#48307): https://lists.yoctoproject.org/g/yocto/message/48307
Mute This Topic: https://lists.yoctoproject.org/mt/71078290/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Architecture of .wic approach; image of images

[Leon Woestenberg]

On Thu, Nov 28, 2019 at 10:01 AM Josef Holzmayr <
holzm...@rsi-elektrotechnik.de> wrote:

> On Thu, Nov 28, 2019 at 09:37:12AM +0100, Leon Woestenberg wrote:
>
> > The .wic image type however, builds an image from *images* rather than
> > packages.
>
> Thats *almost* correct. It builds an image from a *artifacts*.
>

My finding is: ...only if *artifacts* (also) includes a rootfs.

The image class dependency on rootfs seems very hardcoded. I cannot create
a recipe that works without *creating* a rootfs.
(even though I have no rootfs other than the initramfs image which is
already there, as an *artifact*).

inherit image

IMAGE_FSTYPES = "wic"
DEPENDS += "my-initramfs"

IMAGE_FEATURES = ""
IMAGE_INSTALL = ""

# This image does not generate its own root filesystem
# I have tried to exclude it, but it's hardcoded even in buildhistory.
#do_rootfs[noexec] = "1"
#do_image[noexec] = "1"
#do_image_wic[noexec] = "1"
#do_rootfs_wicenv[noexec] = "1"


WKS_FILE = "my-disk-image.wks"
my-disk-image.wks:
part /boot --source bootimg-efi
--sourceparams="loader=grub-efi,initrd=my-initramfs.cpio.gz" --ondisk
sda --label msdos --active --align 1024 --use-uuid
bootloader --ptable gpt --timeout=1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47461): https://lists.yoctoproject.org/g/yocto/message/47461
Mute This Topic: https://lists.yoctoproject.org/mt/63986097/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Architecture of .wic approach; image of images

[Leon Woestenberg]

> Au contraire :) It is the real issue because neither 1) nor 2) is the
> correct way, and I pretty much explained why that is.


So let's then consider the case that the WKS is machine specific. I am
fine with that.

- Does Yocto support building multiple images from one configuration?
- (How) can I build multiple WIC images with different WKSs?

I am not asking anything strange.
I just cannot find an example of a grub + initramfs + kernel packages
into FAT through WIC.
Or documentation on how to implement this correctly.

Regards,

Leon.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47457): https://lists.yoctoproject.org/g/yocto/message/47457
Mute This Topic: https://lists.yoctoproject.org/mt/63986097/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Architecture of .wic approach; image of images

[Leon Woestenberg]

On Thu, Nov 28, 2019 at 12:41 PM Josef Holzmayr
 wrote:
> On Thu, Nov 28, 2019 at 12:11:52PM +0100, Leon Woestenberg wrote:
> > Let me then first describe the issue I am having, which I think
> > results from my misunderstanding then.
> >
> > I would like to package a UEFI bootloader (GRUB), bzImage and
> > initramfs.cpio.gz into an FAT partition using WIC.
> >
> > 1) Should I adapt my existing my-initramfs recipe as follows:
> >
> > IMAGE_FSTYPES += "wic"
> > WKS_FILE = "my-disk-image.wks"
>
> I think I'm starting to see the problem. Do you set those things in your
> image recipe?

IMAGE_FSTYPES += "wic" goes in the image recipe, yes.

WKS_FILE is there as well for this image, because I need to create
multiple images with different WKS's.

> If it included things like that, how could we use it
> as a "hello world"-style image for about every platform?
>
I want to create several images. The one I described is a recovery image.
I also want an application image which has a different WKS.

However, this is not the real issue. I first would like to understand
if I need to follow 1) or 2).

Regards,

Leon.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47454): https://lists.yoctoproject.org/g/yocto/message/47454
Mute This Topic: https://lists.yoctoproject.org/mt/63986097/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Architecture of .wic approach; image of images

[Leon Woestenberg]

Let me then first describe the issue I am having, which I think
results from my misunderstanding then.

I would like to package a UEFI bootloader (GRUB), bzImage and
initramfs.cpio.gz into an FAT partition using WIC.

1) Should I adapt my existing my-initramfs recipe as follows:

IMAGE_FSTYPES += "wic"
WKS_FILE = "my-disk-image.wks"

my-disk-image.wks:
part /boot --source bootimg-efi-initramfs
--sourceparams="loader=grub-efi,initrd=my-initramfs.cpio.gz" --ondisk
sda --label msdos --active --align 1024 --use-uuid
bootloader --ptable gpt --timeout=1

2) Or should I create a new recipe that builds the WIC and depends on
the initramfs?

Remember, I have no rootfs other than the (non-bundled) initramfs.
Depending on the answers, I will come up with the issues I see.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47451): https://lists.yoctoproject.org/g/yocto/message/47451
Mute This Topic: https://lists.yoctoproject.org/mt/63986097/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[yocto] Architecture of .wic approach; image of images

[Leon Woestenberg]

Hello all,

What is the intended approach of building images using WIC?

Most image types (except .wic) build a (root or initial ram) filesystem
from *packages*, then create the respective archive or filesystem from it.

The .wic image type however, builds an image from *images* rather than
packages.

It therefore seems incorrect we can just add IMAGE_FSTYPES += "wic",
because the corresponding .wks might depend on multiple other images than
just ${PN}.

Should we, or do we have a recipe example that builds only a .wic image,
based on one or more other existing images? (and thus not populate a
filesystem itself)

Regards,

Leon.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47445): https://lists.yoctoproject.org/g/yocto/message/47445
Mute This Topic: https://lists.yoctoproject.org/mt/63986097/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] Memory Tests in U-Boot

[Leon Woestenberg]

Hello,

On Sat, 23 Nov 2019 at 00:40, Paul Barker  wrote:

> On Tue, 19 Nov 2019, at 12:28, devendra.devad...@iwavesystems.com wrote:
> > Hi,
> >
> > In U-Boot I found some generic memory tests commands like mtest and post
> > tests. But I need complete DDR4 memory test with below algorithms:
> >
> > * Checkerboard Test
> > * March C- Test
> > * Neighborhood Pattern Sensitive Fault
> >
>
We found stressapptest (by Google) the most reliable test for DDR
calibration problems.

We have seen unreliable systems pass other memory tests such as in U-Boot.

Regards, Leon

>
> --
Leon Woestenberg
l...@sidebranch.com
T: +31 40 711 42 76
M: +31 6 472 30 372

Sidebranch
Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.

View/Reply Online (#47393): https://lists.yoctoproject.org/g/yocto/message/47393
Mute This Topic: https://lists.yoctoproject.org/mt/61340544/21656
Group Owner: yocto+ow...@lists.yoctoproject.org
Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub  
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-