[ANN] U-Boot v2025.04 released

[ANN] U-Boot v2025.04 released

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1433 bytes --]

Hey all,

It's release day and here's v2025.04. We had some last minute issues
reported, but then also resolved.  I want to thank everyone that's
contributed to this release, not just in terms of code, but
documentation, testing and otherwise ensuring things go as smoothly as
they can.

In terms of a changelog, 
git log --merges v2025.04-rc5..v2025.04
contains what I've pulled since the last RC or:
git log --merges v2025.01..v2025.04
for changes since the last full release. As always, more details in
pull requests (or the tags referenced by them) will result in more
details here.

As is becoming reguarly scheduled, we have a community meeting tomorrow
(for me anyhow). The meeting details itself are:
https://meet.google.com/btj-wgcg-euw
April 7th, 2025. 9am (GMT -06:00)

To join by phone:
https://meet.google.com/tel/btj-wgcg-euw?pin=3D1307528552322&hs=3D1

The meeting can be added to your calendar via the link on
https://www.u-boot.org/

The merge window is formally open again. I will be merging next in to
master shortly. The v2025.07 release is scheduled for Monday, July 7th,
2025 and the merge window will close and -rc1 will be released on the
28th of April, and then the next window will open with -rc2, two weeks
later. The keen-eyed among you might notice that I fixed some incorrect
-rc1 dates in the future planning section, including for this cycle.

Thanks all!

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Re: [ANN] U-Boot v2025.04 released

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 1047 bytes --]

On Mon, Apr 07, 2025 at 04:00:11PM -0600, Tom Rini wrote:
> Hey all,
> 
> It's release day and here's v2025.04. We had some last minute issues
> reported, but then also resolved.  I want to thank everyone that's
> contributed to this release, not just in terms of code, but
> documentation, testing and otherwise ensuring things go as smoothly as
> they can.
> 
> In terms of a changelog, 
> git log --merges v2025.04-rc5..v2025.04
> contains what I've pulled since the last RC or:
> git log --merges v2025.01..v2025.04
> for changes since the last full release. As always, more details in
> pull requests (or the tags referenced by them) will result in more
> details here.
> 
> As is becoming reguarly scheduled, we have a community meeting tomorrow
> (for me anyhow). The meeting details itself are:
> https://meet.google.com/btj-wgcg-euw
> April 7th, 2025. 9am (GMT -06:00)

Sigh. As Marek pointed out on IRC, I got the date wrong in the email.
It's today, in about 40 minutes. Sorry for the confusion all.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

Community meeting April 8th 2025 (was: Re: [ANN] U-Boot v2025.04 released)

[Caleb Connolly]

Hi Everyone,

On 4/8/25 00:00, Tom Rini wrote:
> Hey all,
> 
> It's release day and here's v2025.04. We had some last minute issues
> reported, but then also resolved.  I want to thank everyone that's
> contributed to this release, not just in terms of code, but
> documentation, testing and otherwise ensuring things go as smoothly as
> they can.
> 
> In terms of a changelog,
> git log --merges v2025.04-rc5..v2025.04
> contains what I've pulled since the last RC or:
> git log --merges v2025.01..v2025.04
> for changes since the last full release. As always, more details in
> pull requests (or the tags referenced by them) will result in more
> details here.
> 
> As is becoming reguarly scheduled, we have a community meeting tomorrow
> (for me anyhow). The meeting details itself are:
> https://meet.google.com/btj-wgcg-euw
> April 7th, 2025. 9am (GMT -06:00)
> 
> To join by phone:
> https://meet.google.com/tel/btj-wgcg-euw?pin=3D1307528552322&hs=3D1
> 
> The meeting can be added to your calendar via the link on
> https://www.u-boot.org/


Here are the notes from the meeting, please feel free to clarify any 
points I might have missed or gotten wrong. Thanks Tom for chairing.

# U-Boot Community meeting April 8 2025

* Tom intro: next merged into master, small delay
* Heinrich: ACPI has regular regressions due to lack of testing in CI
   * tom proposes adding another QEMU defconfig with ACPI enabled
* Heinrich: Ubuntu images being used in CI are getting too old
   * tom: has a patch to update to GCC 14
   * tom: opened an issue, Simon to investigate (link?)
   * tom: already tested new GCC/LLVM, no new warnings.
   * tom: will rebuild docker container this week, adding byacc for 
binman to enable IMX8 testing

* state of Simons patches re: bootflow/EFI/standard boot
   * issue with standard boot that the EFI bootmgr option is always at 
