Hi,
On 06/06/23 03:29, Ricardo Salveti wrote:
On Mon, Jun 5, 2023 at 5:25 PM Ryan Eatmon via lists.yoctoproject.org
<[email protected]> wrote:
On 6/5/2023 8:30 AM, Ryan Eatmon via lists.yoctoproject.org wrote:
On 6/5/2023 8:11 AM, Paresh Bhagat wrote:
Add new recipe for u-boot-ti-jailhouse and linux-ti-jailhouse which will
be used for jailhouse for am62xx-evm.
Jailhouse support for am62xx-evm requires few patches for u-boot and
linux
which are hosted at processor-sdk/u-boot and processor/linux
respectively.
To build a image with jailhouse for am62xx-evm, these recipes
will be used instead of u-boot-ti-staging and linux-ti-staging by
changing
the preferred_provider.
Signed-off-by: Paresh Bhagat <[email protected]>
---
.../recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb | 9 +++++++++
.../recipes-kernel/linux/linux-ti-jailhouse_6.1.bb | 9 +++++++++
2 files changed, 18 insertions(+)
create mode 100644
meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
create mode 100644
meta-ti-bsp/recipes-kernel/linux/linux-ti-jailhouse_6.1.bb
diff --git
a/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
new file mode 100644
index 00000000..079d55dd
--- /dev/null
+++ b/meta-ti-bsp/recipes-bsp/u-boot/u-boot-ti-jailhouse_2023.04.bb
@@ -0,0 +1,9 @@
+require u-boot-ti-staging_2023.04.bb
+
+# This will have priority over generic uboot path
+
+BRANCH = "ti-u-boot-2023.04-jailhouse"
+
+UBOOT_GIT_URI = "git://git.ti.com/git/processor-sdk/u-boot.git"
What is reasoning for not upstreaming these patches (both u-boot and
kernel) even just into the TI repositories?
My concern is the CICD process. This is adding another recipe with a
completely different linux/u-boot repository that we need to add support
for to keep the recipes up to date.
And you guys will to keep rebasing these patches on top of the latest
6.1 prod branch when CICD promotes.
This just feels like something that is going to turn into a lot of
maintenance work in the future.
After discussing this with Praneeth, these recipes should not be called
jailhouse, but rather something more generic (maybe experiments). We do
not want to explode the number of recipes in the directory with every
experiment we want to run in the future... We can then configure which
branch under the experiments to pick based on something in the distro
features or via machine features.
And upon further reflection, do we want to create a new layer under the
meta-ti repo to house all of these new changes and not host them in
meta-ti-bsp? Basically keep meta-ti-bsp as the production versions of
code? Any thoughs Andrew, Denys, Randolph?
For experiments I think it makes sense to have it hosted in another
layer, but in this case jailhouse is an official functionality that is
also supported by TI, isn't it?
My concern is that real customers might want to have jailhouse
enabled, which will force them to use this extra layer which might not
necessarily be aligned with the main bsp revision used (e.g. kernel
and u-boot), causing maintenance issues for product builders.
Maybe in this case it is just better to have the patches available in
the layer and enabled dynamically via machine features? It is still a
pain to maintain as it might have conflicts in the future and might
require patch updates, but if indeed a desired feature it might make
sense to be part of the main layer.
We need to support various distros going forward, so it must not be tied
to Yocto layers, hence the seperate repos. Additionally, users must be
able to use git kernel tree without going to worry about applying
patches. We want to carry these changes as maintainable branch instead
of *.patch files in meta-ti-bsp.
Thanks
Cheers,
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#16673):
https://lists.yoctoproject.org/g/meta-ti/message/16673
Mute This Topic: https://lists.yoctoproject.org/mt/99339809/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-ti/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
