Message-ID: <ZfRbp8o-4pFBAjc-@gerhold.net>
Date: Fri, 15 Mar 2024 15:31:03 +0100
From: Stephan Gerhold <stephan@...hold.net>
To: Sumit Garg <sumit.garg@...aro.org>
Cc: Caleb Connolly <caleb.connolly@...aro.org>,
	Konrad Dybcio <konrad.dybcio@...aro.org>,
	linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
	andersson@...nel.org, robh+dt@...nel.org,
	krzysztof.kozlowski+dt@...aro.org, conor+dt@...nel.org,
	neil.armstrong@...aro.org, laetitia.mariottini@...com,
	pascal.eberhard@...com, abdou.saker@...com, jimmy.lalande@...com,
	benjamin.missey@....se.com, daniel.thompson@...aro.org,
	linux-kernel@...r.kernel.org,
	Jagdish Gediya <jagdish.gediya@...aro.org>
Subject: Re: [PATCH v2 3/3] arm64: dts: qcom: apq8016: Add Schneider HMIBSC
 board DTS

On Fri, Mar 15, 2024 at 03:01:27PM +0530, Sumit Garg wrote:
> On Thu, 14 Mar 2024 at 21:07, Caleb Connolly <caleb.connolly@...aro.org> wrote:
> > 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@...hold.net>
> > >> 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@...hold.net>
> > >>>> 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@...aro.org> wrote:
> > >>>>>>> On 3/14/24 10:04, Sumit Garg wrote:
> > >>>>>>>> On Wed, 13 Mar 2024 at 18:34, Konrad Dybcio
> > >>>>>>>> <konrad.dybcio@...aro.org> 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@...aro.org>
> > >>>>>>>>>> Signed-off-by: Jagdish Gediya <jagdish.gediya@...aro.org>
> > >>>>>>>>>> Signed-off-by: Sumit Garg <sumit.garg@...aro.org>
> > >>>>>>>>>> ---
> > >>>>>>>>>
> > >>>>>>>>> [...]
> > >>>>>>>>>
> > >>>>>>>>>> +     memory@...00000 {
> > >>>>>>>>>> +             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.
> >
> > [...]
> >
> > 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.
> 
> These are the similar problems Linux has to deal with too but on Qcom
> platforms it is rather offloaded to bootloaders to rather implement
> this. It leads to custom DT modification or board code in U-Boot which
> is hard to maintain. If we want to implement it properly then
> corresponding bindings should be upstreamed too regarding how DRAM
> range is to be discovered via SMEM.
> 
> >
> > 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
> 
> I agree DT should be accurate and not a fan of DT fixups. However,
> when it comes to some hardware configuration being discoverable then
> IMHO DT isn't the appropriate place for that. For the time being I am
> fine with the DRAM range to be specified in DT.
> 
> > >
> > > 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.
> 
> No, I don't think so. We should rather start thinking about the
> overall stack rather than just being Linux kernel centric. Do you have
> a generic solution for U-Boot regarding how this should be
> implemented?
> 

Detecting available memory via /memory in the DT or other firmware
services (such as UEFI GetMemoryMap()) is *the* generic solution used
everywhere, independent of the hardware (e.g. Qualcomm) and the
operating system (e.g. Linux or Xen).

It allows us to implement the board/Qualcomm-specific memory detection
in a single project, rather than having extra porting overhead for each
operating system for something as essential as available memory.

If we implement the SMEM-based memory detection in U-Boot (probably in
dram_init_banksize() as Caleb suggested) everything else will just work
without any Qualcomm-specific DT patching in U-Boot, and without any
special code in the operating system:

 - U-Boot automatically updates the /memory node in generic code (see
   fdt_fixup_memory_banks() call in arch/arm/lib/bootm-fdt.c). If you
   are using UEFI for booting, U-Boot will provide the same information
   via GetMemoryMap(). (The DT spec says /memory should be ignored on
   UEFI systems.)

 - Linux, Xen, and any other operating system can obtain the memory size
   via the standard method, and do not need any Qualcomm-specific at all
   (at least for memory detection).

I don't think there is anything Linux kernel centric for the memory
detection here. Quite the opposite really. :)

Thanks,
Stephan

Powered by blists - more mailing lists