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-s...@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-e2c42dada...@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-d505e5485...@linaro.org/ -- Tom
signature.asc
Description: PGP signature
