[Buildroot] [PATCH] boot/ti-k3-r5-loader: share download files with uboot

[Buildroot] [PATCH] boot/ti-k3-r5-loader: share download files with uboot

[Yann E. MORIN]

ti-k3-r5-loader is just a U-Boot SPL running on the R5 core on TI's K3
processors, so it makes sense to just share the downloads with U-Boot.

With commit ebe238f2b595 (package/pkg-download: use _DL_SUBDIR as root
dir of generated archives), the root of the generated archive will also
be based on _DL_SUBDIR, but the name of the archive, _SOURCE, is still
based on the current package unless explicitly set. For ti-k3-r5-loader,
that would create an archive which fiename does not match its root
directory; although Buildroot does not care (we --strip-components=1
when extracting), this would be a bit surprising to anyone manually
extrating the archive, as it diverges from the usual expectations.

Do like we do for linux-headers, and force the ti-k3-r4-loader archive
filename to be u-boot-VERSION.tar.gz

Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Anand Gadiyar <gadiyar@ti.com>
Cc: Bryan Brattlof <bb@ti.com>
Cc: Xuanhao Shi <X15000177@gmail.com>
Cc: Paresh Bhagat <p-bhagat@ti.com>

---
PS. Not sure if we should do that in the package infra, though, or even
if we can even do it. It's a special case for packages that are both
sharing their downloads, *and* being downloaded from a VCS, which is
not a situation common enough to warrant a generic implementation in the
infras... Thoughts?
---
 boot/ti-k3-r5-loader/ti-k3-r5-loader.mk | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/boot/ti-k3-r5-loader/ti-k3-r5-loader.mk b/boot/ti-k3-r5-loader/ti-k3-r5-loader.mk
index 98a6d473f1..e426f039e0 100644
--- a/boot/ti-k3-r5-loader/ti-k3-r5-loader.mk
+++ b/boot/ti-k3-r5-loader/ti-k3-r5-loader.mk
@@ -5,6 +5,7 @@
 ################################################################################
 
 TI_K3_R5_LOADER_VERSION = $(call qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_VERSION))
+TI_K3_R5_LOADER_DL_SUBDIR = uboot
 
 ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL),y)
 # Handle custom U-Boot tarballs as specified by the configuration
@@ -14,12 +15,15 @@ TI_K3_R5_LOADER_SOURCE = $(notdir $(TI_K3_R5_LOADER_TARBALL))
 else ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_GIT),y)
 TI_K3_R5_LOADER_SITE = $(call qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_URL))
 TI_K3_R5_LOADER_SITE_METHOD = git
+TI_K3_R5_LOADER_SOURCE = u-boot-$(TI_K3_R5_LOADER_VERSION).tar.gz
 else ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_HG),y)
 TI_K3_R5_LOADER_SITE = $(call qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_URL))
 TI_K3_R5_LOADER_SITE_METHOD = hg
+TI_K3_R5_LOADER_SOURCE = u-boot-$(TI_K3_R5_LOADER_VERSION).tar.gz
 else ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_SVN),y)
 TI_K3_R5_LOADER_SITE = $(call qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_URL))
 TI_K3_R5_LOADER_SITE_METHOD = svn
+TI_K3_R5_LOADER_SOURCE = u-boot-$(TI_K3_R5_LOADER_VERSION).tar.gz
 else
 # Handle stable official U-Boot versions
 TI_K3_R5_LOADER_SITE = https://ftp.denx.de/pub/u-boot
-- 
2.45.1

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] boot/ti-k3-r5-loader: share download files with uboot

[Bryan Brattlof via buildroot]

On June  7, 2024 thus sayeth Yann E. MORIN:
> ti-k3-r5-loader is just a U-Boot SPL running on the R5 core on TI's K3
> processors, so it makes sense to just share the downloads with U-Boot.
> 
> With commit ebe238f2b595 (package/pkg-download: use _DL_SUBDIR as root
> dir of generated archives), the root of the generated archive will also
> be based on _DL_SUBDIR, but the name of the archive, _SOURCE, is still
> based on the current package unless explicitly set. For ti-k3-r5-loader,
> that would create an archive which fiename does not match its root
> directory; although Buildroot does not care (we --strip-components=1
> when extracting), this would be a bit surprising to anyone manually
> extrating the archive, as it diverges from the usual expectations.
> 
> Do like we do for linux-headers, and force the ti-k3-r4-loader archive
> filename to be u-boot-VERSION.tar.gz
> 
> Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
> Cc: Anand Gadiyar <gadiyar@ti.com>
> Cc: Bryan Brattlof <bb@ti.com>
> Cc: Xuanhao Shi <X15000177@gmail.com>
> Cc: Paresh Bhagat <p-bhagat@ti.com>
> 

