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

[Bryan Brattlof]

On June 29, 2026 thus sayeth Randolph Sapp:
> 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 at 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 at 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.

Sorry Randolph, I've been buried in emails. Thanks for syncing the 
threads together.

My only worry here is having different builds for each flavor of the PB2 
will complicate things for people who don't care about the BSP layers. 
If all we're worried about is checking if the MMC is populated and which 
DDR to setup before we hand things over to Linux then in my opinion is 
this approach is better. Linux shouldn't care about these things.

We do have some space we can reclaim in the R5 SPL build but I seriously 
doubt swapping out the DT on the fly like we're suggesting will work for 
the R5 SPL. The only hope we have to unify the bootloaders for all PB2s 
is going to be with this approach.

~Bryan