[ANN] U-Boot v2025.04-rc3 released

[Tom Rini]

On Tue, Feb 25, 2025 at 10:41:21AM -0600, Tom Rini wrote:

> Hey all,
> 
> Well, oops. I tagged and pushed things, and wrote this all out
> yesterday. And forgot to hit send. My fault. So it's the day after the
> release, and I tagged it all yesterday but here's the email for
> v2025.04-rc3. The -next branch has been open for two weeks now and I'll
> merge this in there shortly.
> 
> Continuing on with what I started after the -rc1 release, we had a call
> today and the link was
> 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
> February 25th, 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 meeting notes.

- I gave an overview of the master and next branches and asked for links
  to regression fixes that I've missed.
- I noted that in my queue are some ARM FFA patches and that I had
  seen something go by today about EBBR and FFA versions and asked
  Heinrich if he had any comments. He said that the patches we have
  today do need to be reviewed, and the EBBR change is to be backwards
  compatible so there's no rush.
- Heinrich asked about the status of U-Boot as an EFI application and
  arm64 support that Simon has been working on and how close it is to
  being merged. Simon was not on the call yet and so I said I don't
  know. I said it was built on top of some parts of Caleb's series that
  wasn't directly related. Caleb explained their series overall and
  reiterated that it's for a different use case, and some work in
  general is still needed. I reiterated I don't know the intention
  because it's against Simon's personal tree.
- This moved on to a general question on how to get the Qualcomm arm64
  laptops working in Linux, and it's something Caleb's group in Linaro
  is working on. They gave an overview of the general situation, of
  which U-Boot is a part of possible solutions.
- Yannic Moog asked about patches he posted for binman and external
  blobs, and is kind of stuck right now and asked how to get more help,
  I said to setup a video with Simon privately.
- Jesse T noted in 2016 someone posted a patch to disable u-boot
  relocation and asked it that would still be objected to. I asked for
  the use case, and she answered it's a 512KiB system. I asked if they
  knew of GD_FLG_SKIP_RELOC and did not. I noted XIP may or may not work
  in full U-Boot as I'm not sure it's tested currently. Heinrich noted
  that for RISC-V and QEMU, using U-Boot as the pflash payload with
  CONFIG_XIP does work and is documented. I suggested this means that
  generally it should work but there might be some ARM-specific issues
  to resolve.
- At this point, Simon Glass had joined the call and Moteen Shah and
  other TI people asked about bootph property propigation and
  https://lore.kernel.org/all/20250212091820.213895-1-m-shah@ti.com/ and
  what to do next. Kernel community advices that the bootph property
  should be in the child only. Simon wanted to clarify that this is
  indeed for prior to full U-Boot and just SPL and why we needed to add
  the properties. Simon got clarification that the devices are only to
  be bound when the property is present. The parents are missing the
  property and only the child has it. Simon suggested calling a
  recursive function to find what needs to be bound. The question is,
  what is more efficient and wall-clock quicker. Simon asked for
  benchmarking of the recursive method rather than the patch linked
  above instead to confirm his suggestion is slower, as he suspects it
  should be faster, not slower. Caleb wanted to clarify that don't we
  already check every node while binding, and so this patch adds work
  and don't we already have some code that could be called already?
  Manorit asked where that logic is, and Simon wasn't sure if we did,
  and repeated his idea that ideally is most efficient. Manorit asked
  about the binman solution Simon had also mentioned, as he's not sure
  how it would work. Simon confirms binman modifies the flat device tree
  where it needs to. Simon will provide some code pointers after the
  call for clarification. TI will try the algorithm approach above first
  and if that doesn't work, binman.
- Anurag asked about if TI should be using env nowhere or having people
  default to using env default -f -a, in response to some feedback I had
  given them previously. I asked if this is a TI specific
  question or just general best practices. I gave my opinion on how
  it should work, but it's up to indiviual board maintainers to pick
  what they think will work best. I will check on the status of:
  https://lore.kernel.org/u-boot/14701984-073f-4976-b0c2-e2c42dadadd8@ti.com/
  after the call.
  - Follow-up: I had set that to superseded by accident and have since
    merged to next.
- Caleb brought up a more generic qustion, how or should we have a more
  generic arm64 u-boot build. This is related to both the the thread at
  [0] and also Stephen Boyd posting support for a Qualcomm platform
  chainloading from coreboot. Caleb notes there's a large number of ways
  today to pass memory information on qcom platforms as well as to just
  boot them. This will be a mess without some careful planning. Perhaps
  we could have some generic way of checking for some of this
  information and using it, to avoid duplication. This could lead to
  being able to have a more generic image itself. Is there interest?
  Feedback? Tom said yes, but need to be careful about single platform
  support still. Heinrich noted it also needs to be a consideration of
  what the end use case is, are we aiming for on HW itself vs provided
  by the distribution. Caleb noted one use case is HW automation and
  testing, for example citron(trini: I'm not sure I caught the name and
  a follow-up link would be appreciated). There, adding a new HW
  platform is very straightforward and automated. Having U-Boot be able
  to fit in there would be very useful. Other than that, some use cases
  Caleb envisions might be new SoC/device bring-up using U-Boot to start
  with as it can be easier than Linux, mostly about simplifying support
  to new platforms. For example, lots of kernel knowledge in the
  Qualcomm and phone-device community (trini: postmarketOS for example I
  believe was mentioned), but less so of U-Boot. And here, the user can
  only chainload U-Boot anyhow due to lockdown. I reiterated my general
  concern about needing 2+ examples before designing something generic,
  and so to sort out handling Qualcomm first. Jesse asked if we would
  have U-Boot have tons of device trees or if it would be passed in via
  ACPI or similar. Caleb says it depends on the part. Some cases we get
  DT passed in, and in maybe we have some platform specific logic. Tom
  reiterated having SPL figure out the DT and pass to generic full
  U-Boot woould be his preferred solution. Caleb pointed towards barebox
  as an example that has this today. Simon asked about Caleb's comment
  about getting the memory map from coreboot, and how that works
  exactly. Caleb wasn't sure off-hand. Ilias noted that linker scripts
  for EFI runtime services / linker scripts need to be cleaned up due to
  some potential issues. After that, a common linker script for all
  boards could be done, and this would be moving in the direction of
  having genric images. In the chat, Simon says: "I'd like to see more
  generic stuff. When Linux is 40MB uncompressed, we can live with
  U-Boot growing if we are getting benefits from it".

[0]: https://lore.kernel.org/u-boot/b5d2bd37-4424-4660-b5c3-d505e5485ced@linaro.org/

-- 
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/20250225/630b7735/attachment.sig>