RE: [PATCH] 83xx: add support for the kmeter1 board.
Hello all,
(FYI I working on the kmeter1)
kmeter1.c reuses the same QE_ENET10 RGMII errata workaround code from
mpc836x_mds.c (MPC8360EMDS eval board).
In my view errata nodes in the dts is overkill. Maybe the errata code can go
into a reusable function somewhere in 83xx/ or in ucc_geth.c?
I also think the original errata code needs improving:
- mask some SVR bits so activated for all matching CPU models, e.g.
MPC8360 MPC8360E.
- The code in mpc836x_mds.c and kmeter1.c does not do exactly what
Freescale errata says!
Here the errata document:
http://www.freescale.com/files/32bit/doc/errata/MPC8360ECE.pdf
Because kmeter1 is using an MPC8360 CPU model the workaround doesn't actually
trigger. So to kill 2 birds with 1 stone we tested a Uboot patch (below) doing
what QE_ENET10 says. It seemed to work fine for us.
/* RGMII timing Errata workaround for rev 2.1 silicon
* (ref: MPC8360ECE rev.1 12/2007 QE_ENET10 UCC2 option 1)
*/
void *reg = (void *)(CONFIG_SYS_IMMR + 0x14ac);
clrsetbits_be32 (reg, 0x00F0, 0x00A0);
From my point of view:
- The workaround code in kmeter1.c could go for now.
- An improved errata workaround for 836x boards would be nice (..who is
motivated? :-))
Best regards
Christopher Varlese
RD Software
KEYMILE AG
Schwarzenburgstrasse 73
3097 Bern, Switzerland
www.keymile.com
-Original Message-
From: linuxppc-dev-bounces+christopher.varlese=keymile@ozlabs.org
[mailto:linuxppc-dev-bounces+christopher.varlese=keymile@ozlabs.org] On
Behalf Of Heiko Schocher
Sent: Monday, April 27, 2009 7:39 AM
To: Kumar Gala
Cc: linuxppc-dev@ozlabs.org
Subject: Re: [PATCH] 83xx: add support for the kmeter1 board.
Hello Kumar,
Kumar Gala wrote:
[...]
diff --git a/arch/powerpc/platforms/83xx/kmeter1.c
b/arch/powerpc/platforms/83xx/kmeter1.c
new file mode 100644
index 000..99cf5c6
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/kmeter1.c
@@ -0,0 +1,170 @@
+/*
[...]
+np = of_find_compatible_node(NULL, network, ucc_geth);
+if (np != NULL) {
+uint svid;
+
+/* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+svid = mfspr(SPRN_SVR);
+if (svid == 0x80480021) {
+void __iomem *immap;
+
+immap = ioremap(get_immrbase() + 0x14a8, 8);
we should add a proper device node to cover whatever register space this
is.
What if we do something like the following:
1) add in the soc node an errata node and in this errata node
we can add all CPU specific errata as an example the qe_enet10
errata, which above code covers:
soc8...@e000 {
[...]
errata {
device_type = errata;
compatible = fsl,mpc83xx_errata;
#address-cells = 1;
#size-cells = 1;
qe_ene...@14a8 {
device_type = errata;
compatible = fsl,mpc83xx_errata_qe_enet10;
reg = 0x14a8 0x08;
};
};
[...]
};
2) we add in arch/powerpc/sysdev/fsl_soc.c a
static int __init mpc83xx_errata_init(void)
function, which holds the code for the errata
If you agree with that, I can make a patch ...
Hmm.. Is it OK, if I first sent a v2 of the 83xx: add support for
the kmeter1 board. with the QE_ENET10 errata in kmeter1.c (as it is
also for the mpc836x_mds board), and then send a seperate patch, which
removes this errata from the two boards?
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 83xx: add support for the kmeter1 board.
Hello Christopher, Varlese, Christopher wrote: (FYI I working on the kmeter1) kmeter1.c reuses the same QE_ENET10 RGMII errata workaround code from mpc836x_mds.c (MPC8360EMDS eval board). In my view errata nodes in the dts is overkill. Maybe the errata code can go into a reusable function somewhere in 83xx/ or in ucc_geth.c? To put an errata node in the dts was just an idea ;-) I also mentioned putting this code in the ucc_geth.c driver ... I also think the original errata code needs improving: - mask some SVR bits so activated for all matching CPU models, e.g. MPC8360 MPC8360E. Did a first try in my v2 patch, see: http://ozlabs.org/pipermail/linuxppc-dev/2009-April/071384.html but I got no response yet. - The code in mpc836x_mds.c and kmeter1.c does not do exactly what Freescale errata says! :-( Here the errata document: http://www.freescale.com/files/32bit/doc/errata/MPC8360ECE.pdf Because kmeter1 is using an MPC8360 CPU model the workaround doesn't actually trigger. So to kill 2 birds with 1 stone we tested a Uboot patch (below) doing what QE_ENET10 says. It seemed to work fine for us. /* RGMII timing Errata workaround for rev 2.1 silicon * (ref: MPC8360ECE rev.1 12/2007 QE_ENET10 UCC2 option 1) */ void *reg = (void *)(CONFIG_SYS_IMMR + 0x14ac); clrsetbits_be32 (reg, 0x00F0, 0x00A0); From my point of view: - The workaround code in kmeter1.c could go for now. - An improved errata workaround for 836x boards would be nice (..who is motivated? :-)) I can make this errata, if someone gives advice, where to put ... I vote for putting it into the ucc_geth.c driver, and activating it maybe through the phy-connection-type if it activates the rgmii mode ... ? bye Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 83xx: add support for the kmeter1 board.
Hello Scott,
Scott Wood wrote:
On Mon, Apr 27, 2009 at 07:38:38AM +0200, Heiko Schocher wrote:
1) add in the soc node an errata node and in this errata node
we can add all CPU specific errata as an example the qe_enet10
errata, which above code covers:
What about errata discovered after the device tree is deployed?
Didn;t know that there are such errata. Ok, this is a problem.
soc8...@e000 {
[...]
errata {
device_type = errata;
device_type is deprecated except for a couple of legacy uses. Please do
not add new ones.
Ok.
compatible = fsl,mpc83xx_errata;
To be bound to by an errata driver? :-P
Why not ;-) ?
#address-cells = 1;
#size-cells = 1;
qe_ene...@14a8 {
device_type = errata;
compatible = fsl,mpc83xx_errata_qe_enet10;
reg = 0x14a8 0x08;
But that register is part of the QE parallel I/O port block (even if it
happens to be undocumented within that block), not part of the QE ENET10
erratum block. The device tree describes the hardware, not what you
want to do with it.
Hmm.. isn;t this an errata for a buggy hardware? Why not describing this
in the dts?
The presence of the erratum itself is indicated by the presence of the
buggy device, possibly in conjunction with SVR if the device tree is not
specific enough.
Ah, Ok, that was just an idea ... so, where and how to solve the qe_enet10
errata without using get_immrbase() (and I vote not to solve it as it
actuall is in board specific code, maybe as i proposed in an earlier mail
in the ucc_geth.c driver?)?
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 83xx: add support for the kmeter1 board.
On Tue, Apr 28, 2009 at 06:42:43AM +0200, Heiko Schocher wrote: Scott Wood wrote: On Mon, Apr 27, 2009 at 07:38:38AM +0200, Heiko Schocher wrote: 1) add in the soc node an errata node and in this errata node we can add all CPU specific errata as an example the qe_enet10 errata, which above code covers: What about errata discovered after the device tree is deployed? Didn;t know that there are such errata. Ok, this is a problem. Bugs can be discovered at any point in time. The presence of the erratum itself is indicated by the presence of the buggy device, possibly in conjunction with SVR if the device tree is not specific enough. Ah, Ok, that was just an idea ... so, where and how to solve the qe_enet10 errata without using get_immrbase() Get the register block address from the par_io node. -Scott ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 83xx: add support for the kmeter1 board.
Hello Kumar,
Kumar Gala wrote:
[...]
diff --git a/arch/powerpc/platforms/83xx/kmeter1.c
b/arch/powerpc/platforms/83xx/kmeter1.c
new file mode 100644
index 000..99cf5c6
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/kmeter1.c
@@ -0,0 +1,170 @@
+/*
[...]
+np = of_find_compatible_node(NULL, network, ucc_geth);
+if (np != NULL) {
+uint svid;
+
+/* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+svid = mfspr(SPRN_SVR);
+if (svid == 0x80480021) {
+void __iomem *immap;
+
+immap = ioremap(get_immrbase() + 0x14a8, 8);
we should add a proper device node to cover whatever register space this
is.
What if we do something like the following:
1) add in the soc node an errata node and in this errata node
we can add all CPU specific errata as an example the qe_enet10
errata, which above code covers:
soc8...@e000 {
[...]
errata {
device_type = errata;
compatible = fsl,mpc83xx_errata;
#address-cells = 1;
#size-cells = 1;
qe_ene...@14a8 {
device_type = errata;
compatible = fsl,mpc83xx_errata_qe_enet10;
reg = 0x14a8 0x08;
};
};
[...]
};
2) we add in arch/powerpc/sysdev/fsl_soc.c a
static int __init mpc83xx_errata_init(void)
function, which holds the code for the errata
If you agree with that, I can make a patch ...
Hmm.. Is it OK, if I first sent a v2 of the 83xx: add support for
the kmeter1 board. with the QE_ENET10 errata in kmeter1.c (as it is
also for the mpc836x_mds board), and then send a seperate patch, which
removes this errata from the two boards?
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 83xx: add support for the kmeter1 board.
On Mon, Apr 27, 2009 at 07:38:38AM +0200, Heiko Schocher wrote:
1) add in the soc node an errata node and in this errata node
we can add all CPU specific errata as an example the qe_enet10
errata, which above code covers:
What about errata discovered after the device tree is deployed?
soc8...@e000 {
[...]
errata {
device_type = errata;
device_type is deprecated except for a couple of legacy uses. Please do
not add new ones.
compatible = fsl,mpc83xx_errata;
To be bound to by an errata driver? :-P
#address-cells = 1;
#size-cells = 1;
qe_ene...@14a8 {
device_type = errata;
compatible = fsl,mpc83xx_errata_qe_enet10;
reg = 0x14a8 0x08;
But that register is part of the QE parallel I/O port block (even if it
happens to be undocumented within that block), not part of the QE ENET10
erratum block. The device tree describes the hardware, not what you
want to do with it.
The presence of the erratum itself is indicated by the presence of the
buggy device, possibly in conjunction with SVR if the device tree is not
specific enough.
-Scott
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] 83xx: add support for the kmeter1 board.
diff --git a/arch/powerpc/boot/dts/kmeter1.dts b/arch/powerpc/boot/
dts/kmeter1.dts
new file mode 100644
index 000..4f343ca
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmeter1.dts
@@ -0,0 +1,518 @@
+/*
+ * Keymile KMETER1 Device Tree Source
+ *
+ * 2008 DENX Software Engineering GmbH
+ *
+ * This program is free software; you can redistribute it and/or
modify it
+ * under the terms of the GNU General Public License as
published by the
+ * Free Software Foundation; either version 2 of the License, or
(at your
+ * option) any later version.
+ */
+
+
+/*
+/memreserve/ 100;
+*/
is this needed for something?
+
+/dts-v1/;
+
+/ {
+ model = KMETER1;
+ compatible = keymile,KMETER1;
+ #address-cells = 1;
+ #size-cells = 1;
+
+ aliases {
+ ethernet0 = enet_piggy2;
+ ethernet1 = enet_estar1;
+ ethernet2 = enet_estar2;
+ ethernet3 = enet_eth1;
+ ethernet4 = enet_eth2;
+ ethernet5 = enet_eth3;
+ ethernet6 = enet_eth4;
+ serial0 = serial0;
+ };
+
+ cpus {
+ #address-cells = 1;
+ #size-cells = 0;
+
+ PowerPC,8...@0 {
+ device_type = cpu;
+ reg = 0x0;
+ d-cache-line-size = 32; // 32 bytes
+ i-cache-line-size = 32; // 32 bytes
+ d-cache-size = 32768; // L1, 32K
+ i-cache-size = 32768; // L1, 32K
+ timebase-frequency = 6600;
+ bus-frequency = 26400;
+ clock-frequency = 52800;
is the board running at a fixed frequency that isn't possible to change?
+ };
+ };
+
+ memory {
+ device_type = memory;
+ reg = 0x 0x1000;
+ };
does u-boot not set this? Also is the amount of memory fixed?
+
+ soc8...@e000 {
+ #address-cells = 1;
+ #size-cells = 1;
+ device_type = soc;
+ compatible = simple-bus;
+ ranges = 0x0 0xe000 0x0010;
+ reg = 0xe000 0x0200;
+ bus-frequency = 26400;
+
+ i...@3000 {
+ #address-cells = 1;
+ #size-cells = 0;
+ cell-index = 0;
+ compatible = fsl-i2c;
+ reg = 0x3000 0x100;
+ interrupts = 14 0x8;
+ interrupt-parent = ipic;
+ dfsrr;
+ };
+
+ serial0: ser...@4500 {
+ cell-index = 0;
+ device_type = serial;
+ compatible = ns16550;
+ reg = 0x4500 0x100;
+ clock-frequency = 26400;
+ interrupts = 9 0x8;
+ interrupt-parent = ipic;
+ };
+
+ d...@82a8 {
+ #address-cells = 1;
+ #size-cells = 1;
+ compatible = fsl,mpc8360-dma, fsl,elo-dma;
+ reg = 0x82a8 4;
+ ranges = 0 0x8100 0x1a8;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ cell-index = 0;
+ dma-chan...@0 {
+ compatible = fsl,mpc8360-dma-channel,
fsl,elo-dma-channel;
+ reg = 0 0x80;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ dma-chan...@80 {
+ compatible = fsl,mpc8360-dma-channel,
fsl,elo-dma-channel;
+ reg = 0x80 0x80;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ dma-chan...@100 {
+ compatible = fsl,mpc8360-dma-channel,
fsl,elo-dma-channel;
+ reg = 0x100 0x80;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ dma-chan...@180 {
+ compatible = fsl,mpc8360-dma-channel,
fsl,elo-dma-channel;
+ reg = 0x180 0x28;
+ interrupt-parent = ipic;
+ interrupts = 71 8;
+ };
+ };
+
+ ipic: p...@700 {
+ #address-cells = 0;
+ #interrupt-cells = 2;
+ compatible = fsl,pq2pro-pic, fsl,ipic;
+
Re: [PATCH] 83xx: add support for the kmeter1 board.
Hello Kumar,
Kumar Gala wrote:
diff --git a/arch/powerpc/boot/dts/kmeter1.dts
b/arch/powerpc/boot/dts/kmeter1.dts
new file mode 100644
index 000..4f343ca
--- /dev/null
+++ b/arch/powerpc/boot/dts/kmeter1.dts
@@ -0,0 +1,518 @@
+/*
+ * Keymile KMETER1 Device Tree Source
+ *
[...]
+
+
+/*
+/memreserve/ 100;
+*/
is this needed for something?
No, I delete it.
+
+/dts-v1/;
+
+/ {
+model = KMETER1;
[...]
+
+cpus {
+#address-cells = 1;
+#size-cells = 0;
+
+PowerPC,8...@0 {
+device_type = cpu;
+reg = 0x0;
+d-cache-line-size = 32;// 32 bytes
+i-cache-line-size = 32;// 32 bytes
+d-cache-size = 32768;// L1, 32K
+i-cache-size = 32768;// L1, 32K
+timebase-frequency = 6600;
+bus-frequency = 26400;
+clock-frequency = 52800;
is the board running at a fixed frequency that isn't possible to change?
No, u-boot updates this. I fix this.
+};
+};
+
+memory {
+device_type = memory;
+reg = 0x 0x1000;
+};
does u-boot not set this? Also is the amount of memory fixed?
No, u-boot updates this. I fix this too. (and all other places)
+
+soc8...@e000 {
+#address-cells = 1;
+#size-cells = 1;
+device_type = soc;
+compatible = simple-bus;
[...]
+};
+};
+
+q...@e010 {
why isn't this under the SOC?
No reason for that, you are right, I fix this too.
+#address-cells = 1;
+#size-cells = 1;
+device_type = qe;
+compatible = fsl,qe;
+ranges = 0x0 0xe010 0x0010;
+reg = 0xe010 0x480;
+brg-frequency = 0;
+bus-frequency = 39600;
+
[...]
+
+qeic: interrupt-control...@80 {
+interrupt-controller;
+compatible = fsl,qe-ic;
+#address-cells = 0;
+#interrupt-cells = 1;
+reg = 0x80 0x80;
+big-endian;
seems unnecessary .. the qe is only big-endian.
OK.
+interrupts = 32 8 33 8;
+interrupt-parent = ipic;
+};
+};
diff --git a/arch/powerpc/platforms/83xx/kmeter1.c
b/arch/powerpc/platforms/83xx/kmeter1.c
new file mode 100644
index 000..99cf5c6
--- /dev/null
+++ b/arch/powerpc/platforms/83xx/kmeter1.c
@@ -0,0 +1,170 @@
+/*
+ * Copyright 2008 DENX Software Engineering GmbH
+ * Author: Heiko Schocher h...@denx.de
[...]
+
+np = of_find_compatible_node(NULL, network, ucc_geth);
+if (np != NULL) {
+uint svid;
+
+/* handle mpc8360ea rev.2.1 erratum 2: RGMII Timing */
+svid = mfspr(SPRN_SVR);
+if (svid == 0x80480021) {
+void __iomem *immap;
+
+immap = ioremap(get_immrbase() + 0x14a8, 8);
we should add a proper device node to cover whatever register space this
is.
Hmm... in the MPC8360ERM.pdf this is a reserved register ... This
register is mentioned in the MPC8360ECE.pdf for this CPU in
Table 4. RGMII Programmable I/O Delay Work Arounds in the QE_ENET10
section.
So this is a MPC8360E, MPC8358E specific errata, so shouldn;t
we add this fix in the drivers/net/ucc_geth.c driver so all
boards have this fix?
thanks for commenting
bye
Heiko
--
DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
