Re: Yocto and Buildroot (was Re: l4-hackers Digest, Vol 246, Issue 9)
On Monday, 19 May 2025 17:47:04 CEST Torsten Wierschin wrote: > > For a detailed intro see https://bootlin.com/training/yocto/ It can be > used to fetch, configure, build, install and boot every part of an > embedded system that contains *open source* toolchain, bootloader, > kernel, filesystem, startup system, userspace etc. I am aware of what Yocto is, but I was hoping for some more detail. However, I understand that it might be an unreasonable demand on your time to get into specific details, and I was only really making a casual enquiry. When I previously used the OpenWrt distribution for the Ben NanoNote, which used comparable technology (as do many distribution building systems), the process involved wrapping up the different components so that the source code is obtained, verified, unpacked, patched (an important aspect), built and installed. I can envisage the different L4Re components being similarly wrapped up and the dependency declarations (in Control files) being converted into the appropriate form for Yocto. So, the DEPENDS definition in Yocto recipes would express the Requires definition in L4Re's Control files. One concern I might have is how the Makefile-based system used by L4Re would be used, given that it invokes all sorts of tasks that also try and organise the broader build process, satisfy dependencies, and so on. It seems to me that without simplifying the existing use of make, there might be a fair amount of duplication of work, limiting the benefits of Yocto and increasing the maintenance burden. > Unfortunately, this doesn't happen easily and the initial learning > curve is steep but a lot of chip manufacturers are moving or have > already moved in this direction providing customized yocto bsp layers > (for Linux). The kernel is really only (but important) part of the > game. Yes, having Linux Foundation support made its adoption rather more likely amongst many of the ecosystem participants. Thanks for referencing the Bootlin materials which are quite helpful! Paul ___ l4-hackers mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: Yocto and Buildroot (was Re: l4-hackers Digest, Vol 246, Issue 9)
> How are you using Yocto with L4Re? By writing layers and recipes in yocto. This is the short answer, since yocto is basically independent from Linux. For a detailed intro see https://bootlin.com/training/yocto/ It can be used to fetch, configure, build, install and boot every part of an embedded system that contains *open source* toolchain, bootloader, kernel, filesystem, startup system, userspace etc. Unfortunately, this doesn't happen easily and the initial learning curve is steep but a lot of chip manufacturers are moving or have already moved in this direction providing customized yocto bsp layers (for Linux). The kernel is really only (but important) part of the game. Am Mo., 19. Mai 2025 um 15:13 Uhr schrieb Paul Boddie : > > On Monday, 19 May 2025 08:11:58 CEST Torsten Wierschin wrote: > > Hi there! > > > > In my opinion, the problem discussed here can be solved quite well > > using yocto or buildroot or something else. If I ever find the time, > > I'd be happy to publish my yocto build environment for l4re. But maybe > > someone else will be faster? > > How are you using Yocto with L4Re? I'm familiar with tools like Buildroot and > derivatives, and it seems plausible that beyond the level of individual > packages one could probably replicate the dependency management that the L4Re > build system provides. > > I have actually used Buildroot with L4Re, but only to generate toolchains with > fairly specific requirements, so there was no real integration with L4Re as > such. > > Paul > > P.S. Another question I might ask relates to how you and others are using > L4Re, but that deserves a separate thread. > > ___ l4-hackers mailing list -- [email protected] To unsubscribe send an email to [email protected]
Yocto and Buildroot (was Re: l4-hackers Digest, Vol 246, Issue 9)
On Monday, 19 May 2025 08:11:58 CEST Torsten Wierschin wrote: > Hi there! > > In my opinion, the problem discussed here can be solved quite well > using yocto or buildroot or something else. If I ever find the time, > I'd be happy to publish my yocto build environment for l4re. But maybe > someone else will be faster? How are you using Yocto with L4Re? I'm familiar with tools like Buildroot and derivatives, and it seems plausible that beyond the level of individual packages one could probably replicate the dependency management that the L4Re build system provides. I have actually used Buildroot with L4Re, but only to generate toolchains with fairly specific requirements, so there was no real integration with L4Re as such. Paul P.S. Another question I might ask relates to how you and others are using L4Re, but that deserves a separate thread. ___ l4-hackers mailing list -- [email protected] To unsubscribe send an email to [email protected]
Re: l4-hackers Digest, Vol 246, Issue 9
Hi there! In my opinion, the problem discussed here can be solved quite well using yocto or buildroot or something else. If I ever find the time, I'd be happy to publish my yocto build environment for l4re. But maybe someone else will be faster? I'd like to thank you for the many very valuable tips posted here. Torsten Am Do., 15. Mai 2025 um 00:34 Uhr schrieb : > > Send l4-hackers mailing list submissions to > [email protected] > > To subscribe or unsubscribe via email, send a message with subject or > body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of l4-hackers digest..." > > Today's Topics: > >1. Re: Configuration, component and repository versioning (was Re: Upgrade > issues. VM won't start.) > (Marcus Hähnel) >2. Re: Configuration, component and repository versioning (was Re: Upgrade > issues. VM won't start.) > (Paul Boddie) >3. RE: Configuration, component and repository versioning (was Re: Upgrade > issues. VM won't start.) > (Richard Clark) > > > -- > > Message: 1 > Date: Wed, 14 May 2025 16:52:48 +0200 > From: Marcus Hähnel > Subject: Re: Configuration, component and repository versioning (was > Re: Upgrade issues. VM won't start.) > To: Paul Boddie , [email protected] > Message-ID: > > Content-Type: text/plain; charset="UTF-8" > > On Mon, 2025-05-12 at 22:37 +0200, Paul Boddie wrote: > > On Monday, 12 May 2025 15:09:52 CEST Marcus Hähnel wrote: > > > > > > On Mon, 2025-05-05 at 11:25 +, Richard Clark wrote: > > > > > > > But that brings me to a bigger question. > > > > How do I fetch only Long-Term-Support or Fully-Tested-and-Blessed > > > > versions? Github is woefully lacking in proper version support. > > > > I can't send random untested code to my customers. > > > > > > All code we push to Github went through our internal QA process, running > > > compile checks for all our supported architectures as well as an extensive > > > test suite on different platforms and configurations. So from that point > > > of > > > view I would say you can consider all code pushed to Github as > > > “Fully-Tested-and-Blessed”. > > > > I don't have a strong opinion about quality assurance for people wanting to > > provide solutions for paying customers, but I have personally wondered how I > > might successfully and conveniently reproduce repository configurations when > > creating new L4Re development environments. > > > > For example, if I decide to work on support for a new board, I might want to > > replicate the L4Re configuration I have been using for another board. > > Starting > > from scratch, it was possible to use the ham tool, but despite it apparently > > maintaining version details for the different repositories, it wasn't > > particularly clear how one might preserve or export that metadata for > > further > > use. > > > > I now see that there is another tool involved: > > > > https://l4re.org/getting_started/bob.html > > > > Although that doesn't seem to replace the ham tool: > > > > https://l4re.org/getting_started/make.html > > > > Naturally, one might say that this is the point at which anyone > > serious-enough > > about using L4Re would get in touch with Kernkonzept and start talking > > business, but such a lack of clarity tends to suggest that either there > > aren't > > particularly adequate solutions for such fundamental needs or that any > > adequate solutions that may exist aren't for people merely investigating or > > evaluating the technology. > > > > Again, it isn't my concern if there's a business decision involved that > > everybody feels comfortable with, and if there's a steady stream of > > interested > > customers that seems to justify such a decision, but I could easily see > > potential users going elsewhere if the answer to simple questions is "talk > > to > > us". Even in reasonably large organisations, hitting an approval barrier > > that > > "talk to us" or "register your interest" represents can be a strong > > disincentive, especially if other solutions exist. > > > > I accept that my opinion isn't important, however, since my own activities > > are > > confined to my own interests and driven by a general belief that L4Re > > represents a reasonable foundation for certain kinds of systems. That there > > isn't exactly much of a public community around L4Re could also be regarded > > as > > a disincentive for potential adopters, which is unfortunate. > > > > Paul > > Hi Paul, > > thank you very much for your thoughtful message — it's really appreciated. > > First of all: your opinion absolutely matters. The input from users like you, > who engage deeply and share candid feedback, > helps us m
