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

["Yann E. MORIN" <yann.morin.1998@free.fr>]

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