[ANN] U-Boot v2025.07-rc1 released

[Tom Rini]

On Mon, Apr 28, 2025 at 03:40:32PM -0600, Tom Rini wrote:

> Hey all,
> 
> So it's release day and I have tagged and pushed things out. Looking at
> my own TODO list, I think it's in reasonable shape. I do think there's a
> few other pull requests that need to happen still and I am optimistic
> will come shortly (but I've not reached out to anyone in particular). If
> there's anything big that people see missing, please speak up.
> 
> We're continuing with a community meeting following the release and the
> calendar link is
> https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=N280N2tlcXE3aDVtbjlicnNkcm82YnA1bDAgODliZTdiODEzMTM2YmVjMDZhODNkZTRkYTU5NzQ1ZjBhYmQxMWMxYjgzNjA2MWFlMDZjMWM3ZGJjZDE4ZGY0MUBn&tmsrc=89be7b813136bec06a83de4da59745f0abd11c1b836061ae06c1c7dbcd18df41%40group.calendar.google.com
> and once again this is the same time as the previous meeting. The
> meeting details itself are:
> https://meet.google.com/btj-wgcg-euw
> April 29th, 2025. 9am (GMT -06:00)
> 
> To join by phone:
> https://meet.google.com/tel/btj-wgcg-euw?pin=1307528552322&hs=1

And here are the notes I took on the call.

- I noted that rc1 is out, I think my queue looks good and while most of
  the PRs I expected have come in, a few haven't yet. And I may need to
  look at the SPI/NAND/NOR queue myself.
- Heinrich asked about updating QEMU in CI and the two platform failures
  that updating has shown. I've not had time to look at the
  vexpress_ca9x4 failure to see if this is a regression in QEMU or
  exposing a U-Boot bug. Heinrich has not had time to look at the RISC-V
  failure of sifive_unleashed. He will try and boot -rc1 on an Icicle
  platform which is the same cores at least as the unleashed. As part of
  this we had a short general discussion of some of the RISC-V platforms
  and cores they utilize.
- Heinrich noted E Shattow's issue that was brought up on IRC, of having
  RISC-V platforms that read the EEPROM in SPL to determine what the
  platform is and then load the proper device tree, but that they need
  to do this again in full U-Boot in order to set fdtfile in the
  environment. Is there a better way of doing this to avoid the
  double-read? Heinrich thinks there might be some mechanism to copy
  some properties today, but not everything. Simon noted bloblist could
  be an option. Further discussion about fdtfile was had. I suggested
  looking at board/ti/common/ as they also have this problem and have
  been doing something at least for a number of years. Simon noted
  SPL_HANDOFFF may be another option here.
- Heinrich noted there's many bootm stages and states are not well
  documented. Wondered who has a good understanding these days of the
  states and stages and who could describe it. Simon knows much of it,
  but it's not comprehensive. Simon has been trying to make it so you
  can work without CMDLINE, which means having function calls to go
  through the states. Simon can start by describing the constants better
  at least.
- Heinrich brought up his RFC for efi boot manager + bootstd he posted.
  Wanted to know if Simon had looked in to the rest of the patches.
  Simon is OK enough with the approach. Simon thinks that boot manager
  should be more iterative, but a discussion for later. Heinrich noted
  that for background at least, the spec requires certain behaviors to
  be done.
- Andre noted that Heinrich said Ubuntu uses fdtfile, does that mean it
  always ignores the U-Boot tree? sunxi takes the running tree and
  modifies it in tf-a/u-boot and that's the right one for the OS. This
  lead to a fairly long discussion of how Ubuntu does and doesn't work
  today, but at the end of the day U-Boot can and does support the
  various contrasting approaches used here.
- Andre asked who pays for CI (Gitlba), I noted it's all donated and use
  as much as you like as the jobs are split such that aside from
  bottlenecks on the high end machines no one else should get overly
  blocked. Simon asked if Andre can setup a lab of his HW visible to
  Gitlab. Andre will see what if anything can be done, but the sunxi
  stuff is his personal project.
- Heinrich asked of sunxi has newer hardware for example and Andre gave
  a short general update.
- Simon wanted to talk about standard passage. Heinrich asked for a
  brief overview. I asked that we not go over it without other people
  that use the code on the call. I noted the vexpress_fvp option and
  will enable it in CI later today.
- Simon asked about the Python patches he posted earlier in the day and
  I reiterated that all patches for mainline need to be against mainline
  and not some other tree.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20250429/a601a590/attachment.sig>