[PATCHv8 0/3] various memory related fixups

[Randolph Sapp]

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?