Live Q&A with Mohammed Billoo - Yocto Project Hands-On with Toradex
Hi,
Great that you found the webinar useful. Here's the recommended way to capture a modified kernel config in a recipe: https://www.yoctoproject.org/docs/2.5/kernel-dev/kernel-dev.html#changing-the-configuration.
The recording of the Q&A session has been uploaded and can be accessed at the following location:
https://www.embeddedonlineconference.com/session/Live_QA_with_Mohammed_Billoo_Yocto_Project_Hands-On_with_Toradex
Instead of repo tool, could they use git with sub-modules ? I think that it would be better to use existing tools instead of introducing a new tool. What do you think?
Because submodules are "native" to the git repo, the don't provide the level of flexibility that multiple repo manifest files can provide. Notice that he places the manifest in a seperate git repo (personal best practice, he noted), making it independent of the git repositories referenced within the repo manifest.
This allows the repo to be modified without disturbing the manifest, and the manifest can be modified independent of the source repo. Max flexibility.
You could do something similar with a "meta" project containing just submodules -- I've done that in the past. They're not as easy to maintain as a manifest.
Thanks for the answer Dan!
It's "an answer", not "the answer", but you're welcome!
Great answer DanR. Another challenge that I've found with git submodules is that I have to have a repo within a repo, where the top level repo references a particular commit of the submodule. When a teammate wishes to make a change to the submodule, they have to push up the change to the submodule AND the top level repo (since the commit of the submodule that is referenced by the top level repo has to be updated). With repo, if it's set up to track a branch of a repo, then the teammate just needs to push up the change to the repo they're working on.
With git submodules, I always forget to update the commit pointed to by the top level repo.
In this case it was very easy to add i2c-tool package because it is included in open-embedded and that assures you that it will be compatible and it will work, but what if the package we want to install is not available there? then I guess that you would have to create a dedicated recipe for it with all the instructions for fetching, patching, configuring, building and installing it, right?
Hi,
Yes, if no recipe exists, you would need to create your own.
Hello, can these procedures be applied when using beagle bone board as the target board?
Hi,
The general processes should be the same, but there may be specific steps that are different, especially flashing.
I know there was a lot of desktop demo action, but will any of the presentation content be available later?
Hi,
Slides should be available as pdf.
you did mention during the repo sync step it is possible to create a "local" cache of the downloads folder for use inside an organization. So there is no need to download the sources again. What is best practice for such a local cache? A git repo or a file share or a NuGet feed??
Hi,
Actually neither. This is a great answer on Stack Overflow showing how to set up a mirror of your cached downloads directory:
About how long does it take to build a minimal Linux with Toradex bsp?
And what's the final build size?
Hi,
Build time is heavily dependent on machine resourcing. With a 24-core Ryzen 3950 and 32 GB of RAM, a complete build from scratch took about an hour. The size of the final WIC tarball was 57 MB.
Have you ever ported Yocto to run on a ARM that is integrated into an Xilinx FPGA?
Hi,
Yocto is already supported in Xilinx FPGAs. Check out this web page: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18841883/Yocto
Thanks! Turned out to be a bit of a refresher, but that was useful for me.
Can I still joini in this late?
Yes you can
Don't forget to join us for the live Q&A with Mohammed at 4pm EDT:
https://www.embeddedonlineconference.com/session/Live_QA_with_Mohammed_Billoo_Yocto_Project_Hands-On_with_Toradex
At about 1:08:10 into the video, you run menuconfig to enable an option in the kernel. However, it's already set like you need. Later on, you walk through the way to create a patch that includes the changes to the DTS. I cannot seem to find an equivalent way to capture the updates to the .config file resulting from menuconfig. Can you provide steps to capture those updates in a recipe as if a change had needed to be applied? I am needing to do something similar for my current project and need a change captured in a recipe.
By the way, this was a very useful session. Great webinar.