[bug#70131,0/5] Update U-boot.

Hello,

I bumped U-boot to a proper release, that's all.

Cheers,
Herman

Herman Rimm (5):
  gnu: bootloader: Add nanopi-r4s-rk3399 bootloader.
  gnu: u-boot: Use DDR3 patch for Nano Pi R4S.
  gnu: firmware: Update make-arm-trusted-firmware to 2.10.
  gnu: u-boot: Update to 2024.04.
  gnu: bootloader: Add orangepi-zero2w bootloader.

 gnu/bootloader/u-boot.scm                     |  24 +++-
 gnu/local.mk                                  |   4 +-
 gnu/packages/bootloaders.scm                  |  66 ++++++++--
 gnu/packages/firmware.scm                     |  11 +-
 .../u-boot-build-without-libcrypto.patch      | 123 ------------------
 .../patches/u-boot-nanopi-r4s-ddr3.patch      |  25 ++++
 6 files changed, 110 insertions(+), 143 deletions(-)
 delete mode 100644 gnu/packages/patches/u-boot-build-without-libcrypto.patch
 create mode 100644 gnu/packages/patches/u-boot-nanopi-r4s-ddr3.patch


base-commit: 014875b29e68da6357a5323e6dd1eaa74a05b753
  

My summary of the situation so far...

On 2024-05-09, Herman Rimm wrote:
> Herman Rimm (5):
>   gnu: bootloader: Add nanopi-r4s-rk3399 bootloader.

Looks good, although is it useful without the follow-up patch? If not, I
would squash the two in a single commit?


>   gnu: u-boot: Use DDR3 patch for Nano Pi R4S.

Question regarding the upstream status for this patch and including
relevent descriptions about upstream status, origin, purporse, etc. in
the .patch comments.


>   gnu: firmware: Update make-arm-trusted-firmware to 2.10.

I can confirm the upstream hashes on this and it builds.

I suspect this would be fine to merge as-is even without including the
other patches in the series, though I have not verified this as yet.


>   gnu: u-boot: Update to 2024.04.

Also able to confirm the upstream hashes, although at least two packages
to fail to build, u-boot-sandbox and u-boot-rockpro64-rk3399. From the
comments on the earlier series, I am guessing you were aware of this,
but figured I'd mention which packages.

This is probably due to trying to build without openssl, due to
(potential) license incompatibilities between openssl and GPL; this is
not well suppored upstream and we have been carrying patches for quite
some time about this...


>   gnu: bootloader: Add orangepi-zero2w bootloader.

Looks good.


For the most part, there are substitutes available from bordeaux, at
least for x86_64. I will also try to do some builds on aarch64.


live well,
  vagrant
  

Hello,

On Wed, May 15, 2024 at 01:26:01PM -0700, Vagrant Cascadian wrote:
> My summary of the situation so far...
> 
> On 2024-05-09, Herman Rimm wrote:
> > Herman Rimm (5):
> >   gnu: bootloader: Add nanopi-r4s-rk3399 bootloader.
> 
> Looks good, although is it useful without the follow-up patch? If not, I
> would squash the two in a single commit?

The bootloader with the DDR3 patch works, so it should also work without
the patch.  I believe the LPDDR4 version is more common because it has
OpenWRT support while the DDR3 version does not [1].  The LPDDR4 version
would not be useful to me, but in general it would be more useful.

> >   gnu: u-boot: Use DDR3 patch for Nano Pi R4S.
> 
> Question regarding the upstream status for this patch and including
> relevent descriptions about upstream status, origin, purporse, etc. in
> the .patch comments.

The patch is not submitted upstream or already present upstream.  I made
the patch for the DDR3 (as opposed to LPDDR4) variant of the Nano Pi
R4S.  I will write this in the patch comments as well.

Should there be bootloaders for both Nano Pi R4S variants?

> >   gnu: u-boot: Update to 2024.04.
> 
> Also able to confirm the upstream hashes, although at least two packages
> to fail to build, u-boot-sandbox and u-boot-rockpro64-rk3399. From the
> comments on the earlier series, I am guessing you were aware of this,
> but figured I'd mention which packages.

I will try getting u-boot-rockpro64-rk3399 to build.

Cheers,
Herman

[1]: https://openwrt.org/toh/friendlyarm/nanopi_r4s_v1
  

On 2024-05-16, Herman Rimm wrote:
> On Wed, May 15, 2024 at 01:26:01PM -0700, Vagrant Cascadian wrote:
>> My summary of the situation so far...
>> 
>> On 2024-05-09, Herman Rimm wrote:
>> > Herman Rimm (5):
>> >   gnu: bootloader: Add nanopi-r4s-rk3399 bootloader.
>> 
>> Looks good, although is it useful without the follow-up patch? If not, I
>> would squash the two in a single commit?
>
> The bootloader with the DDR3 patch works, so it should also work without
> the patch.  I believe the LPDDR4 version is more common because it has
> OpenWRT support while the DDR3 version does not [1].  The LPDDR4 version
> would not be useful to me, but in general it would be more useful.

Got it, thanks!


>> >   gnu: u-boot: Use DDR3 patch for Nano Pi R4S.
>> 
>> Question regarding the upstream status for this patch and including
>> relevent descriptions about upstream status, origin, purporse, etc. in
>> the .patch comments.
>
> The patch is not submitted upstream or already present upstream.  I made
> the patch for the DDR3 (as opposed to LPDDR4) variant of the Nano Pi
> R4S.  I will write this in the patch comments as well.

Great!

> Should there be bootloaders for both Nano Pi R4S variants?

Based on the fact that there are two models with different hardware,
seems like there should be two variants of the package.

Bringing this up upstream might also be a good idea, as they might
either make a second variant upstream, or suggest a clever way to have a
single build that autodetects which variant it is and "does the right
thing" out of the box.

If you do start such a thread, a link to the discussion would be great
to have in the patch comments.


>> >   gnu: u-boot: Update to 2024.04.
>> 
>> Also able to confirm the upstream hashes, although at least two packages
>> to fail to build, u-boot-sandbox and u-boot-rockpro64-rk3399. From the
>> comments on the earlier series, I am guessing you were aware of this,
>> but figured I'd mention which packages.
>
> I will try getting u-boot-rockpro64-rk3399 to build.

Thanks!

live well,
  vagrant