[PATCHv8 0/3] various memory related fixups

[Tom Rini]

On Tue, Jun 02, 2026 at 06:17:26PM -0500, Randolph Sapp wrote:
> On Tue Jun 2, 2026 at 3:31 PM CDT, Tom Rini wrote:
> > 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.
> 
> Hell. Had to bisect all of the ut tests just to find out
> ut_bootstd_bootflow_cmd_boot is changing out the device tree before my test.
> 
> I didn't want to make my test dynamic because there's a chance any reservations
> I try to make could overlap with a device or some already allocated range. I
> need some known working allocation that's in a valid DT to be safe.
> 
> The bootflow_cmd_boot test will change the state of the running sandbox in a way
> that I assume can not be easily reverted. Please inform me if this assumption is
> untrue.
> 
> I can add a wrapper fixture in pytest to make sure the sandbox is restarted
> specifically after that test, but I'm not sure if that's appropriate.
> 
> ---
> 
> As an aside, test_ut_dm_init_bootstd should absolutely be a fixture instead of a
> test. May need to fix that later.

There's other tests which force a reboot, and so it wouldn't surprise me
if one got missed. And then yes, our pytests themselves would benefit
from someone with a bit better understanding of pytest spending time on
it, or just someone spending time on them and not a dozen other things
at the same time as well. Thanks!

-- 
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/20260603/c937373a/attachment.sig>