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

[Randolph Sapp <rs@ti.com>]

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