On 14/03/2024 15:20, Konrad Dybcio wrote: > > > On 3/14/24 14:50, Sumit Garg wrote: >> On Thu, 14 Mar 2024 at 18:54, Stephan Gerhold <stephan@xxxxxxxxxxx> >> wrote: >>> >>> On Thu, Mar 14, 2024 at 05:26:27PM +0530, Sumit Garg wrote: >>>> On Thu, 14 Mar 2024 at 16:13, Stephan Gerhold <stephan@xxxxxxxxxxx> >>>> wrote: >>>>> 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. :') >>>> >>>> Ah now I see the reasoning for that particular piece of code. Is SMEM >>>> based approach the standardized way used by early stage boot-loaders >>>> on other Qcom SoCs too? >>>> >>> >>> It is definitely used on all the SoCs that were deployed with LK. I am >>> not entirely sure about the newer ABL/UEFI-based ones. A quick look at >>> the ABL source code suggests it is abstracted through an EFI protocol >>> there (so we cannot see where the information comes from with just the >>> open-source code). However, in my experience SMEM data structures are >>> usually kept quite stable (or properly versioned), so it is quite likely >>> that we could use this approach for all Qualcomm SoCs. >>> >> >> If the SoCs which support this standardized way to dynamic discover >> DRAM size via SMEM then why do we need to rely on DT at all for those >> SoCs? Can't U-Boot and Linux have the same driver to fetch DRAM size >> via SMEM? I am not sure if it's an appropriate way for U-Boot to fixup >> DT when that information can be discovered dynamically. "standardized" I'm not so sure... But yes, smem does offer this. The definition in DT here is for U-Boot, ABL will always clobber it, and so does U-Boot before handing over to the kernel. Linux should never see this without a bootloader having looked at it. The reason I decided to hardcode this in DT for U-Boot is because SMEM currently relies on the driver model and isn't available early enough. Also admittedly I just wasn't that familiar with the U-Boot codebase. I just wanted to avoid hardcoding this in C code, and given that this was already supported for the "chainloading from ABL" usecase, just hardcoding the values was the obvious solution. I would definitely be open to revisiting this in U-Boot, having an SMEM framework that we could use without the driver model which would just take a base address and then let us interact with SMEM and populate the dram bank data would be a good improvement, and would let us avoid hardcoding the memory layout in DT. We'd just need to manually find the SMEM base address in the FDT as part of "dram_init_banksize()" and retrieve the data there. That all being said, I don't see any reason not to define the memory layout in DT, it's a hardware feature, DT describes the hardware. The whole "bootloader will fill this in" implies that the bootloader isn't also using DT as the source of truth, but now with U-Boot it actually is, so it's all the more important that DT be accurate ;P > > You're mixing two things. Linux expects a devicetree where > /memory/reg[size] > is valid. Such driver should indeed be (re)implemented in u-boot to provide > this information. > > As for linux, I am working on making Linux aware of the DDR capabilities > on Snapdragons, for other reasons, but it's on the back burner, as it > still needs some broad thinking about integrating it with the interested > consumers.. Bottom line is, Linux should be fed a devicetree with DRAM size > filled. > > Konrad -- // Caleb (they/them)