Re: [PATCH 2/3] k3-am62-pocketbeagle2: add initial board support

[Randolph Sapp <rs@ti.com>]

On Wed Mar 25, 2026 at 7:34 PM CDT, Randolph Sapp wrote:
> On Mon Mar 23, 2026 at 2:46 PM CDT, Robert Nelson wrote:
>> On Mon, Mar 23, 2026 at 2:37 PM Randolph Sapp <rs@ti.com> wrote:
>>> On Fri Mar 20, 2026 at 10:32 AM CDT, Robert Nelson wrote:
>>> >> > +++ b/configs/am62_pocketbeagle2_a53_defconfig
>>> >> > @@ -6,11 +6,11 @@ CONFIG_SPL_LIBCOMMON_SUPPORT=y
>>> >> >  CONFIG_SPL_LIBGENERIC_SUPPORT=y
>>> >> >  CONFIG_NR_DRAM_BANKS=1
>>> >> >  CONFIG_SOC_K3_AM625=y
> [snip]
>>> >> > @@ -120,7 +115,8 @@ CONFIG_SYSRESET_TI_SCI=y
>>> >> >  CONFIG_EXT4_WRITE=y
>>> >> >  CONFIG_FS_FAT_MAX_CLUSTSIZE=16384
>>> >> >  CONFIG_LZO=y
>>> >> > -CONFIG_EFI_SET_TIME=y
>>> >> > +CONFIG_SYS_MEM_TOP_HIDE=0x4000000
>>> >>
>>> >> Any reason why we are using TOP_HIDE here instead of just moving OPTEE
>>> >> lower in DDR like we do on the 512MiB AM6254atl EVM?
>>> >
>>> > Sorry, that is now a legacy setting before OPTEE finally got moved in
>>> > v2026.01, as this had been developed thru v2025 u-boot releases..
>>> >
>>>
>>> Well, it's worth noting that this change was not done in the usual way, and
>>> involves user interaction during the build beyond selecting a defconfig.
>>>
>>> https://texasinstruments.github.io/processor-sdk-doc/processor-sdk-linux-AM62X/esd/docs/master/linux/Foundational_Components_ATF.html
>>> https://git.ti.com/cgit/arago-project/meta-ti/tree/meta-ti-bsp/conf/machine/am62xxsip-evm.conf
>>>
>>> Robert, are you alright with me making the requested changes?
>>
>> I guess as long as we document it. I know the Octavo OSD62-sip @Erik
>> Welsh  will also be building on both am62xxsip and pocketbeagle2 based
>> on the 512MB and then larger memory sizes (1G, 2G, etc.).
>>
>> Regards,
>
> Oh boy, adjusting the memory maps kept getting me out of memory errors in the
> EFI flow that I knew should not be true. Found something fun: LMB reserved
> memory regions do not match EFI reserved memory regions. EFI's
> efi_carve_out_dt_rsv is setting regions to be more strict that LMB's base
> requirements. When this occurs and an allocation runs into this discrepancy,
> that allocation and all future allocation requests in the EFI flow will begin to
> fail as they are repeatedly given the same LMB start address in the unapproved
> region.
>
> Randolph

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:

[    0.048167] [Firmware Bug]: Unable to handle paging request in EFI runtime service
[    0.048246] ------------[ cut here ]------------
[    0.048249] WARNING: CPU: 0 PID: 1 at /usr/src/kernel/drivers/firmware/efi/runtime-wrappers.c:341 __efi_queue_work+0xd4/0x108
[    0.048270] Modules linked in:
[    0.048285] CPU: 0 UID: 0 PID: 1 Comm: swapper/0 Tainted: G          I         6.18.13-ti-00636-g30182cf3ac7d-dirty #1 PREEMPT 
[    0.048296] Tainted: [I]=FIRMWARE_WORKAROUND
[    0.048299] Hardware name: beagle BeagleBoard.org PocketBeagle2/BeagleBoard.org PocketBeagle2, BIOS 2026.04-rc5-00003-gf1dace477fb8-dirty 04/01/2026
[    0.048305] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[    0.048312] pc : __efi_queue_work+0xd4/0x108
[    0.048318] lr : __efi_queue_work+0xc0/0x108
[    0.048323] sp : ffff80008003bc80
[    0.048326] x29: ffff80008003bc80 x28: ffffad05b176bad4 x27: ffffad05b16b00ac
[    0.048336] x26: ffffad05b1622e60 x25: ffffad05b1953000 x24: ffffad05b1749050
[    0.048345] x23: 0000000000000004 x22: ffff80008003bd1e x21: ffff80008003bd20
[    0.048353] x20: ffff80008003bd28 x19: ffffad05b19cd5d8 x18: fffffffffffe2f20
[    0.048362] x17: 0000000000007000 x16: ffff000001c065a0 x15: 0000000000000000
[    0.048370] x14: 000000000000008a x13: ffff000001cf8090 x12: 0000000000000001
[    0.048379] x11: 00000000000000c0 x10: 00000000000009f0 x9 : ffff80008003bad0
[    0.048387] x8 : ffff000001cf8a50 x7 : 0000000000000001 x6 : 0000000000000001
[    0.048395] x5 : 0000000000000000 x4 : 0000000000000000 x3 : 0000000000000001
[    0.048403] x2 : 0000000000000000 x1 : 8000000000000015 x0 : 8000000000000015
[    0.048413] Call trace:
[    0.048417]  __efi_queue_work+0xd4/0x108 (P)
[    0.048426]  virt_efi_get_next_variable+0x5c/0xac
[    0.048434]  efisubsys_init+0x148/0x390
[    0.048444]  do_one_initcall+0x60/0x1d4
[    0.048457]  kernel_init_freeable+0x248/0x2c4
[    0.048468]  kernel_init+0x20/0x140
[    0.048478]  ret_from_fork+0x10/0x20
[    0.048489] ---[ end trace 0000000000000000 ]---

U-boot itself doesn't report any errors, so I want to assume this is probably a
configuration issue regarding something else I've forgotten to add.

Anyone got any quick/obvious comments before I start digging through more of
that? Was my assumption about EFI_CONVENTIONAL_MEMORY incorrect? Is this, as
unlikely as I think it is, actually just a known issue right now?