Nice! Thank you.

Reviewed-by: Bryan Brattlof <bb@ti.com>

This should also free us from the ti-k3-r5-loader.hash files correct? I 
can send the cleanup once this is merged unless you would like to.

    $ find -iname ti-k3-r5-loader.hash
    ./boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
    ./board/ti/am64x-sk/patches/ti-k3-r5-loader/ti-k3-r5-loader.hash
    ./board/beagleboard/beagleboneai64/patches/ti-k3-r5-loader/ti-k3-r5-loader.hash

>
> ---
> PS. Not sure if we should do that in the package infra, though, or even
> if we can even do it. It's a special case for packages that are both
> sharing their downloads, *and* being downloaded from a VCS, which is
> not a situation common enough to warrant a generic implementation in the
> infras... Thoughts?

My thinking is these are unique enough cases and I'm not too sure how 
common the need will be to do this kind of thing. So it should be fine 
to keep it out of the core package system.

~Bryan

> ---
>  boot/ti-k3-r5-loader/ti-k3-r5-loader.mk | 4 ++++
>  1 file changed, 4 insertions(+)
> 
> diff --git a/boot/ti-k3-r5-loader/ti-k3-r5-loader.mk b/boot/ti-k3-r5-loader/ti-k3-r5-loader.mk
> index 98a6d473f1..e426f039e0 100644
> --- a/boot/ti-k3-r5-loader/ti-k3-r5-loader.mk
> +++ b/boot/ti-k3-r5-loader/ti-k3-r5-loader.mk
> @@ -5,6 +5,7 @@
>  ################################################################################
>  
>  TI_K3_R5_LOADER_VERSION = $(call qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_VERSION))
> +TI_K3_R5_LOADER_DL_SUBDIR = uboot
>  
>  ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_TARBALL),y)
>  # Handle custom U-Boot tarballs as specified by the configuration
> @@ -14,12 +15,15 @@ TI_K3_R5_LOADER_SOURCE = $(notdir $(TI_K3_R5_LOADER_TARBALL))
>  else ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_GIT),y)
>  TI_K3_R5_LOADER_SITE = $(call qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_URL))
>  TI_K3_R5_LOADER_SITE_METHOD = git
> +TI_K3_R5_LOADER_SOURCE = u-boot-$(TI_K3_R5_LOADER_VERSION).tar.gz
>  else ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_HG),y)
>  TI_K3_R5_LOADER_SITE = $(call qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_URL))
>  TI_K3_R5_LOADER_SITE_METHOD = hg
> +TI_K3_R5_LOADER_SOURCE = u-boot-$(TI_K3_R5_LOADER_VERSION).tar.gz
>  else ifeq ($(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_SVN),y)
>  TI_K3_R5_LOADER_SITE = $(call qstrip,$(BR2_TARGET_TI_K3_R5_LOADER_CUSTOM_REPO_URL))
>  TI_K3_R5_LOADER_SITE_METHOD = svn
> +TI_K3_R5_LOADER_SOURCE = u-boot-$(TI_K3_R5_LOADER_VERSION).tar.gz
>  else
>  # Handle stable official U-Boot versions
>  TI_K3_R5_LOADER_SITE = https://ftp.denx.de/pub/u-boot
> -- 
> 2.45.1
> 
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] boot/ti-k3-r5-loader: share download files with uboot

[Yann E. MORIN]

Bryan, All,

On 2024-06-07 12:26 -0500, Bryan Brattlof via buildroot spake thusly:
> On June  7, 2024 thus sayeth Yann E. MORIN:
> > ti-k3-r5-loader is just a U-Boot SPL running on the R5 core on TI's K3
> > processors, so it makes sense to just share the downloads with U-Boot.
[--SNIP--]
> This should also free us from the ti-k3-r5-loader.hash files correct? I 
> can send the cleanup once this is merged unless you would like to.
>     $ find -iname ti-k3-r5-loader.hash
>     ./boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
>     ./board/ti/am64x-sk/patches/ti-k3-r5-loader/ti-k3-r5-loader.hash
>     ./board/beagleboard/beagleboneai64/patches/ti-k3-r5-loader/ti-k3-r5-loader.hash