the top
   * heinrich: proposes a new virtual device that can be ordered anywhere
   * heinrich will investigate in the next few weeks

* tom: modernising the Makefile
   * tom: which platforms are still using old stuff? will consider 
disabling or removing boards
   * tom: e.g. watchdog (deadline 2019), legacy i2c (deadline 2022.04)

* caleb: FdtFile revival
   * context: https://github.com/systemd/systemd/issues/36835
   * would enable picking DTB matching your kernel version
   * heinrich: robh thinks we should match on compatible instead. Simon 
also agrees
   * heinrich: fine with adding this patch
   * simon: significant harm - compatible is the only right way to 
match, anything else is a workaround
   * caleb/tom: agrees in theory, but in practise this isn't what we 
witness. Having a compressed blob of all DTs would be ideal, and 
compresses well, but nobody is doing this..
   * heinrich: U-Boot is also not the only firmware, we can't expect 
EDK2 to start shipping this.
   * Ilias: Agrees, best of the bad options
   * simon: what would be the right solution?
     * caleb: have the kernel emit a file with compatible -> fdtfile 
lookups since that's faster to read
   * Bryan Brattlof: what about overlays?
     * caleb: probably you have a more vertically integrated system
     * bryan: customers want yocto and a redhat image that works ootb

* tom/simon: bloblist:
   * tom: if bloblist is enabled it MUST have the DT, set the "mandatory 
passage flag"
   * simon: OF_BLOBLIST means DT is in bloblist
   * tom: it's a bad idea to divorce standard passage handoff from 
bloblist, but if it eases some issues for now and we can revisit in a 
~year that might be best
   * ilias: we have discussed this before. doesn't think OF_BLOBLIST 
should exist, because the info is discoverable at runtime.
   * ilias: we have a standard (firmware handoff), why do we need 
another implementation?
     * tom: hoping to reconcile over time between fw handoff and bloblist
   * tom: to re-iterate what Simon said: dt should be either in 
bloblist, embedded, or discovered through board specific means. Need to 
avoid conflating consuming bloblist and creating bloblist (e.g. in SPL).
     * tom: in SPL, if we don't have a bloblist, we don't need a config 
option.
     * tom: we should remove BLOBLIST_FIXED
   * simon: we can get rid of BLOBLIST_FIXED if we have a register 
hand-off firmware (x86)
   * out of time... Tom ok to add OF_BLOBLIST if we remove 
BLOBLIST_FIXED. Hopes that in ~1 year we'll all agree that we want the 
same thing...


> 
> The merge window is formally open again. I will be merging next in to
> master shortly. The v2025.07 release is scheduled for Monday, July 7th,
> 2025 and the merge window will close and -rc1 will be released on the
> 28th of April, and then the next window will open with -rc2, two weeks
> later. The keen-eyed among you might notice that I fixed some incorrect
> -rc1 dates in the future planning section, including for this cycle.
> 
> Thanks all!
> 

-- 
Caleb (they/them)

Re: Community meeting April 8th 2025 (was: Re: [ANN] U-Boot v2025.04 released)

[Raymond Mao]

Hi all,

I didn't have a chance to join the meeting due to a different time
zone but I have a few comments on bloblist/fdt as below.

