linux-kernel - Re: [PATCH 11/15] arm64: dts: nuvoton: Add initial ma35d1 device tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <12298b67-3012-4902-9dcc-61c3c9907a47@app.fastmail.com>
Date:   Sat, 18 Mar 2023 15:04:58 +0100
From:   "Arnd Bergmann" <arnd@...db.de>
To:     "Jacky Huang" <ychuang570808@...il.com>,
        "Rob Herring" <robh+dt@...nel.org>,
        krzysztof.kozlowski+dt@...aro.org, "Lee Jones" <lee@...nel.org>,
        "Michael Turquette" <mturquette@...libre.com>,
        "Stephen Boyd" <sboyd@...nel.org>,
        "Philipp Zabel" <p.zabel@...gutronix.de>,
        "Greg Kroah-Hartman" <gregkh@...uxfoundation.org>,
        "Jiri Slaby" <jirislaby@...nel.org>
Cc:     devicetree@...r.kernel.org, linux-clk@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-serial@...r.kernel.org,
        schung@...oton.com, "Jacky Huang" <ychuang3@...oton.com>
Subject: Re: [PATCH 11/15] arm64: dts: nuvoton: Add initial ma35d1 device tree

On Sat, Mar 18, 2023, at 14:17, Jacky Huang wrote:
> On 2023/3/16 下午 10:17, Arnd Bergmann wrote:
>> On Wed, Mar 15, 2023, at 08:28, Jacky Huang wrote:
>>> +	mem: memory@...00000 {
>>> +		device_type = "memory";
>>> +		reg = <0x00000000 0x80000000 0 0x20000000>; /* 512M DRAM */
>>> +	};
>>> +};
>> In most machines, the memory size is detected by the boot loader
>> and filled in the dtb in memory before starting the kernel, so
>> you should not need two separate files here for the two common
>> memory configurations.
>
>
> On ma35d1, memory size is determined early before uboot.
>
> BL1 (MaskROM boot code) -> BL2 (arm-trust-firmware) -> BL32 (op-tee) & 
> BL33 (uboot).
> The DDR was initialized in BL2 stage with a selected DDR setting, which
> is hard coded, including DDR size.
>
> We searched the arm64 dts and found that almost all vendors claimed
> memory size in board level dtsi/dts. This seems to be common.
>
> So, can we have it unchanged?

I see the memory size encoded in about one out of three .dts files,
which is more than I expected. It's clearly not harmful to have it
listed in the dts, it just shouldn't be necessary.

If it helps you with your current u-boot, then leave it in, but
consider adding detection logic into u-boot so it can override
the value in the dtb file at boot time.

>> Since the machine is called 'som', I would assume that this is a
>> module that is integrated on another board, so more commonly one
>> would have a dtsi file for the som in addition to the one for the
>> soc, and have all the components of the module listed in this
>> file, while the dts file that includes the som.dtsi lists the
>> devices on the carrier board and enables the on-chip devices
>> that are connected to the outside.
>>
>
> You are right, ma35d1 som have a base board, and a cpu board on it.
>
> It is a good suggestion that we should have a dtsi for som base board.
>
> Consider that we are in the initial submit, and such a dtsi will be an empty
> file at this stage. So, I would like to do it when peripheral drivers
> upstream started. Is it ok?

It's not a big deal either way. I if you want to keep it only with
one dts file and one dtsi file, that's fine, but maybe rename the dts
file based on the name of the carrier rather than the SoM in this
case.

     Arnd