[PATCHv8 0/3] various memory related fixups

[Randolph Sapp]

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.