On Wed, 9 Apr 2025 at 09:46, Caleb Connolly <caleb.connolly@linaro.org> wrote:
>
> Hi Everyone,
>
> On 4/8/25 00:00, Tom Rini wrote:
> > Hey all,
> >
> > It's release day and here's v2025.04. We had some last minute issues
> > reported, but then also resolved.  I want to thank everyone that's
> > contributed to this release, not just in terms of code, but
> > documentation, testing and otherwise ensuring things go as smoothly as
> > they can.
> >
> > In terms of a changelog,
> > git log --merges v2025.04-rc5..v2025.04
> > contains what I've pulled since the last RC or:
> > git log --merges v2025.01..v2025.04
> > for changes since the last full release. As always, more details in
> > pull requests (or the tags referenced by them) will result in more
> > details here.
> >
> > As is becoming reguarly scheduled, we have a community meeting tomorrow
> > (for me anyhow). The meeting details itself are:
> > https://meet.google.com/btj-wgcg-euw
> > April 7th, 2025. 9am (GMT -06:00)
> >
> > To join by phone:
> > https://meet.google.com/tel/btj-wgcg-euw?pin=3D1307528552322&hs=3D1
> >
> > The meeting can be added to your calendar via the link on
> > https://www.u-boot.org/
>
>
> Here are the notes from the meeting, please feel free to clarify any
> points I might have missed or gotten wrong. Thanks Tom for chairing.
>
> # U-Boot Community meeting April 8 2025
>
> * Tom intro: next merged into master, small delay
> * Heinrich: ACPI has regular regressions due to lack of testing in CI
>    * tom proposes adding another QEMU defconfig with ACPI enabled
> * Heinrich: Ubuntu images being used in CI are getting too old
>    * tom: has a patch to update to GCC 14
>    * tom: opened an issue, Simon to investigate (link?)
>    * tom: already tested new GCC/LLVM, no new warnings.
>    * tom: will rebuild docker container this week, adding byacc for
> binman to enable IMX8 testing
>
> * state of Simons patches re: bootflow/EFI/standard boot
>    * issue with standard boot that the EFI bootmgr option is always at
> the top
>    * heinrich: proposes a new virtual device that can be ordered anywhere
>    * heinrich will investigate in the next few weeks
>
> * tom: modernising the Makefile
>    * tom: which platforms are still using old stuff? will consider
> disabling or removing boards
>    * tom: e.g. watchdog (deadline 2019), legacy i2c (deadline 2022.04)
>
> * caleb: FdtFile revival
>    * context: https://github.com/systemd/systemd/issues/36835
>    * would enable picking DTB matching your kernel version
>    * heinrich: robh thinks we should match on compatible instead. Simon
> also agrees
>    * heinrich: fine with adding this patch
>    * simon: significant harm - compatible is the only right way to
> match, anything else is a workaround
>    * caleb/tom: agrees in theory, but in practise this isn't what we
> witness. Having a compressed blob of all DTs would be ideal, and
> compresses well, but nobody is doing this..
>    * heinrich: U-Boot is also not the only firmware, we can't expect
> EDK2 to start shipping this.
>    * Ilias: Agrees, best of the bad options
>    * simon: what would be the right solution?
>      * caleb: have the kernel emit a file with compatible -> fdtfile
> lookups since that's faster to read
>    * Bryan Brattlof: what about overlays?
>      * caleb: probably you have a more vertically integrated system
>      * bryan: customers want yocto and a redhat image that works ootb
>
> * tom/simon: bloblist:
>    * tom: if bloblist is enabled it MUST have the DT, set the "mandatory
> passage flag"
>    * simon: OF_BLOBLIST means DT is in bloblist

Not only DT but other stuff should be considered to be handed over via
the bloblist, currently TPM eventlog and the list will be increasing
in the future. It is a nightmare to create one kconfig for each.
Also, Firmware Handoff spec is in order to unify the handoff between
stages in one standard way but creating one kconfig for each component
implies that we are allowing "partially" compliance with the spec and
able to select which one should be from bloblist and which one should
not be.
We have kconfig BLOBLIST_PASSAGE_MANDATORY and I think we can use it
for all scenarios instead of creating new ones.

>    * tom: it's a bad idea to divorce standard passage handoff from
> bloblist, but if it eases some issues for now and we can revisit in a
> ~year that might be best
>    * ilias: we have discussed this before. doesn't think OF_BLOBLIST
> should exist, because the info is discoverable at runtime.
>    * ilias: we have a standard (firmware handoff), why do we need
> another implementation?
>      * tom: hoping to reconcile over time between fw handoff and bloblist
>    * tom: to re-iterate what Simon said: dt should be either in
> bloblist, embedded, or discovered through board specific means. Need to
> avoid conflating consuming bloblist and creating bloblist (e.g. in SPL).
>      * tom: in SPL, if we don't have a bloblist, we don't need a config
> option.
>      * tom: we should remove BLOBLIST_FIXED
>    * simon: we can get rid of BLOBLIST_FIXED if we have a register
> hand-off firmware (x86)

x86 is out of the scope of Firmware Handoff which is a spec led by Arm.
I agree that maybe x86 needs something similar but we should keep it
as-is until there is a spec telling what should be done.

Regards,
Raymond

>    * out of time... Tom ok to add OF_BLOBLIST if we remove
> BLOBLIST_FIXED. Hopes that in ~1 year we'll all agree that we want the
> same thing...
>
>
> >
> > The merge window is formally open again. I will be merging next in to
> > master shortly. The v2025.07 release is scheduled for Monday, July 7th,
> > 2025 and the merge window will close and -rc1 will be released on the
> > 28th of April, and then the next window will open with -rc2, two weeks
> > later. The keen-eyed among you might notice that I fixed some incorrect
> > -rc1 dates in the future planning section, including for this cycle.
> >
> > Thanks all!
> >
>
> --
> Caleb (they/them)
>