Thu, Mar 26, 2026 at 06:23:20PM -0500, Randolph Sapp wrote:
[snip]
Alright, looking into the allocation helpers it seems that
EFI_CONVENTIONAL_MEMORY can be remapped in efi_allocate_pages so long as LMB
agrees that it's free. This aligns with my understanding of the UEFI spec as
well. I dumped the EFI memory map and noticed there were 2 fragmented sections
of EFI_CONVENTIONAL_MEMORY that it could still use.
Wired up efi_allocate_pages to go to those regions and attempt to allocate from
there in the even an LMB_MEM_ALLOC_MAX or LMB_MEM_ALLOC_ANY start failing. Seems
to have worked, but now I'm seeing the following reported in the kernel:
[snip]
I can't help with that, but I hope that someone can. Because I intend to
work on improvements related to secure boot and FIT verification, having
this board working in the current u-boot would be really great. I'm
looking forward to test a revised patch set.
Coincidentally, I just got a PocketBeagle 2 yesterday. It took a while
for me to find some useful u-boot source code. I came across
https://github.com/beagleboard/u-boot/commit/64be5e474943dc5c6e6e01edc124ff6f53f616a4
which is a few changes ahead of u-boot:
64be5e47494 arm: dts: k3-am62-r5-pocketbeagle2: remove chosen uart override
e1207aad9b0 arm: dts: k3-am62-pocketbeagle2: add boot phase flag to uart6
23f9fc5d6da arm: mach-k3: am62: add &main_uart6 to clock and pwr tree
156a9bb1410 add: k3-am62-pocketbeagle2
On a merge to the current u-boot master, I discarded a change to
k3_get_a53_max_frequency(void) by 156a9bb1410 because that function has
been replaced with am62p_map[]. In that array, the clock rates for the
speed grades S,T,U,V would conflict with patch. I don't expect this to
be essential, but I thought that I would mention it because there were
no adjustments to the speed grade in this patch set.
With best regards,
Marko