I also pondered that. However, it is going to be a little bit
complicated, INHO. Indeed, the two can use different versions, so it
would be difficult to maintain the uboot.hash file: it would be easy to
drop a hash in uboot.hash while it is still used by ti-k3-r5-loader;
similarly for defconfigs: since they can be different versions, we can't
even share the hashes for the two, so they will have different hashes.

So that's why I did not merge the hash files.

Of course, now I notice that the two defconfigs use the same versions
for uboot and ti-k3-r5-loader. Which got me thinking that maybe we
should make that explicit (and easier!) in the menuconfig:


    diff --git a/boot/ti-k3-r5-loader/Config.in b/boot/ti-k3-r5-loader/Config.in
    index c276528fad..303f448f8b 100644
    --- a/boot/ti-k3-r5-loader/Config.in
    +++ b/boot/ti-k3-r5-loader/Config.in
    @@ -16,6 +16,10 @@ choice
          use cases you will want to use the exact same version/source
          here as it is used to build the main U-Boot package.

    +config BR2_TARGET_TI_K3_R5_LOADER_SAME_AS_UBOOT
    +   bool "same as uboot"
    +   depends on BR2_TARGET_UBOOT
    +
     config BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION
        bool "2024.04"

And then with a bit of sorcey/trickery in ti-k3-r5-loader (like we have
in package/linux-headers for example) to handle the same-as case.

Then that would make sense to merge the hash files, maybe.

Thoughts?

> > ---
> > PS. Not sure if we should do that in the package infra, though, or even
> > if we can even do it. It's a special case for packages that are both
> > sharing their downloads, *and* being downloaded from a VCS, which is
> > not a situation common enough to warrant a generic implementation in the
> > infras... Thoughts?
> My thinking is these are unique enough cases and I'm not too sure how 
> common the need will be to do this kind of thing. So it should be fine 
> to keep it out of the core package system.

Exactly my thinking too.

Thanks for the review! :-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] boot/ti-k3-r5-loader: share download files with uboot

[Bryan Brattlof via buildroot]

On June  7, 2024 thus sayeth Yann E. MORIN:
> Bryan, All,
> 
> On 2024-06-07 12:26 -0500, Bryan Brattlof via buildroot spake thusly:
> > On June  7, 2024 thus sayeth Yann E. MORIN:
> > > ti-k3-r5-loader is just a U-Boot SPL running on the R5 core on TI's K3
> > > processors, so it makes sense to just share the downloads with U-Boot.
> [--SNIP--]
> > This should also free us from the ti-k3-r5-loader.hash files correct? I 
> > can send the cleanup once this is merged unless you would like to.
> >     $ find -iname ti-k3-r5-loader.hash
> >     ./boot/ti-k3-r5-loader/ti-k3-r5-loader.hash
> >     ./board/ti/am64x-sk/patches/ti-k3-r5-loader/ti-k3-r5-loader.hash
> >     ./board/beagleboard/beagleboneai64/patches/ti-k3-r5-loader/ti-k3-r5-loader.hash
> 
> I also pondered that. However, it is going to be a little bit
> complicated, INHO. Indeed, the two can use different versions, so it
> would be difficult to maintain the uboot.hash file: it would be easy to
> drop a hash in uboot.hash while it is still used by ti-k3-r5-loader;
> similarly for defconfigs: since they can be different versions, we can't
> even share the hashes for the two, so they will have different hashes.
> 
> So that's why I did not merge the hash files.
> 
> Of course, now I notice that the two defconfigs use the same versions
> for uboot and ti-k3-r5-loader. Which got me thinking that maybe we
> should make that explicit (and easier!) in the menuconfig:
> 
> 
>     diff --git a/boot/ti-k3-r5-loader/Config.in b/boot/ti-k3-r5-loader/Config.in
>     index c276528fad..303f448f8b 100644
>     --- a/boot/ti-k3-r5-loader/Config.in
>     +++ b/boot/ti-k3-r5-loader/Config.in
>     @@ -16,6 +16,10 @@ choice
>           use cases you will want to use the exact same version/source
>           here as it is used to build the main U-Boot package.
> 
>     +config BR2_TARGET_TI_K3_R5_LOADER_SAME_AS_UBOOT
>     +   bool "same as uboot"
>     +   depends on BR2_TARGET_UBOOT
>     +
>      config BR2_TARGET_TI_K3_R5_LOADER_LATEST_VERSION
>         bool "2024.04"
> 
> And then with a bit of sorcey/trickery in ti-k3-r5-loader (like we have
> in package/linux-headers for example) to handle the same-as case.
> 
> Then that would make sense to merge the hash files, maybe.
> 

