uboot: Bump uboot version to 2026.07-rc1#2016
uboot: Bump uboot version to 2026.07-rc1#2016ricardosalveti merged 2 commits intoqualcomm-linux:masterfrom
Conversation
aswinm94
requested review from
anujm1,
koenkooi,
lumag,
ndechesne,
ricardosalveti,
sbanerjee-quic and
vkraleti
as code owners
Test run workflowTest jobs for commit 11e7c649be0f17bfb975726187efd933d916b2b5
All jobs summary
|
Test Results 95 files ± 0 479 suites ±0 6h 23m 54s ⏱️ + 11m 45s For more details on these failures, see this check. Results for commit 0596725. ± Comparison against base commit 517d87f. ♻️ This comment has been updated with latest results. |
|
Please rebase. |
|
NAK for this U-Boot bump since it's based on a downstream U-Boot branch: https://github.com/qualcomm-linux/u-boot/commits/u-boot-mainline-1.0/ and not on qcom-next. @aswinm94 didn't we discussed about that the meta-qcom integration has to closely follow U-Boot upstream and not a dump of downstream patches. |
the srcrev has been updated to point to qcom-next |
Update the uboot version from 2026.04-rc1 to stable 2026.07-rc1 release Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
aswinm94
changed the title
The mkeficapsule host tool fails to compile with U-Boot v2026.04+ in Yocto builds. This is a known upstream issue already reported in U-Boot and OE-Core. As OE-Core has not yet been updated to support v2026.04, disable CONFIG_TOOLS_MKEFICAPSULE to unblock the build. This change is intended as a temporary workaround until the upstream fixes are merged and consumed. References: - https://lore.kernel.org/all/20260408130553.819420-1-fra.schnyder@gmail.com/ - https://lore.kernel.org/u-boot/20260409074710.1322519-1-Wojciech.Dubowik@mt.com/ Signed-off-by: Aswin Murugan <aswin.murugan@oss.qualcomm.com>
|
Since uboot qcom-nxt branch has been rebased to 2026.07-rc1 recently, updated the PR to align with it |
Bump to qcom-next based on 2026.07-rc1 sounds fine to me. |
|
But why are you updating to a newer version after this PR was proposed and approved? Since this is a major change I would prefer updating in steps, first to the final 04 release and then to the 07-rc1 (since this is rc1 and it might have other issues). |
@ricardosalveti , when the PR was created the qcom-next branch was based on 2026.04, yesterday we had a 2026.07-rc1 release from uboot which has many of the changes from Qualcomm also the qcom-next branch was rebased to the newer version, hence i updated PR to point to 2026.07-rc1 |
Sure, but please avoid changing PRs which were already approved for the previous release, it is perfectly fine to propose a new one later for the new bump, which also helps when we want to bisect possible regressions and issues. |
@ricardosalveti , qli2.0 required features & bug fixes are present in 2026.07-rc1, so it will be good to bump to that version directly. |
That's a good thing to discuss, as wrynose (which is the release QLI 2.0 will be based on) uses u-boot 2026.04 by default, so this will move us ahead of oe-core, which is fine for master but we might want to discuss for wrynose. I'm OK using a newer version for wrynose as there is no LTS for u-boot, but I'm not sure releasing on 07-rc1 is ideal, I would prefer to only bump wrynose once we have the final 07 release. @b49020 @lumag @ndechesne what do you guys thing? Meanwhile can you move back to the 2026.04 based rev? We can merge it first and then decide how to bump to 07-rc1. |
Unless @b49020 recommends otherwise, I'd go with 2026.04. |
Not sure if we tightly follow that practice from kernel point of view as well.
U-Boot LTS has been long discussed but it doesn't exist at all. The U-Boot team's effort are towards mainline enablement only and I think that's the feasible approach only given the limited number of folks working upstream. Surely there will be regular rcX bumps for U-Boot as we already do for the kernel rcX but U-Boot doesn't have the LTS model as the kernel does. That means all the fixes even after U-Boot main releases land in master branch only. Regarding Yocto wrynose vs mainline, even if we decide 2026.04 then there aren't any plans to support any feature updates or fixes there. Not sure if that would be useful for the customers if regular updates don't come there. However, if we stick with mainline then for sure it will go through the testing process and any fixes required will get merged in staging tree as well as in mainline. |
So the only "supported" path from our side would be to keep moving it to newer releases even in wrynose. Guess with that it is fine to move it to 07-rc1 then, as it will be the baseline we support. |
Given the resourcing constraints and U-Boot no LTS model, I think that's a reasonable approach to take. Also, we would be tracking the U-Boot patch-set delta in staging tree to be well under control as the upstream work continues. |
Just a note to link to an issue so we can revert the changes later. |
ricardosalveti
merged commit 56c213d
into
qualcomm-linux:master
5 participants
Update the uboot version from 2026.04-rc1 to 2026.07-rc1 release
U-Boot v2026.04 introduces a build failure in the mkeficapsule host tool
when building via Yocto/OpenEmbedded.
This is a known upstream issue reported in both U-Boot and OE-Core,
and the required fixes are not yet present in the OpenEmbedded layer,
which has not been updated to fully support v2026.04.
As a temporary workaround, CONFIG_TOOLS_MKEFICAPSULE is disabled to
allow the U-Boot build to succeed until the upstream fixes are
available and integrated.