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 <[email protected]> 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?
