Re: [PATCHv3 3/4] k3-am62-pocketbeagle2: add support for 1GB variant

[Randolph Sapp <rs@ti.com>]

On Thu Jun 25, 2026 at 3:21 AM CDT, Anshul Dalal wrote:
> On Thu Jun 25, 2026 at 4:59 AM IST, Randolph Sapp wrote:
>> On Wed Jun 24, 2026 at 4:19 PM CDT, rs wrote:
>>> From: Randolph Sapp <rs@ti.com>
>>>
>>> Take Phytec's current DDR fixup functions and utilize them to
>>> dynamically adjust for variants in the pocketbeagle2. There are
>>> currently 3 skews, two of which are both 512MB with the same memory
>>> configuration, and one which is 1GB using the same CWL and CL settings
>>> but a modified density [1].
>>>
>>> Based off of Bryan Brattlof's patch [2].
>>>
>>> [1] https://mm.digikey.com/Volume0/opasdata/d220001/medias/docus/5411/8G%20Bits%20DDR4%20SDRAM.pdf
>>> [2] https://github.com/bryanbrattlof/beagleboot/commit/fb2f022e27427e990d7a33fd001ffb571e13cfc3
>>>
>>> Signed-off-by: Randolph Sapp <rs@ti.com>
>>> ---
>>>  board/beagle/pocketbeagle2/Kconfig            |  26 +++++
>>>  board/beagle/pocketbeagle2/Makefile           |   2 +
>>>  board/beagle/pocketbeagle2/pocketbeagle2.c    | 103 +++++++++++++++++-
>>>  .../beagle/pocketbeagle2/pocketbeagle2_ddr.h  |  50 +++++++++
>>>  configs/am62_pocketbeagle2_r5_defconfig       |   5 +-
>>>  5 files changed, 184 insertions(+), 2 deletions(-)
>>>  create mode 100644 board/beagle/pocketbeagle2/pocketbeagle2_ddr.h
>>>
>>> [snip]
>>
>> Just thinking out loud here, but maybe we shouldn't take this patch. The
>> industrial version, on top of having more memory, also has eMMC. That already
>> mandates a new device tree and configuration if people are going to use it as a
>> boot method.
>>
>> Then again, maybe it's convenient for the users who don't care about eMMC? I
>> dunno. Seems odd either way.
>
> Since it's technically a different board altogether and not just PB2 w/
> extra DDR. I think it might be better if it had a separate DT and we can
> decide the correct one based on the EEPROM at runtime using
> SPL_MULTI_DTB_FIT which would allow us to still have a single defconfig
> in U-Boot.

Syncing some internal comments here:

Zephyr and Jason Kridner apparently agree with me here. They treat the device as
a separate model: https://github.com/zephyrproject-rtos/zephyr/pull/106680

To cite Bryan Brattlof:

	I don't think the R5 has the space to switch-out the DT like this during
	bootup. it would need to be another build

Sounds like we'll have to upstream a separate dt and defconfig then. I'll play
around with this a little on my end before submitting another revision. Suppose
the dt will have to go to the kernel first so it'll be a little bit.