From: William Zhang <[email protected]>
Add support for Broadcom STB NAND controller in BCMBCA ARMv7 chip dts
files.
Signed-off-by: William Zhang <[email protected]>
Reviewed-by: David Regan <[email protected]>
---
Changes in v3: None
---
Changes in v2: None
---
arch/arm/boot/dts/broadcom/bcm47622.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/broadcom/bcm63138.dtsi | 10 +++++++++-
arch/arm/boot/dts/broadcom/bcm63148.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/broadcom/bcm63178.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/broadcom/bcm6756.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/broadcom/bcm6846.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/broadcom/bcm6855.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/broadcom/bcm6878.dtsi | 17 +++++++++++++++++
arch/arm/boot/dts/broadcom/bcm947622.dts | 4 ++++
arch/arm/boot/dts/broadcom/bcm963138.dts | 4 ++++
arch/arm/boot/dts/broadcom/bcm963138dvt.dts | 12 +++++-------
arch/arm/boot/dts/broadcom/bcm963148.dts | 4 ++++
arch/arm/boot/dts/broadcom/bcm963178.dts | 4 ++++
arch/arm/boot/dts/broadcom/bcm96756.dts | 4 ++++
arch/arm/boot/dts/broadcom/bcm96846.dts | 4 ++++
arch/arm/boot/dts/broadcom/bcm96855.dts | 4 ++++
arch/arm/boot/dts/broadcom/bcm96878.dts | 4 ++++
17 files changed, 165 insertions(+), 8 deletions(-)
diff --git a/arch/arm/boot/dts/broadcom/bcm47622.dtsi b/arch/arm/boot/dts/broadcom/bcm47622.dtsi
index 7cd38de118c3..55ff18043d96 100644
--- a/arch/arm/boot/dts/broadcom/bcm47622.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm47622.dtsi
@@ -138,6 +138,23 @@ hsspi: spi@1000 {
status = "disabled";
};
+ nand_controller: nand-controller@1800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1", "brcm,brcmnand";
+ reg = <0x1800 0x600>, <0x2000 0x10>;
+ reg-names = "nand", "nand-int-base";
+ brcm,nand-use-wp = <0>;
+ status = "disabled";
+
+ nandcs: nand@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-on-flash-bbt;
+ brcm,nand-ecc-use-strap;
+ };
+ };
+
uart0: serial@12000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x12000 0x1000>;
diff --git a/arch/arm/boot/dts/broadcom/bcm63138.dtsi b/arch/arm/boot/dts/broadcom/bcm63138.dtsi
index 4ef02283612b..3aaee1c6994e 100644
--- a/arch/arm/boot/dts/broadcom/bcm63138.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm63138.dtsi
@@ -229,7 +229,15 @@ nand_controller: nand-controller@2000 {
reg-names = "nand", "nand-int-base";
status = "disabled";
interrupts = <GIC_SPI 38 IRQ_TYPE_LEVEL_HIGH>;
- interrupt-names = "nand";
+ interrupt-names = "nand_ctlrdy";
+ brcm,nand-use-wp = <0>;
+
+ nandcs: nand@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-on-flash-bbt;
+ brcm,nand-ecc-use-strap;
+ };
};
serial@4400 {
diff --git a/arch/arm/boot/dts/broadcom/bcm63148.dtsi b/arch/arm/boot/dts/broadcom/bcm63148.dtsi
index 24431de1810e..6ecd530a7225 100644
--- a/arch/arm/boot/dts/broadcom/bcm63148.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm63148.dtsi
@@ -119,5 +119,22 @@ hsspi: spi@1000 {
num-cs = <8>;
status = "disabled";
};
+
+ nand_controller: nand-controller@2000 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1", "brcm,brcmnand";
+ reg = <0x2000 0x600>, <0xf0 0x10>;
+ reg-names = "nand", "nand-int-base";
+ brcm,nand-use-wp = <0>;
+ status = "disabled";
+
+ nandcs: nand@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-on-flash-bbt;
+ brcm,nand-ecc-use-strap;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/broadcom/bcm63178.dtsi b/arch/arm/boot/dts/broadcom/bcm63178.dtsi
index 3f9aed96babf..742991fc7544 100644
--- a/arch/arm/boot/dts/broadcom/bcm63178.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm63178.dtsi
@@ -129,6 +129,23 @@ hsspi: spi@1000 {
status = "disabled";
};
+ nand_controller: nand-controller@1800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1", "brcm,brcmnand";
+ reg = <0x1800 0x600>, <0x2000 0x10>;
+ reg-names = "nand", "nand-int-base";
+ brcm,nand-use-wp = <0>;
+ status = "disabled";
+
+ nandcs: nand@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-on-flash-bbt;
+ brcm,nand-ecc-use-strap;
+ };
+ };
+
uart0: serial@12000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x12000 0x1000>;
diff --git a/arch/arm/boot/dts/broadcom/bcm6756.dtsi b/arch/arm/boot/dts/broadcom/bcm6756.dtsi
index 1d8d957d65dd..0f08b99d93c2 100644
--- a/arch/arm/boot/dts/broadcom/bcm6756.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm6756.dtsi
@@ -139,6 +139,23 @@ hsspi: spi@1000 {
status = "disabled";
};
+ nand_controller: nand-controller@1800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1", "brcm,brcmnand";
+ reg = <0x1800 0x600>, <0x2000 0x10>;
+ reg-names = "nand", "nand-int-base";
+ brcm,nand-use-wp = <0>;
+ status = "disabled";
+
+ nandcs: nand@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-on-flash-bbt;
+ brcm,nand-ecc-use-strap;
+ };
+ };
+
uart0: serial@12000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x12000 0x1000>;
diff --git a/arch/arm/boot/dts/broadcom/bcm6846.dtsi b/arch/arm/boot/dts/broadcom/bcm6846.dtsi
index cf92cf8c4693..856fd2352cca 100644
--- a/arch/arm/boot/dts/broadcom/bcm6846.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm6846.dtsi
@@ -119,5 +119,22 @@ hsspi: spi@1000 {
num-cs = <8>;
status = "disabled";
};
+
+ nand_controller: nand-controller@1800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1", "brcm,brcmnand";
+ reg = <0x1800 0x600>, <0x2000 0x10>;
+ reg-names = "nand", "nand-int-base";
+ brcm,nand-use-wp = <0>;
+ status = "disabled";
+
+ nandcs: nand@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-on-flash-bbt;
+ brcm,nand-ecc-use-strap;
+ };
+ };
};
};
diff --git a/arch/arm/boot/dts/broadcom/bcm6855.dtsi b/arch/arm/boot/dts/broadcom/bcm6855.dtsi
index 52d6bc89f9f8..ad6f63a92c3a 100644
--- a/arch/arm/boot/dts/broadcom/bcm6855.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm6855.dtsi
@@ -129,6 +129,23 @@ hsspi: spi@1000 {
status = "disabled";
};
+ nand_controller: nand-controller@1800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1", "brcm,brcmnand";
+ reg = <0x1800 0x600>, <0x2000 0x10>;
+ reg-names = "nand", "nand-int-base";
+ brcm,nand-use-wp = <0>;
+ status = "disabled";
+
+ nandcs: nand@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-on-flash-bbt;
+ brcm,nand-ecc-use-strap;
+ };
+ };
+
uart0: serial@12000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x12000 0x1000>;
diff --git a/arch/arm/boot/dts/broadcom/bcm6878.dtsi b/arch/arm/boot/dts/broadcom/bcm6878.dtsi
index 2c5d706bac7e..540aac1b82f9 100644
--- a/arch/arm/boot/dts/broadcom/bcm6878.dtsi
+++ b/arch/arm/boot/dts/broadcom/bcm6878.dtsi
@@ -120,6 +120,23 @@ hsspi: spi@1000 {
status = "disabled";
};
+ nand_controller: nand-controller@1800 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1", "brcm,brcmnand";
+ reg = <0x1800 0x600>, <0x2000 0x10>;
+ reg-names = "nand", "nand-int-base";
+ brcm,nand-use-wp = <0>;
+ status = "disabled";
+
+ nandcs: nand@0 {
+ compatible = "brcm,nandcs";
+ reg = <0>;
+ nand-on-flash-bbt;
+ brcm,nand-ecc-use-strap;
+ };
+ };
+
uart0: serial@12000 {
compatible = "arm,pl011", "arm,primecell";
reg = <0x12000 0x1000>;
diff --git a/arch/arm/boot/dts/broadcom/bcm947622.dts b/arch/arm/boot/dts/broadcom/bcm947622.dts
index 93b8ce22678d..22e3c4508e1a 100644
--- a/arch/arm/boot/dts/broadcom/bcm947622.dts
+++ b/arch/arm/boot/dts/broadcom/bcm947622.dts
@@ -32,3 +32,7 @@ &uart0 {
&hsspi {
status = "okay";
};
+
+&nand_controller {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm963138.dts b/arch/arm/boot/dts/broadcom/bcm963138.dts
index 1b405c249213..450289d47dc7 100644
--- a/arch/arm/boot/dts/broadcom/bcm963138.dts
+++ b/arch/arm/boot/dts/broadcom/bcm963138.dts
@@ -29,3 +29,7 @@ &serial0 {
&hsspi {
status = "okay";
};
+
+&nand_controller {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm963138dvt.dts b/arch/arm/boot/dts/broadcom/bcm963138dvt.dts
index b5af61853a07..22107d14a120 100644
--- a/arch/arm/boot/dts/broadcom/bcm963138dvt.dts
+++ b/arch/arm/boot/dts/broadcom/bcm963138dvt.dts
@@ -33,14 +33,12 @@ &serial1 {
&nand_controller {
status = "okay";
+};
- nand@0 {
- compatible = "brcm,nandcs";
- reg = <0>;
- nand-ecc-strength = <4>;
- nand-ecc-step-size = <512>;
- brcm,nand-oob-sectors-size = <16>;
- };
+&nandcs {
+ nand-ecc-strength = <4>;
+ nand-ecc-step-size = <512>;
+ brcm,nand-oob-sector-size = <16>;
};
&ahci {
diff --git a/arch/arm/boot/dts/broadcom/bcm963148.dts b/arch/arm/boot/dts/broadcom/bcm963148.dts
index 1f5d6d783f09..aa08b473c7cd 100644
--- a/arch/arm/boot/dts/broadcom/bcm963148.dts
+++ b/arch/arm/boot/dts/broadcom/bcm963148.dts
@@ -32,3 +32,7 @@ &uart0 {
&hsspi {
status = "okay";
};
+
+&nand_controller {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm963178.dts b/arch/arm/boot/dts/broadcom/bcm963178.dts
index d036e99dd8d1..c0f504ac43a4 100644
--- a/arch/arm/boot/dts/broadcom/bcm963178.dts
+++ b/arch/arm/boot/dts/broadcom/bcm963178.dts
@@ -32,3 +32,7 @@ &uart0 {
&hsspi {
status = "okay";
};
+
+&nand_controller {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm96756.dts b/arch/arm/boot/dts/broadcom/bcm96756.dts
index 8b104f3fb14a..2ce998f2b84f 100644
--- a/arch/arm/boot/dts/broadcom/bcm96756.dts
+++ b/arch/arm/boot/dts/broadcom/bcm96756.dts
@@ -32,3 +32,7 @@ &uart0 {
&hsspi {
status = "okay";
};
+
+&nand_controller {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm96846.dts b/arch/arm/boot/dts/broadcom/bcm96846.dts
index 55852c229608..f4b9a07370ee 100644
--- a/arch/arm/boot/dts/broadcom/bcm96846.dts
+++ b/arch/arm/boot/dts/broadcom/bcm96846.dts
@@ -32,3 +32,7 @@ &uart0 {
&hsspi {
status = "okay";
};
+
+&nand_controller {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm96855.dts b/arch/arm/boot/dts/broadcom/bcm96855.dts
index 2ad880af2104..5c94063bceaf 100644
--- a/arch/arm/boot/dts/broadcom/bcm96855.dts
+++ b/arch/arm/boot/dts/broadcom/bcm96855.dts
@@ -32,3 +32,7 @@ &uart0 {
&hsspi {
status = "okay";
};
+
+&nand_controller {
+ status = "okay";
+};
diff --git a/arch/arm/boot/dts/broadcom/bcm96878.dts b/arch/arm/boot/dts/broadcom/bcm96878.dts
index b7af8ade7a9d..910f7e125bad 100644
--- a/arch/arm/boot/dts/broadcom/bcm96878.dts
+++ b/arch/arm/boot/dts/broadcom/bcm96878.dts
@@ -32,3 +32,7 @@ &uart0 {
&hsspi {
status = "okay";
};
+
+&nand_controller {
+ status = "okay";
+};
--
2.37.3
Hi David,
[email protected] wrote on Tue, 23 Jan 2024 19:04:50 -0800:
> From: William Zhang <[email protected]>
>
> Add support for Broadcom STB NAND controller in BCMBCA ARMv7 chip dts
> files.
>
> Signed-off-by: William Zhang <[email protected]>
> Reviewed-by: David Regan <[email protected]>
> ---
> Changes in v3: None
> ---
> Changes in v2: None
> ---
> arch/arm/boot/dts/broadcom/bcm47622.dtsi | 17 +++++++++++++++++
> arch/arm/boot/dts/broadcom/bcm63138.dtsi | 10 +++++++++-
> arch/arm/boot/dts/broadcom/bcm63148.dtsi | 17 +++++++++++++++++
> arch/arm/boot/dts/broadcom/bcm63178.dtsi | 17 +++++++++++++++++
> arch/arm/boot/dts/broadcom/bcm6756.dtsi | 17 +++++++++++++++++
> arch/arm/boot/dts/broadcom/bcm6846.dtsi | 17 +++++++++++++++++
> arch/arm/boot/dts/broadcom/bcm6855.dtsi | 17 +++++++++++++++++
> arch/arm/boot/dts/broadcom/bcm6878.dtsi | 17 +++++++++++++++++
> arch/arm/boot/dts/broadcom/bcm947622.dts | 4 ++++
> arch/arm/boot/dts/broadcom/bcm963138.dts | 4 ++++
> arch/arm/boot/dts/broadcom/bcm963138dvt.dts | 12 +++++-------
> arch/arm/boot/dts/broadcom/bcm963148.dts | 4 ++++
> arch/arm/boot/dts/broadcom/bcm963178.dts | 4 ++++
> arch/arm/boot/dts/broadcom/bcm96756.dts | 4 ++++
> arch/arm/boot/dts/broadcom/bcm96846.dts | 4 ++++
> arch/arm/boot/dts/broadcom/bcm96855.dts | 4 ++++
> arch/arm/boot/dts/broadcom/bcm96878.dts | 4 ++++
> 17 files changed, 165 insertions(+), 8 deletions(-)
>
> diff --git a/arch/arm/boot/dts/broadcom/bcm47622.dtsi b/arch/arm/boot/dts/broadcom/bcm47622.dtsi
> index 7cd38de118c3..55ff18043d96 100644
> --- a/arch/arm/boot/dts/broadcom/bcm47622.dtsi
> +++ b/arch/arm/boot/dts/broadcom/bcm47622.dtsi
> @@ -138,6 +138,23 @@ hsspi: spi@1000 {
> status = "disabled";
> };
>
> + nand_controller: nand-controller@1800 {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1", "brcm,brcmnand";
> + reg = <0x1800 0x600>, <0x2000 0x10>;
> + reg-names = "nand", "nand-int-base";
> + brcm,nand-use-wp = <0>;
> + status = "disabled";
> +
> + nandcs: nand@0 {
> + compatible = "brcm,nandcs";
> + reg = <0>;
> + nand-on-flash-bbt;
> + brcm,nand-ecc-use-strap;
Describing the NAND chip in a SoC DTSI does not look relevant to me.
Even more if you add something like this nand-ecc-use-strap setting
which is very board dependent.
Same applies to your arm64 DT patch.
Thanks,
Miquèl
Hi Miquel,
On 1/24/24 09:30, Miquel Raynal wrote:
> Hi David,
>
> [email protected] wrote on Tue, 23 Jan 2024 19:04:50 -0800:
>
>> From: William Zhang <[email protected]>
>>
>> Add support for Broadcom STB NAND controller in BCMBCA ARMv7 chip dts
>> files.
>>
>> Signed-off-by: William Zhang <[email protected]>
>> Reviewed-by: David Regan <[email protected]>
>> ---
>> Changes in v3: None
>> ---
>> Changes in v2: None
>> ---
>> arch/arm/boot/dts/broadcom/bcm47622.dtsi | 17 +++++++++++++++++
>> arch/arm/boot/dts/broadcom/bcm63138.dtsi | 10 +++++++++-
>> arch/arm/boot/dts/broadcom/bcm63148.dtsi | 17 +++++++++++++++++
>> arch/arm/boot/dts/broadcom/bcm63178.dtsi | 17 +++++++++++++++++
>> arch/arm/boot/dts/broadcom/bcm6756.dtsi | 17 +++++++++++++++++
>> arch/arm/boot/dts/broadcom/bcm6846.dtsi | 17 +++++++++++++++++
>> arch/arm/boot/dts/broadcom/bcm6855.dtsi | 17 +++++++++++++++++
>> arch/arm/boot/dts/broadcom/bcm6878.dtsi | 17 +++++++++++++++++
>> arch/arm/boot/dts/broadcom/bcm947622.dts | 4 ++++
>> arch/arm/boot/dts/broadcom/bcm963138.dts | 4 ++++
>> arch/arm/boot/dts/broadcom/bcm963138dvt.dts | 12 +++++-------
>> arch/arm/boot/dts/broadcom/bcm963148.dts | 4 ++++
>> arch/arm/boot/dts/broadcom/bcm963178.dts | 4 ++++
>> arch/arm/boot/dts/broadcom/bcm96756.dts | 4 ++++
>> arch/arm/boot/dts/broadcom/bcm96846.dts | 4 ++++
>> arch/arm/boot/dts/broadcom/bcm96855.dts | 4 ++++
>> arch/arm/boot/dts/broadcom/bcm96878.dts | 4 ++++
>> 17 files changed, 165 insertions(+), 8 deletions(-)
>>
>> diff --git a/arch/arm/boot/dts/broadcom/bcm47622.dtsi b/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>> index 7cd38de118c3..55ff18043d96 100644
>> --- a/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>> +++ b/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>> @@ -138,6 +138,23 @@ hsspi: spi@1000 {
>> status = "disabled";
>> };
>>
>> + nand_controller: nand-controller@1800 {
>> + #address-cells = <1>;
>> + #size-cells = <0>;
>> + compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1", "brcm,brcmnand";
>> + reg = <0x1800 0x600>, <0x2000 0x10>;
>> + reg-names = "nand", "nand-int-base";
>> + brcm,nand-use-wp = <0>;
>> + status = "disabled";
>> +
>> + nandcs: nand@0 {
>> + compatible = "brcm,nandcs";
>> + reg = <0>;
>> + nand-on-flash-bbt;
>> + brcm,nand-ecc-use-strap;
>
> Describing the NAND chip in a SoC DTSI does not look relevant to me.
> Even more if you add something like this nand-ecc-use-strap setting
> which is very board dependent.
>
I am not sure if I understand you comments correctly but are you
suggesting to put this whole nand controller node into each board dts?
We have other ip block nodes like SPI, uart in this same soc dtsi file
too. For all the bcmbca soc dtsi I am updating here(and its board
design), we always use the strap to for ecc setting. So I thought it
should be okay to put brcm,nand-ecc-use-strap in the default dtsi file.
For any board that uses the raw nand nand-ecc property, the board dts
can do so and override the brcm,nand-ecc-use-strap setting.
> Same applies to your arm64 DT patch.
>
> Thanks,
> Miquèl
On 1/24/2024 7:09 PM, William Zhang wrote:
> Hi Miquel,
>
> On 1/24/24 09:30, Miquel Raynal wrote:
>> Hi David,
>>
>> [email protected] wrote on Tue, 23 Jan 2024 19:04:50 -0800:
>>
>>> From: William Zhang <[email protected]>
>>>
>>> Add support for Broadcom STB NAND controller in BCMBCA ARMv7 chip dts
>>> files.
>>>
>>> Signed-off-by: William Zhang <[email protected]>
>>> Reviewed-by: David Regan <[email protected]>
>>> ---
>>> Changes in v3: None
>>> ---
>>> Changes in v2: None
>>> ---
>>> arch/arm/boot/dts/broadcom/bcm47622.dtsi | 17 +++++++++++++++++
>>> arch/arm/boot/dts/broadcom/bcm63138.dtsi | 10 +++++++++-
>>> arch/arm/boot/dts/broadcom/bcm63148.dtsi | 17 +++++++++++++++++
>>> arch/arm/boot/dts/broadcom/bcm63178.dtsi | 17 +++++++++++++++++
>>> arch/arm/boot/dts/broadcom/bcm6756.dtsi | 17 +++++++++++++++++
>>> arch/arm/boot/dts/broadcom/bcm6846.dtsi | 17 +++++++++++++++++
>>> arch/arm/boot/dts/broadcom/bcm6855.dtsi | 17 +++++++++++++++++
>>> arch/arm/boot/dts/broadcom/bcm6878.dtsi | 17 +++++++++++++++++
>>> arch/arm/boot/dts/broadcom/bcm947622.dts | 4 ++++
>>> arch/arm/boot/dts/broadcom/bcm963138.dts | 4 ++++
>>> arch/arm/boot/dts/broadcom/bcm963138dvt.dts | 12 +++++-------
>>> arch/arm/boot/dts/broadcom/bcm963148.dts | 4 ++++
>>> arch/arm/boot/dts/broadcom/bcm963178.dts | 4 ++++
>>> arch/arm/boot/dts/broadcom/bcm96756.dts | 4 ++++
>>> arch/arm/boot/dts/broadcom/bcm96846.dts | 4 ++++
>>> arch/arm/boot/dts/broadcom/bcm96855.dts | 4 ++++
>>> arch/arm/boot/dts/broadcom/bcm96878.dts | 4 ++++
>>> 17 files changed, 165 insertions(+), 8 deletions(-)
>>>
>>> diff --git a/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>>> b/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>>> index 7cd38de118c3..55ff18043d96 100644
>>> --- a/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>>> +++ b/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>>> @@ -138,6 +138,23 @@ hsspi: spi@1000 {
>>> status = "disabled";
>>> };
>>> + nand_controller: nand-controller@1800 {
>>> + #address-cells = <1>;
>>> + #size-cells = <0>;
>>> + compatible = "brcm,nand-bcm63138", "brcm,brcmnand-v7.1",
>>> "brcm,brcmnand";
>>> + reg = <0x1800 0x600>, <0x2000 0x10>;
>>> + reg-names = "nand", "nand-int-base";
>>> + brcm,nand-use-wp = <0>;
>>> + status = "disabled";
>>> +
>>> + nandcs: nand@0 {
>>> + compatible = "brcm,nandcs";
>>> + reg = <0>;
>>> + nand-on-flash-bbt;
>>> + brcm,nand-ecc-use-strap;
>>
>> Describing the NAND chip in a SoC DTSI does not look relevant to me.
>> Even more if you add something like this nand-ecc-use-strap setting
>> which is very board dependent.
>>
> I am not sure if I understand you comments correctly but are you
> suggesting to put this whole nand controller node into each board dts?
> We have other ip block nodes like SPI, uart in this same soc dtsi file
> too. For all the bcmbca soc dtsi I am updating here(and its board
> design), we always use the strap to for ecc setting. So I thought it
> should be okay to put brcm,nand-ecc-use-strap in the default dtsi file.
> For any board that uses the raw nand nand-ecc property, the board dts
> can do so and override the brcm,nand-ecc-use-strap setting.
I read Miquel's comment as meaning that the nandcs aka the NAND
chip/flash part description should be in the board .dts file, while the
controller itself can remain in the .dtsi file with its status =
"disabled" property.
Are there customer boards, that is non reference boards that might chose
a different chip select number and/or not use the strap settings?
--
Florian
Hi William,
> >>>> + nand_controller: nand-controller@1800 {
> >>>> + #address-cells = <1>;
> >>>> + #size-cells = <0>;
> >>>> + compatible = "brcm,nand-bcm63138", >>>> "brcm,brcmnand-v7.1", "brcm,brcmnand";
> >>>> + reg = <0x1800 0x600>, <0x2000 0x10>;
> >>>> + reg-names = "nand", "nand-int-base";
> >>>> + brcm,nand-use-wp = <0>;
> >>>> + status = "disabled";
> >>>> +
> >>>> + nandcs: nand@0 {
> >>>> + compatible = "brcm,nandcs";
> >>>> + reg = <0>;
> >>>> + nand-on-flash-bbt;
> >>>> + brcm,nand-ecc-use-strap;
> >>>
> >>> Describing the NAND chip in a SoC DTSI does not look relevant to me.
> >>> Even more if you add something like this nand-ecc-use-strap setting
> >>> which is very board dependent.
> >>>
> >> I am not sure if I understand you comments correctly but are you >> suggesting to put this whole nand controller node into each board dts? >> We have other ip block nodes like SPI, uart in this same soc dtsi file >> too. For all the bcmbca soc dtsi I am updating here(and its board >> design), we always use the strap to for ecc setting. So I thought it >> should be okay to put brcm,nand-ecc-use-strap in the default dtsi >> file. For any board that uses the raw nand nand-ecc property, the >> board dts can do so and override the brcm,nand-ecc-use-strap setting.
> >
> > I read Miquel's comment as meaning that the nandcs aka the NAND > chip/flash part description should be in the board .dts file, while the > controller itself can remain in the .dtsi file with its status = > "disabled" property.
> >
> > Are there customer boards, that is non reference boards that might chose > a different chip select number and/or not use the strap settings?
> In BCMBCA SoC, there is only one cs and customer design also have to use strap for the bootrom to boot up properly. They can override it with dts in linux but I don't think any customer would do that.
>
> Maybe the nand-on-flash-bbt could be possible item that customer may have to set it differently if they don't follow our reference software design.
>
> I will move the nand-on-flash-bbt to the board dts but I would like to keep the other default nandcs settings in SoC.dsti if that is not too out of the conventional rule and Miquel is okay with it.
I think there is a global misunderstanding regarding the use of the
nand-ecc-* properties. These are not the default. The default is the OS
choice and depends on the NAND capabilities. The OS will always try to
match the closest ECC settings offered by the engine, based on the NAND
chip requirements which are discoverable. If you want to maximize your
strength, it is also possible to tell the OS with a dedicated (generic)
property. And only if you want something different, you may use these
properties, but they should be the exception rather than the rule.
Overriding this with a strap is a bad hardware design on commercial
products IMO. I am totally fine with the idea of a strap to choose
the ECC configuration for development boards/evaluation kits, but once
you've decided which setting you want you cannot change it for the
lifetime of your project (or with a lot of difficulties) so I don't see
the point of such a strap. So really, I don't like the idea of defining
by default a variable which asks for an override of the defaults, even
though many of your customers might want to use that.
So, anything that is design dependent (the chip CS, ECC
configuration, etc) should go into the board DTS, and what is SoC
related hardware (like the definition of the NAND controller) should
stay in the DTSI, as properly clarified by Florian.
Thanks,
Miquèl
On 1/24/24 19:34, Florian Fainelli wrote:
>
>
> On 1/24/2024 7:09 PM, William Zhang wrote:
>> Hi Miquel,
>>
>> On 1/24/24 09:30, Miquel Raynal wrote:
>>> Hi David,
>>>
>>> [email protected] wrote on Tue, 23 Jan 2024 19:04:50 -0800:
>>>
>>>> From: William Zhang <[email protected]>
>>>>
>>>> Add support for Broadcom STB NAND controller in BCMBCA ARMv7 chip dts
>>>> files.
>>>>
>>>> Signed-off-by: William Zhang <[email protected]>
>>>> Reviewed-by: David Regan <[email protected]>
>>>> ---
>>>> Changes in v3: None
>>>> ---
>>>> Changes in v2: None
>>>> ---
>>>> arch/arm/boot/dts/broadcom/bcm47622.dtsi | 17 +++++++++++++++++
>>>> arch/arm/boot/dts/broadcom/bcm63138.dtsi | 10 +++++++++-
>>>> arch/arm/boot/dts/broadcom/bcm63148.dtsi | 17 +++++++++++++++++
>>>> arch/arm/boot/dts/broadcom/bcm63178.dtsi | 17 +++++++++++++++++
>>>> arch/arm/boot/dts/broadcom/bcm6756.dtsi | 17 +++++++++++++++++
>>>> arch/arm/boot/dts/broadcom/bcm6846.dtsi | 17 +++++++++++++++++
>>>> arch/arm/boot/dts/broadcom/bcm6855.dtsi | 17 +++++++++++++++++
>>>> arch/arm/boot/dts/broadcom/bcm6878.dtsi | 17 +++++++++++++++++
>>>> arch/arm/boot/dts/broadcom/bcm947622.dts | 4 ++++
>>>> arch/arm/boot/dts/broadcom/bcm963138.dts | 4 ++++
>>>> arch/arm/boot/dts/broadcom/bcm963138dvt.dts | 12 +++++-------
>>>> arch/arm/boot/dts/broadcom/bcm963148.dts | 4 ++++
>>>> arch/arm/boot/dts/broadcom/bcm963178.dts | 4 ++++
>>>> arch/arm/boot/dts/broadcom/bcm96756.dts | 4 ++++
>>>> arch/arm/boot/dts/broadcom/bcm96846.dts | 4 ++++
>>>> arch/arm/boot/dts/broadcom/bcm96855.dts | 4 ++++
>>>> arch/arm/boot/dts/broadcom/bcm96878.dts | 4 ++++
>>>> 17 files changed, 165 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>>>> b/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>>>> index 7cd38de118c3..55ff18043d96 100644
>>>> --- a/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>>>> +++ b/arch/arm/boot/dts/broadcom/bcm47622.dtsi
>>>> @@ -138,6 +138,23 @@ hsspi: spi@1000 {
>>>> status = "disabled";
>>>> };
>>>> + nand_controller: nand-controller@1800 {
>>>> + #address-cells = <1>;
>>>> + #size-cells = <0>;
>>>> + compatible = "brcm,nand-bcm63138",
>>>> "brcm,brcmnand-v7.1", "brcm,brcmnand";
>>>> + reg = <0x1800 0x600>, <0x2000 0x10>;
>>>> + reg-names = "nand", "nand-int-base";
>>>> + brcm,nand-use-wp = <0>;
>>>> + status = "disabled";
>>>> +
>>>> + nandcs: nand@0 {
>>>> + compatible = "brcm,nandcs";
>>>> + reg = <0>;
>>>> + nand-on-flash-bbt;
>>>> + brcm,nand-ecc-use-strap;
>>>
>>> Describing the NAND chip in a SoC DTSI does not look relevant to me.
>>> Even more if you add something like this nand-ecc-use-strap setting
>>> which is very board dependent.
>>>
>> I am not sure if I understand you comments correctly but are you
>> suggesting to put this whole nand controller node into each board dts?
>> We have other ip block nodes like SPI, uart in this same soc dtsi file
>> too. For all the bcmbca soc dtsi I am updating here(and its board
>> design), we always use the strap to for ecc setting. So I thought it
>> should be okay to put brcm,nand-ecc-use-strap in the default dtsi
>> file. For any board that uses the raw nand nand-ecc property, the
>> board dts can do so and override the brcm,nand-ecc-use-strap setting.
>
> I read Miquel's comment as meaning that the nandcs aka the NAND
> chip/flash part description should be in the board .dts file, while the
> controller itself can remain in the .dtsi file with its status =
> "disabled" property.
>
> Are there customer boards, that is non reference boards that might chose
> a different chip select number and/or not use the strap settings?
In BCMBCA SoC, there is only one cs and customer design also have to use
strap for the bootrom to boot up properly. They can override it with
dts in linux but I don't think any customer would do that.
Maybe the nand-on-flash-bbt could be possible item that customer may
have to set it differently if they don't follow our reference software
design.
I will move the nand-on-flash-bbt to the board dts but I would like to
keep the other default nandcs settings in SoC.dsti if that is not too
out of the conventional rule and Miquel is okay with it.
Hi Miquel,
On 1/25/24 01:20, Miquel Raynal wrote:
> Hi William,
>
>>>>>> + nand_controller: nand-controller@1800 {
>>>>>> + #address-cells = <1>;
>>>>>> + #size-cells = <0>;
>>>>>> + compatible = "brcm,nand-bcm63138", >>>> "brcm,brcmnand-v7.1", "brcm,brcmnand";
>>>>>> + reg = <0x1800 0x600>, <0x2000 0x10>;
>>>>>> + reg-names = "nand", "nand-int-base";
>>>>>> + brcm,nand-use-wp = <0>;
>>>>>> + status = "disabled";
>>>>>> +
>>>>>> + nandcs: nand@0 {
>>>>>> + compatible = "brcm,nandcs";
>>>>>> + reg = <0>;
>>>>>> + nand-on-flash-bbt;
>>>>>> + brcm,nand-ecc-use-strap;
>>>>>
>>>>> Describing the NAND chip in a SoC DTSI does not look relevant to me.
>>>>> Even more if you add something like this nand-ecc-use-strap setting
>>>>> which is very board dependent.
>>>>>
>>>> I am not sure if I understand you comments correctly but are you >> suggesting to put this whole nand controller node into each board dts? >> We have other ip block nodes like SPI, uart in this same soc dtsi file >> too. For all the bcmbca soc dtsi I am updating here(and its board >> design), we always use the strap to for ecc setting. So I thought it >> should be okay to put brcm,nand-ecc-use-strap in the default dtsi >> file. For any board that uses the raw nand nand-ecc property, the >> board dts can do so and override the brcm,nand-ecc-use-strap setting.
>>>
>>> I read Miquel's comment as meaning that the nandcs aka the NAND > chip/flash part description should be in the board .dts file, while the > controller itself can remain in the .dtsi file with its status = > "disabled" property.
>>>
>>> Are there customer boards, that is non reference boards that might chose > a different chip select number and/or not use the strap settings?
>> In BCMBCA SoC, there is only one cs and customer design also have to use strap for the bootrom to boot up properly. They can override it with dts in linux but I don't think any customer would do that.
>>
>> Maybe the nand-on-flash-bbt could be possible item that customer may have to set it differently if they don't follow our reference software design.
>>
>> I will move the nand-on-flash-bbt to the board dts but I would like to keep the other default nandcs settings in SoC.dsti if that is not too out of the conventional rule and Miquel is okay with it.
>
> I think there is a global misunderstanding regarding the use of the
> nand-ecc-* properties. These are not the default. The default is the OS
> choice and depends on the NAND capabilities. The OS will always try to
> match the closest ECC settings offered by the engine, based on the NAND
> chip requirements which are discoverable. If you want to maximize your
> strength, it is also possible to tell the OS with a dedicated (generic)
This is the nand-ecc-* property, right?
> property. And only if you want something different, you may use these
> properties, but they should be the exception rather than the rule.
>
> Overriding this with a strap is a bad hardware design on commercial
> products IMO. I am totally fine with the idea of a strap to choose
> the ECC configuration for development boards/evaluation kits, but once
> you've decided which setting you want you cannot change it for the
> lifetime of your project (or with a lot of difficulties) so I don't see
> the point of such a strap. So really, I don't like the idea of defining
> by default a variable which asks for an override of the defaults, even
> though many of your customers might want to use that.
Correct, no change to strap is possible on real product because they are
always through soldered down resister and no dip switch/jumper for ecc
strap. But as the SoC requires, it is part of bootstrap each product has
to set and that's how bootloader get the ecc setting as it does not have
the access to the dts and the capability to auto select the ecc setting.
Most of the time, customer will set strap to match the OS auto selected
ecc setting but there are times customer want more strength so yes they
can use nand-ecc-* to override but it has to match the strap setting.
Then I think it make sense and much easier for customer to just use
strap to override and reduce the any manual setting error in dts. It
will cause many trouble down the road if the edit does not match strap
setting. Not saying this is for everyone but definitively a good
feature for our product and it reduces ecc setting error in case of
overriding OS default selection.
>
> So, anything that is design dependent (the chip CS, ECC
> configuration, etc) should go into the board DTS, and what is SoC
> related hardware (like the definition of the NAND controller) should
> stay in the DTSI, as properly clarified by Florian.
>
Okay I will move nand-on-flash-bbt and brcm,nand-ecc-use-strap from soc
dtsi to board dts but leave the default nandcs node with compatible and
reg = 0 in the dtsi as they are not design dependent and board dts can
conveniently reference the nandcs node.
> Thanks,
> Miquèl