Ah Ok! Ideally they should never be different as it can only lead to 
hard to debug issues between the jump from tiboot3.bin to tispl.bin with 
vague error messages or no message at all. It's unfortunate that we even 
have the ability to select a version which can be different from uboot/

IMHO the K3 boot is complicated enough even without the ability to have 
different U-Boot version thrown into the mix. :) 

~Bryan

>
> Thoughts?
> 
> > > ---
> > > PS. Not sure if we should do that in the package infra, though, or even
> > > if we can even do it. It's a special case for packages that are both
> > > sharing their downloads, *and* being downloaded from a VCS, which is
> > > not a situation common enough to warrant a generic implementation in the
> > > infras... Thoughts?
> > My thinking is these are unique enough cases and I'm not too sure how 
> > common the need will be to do this kind of thing. So it should be fine 
> > to keep it out of the core package system.
> 
> Exactly my thinking too.
> 
> Thanks for the review! :-)
> 
> Regards,
> Yann E. MORIN.
> 
> -- 
> .-----------------.--------------------.------------------.--------------------.
> |  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
> | +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
> | +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
> | http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
> '------------------------------^-------^------------------^--------------------'
> _______________________________________________
> buildroot mailing list
> buildroot@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] boot/ti-k3-r5-loader: share download files with uboot

[Yann E. MORIN]

Bryan, All,

On 2024-06-07 14:06 -0500, Bryan Brattlof spake thusly:
> On June  7, 2024 thus sayeth Yann E. MORIN:
> > Of course, now I notice that the two defconfigs use the same versions
> > for uboot and ti-k3-r5-loader. Which got me thinking that maybe we
> > should make that explicit (and easier!) in the menuconfig:
[--SNIP--]
> > And then with a bit of sorcey/trickery in ti-k3-r5-loader (like we have
> > in package/linux-headers for example) to handle the same-as case.
> Ah Ok! Ideally they should never be different as it can only lead to 
> hard to debug issues between the jump from tiboot3.bin to tispl.bin with 
> vague error messages or no message at all. It's unfortunate that we even 
> have the ability to select a version which can be different from uboot/
> 
> IMHO the K3 boot is complicated enough even without the ability to have 
> different U-Boot version thrown into the mix. :) 

Oh, so would it make sense to completely drop that big choice, and just
always use the same version as uboot, always?

But nowadays, it is possible to enable ti-k3-r5-loader even when uboot
is not enabled. Does that even make sense, or should we tie
ti-k3-r5-loader to depend on uboot?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] boot/ti-k3-r5-loader: share download files with uboot

[Bryan Brattlof via buildroot]

On June  7, 2024 thus sayeth Yann E. MORIN:
> Bryan, All,
> 
> On 2024-06-07 14:06 -0500, Bryan Brattlof spake thusly:
> > On June  7, 2024 thus sayeth Yann E. MORIN:
> > > Of course, now I notice that the two defconfigs use the same versions
> > > for uboot and ti-k3-r5-loader. Which got me thinking that maybe we
> > > should make that explicit (and easier!) in the menuconfig:
> [--SNIP--]
> > > And then with a bit of sorcey/trickery in ti-k3-r5-loader (like we have
> > > in package/linux-headers for example) to handle the same-as case.
> > Ah Ok! Ideally they should never be different as it can only lead to 
> > hard to debug issues between the jump from tiboot3.bin to tispl.bin with 
> > vague error messages or no message at all. It's unfortunate that we even 
> > have the ability to select a version which can be different from uboot/
> > 
> > IMHO the K3 boot is complicated enough even without the ability to have 
> > different U-Boot version thrown into the mix. :) 
> 
> Oh, so would it make sense to completely drop that big choice, and just
> always use the same version as uboot, always?
> 

