RFC: Setup dynamic layers #45
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
By default it will use sdimgage-sota.wks that is the correct to be used with rpi Signed-off-by: Matheus Castello <[email protected]>
We need ota-ext4 and wic for rpi Signed-off-by: Matheus Castello <[email protected]>
we have to make sure to set the u-boot-fio and use only it Signed-off-by: Matheus Castello <[email protected]>
meta-lmp is applying some patches for rpi Kernel v4.19 Signed-off-by: Matheus Castello <[email protected]>
Setting uart enabled as default Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Changing torizonlogo to add the "Powered by Toradex", since the hardware is not by Toradex but the software is Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
This is mainly for debug purposes, we need to add support also to torizoncore-builder to add custom kernel args in production images. Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Ooops, some cherry pick mess up with ostree Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Using kirkstone Torizon 6.0.0 Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
The entry for the /dev/sda1 partition make sense only for x86, for the other machines this is causing a boot wait for the /dev/sda1 device that does not exist. Signed-off-by: Matheus Castello <[email protected]>
Update the feature support table according to the 6.6.0 release table available on https://github.com/commontorizon/meta-common-torizon/releases/tag/v6.6.0-common Signed-off-by: Leonardo Graboski Veiga <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
Add a distro named "torizon-xenomai" that select the Xenomai kernel and set the corresponding kernel command-line args. Add a recipe that build the "linux-evl" Xenomai 4 kernel fork, which include the EVL co-processor implementation. Use the active SLTS kernel 5.10.y branch from Xenomai, because it's the same version as "linux-intel-lts" for kirkstone in meta-common-torizon. Set minimal kernel config for Xenomai to work. Further optimization may be possible, but is not covered. Signed-off-by: Leonardo Graboski Veiga <[email protected]>
Use LABEL=efi instead of /dev/sda1 to mount the EFI partition. This fix the boot issue under devices that does not create the /dev/sda1 device node, for example device that uses eMMC storage or other storage devices. Signed-off-by: Matheus Castello <[email protected]>
In the Xenomai docs and also on Intel ECI docs, there are comments on kernel config that help with low latency, which improves the real-time reliability and performance. From https://v4.xenomai.org/dovetail/rulesofthumb/: * CONFIG_DEBUG_IRQ_PIPELINE and CONFIG_DEBUG_DOVETAIL are helpful to keep the development process sane. * CONFIG_RAW_PRINTK is useful and recommended for debugging Xenomai out-of-band issues. From https://v4.xenomai.org/core/user-api/scheduling/: * CONFIG_EVL_SCHED_QUOTA and CONFIG_EVL_SCHED_TP enabled to give users more scheduler options for the Xenomai out-of-band scheduler. From https://eci.intel.com/docs/3.1/appendix.html#eci-kernel-configuration-optimizations: * CONFIG_NO_HZ and CPU_FREQ_STAT disabled to reduce task scheduling clock overhead. * CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE enabled as default to prevent the CPU governor from throttling the CPU frequency for power-saving. * CONFIG_SUSPEND and CONFIG_PM disabled to prevent power management features to introduce spikes to latency. * CONFIG_VIRT_CPU_ACCOUNTING and CONFIG_VIRT_CPU_ACCOUNTING_GEN for more accurate task and CPU time accounting. * CONFIG_RCU_NOCB_CPU for CPU temporal isolation. Each config in this commit was enabled individually and tested for 5 minutes under stress, using the Scary Grinder workload as defined on the doc https://v4.xenomai.org/core/benchmarks/#stress-workloads A final stress test was run for 3 hours. This is the same idea as the "EVL stress" test defined on https://v4.xenomai.org/ports/, except it was not run for 24h. Signed-off-by: Leonardo Graboski Veiga <[email protected]>
Signed-off-by: Matheus Castello <[email protected]>
When the SRCREV:use-head-next is set to ${AUTOREV} the rac recipe
fails to build because the SRCREV_tough should be exactly the same
as the Cargo.lock file is referencing, and it need to be set
manually.
Signed-off-by: Matheus Castello <[email protected]>
The raspberrypi0-wifi machine does not support the drm renderer, so we need to force the use of the frame buffer renderer. Signed-off-by: Matheus Castello <[email protected]>
xenomai: tune kernel config for low latency
On the kernel, Xenomai 3 and 4 use the same base patch set, named "Dovetail" since the kernel 5.10 and newer. The difference is the co-kernel: Xenomai 3 uses Cobalt, and Xenomai 4 uses EVL. Due to this difference, this commit split the current implementation in two, so users can choose which version of the framework to use. The kernel is built as recommended on https://v3.xenomai.org/installation/ and the installation is tested on a Seeed Studio Odyssey X86J4125 v2 SBC using the official Xenomai 3 tools packaged in a container. Test instructions are available on https://github.com/leograba/xenomai-torizon-tests Signed-off-by: Leonardo Graboski Veiga <[email protected]>
xenomai: add Xenomai 3 in addition to Xenomai 4
The ti-soc override is used for some changes needed on verdin-am62. But those changes do not work for beagleplay. Change the override to specifically use verdin-am62. Signed-off-by: Drew Moseley <[email protected]>
Signed-off-by: Drew Moseley <[email protected]>
Signed-off-by: Drew Moseley <[email protected]>
Signed-off-by: Drew Moseley <[email protected]>
Signed-off-by: Drew Moseley <[email protected]>
Signed-off-by: Drew Moseley <[email protected]>
Signed-off-by: Drew Moseley <[email protected]>
Signed-off-by: Drew Moseley <[email protected]>
Signed-off-by: Drew Moseley <[email protected]>
|
For now this is just for discussion. I'll rebase at some point to get rid of the merge conflicts. |
Signed-off-by: Drew Moseley <[email protected]>
|
This makes a lot of sense to me. Will the manifest stay the same or can we use some other tool to also dynamically download just what's needed? |
|
Looks quite an interesting feature, especially for a setup with many machines from several different vendors. |
|
Yeah, I'm not sure how well repo would handle this. In past projects we had a base XML repo manifest and many others that included it. And I think our current repo does something like this so we can certainly consider reworking the manifest to make it easier to checkout only a subset of the report. Alternatively, but more of a change, we could consider using Kas as it has even easier workflows to support this. I've played with it a bit and even wrote a python script to help convert a Toradex repo into a kas file but I have not done much testing on it. |
microhobby
force-pushed
the
kirkstone
branch
3 times, most recently
from
62e7de7 to
68a7613
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Thinking about users of non-Toradex platforms, they may not want all the toradex and freescale layers. I used a combination of BBFILES_DYNAMIC and conditional settings in bblayers.conf to only include the needed layers.
We can't completely remove meta-toradex-bsp-common as some of the bbclasses in there are used in the Torizon metadata. In the future it might be nice to refactor that so we do not need the Toradex BSP layer.