On Mon, Feb 10, 2025 at 04:01:51PM -0600, Tom Rini wrote: > Hey all, > > It's release day and so here's v2025.04-rc2. As this is the -rc2 > release, I've now also opened up the -next branch and will be stricter > about what I apply myself, and what I see coming in for pull requests as > well moving forward. > > Continuing on with what I started after the -rc1 release, I've > scheduled a video call tomorrow at 9am -0600 and the calendar link is: > https://calendar.google.com/calendar/event?action=TEMPLATE&tmeid=N280N2tlcXE3aDVtbjlicnNkcm82YnA1bDAgODliZTdiODEzMTM2YmVjMDZhODNkZTRkYTU5NzQ1ZjBhYmQxMWMxYjgzNjA2MWFlMDZjMWM3ZGJjZDE4ZGY0MUBn&tmsrc=89be7b813136bec06a83de4da59745f0abd11c1b836061ae06c1c7dbcd18df41%40group.calendar.google.com > and this is the same as last time. I've edited that event to be > recurring and will tweak it as needed as we aren't quite every 2 weeks > every time, but close enough.
And here are my meeting minutes. I'll preface this by saying what I mentioned on the call, moving forward I'm going to get in the habit of sending out a reminder about the meeting, maybe a week before, maybe just the Friday before (I'm not sure yet) and making sure the release announcement includes the meeting information itself too. I'm not entirely sure why the calendar link is wrong but I'll make sure the next release has the right one. With that said... Michal Simek asked if Tom had done a defconfig sync prior to release. He had not, and will do so (aside, is done now). Next, Michal asked about CVE-2024-42040: https://www.cve.org/CVERecord?id=CVE-2024-42040 https://vulert.com/vuln-db/debian-11-u-boot-170342 and if anyone was working on this issue given that it's for the old networking stack. Tom confirmed that no one is currently doing so and that it falls in to the broad category of known issues that also need someone with time and interest to investigate. Related to this, Heinrich asked about when lwIP might become the default networking stack, and also if networking is used in any SPL cases. I said that maybe by v2026.01 we could have lwIP be the default and that yes, there's SPL users of networking (and no lwIP SPL support today), along with being some uncommon but valid use cases of networking protocols that lwIP does not support such as NFS. This means that we'll likely never remove the older stack entirely. Michal noted that Xilinx platforms now default to using lwIP in mainline (not internally yet) to help with coverage. Heinrich noted that the changes in: https://patchwork.ozlabs.org/project/uboot/list/?series=442578 are important security-wise and should be applied. Tom agreed and will follow up with Jerome about a pull request (aside, being sent after this email). Heinrich also noted that the string function changes in that series are part of a more general problem and Tom agreed and noted it would be a good project for someone or some entity to audit the codebase with that in mind. Heinrich brought up the topic of EFI bootmanager probing all devices and the suggestion of using a "dummy device" to try and use EFI bootmanager after block devices but before network devices in the default scan. He hasn't had time to make an RFC patch for this due to time. He asked if Simon could live with that approach. Simon was unsure and noted that one proposed alternative was disabling EFI bootmeth completely. Heinrich explained that the problem today is the global meths run before specific ones, and some block devices are probed before this point but some may not (NVMe, USB for example, if no "start" command run) which leads to missing valid boot options (both when presenting the user a menu and if configured to boot a specific device). The first idea was to do all possible the probing needed, but this leads to boot time delays as various probes require delays for the bus to settle for example. Heinrich said we could have EFI bootmanager not probe but run it before network bootdevs are tried. Simon asked for the right idea to solve this would be and Heinrich explained his idea, which was essentially (Tom paraphrasing) with a dummy device (bootdev) for global methods to be put before network and Simon asked how it would work for when not using EFI bootmanager. Simon noted it would check block devices including USB and asked if EFI bootmanager would handle network? Heinrich said yes. Simon re-iterated the desire to more strongly integrate EFI bootmanager with bootstd/bootmeth. Heinrich noted the problem with that is that it takes too long to do just that. Simon is OK with this approach as a work-around, but thinks the right way is for EFI bootmanager to be more "dynamic". Heinrich and Simon discussed how to possibly integrate this more, but a potential problem is presenting other possible options. Simon asked if network devices takes a long time. Tom tried to clarify what network means in this case as there is a difference between EFI bootmanager today (which checks for the presence of network devices) compared with say "PXE Boot" (which will check for a device then perform a DHCP request and then TFTP the config(s)). This means that networking options in EFI bootmanager are quick until selected to be used. At the end of this, Heinrich said he would make an RFC patch of the "dummy device (bootdev)" approach. (aside, Tom asked for Heinrich and Simon to clarify the above if needed). Heinrich next noted that he's been looking in to multi dtb FIT images of late. Seems the design for some of the RISC-V platforms did not follow best practices, and some of the general FIT documentation could be improved. He said we need better documentation for implementation. Tom agreed that it was likely that some of those changes / designs were copied from another platform. Simon suggested Heinrich would be the best person to update the docs based on having just done this development. Simon thinks there's some part of this code which could be tidied up as we have similar but different approaches to this conceptual problem for xPL and full U-Boot. Simon has a RISC-V platform as well, wants to look in to this. At this point Michal Simek noted one of the Xilinx platforms addresses this problem too (xilinx_zynqmp_kria_defconfig) as another example to look at, and described how that's implemented. Heinrich asked some clarification questions, and Michal noted that in production Xilinx doesn't use dtb reselection. Tom asked for TI to chime in and explain how they handle this problem and Vignesh R explained their EEPROM-based solution and dtb reselection. Michal asked where/how DDR init is done here and Vignesh confirmed it's done in SPL, but also yes that DDR does make this tricky. The TI implementation can be reviewed at: https://source.denx.de/u-boot/u-boot/-/blob/master/board/ti/am64x/evm.c?ref_type=heads#L71 (entire file actually) https://source.denx.de/u-boot/u-boot/-/blob/master/arch/arm/mach-k3/am64x/am642_init.c Heinrich asked if OF_UPSTREAM is documented, Tom said yes, generally. Heinrich how binman nodes get in for example. Tom mentioned that it's handled via -u-boot.dtbsi and that mechanism isn't well documented and that better documentation is needed. Tom mentioned that binman nodes may not be upstreamable at this time however bootph* ones are. Simon said that populating nodes to parents should be done, but Neha Malcom Francis explained there's still cases where that's not working. Tom asked if there's a gitlab issue, Neha says yes there should be. After the call she sent me a link to: https://source.denx.de/u-boot/custodians/u-boot-dm/-/issues/21 and noted that TI is working on this part of the problem internally but is not yet ready for external review. Simon noted in chat that binman schema should be upstreamed, Tom agreed it should be when Simon is ready to deal with it. Simon would love someone else to pick it up and continue. Michal noted the SystemReady "clean dtb" requirement and the challenge comes in here. Vignesh brought up the framework to support expansion boards at: https://lore.kernel.org/u-boot/20230710145026.128481-1-rog...@kernel.org/ Heinrich mentioned wanting to get better overlay support in the kernel a few years ago, back when Beagle and Pi both had their own frameworks for handling overlays but kernel reviewers were hesitant at the time, and discussion died out. Vignesh mentioned handling this within U-Boot is still wanted in part for secure boot reasons, and set aside the kernel side discussion of this. Michal mentioned transfer list for passing along some of this kind of information as well such as which cards should be applied. Michal talked a little about the kernel side as well, including removing overlays being part of the challenge. Simon mentioned that having a uclass and building on the extensions command would help with what Roger wrote and then be easier to integrate with standard boot, Vignesh will pass that to Roger. A link to what Heinrich was referring to at the time is: https://lore.kernel.org/linux-devicetree/1482109835-9000-3-git-send-email-xypron.g...@gmx.de/ And with this, the meeting was brought to a close. -- Tom
signature.asc
Description: PGP signature