Absolutely!

>
> But nowadays, it is possible to enable ti-k3-r5-loader even when uboot
> is not enabled. Does that even make sense, or should we tie
> ti-k3-r5-loader to depend on uboot?
> 

There is the falcon mode option but I haven't typed out the support for 
any K3 SoCs yet (on my to-do soon list) and I haven't seen anyone use a 
separate fitimage made outside of U-Boot for falcon mode. But that 
doesn't eliminate the possibility of a future package being introduced 
to do that.

If you're OK with it, I would probably make ti-k3-r5-loader/ depend on 
uboot/ and tie the versions together until that mythical falcon mode 
package arrives.

~Bryan
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] boot/ti-k3-r5-loader: share download files with uboot

[Yann E. MORIN]

Bryan, All,

On 2024-06-07 15:34 -0500, Bryan Brattlof via buildroot spake thusly:
> On June  7, 2024 thus sayeth Yann E. MORIN:
[--SNIP--]
> > Oh, so would it make sense to completely drop that big choice, and just
> > always use the same version as uboot, always?
[--SNIP--]
> There is the falcon mode option but I haven't typed out the support for 
> any K3 SoCs yet (on my to-do soon list) and I haven't seen anyone use a 
> separate fitimage made outside of U-Boot for falcon mode. But that 
> doesn't eliminate the possibility of a future package being introduced 
> to do that.

Thanks for the interesting feedback. 👍

> If you're OK with it, I would probably make ti-k3-r5-loader/ depend on 
> uboot/ and tie the versions together until that mythical falcon mode 
> package arrives.

Yes, please. Beware that you'll need to be careful on what variables you
evaluate and when:

  - some variables are used to define make dependencies; e.g. _VERSION;

  - uboot sorts after ti-k3-r5-loader, so you can't rely on variables
    that are _computed_ in uboot.mk, but only on those that come from
    Kconfig;

  - variables that are evaluated in _CMD blocks can be anything, because
    those are evaluated 'late'.

I would direct you to the doc about that, if there was one... :-(
I think _VERSION is the only that really matters, though, but look at
how it's done for linux-headers vs linux, this is the kind of ugliness
will need here too.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] [PATCH] boot/ti-k3-r5-loader: share download files with uboot

[Romain Naour via buildroot]

Hello Yann, All,

Le 07/06/2024 à 22:50, Yann E. MORIN a écrit :
> Bryan, All,
> 
> On 2024-06-07 15:34 -0500, Bryan Brattlof via buildroot spake thusly:
>> On June  7, 2024 thus sayeth Yann E. MORIN:
> [--SNIP--]
>>> Oh, so would it make sense to completely drop that big choice, and just
>>> always use the same version as uboot, always?
> [--SNIP--]
>> There is the falcon mode option but I haven't typed out the support for 
>> any K3 SoCs yet (on my to-do soon list) and I haven't seen anyone use a 
>> separate fitimage made outside of U-Boot for falcon mode. But that 
>> doesn't eliminate the possibility of a future package being introduced 
>> to do that.
> 
> Thanks for the interesting feedback. 👍
> 
>> If you're OK with it, I would probably make ti-k3-r5-loader/ depend on 
>> uboot/ and tie the versions together until that mythical falcon mode 
>> package arrives.
> 
> Yes, please. Beware that you'll need to be careful on what variables you
> evaluate and when:
> 
>   - some variables are used to define make dependencies; e.g. _VERSION;
> 
>   - uboot sorts after ti-k3-r5-loader, so you can't rely on variables
>     that are _computed_ in uboot.mk, but only on those that come from
>     Kconfig;
> 
>   - variables that are evaluated in _CMD blocks can be anything, because
>     those are evaluated 'late'.
> 
> I would direct you to the doc about that, if there was one... :-(
> I think _VERSION is the only that really matters, though, but look at
> how it's done for linux-headers vs linux, this is the kind of ugliness
> will need here too.

As is, this patch is fine.

Indeed, in practice the meta-ti yocto layer use the same u-boot version for r5
core and the A72 core.

Applied to master, thanks.

Best regards,
Romain


> 
> Regards,
> Yann E. MORIN.
> 

_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot