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