linux-kernel - Re: [PATCH 3/4] arm64: dts: add support for A4 based Amlogic BA400

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] [day] [month] [year] [list]

Date: Fri, 15 Mar 2024 16:48:40 +0800
From: Xianwei Zhao <xianwei.zhao@...ogic.com>
To: Jerome Brunet <jbrunet@...libre.com>
Cc: Rob Herring <robh+dt@...nel.org>,
 Krzysztof Kozlowski <krzysztof.kozlowski+dt@...aro.org>,
 Conor Dooley <conor+dt@...nel.org>,
 Neil Armstrong <neil.armstrong@...aro.org>,
 Martin Blumenstingl <martin.blumenstingl@...glemail.com>,
 Kevin Hilman <khilman@...libre.com>, devicetree@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
 linux-amlogic@...ts.infradead.org
Subject: Re: [PATCH 3/4] arm64: dts: add support for A4 based Amlogic BA400

Hi Jerome,
     Thanks for your reply.

On 2024/3/14 17:26, Jerome Brunet wrote:
> [ EXTERNAL EMAIL ]
> 
> On Thu 14 Mar 2024 at 16:08, Xianwei Zhao <xianwei.zhao@...ogic.com> wrote:
> 
>>>> +
>>>> +#include "amlogic-a4.dtsi"
>>> Could you describe how the a4 and a5 differs from each other ?
>>> The description given in the commit description is the same.
>>> Beside the a53 vs a55, I'm not seeing much of a difference.
>>> Admittedly, there is not much yet but I wonder if a4 and a5 should have
>>> a common dtsi.
>>>
>> They are mostly the same, A5 include HiFi-DSP and NPU, but A4 is not. And
>> some peripheral modules are different, such as SPI and Ehernet phy.
>>
>> I would like to wait for the follow-on chips to come out before considering
>> a merger with common dtsi file.
>>
> 
> No, Please do it now. There is no reason for the community to review the
> same thing twice if the SoCs are "mostly the same".
> 
OK, I will do it.
>>>> +
>>>> +/ {
>>>> +     model = "Amlogic A113L2 ba400 Development Board";
>>>> +     compatible = "amlogic,ba400","amlogic,a4";
>>>> +     interrupt-parent = <&gic>;
>>>> +     #address-cells = <2>;
>>>> +     #size-cells = <2>;
>>>> +
>>>> +     aliases {
>>>> +             serial0 = &uart_b;
>>>> +     };
>>>> +
>>>> +     memory@0 {
>>>> +             device_type = "memory";
>>>> +             reg = <0x0 0x0 0x0 0x40000000>;
>>>> +     };
>>>> +
>>>> +     reserved-memory {
>>>> +             #address-cells = <2>;
>>>> +             #size-cells = <2>;
>>>> +             ranges;
>>>> +
>>>> +             /* 52 MiB reserved for ARM Trusted Firmware */
>>> That's a lot of memory to blindly reserve.
>>> Any chance we can stop doing that and have u-boot amend reserved memory
>>> zone based on the actual needs of the device ?
>> Yes. U-boot will change size of reserved memory base on actual usage.
> 
> Then u-boot should add (not change) the memory if necessary.
> Please drop this.
> 
Amlogic's u-boot will change the reserved memory size, size is not an 
issue. But Some one use u-boot himself not Amlogic's, If here drop this, 
there is a strange problem when it runs.
>>>
>>>> +             secmon_reserved:linux,secmon {
>>>> +                     compatible = "shared-dma-pool";
>>>> +                     no-map;
>>>> +                     alignment = <0x0 0x400000>;
>>>> +                     reg = <0x0 0x05000000 0x0 0x3400000>;
>>>> +             };
>>>> +     };
>>>> +};
>>>> +
>