[PATCH 2/3] k3-am62-pocketbeagle2: add initial board support
Randolph Sapp
rs at ti.com
Wed Apr 1 00:54:59 CEST 2026
On Tue Mar 31, 2026 at 11:13 AM CDT, Robert Nelson wrote:
> adding @Ayush Singh too...
>
> On Mon, Mar 30, 2026 at 6:57 PM Randolph Sapp <rs at ti.com> wrote:
>>
>> 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.
>
> Ayush is dealing with Zephyr fallout too. I'm wondering if we are
> doing too many dynamic memory moves. Do we need to start hard-coding
> some of these memory regions in device-tree and then load the 512MB or
> 1GB memory settings starting in A53 SPL?
>
Actually it was the opposite here. Chicken and the egg issue. We don't know
about the memory reservations until after we load a device tree, but we can't
load a device tree until we've at least carved out some memory for U-Boot and
it's runtime allocations. U-Boot relocates itself to ram_top, which is too close
to our reserved regions.
I just went in and forced it to relocate to a known region between our
reservations and other blob addresses and it worked. Passed all the unit tests
and my own runtime tests with efibootmgr. I did also have to adjust
add_u_boot_and_runtime and lmb_reserve_uboot_region to handle that arbitrary
address and use mon_len instead of just assuming ram_top would be the end.
This does bring an interesting question though. If we aren't going to change our
r5 and m4 reserved regions then we'll have to make arbitrary gd->relocaddr
values more properly supported for both this device and am6254atl.
I assume since it's part of the global data it should just be part of the board
config instead of a static Kconfig parameter. Anyone from the community got any
comments on this? I'm just a lowly graphics developer.
More information about the U-Boot
mailing list