[PATCHv8 0/3] various memory related fixups

[Tom Rini]

On Tue, Jun 02, 2026 at 02:43:09PM -0500, Randolph Sapp wrote:
> On Tue May 26, 2026 at 7:09 PM CDT, Tom Rini wrote:
> > On Wed, May 13, 2026 at 03:49:40PM -0500, rs at ti.com wrote:
> >
> >> From: Randolph Sapp <rs at ti.com>
> >> 
> >> Nitpicks and fixes from the discovery thread on adding PocketBeagle2 support
> >> [1]. This does a lot of general setup required for the device, but these
> >> modifications themselves aren't device specific. For those specifically
> >> interested in PocketBeagle2 support and don't care about these details, my
> >> development branch is public [2].
> >> 
> >> That first patch may provoke some opinions, but honestly if that warning was
> >> still present I wouldn't have spent a week poking holes in both the EFI and LMB
> >> allocations systems. Please let me know if there is a specific usecase that it
> >> breaks though.
> >> 
> >> [1] https://lore.kernel.org/all/DHHC66BBMD27.YHGIH43C6XBK@ti.com/
> >> [2] https://github.com/StaticRocket/u-boot/tree/feature/pocketbeagle2
> >
> > This leads to test failures now (that either need to be fixed or
> > updated):
> > https://source.denx.de/u-boot/u-boot/-/jobs/1464028 and please see
> > https://docs.u-boot.org/en/latest/develop/ci_testing.html as well for
> > starting CI, however you might want to run the tests locally first.
> > Thanks.
> 
> So, that's the fun part. I ran qcheck with this. I went tracing through that
> make target and even started manually issuing "./test/py/test.py --bd
> sandbox_flattree --build -k ut_image_fdt_test_boot_fdt_add_mem_rsv_regions -s"
> (and again with sandbox, sandbox64, etc.) to see exactly why that's failing in
> CI. I cannot reproduce the issue reported. It passes and reports all the
> messages I'm expecting on my end.
> 
> The CI pipeline must not be loading the test.dtb. No idea how that's occurring,
> or how the other UT_DM tests are passing. I don't see any particularly weird
> parameters in the test logs.
> 
> It's not like this test is dependent on the same things UTF_DM tagged tests are,
> but I expected to be able to reuse that device tree without having to specify
> that flag. That's the behavior I have locally at least. Adding an explicit check
> for CONFIG_UT_DM didn't seem to help at all.
> 
> Any advice here?

Have you tried running it the way it's shown in the
.azure-pipelines.yml or .gitlab-ci.yml files? And I wouldn't limit
things to just the single test, it's possible there's some unexpected
thing to be cleaned up from another test that's contaminating things.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260602/6c6c8ff5/attachment.sig>