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

Tue Mar 31 01:57:04 CEST 2026

On Thu Mar 26, 2026 at 6:23 PM CDT, Randolph Sapp wrote:
> 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 at 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?

Ugh, that took longer than it should have. Alright, what I did would have been
correct if there weren't a few issues with other things. Primarily, this memory
map for the am6254atl. The U-Boot stack overlaps 2 regions we carve out in
device tree. LMB doesn't actually inform the user of this, and just keeps
trucking, thinking that the general u-boot reservation will be good enough.

Eventually, when some of the stack can be reclaimed, we will put some useful
things in these regions that were never properly reserved.

What was driving me crazy was that the efiboot selftest reported that everything
was okay except for the device tree region. Fun, what could have changed that?
Well, that's just efi_carve_out_dt_rsv going back and trying to enforce things
LMB never did.

Somehow we got it perfectly where copy_fdt would place the device tree squarely
in a region that was reserved by the device tree itself. Anything else wouldn't
have been exposed to the user.

So, I assume that kernel warning is actually a result of some EFI regions being
reclaimed by efi_carve_out_dt_rsv and the runtime blowing up because what it
thought was a valid address is now in some reserved region.

I've checked and am6254atl is also not able to reserve the
wkup_r5fss0_core0_memory_region (0x9db00000) at startup due to the u-boot stack
size. A ram top value of 0xa0000000 doesn't work with these reservations.

Adjusting the CONFIG_STACK_SIZE won't help here, as it u-boot naturally extends
into the wkup_r5fss0_core0_memory_region on it's own. I was seeing a stack size
of 0x22184c0 locally at the time reservations were being setup.