From trini at konsulko.com Tue Jan 7 01:55:44 2025 From: trini at konsulko.com (Tom Rini) Date: Mon, 6 Jan 2025 18:55:44 -0600 Subject: [ANN] U-Boot v2025.01 released Message-ID: <20250107005544.GG3476@bill-the-cat> Hey all, It's late in the day, but here's v2025.01. Note that this isn't late due to any issues with the master branch but rather because I've been bisect'ing a stubborn issue in -next. Our January release is always tricky due to holidays, but the extra -rc may have helped. We won't really know I suspect however until much later this month when even more testing happens post release. 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 v2024.01-rc6..v2025.01 contains what I've pulled since the last RC or: git log --merges v2024.10..v2025.01 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. The merge window is formally open again. However, I'm going to hold off on merging -next as I'm bisect'ing an issue there still and want to sort that out before merging. I'll post about that on it's own soon. The v2025.04 release is scheduled for Monday, April 7th, 2025 and the merge window will close and -rc1 will be released on the 27th of January, and then the next window will open with -rc2, two weeks later. Thanks all! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From trini at konsulko.com Mon Jan 27 23:40:21 2025 From: trini at konsulko.com (Tom Rini) Date: Mon, 27 Jan 2025 16:40:21 -0600 Subject: [ANN] U-Boot v2025.04-rc1 released Message-ID: <20250127224021.GH1233568@bill-the-cat> Hey all, It's release day and so here's v2025.04-rc1. For a -rc1, I think we're in fine enough shape. The next window won't open until after -rc2 so if you have some outstanding patches that you think should be merged to mainline for v2025.04 please speak up (or for custodians, send a pull request). As I mentioned elsewhere, 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 I also send the meeting invite via Google to the mailing list. I plan to do these regularly, post release and depending on reception the time can be adjusted or perhaps duplicate meetings held. In terms of a changelog, git log --merges v2025.01..v2025.04-rc1 As always, more details in pull requests (or the tags referenced by them) will result in more details here. I continue to plan to do an rc release every two weeks and the final release will be 07 April 2025. Thanks all! -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: From trini at konsulko.com Tue Jan 28 18:19:23 2025 From: trini at konsulko.com (Tom Rini) Date: Tue, 28 Jan 2025 11:19:23 -0600 Subject: [ANN] U-Boot v2025.04-rc1 released In-Reply-To: <20250127224021.GH1233568@bill-the-cat> References: <20250127224021.GH1233568@bill-the-cat> Message-ID: <20250128171923.GQ1233568@bill-the-cat> On Mon, Jan 27, 2025 at 04:40:21PM -0600, Tom Rini wrote: > Hey all, > > It's release day and so here's v2025.04-rc1. For a -rc1, I think we're > in fine enough shape. The next window won't open until after -rc2 so if > you have some outstanding patches that you think should be merged to > mainline for v2025.04 please speak up (or for custodians, send a pull > request). > > As I mentioned elsewhere, 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 If anyone who couldn't make it has feedback about the time, please speak up. > and I also send the meeting invite via Google to the mailing list. I > plan to do these regularly, post release and depending on reception the > time can be adjusted or perhaps duplicate meetings held. Here are my notes from the call. Anyone who was there should feel free to send any corrections / updates. Thanks! - Introductory remarks from myself. - Michal Simek brought up the "SPI issue" that we had in testing v2025.01. He reiterated that it was tested on AMD hardware but only there as it's what they have access to. Ilias Apalodimas is trying to setup access to testing on Linaro HW, and has been for a while so this is still ongoing. Ilias noted in response to my concern about HW longevity that SPI NOR should be fine to test on, but that SPI NAND might need to be tested only weekly or similar. Michal noted Love Kumar posted the SPI tests that AMD uses. He agreed that weekly running might be OK, but they (and other HW vendors likely) have plentiful HW access, for their own at least and so wearing out a component isn't a concern. Finally, Michal noted that they want to get their HW working and can isolate the code as needed to not break other platforms. - This segued in to Ilias noting that we have the general problem as well of getting things tested. Ilias asked about perhaps being strict at -rc1 instead of -rc2, just like the Linux kernel. Would people test next more if it was required to be used more? I said I was unsure as I had thought that I had been good about being strict with the -rc2 cutoff in 2024, and the problem being a lack of testing of the next branch in general. Nishanth Menon talked about what TI tests as well (and showed some graphs/etc), on the topic of can we get more broad testing run. Ilias noted there's some outstanding patches that will let arm64 boot and run an OS image via dram, and this could help expand functional testing. Nishanth noted there's many testing frameworks in use, noted using a common test framework would be good, and that while we have pytest it's not been able to be integrated to their framework. Michal Suchanek suggested moving our pytests to UT. I asked how do we handle FS tests for example? The answer is that we would have to create the images outside of the testing framework in some manner and tests will expect them to exist. I suggested it would be good to see someone convert some of the more complex tests to UT, and we could use the Dockerfile to create the required images as to not have to rely on unknown binary files. I also noted that Simon Glass has noted a number of times that pytest is much slower than just running UT for a given set of tests. Ilias noted that using pytest is a bit of a hard learning curve. Ilias talked about how his TPM testing works, including using a VM to boot an OS and check the TPM output. I talked about how this could work with pytest as well. Nishanth was saying that in terms of a framework to enable the community to do tests, the kernel community seems to be ahead. He sees 3 key things in testing frameworks which are, the capability to do distributed testing, scale up from testing at the developer's desk testing to testing in corporate farms, this means having reference builds available and moving to a pull not push methodology and a centralized reporting system. It is a bigger, but tangential problem of scaling and standardizing testing. Ilias noted that some of those are orthogonal. Michal Suchanek said this is where testing diverges. I noted a reason for pushing for Labgrid is kenelci uses it and in turn this could be a good window in to existing hardware farms, Michal Simek noted problems with getting corporate IT to allow labgrid even, and this can require a separate lab. He suggested getting common reporting of common testing would be good and gave the example of being able to record the commands and results used in AMD testing environments. I mentioned perhaps saving/reporting pytest xml? This can be viewed in the pipeline page of a recent build (artifacts aren't kept for too long due to storage needs). - This had a short follow-up with Ilias asking about if we can do sandbox tests on arm64 hosts in CI and I will follow up to enable that as the patches look to have been merged. - Michal Suchanek asked about building 32bit sandbox but doesn't have time to look in to this right now, will file a gitlab issue instead so it's not lost. - At this point no new topics were raised and I thanked everyone for their time and contributions and reiterated we'll have a meeting again in two weeks at this time, post -rc2. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: