On Thu, Mar 14, 2024 at 03:02:31PM +0530, Sumit Garg wrote: > On Thu, 14 Mar 2024 at 14:48, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote: > > On 3/14/24 10:04, Sumit Garg wrote: > > > On Wed, 13 Mar 2024 at 18:34, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote: > > >> On 3/13/24 13:30, Sumit Garg wrote: > > >>> Add Schneider Electric HMIBSC board DTS. The HMIBSC board is an IIoT Edge > > >>> Box Core board based on the Qualcomm APQ8016E SoC. > > >>> > > >>> Support for Schneider Electric HMIBSC. Features: > > >>> - Qualcomm Snapdragon 410C SoC - APQ8016 (4xCortex A53, Adreno 306) > > >>> - 1GiB RAM > > >>> - 8GiB eMMC, SD slot > > >>> - WiFi and Bluetooth > > >>> - 2x Host, 1x Device USB port > > >>> - HDMI > > >>> - Discrete TPM2 chip over SPI > > >>> - USB ethernet adaptors (soldered) > > >>> > > >>> Co-developed-by: Jagdish Gediya <jagdish.gediya@xxxxxxxxxx> > > >>> Signed-off-by: Jagdish Gediya <jagdish.gediya@xxxxxxxxxx> > > >>> Signed-off-by: Sumit Garg <sumit.garg@xxxxxxxxxx> > > >>> --- > > >> > > >> [...] > > >> > > >>> + memory@80000000 { > > >>> + reg = <0 0x80000000 0 0x40000000>; > > >>> + }; > > >> > > >> I'm not sure the entirety of DRAM is accessible.. > > >> > > >> This override should be unnecessary, as bootloaders generally update > > >> the size field anyway. > > > > > > On this board, U-Boot is used as the first stage bootloader (replacing > > > Little Kernel (LK), thanks to Stephan's work). And U-Boot consumes > > > memory range from DT as Linux does but doesn't require any memory to > > > be reserved for U-Boot itself. So apart from reserved memory nodes > > > explicitly described in DT all the other DRAM regions are accessible. > > > > Still, u-boot has code to fetch the size dynamically, no? > > > > No U-Boot being the first stage bootloader fetches size from DT which > is bundled into U-Boot binary. > Back when I added support for using U-Boot as first stage bootloader on DB410c the way it worked is that U-Boot used a fixed amount of DRAM (originally 968 MiB, later 1 GiB since I fixed this in commit 1d667227ea51 ("board: dragonboard410c: Fix PHYS_SDRAM_1_SIZE") [1]). When booting Linux, the Linux DT was dynamically patched with the right amount of DRAM (obtained from SMEM). So if you had e.g. a Geniatech DB4 board with 2 GiB DRAM, U-Boot was only using 1 GiB of DRAM, but Linux later got the full 2 GiB patched into its DTB. I didn't have much time for testing U-Boot myself lately but a quick look at the recent changes suggest that Caleb accidentally removed that functionality in the recent cleanup. Specifically, the SMEM-based DRAM size detection was removed in commit 14868845db54 ("board: dragonboard410c: import board code from mach-snapdragon" [2]), the msm_fixup_memory() function does not seem to exist anymore now. :') Also, the DRAM size is now always taken from the DT (which is probably better than the previous hardcoded size in the U-Boot board code). I think we should bring the dynamic DRAM size detection back, because there are quite some boards available with varying DRAM size. Restoring msm_fixup_memory() would likely be easiest, I guess the ideal solution would be to parse SMEM in U-Boot's dram_init() function so even U-Boot has the correct amount of DRAM to work with. Thanks, Stephan [1]: https://source.denx.de/u-boot/u-boot/-/commit/1d667227ea512537b8453abeb49abbf19a1a18e8 [2]: https://source.denx.de/u-boot/u-boot/-/commit/14868845db54b4f64701977385dc9a6e951e4139