Hi Michal,
Thanks for reviewing the patch.
On 5/16/23 09:54, Michal Simek wrote:
> On 5/15/23 20:16, Brad Larson wrote:
>> Add AMD Pensando common and Elba SoC specific device nodes
>>
>> Signed-off-by: Brad Larson <blarson@xxxxxxx>
>> ---
>>
>> v14 changes:
>> - Fix dtbs_check l2-cache* property issue by adding required
>> cache-level and cache-unified properties
>> - Observed the issue after updating dtschema from 2023.1 to 2023.4
>> and yamllint from 1.26.3 to 1.30.0
>>
>> v11 changes:
>> - Delete reset-names
>> - Fix spi0 compatible to be specific 'amd,pensando-elba-ctrl'
>>
>> v9 changes:
>> - Single node for spi0 system-controller and squash
>> the reset-controller child into parent
>>
>> ---
>> arch/arm64/boot/dts/amd/Makefile | 1 +
>> arch/arm64/boot/dts/amd/elba-16core.dtsi | 197 ++++++++++++++++++
>> arch/arm64/boot/dts/amd/elba-asic-common.dtsi | 80 +++++++
>> arch/arm64/boot/dts/amd/elba-asic.dts | 28 +++
>> arch/arm64/boot/dts/amd/elba-flash-parts.dtsi | 106 ++++++++++
>> arch/arm64/boot/dts/amd/elba.dtsi | 191 +++++++++++++++++
>> 6 files changed, 603 insertions(+)
>> create mode 100644 arch/arm64/boot/dts/amd/elba-16core.dtsi
>> create mode 100644 arch/arm64/boot/dts/amd/elba-asic-common.dtsi
>> create mode 100644 arch/arm64/boot/dts/amd/elba-asic.dts
>> create mode 100644 arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
>> create mode 100644 arch/arm64/boot/dts/amd/elba.dtsi
>>
>> diff --git a/arch/arm64/boot/dts/amd/Makefile b/arch/arm64/boot/dts/amd/Makefile
>> index 68103a8b0ef5..8502cc2afbc5 100644
>> --- a/arch/arm64/boot/dts/amd/Makefile
>> +++ b/arch/arm64/boot/dts/amd/Makefile
>> @@ -1,2 +1,3 @@
>> # SPDX-License-Identifier: GPL-2.0
>> +dtb-$(CONFIG_ARCH_PENSANDO) += elba-asic.dtb
>> dtb-$(CONFIG_ARCH_SEATTLE) += amd-overdrive-rev-b0.dtb amd-overdrive-rev-b1.dtb
>> diff --git a/arch/arm64/boot/dts/amd/elba-16core.dtsi b/arch/arm64/boot/dts/amd/elba-16core.dtsi
>> new file mode 100644
>> index 000000000000..f9f9f5fd5f69
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/amd/elba-16core.dtsi
>> @@ -0,0 +1,197 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +/*
>> + * Copyright 2020-2022 Advanced Micro Devices, Inc.
>
> 2023 and the same below.
I'll update the copyright in the next submit
>> + */
>> +
>> +/ {
>> + cpus {
>> + #address-cells = <2>;
>> + #size-cells = <0>;
>> +
>> + cpu-map {
>> + cluster0 {
>> + core0 { cpu = <&cpu0>; };
>> + core1 { cpu = <&cpu1>; };
>> + core2 { cpu = <&cpu2>; };
>> + core3 { cpu = <&cpu3>; };
>> + };
>> +
>> + cluster1 {
>> + core0 { cpu = <&cpu4>; };
>> + core1 { cpu = <&cpu5>; };
>> + core2 { cpu = <&cpu6>; };
>> + core3 { cpu = <&cpu7>; };
>> + };
>> +
>> + cluster2 {
>> + core0 { cpu = <&cpu8>; };
>> + core1 { cpu = <&cpu9>; };
>> + core2 { cpu = <&cpu10>; };
>> + core3 { cpu = <&cpu11>; };
>> + };
>> +
>> + cluster3 {
>> + core0 { cpu = <&cpu12>; };
>> + core1 { cpu = <&cpu13>; };
>> + core2 { cpu = <&cpu14>; };
>> + core3 { cpu = <&cpu15>; };
>> + };
>> + };
>> +
>> + /* CLUSTER 0 */
>> + cpu0: cpu@0 {
>> + device_type = "cpu";
>> + compatible = "arm,cortex-a72";
>> + reg = <0 0x0>;
>
> Do you really need 2/0 split here. The first cell is 0 anyway.
Yes following 64-bit system definition
...
>> diff --git a/arch/arm64/boot/dts/amd/elba-flash-parts.dtsi b/arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
>> new file mode 100644
>> index 000000000000..734893fef2c3
>> --- /dev/null
>> +++ b/arch/arm64/boot/dts/amd/elba-flash-parts.dtsi
>> @@ -0,0 +1,106 @@
>> +// SPDX-License-Identifier: (GPL-2.0-only or BSD-2-Clause)
>> +/*
>> + * Copyright 2020-2022 Advanced Micro Devices, Inc.
>> + */
>> +
>> +&flash0 {
0xf0000>> + partitions {
>> + compatible = "fixed-partitions";
>> + #address-cells = <1>;
>> + #size-cells = <1>;
>> + partition@0 {
>> + label = "flash";
>> + reg = <0x10000 0xfff0000>;
>
> This doesn't fit with partition@0 above.
> Also size is weird.
This is intended to not expose sector 0.
>> + };
>> +
>> + partition@f0000 {
>> + label = "golduenv";
>> + reg = <0xf0000 0x10000>;
>> + };
>> +
>> + partition@100000 {
>> + label = "boot0";
>> + reg = <0x100000 0x80000>;
>> + };
>> +
>> + partition@180000 {
>> + label = "golduboot";
>> + reg = <0x180000 0x200000>;
>> + };
>> +
>> + partition@380000 {
>> + label = "brdcfg0";
>> + reg = <0x380000 0x10000>;
>> + };
>> +
>> + partition@390000 {
>> + label = "brdcfg1";
>> + reg = <0x390000 0x10000>;
>> + };
>> +
>> + partition@400000 {
>> + label = "goldfw";
>> + reg = <0x400000 0x3c00000>;
>
> This size looks weird.
It's the allocated size for this firmware component.
>> + };
>> +
>> + partition@4010000 {
>> + label = "fwmap";
>> + reg = <0x4010000 0x20000>;
>> + };
>> +
>> + partition@4030000 {
>> + label = "fwsel";
>> + reg = <0x4030000 0x20000>;
>> + };
>> +
>> + partition@4090000 {
>> + label = "bootlog";
>> + reg = <0x4090000 0x20000>;
>> + };
>> +
>> + partition@40b0000 {
>> + label = "panicbuf";
>> + reg = <0x40b0000 0x20000>;
>> + };
>> +
>> + partition@40d0000 {
>> + label = "uservars";
>> + reg = <0x40d0000 0x20000>;
>> + };
>> +
>> + partition@4200000 {
>> + label = "uboota";
>> + reg = <0x4200000 0x400000>;
>> + };
>> +
>> + partition@4600000 {
>> + label = "ubootb";
>> + reg = <0x4600000 0x400000>;
>> + };
>> +
>> + partition@4a00000 {
>> + label = "mainfwa";
>> + reg = <0x4a00000 0x1000000>;
>> + };
>> +
>> + partition@5a00000 {
>> + label = "mainfwb";
>> + reg = <0x5a00000 0x1000000>;
>> + };
>> +
>> + partition@6a00000 {
>> + label = "diaguboot";
>> + reg = <0x6a00000 0x400000>;
>> + };
>> +
>
> here is gap
This is intentional for unallocated space. I'll put in a 'spare' partition.
>> + partition@8000000 {
>> + label = "diagfw";
>> + reg = <0x8000000 0x7fe0000>;
>> + };
>> +
>> + partition@ffe0000 {
>> + label = "ubootenv";
>> + reg = <0xffe0000 0x10000>;
>> + };
>
> And this is missing space description.
space description?
Regards,
Brad
