[PATCH] ppc32: ppc_sys fixes for 8xx and 82xx

[PATCH] ppc32: ppc_sys fixes for 8xx and 82xx

[Vitaly Bordug]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

This patch fixes a numbers of issues regarding to that both 8xx and 82xx 
began to use ppc_sys model:
	- Platform is now identified by default deviceless SOC, if no 
BOARD_CHIP_NAME is specified in the bard-specific header. For the list 
of supported names refer to (arch/ppc/syslib/) mpc8xx_sys.c and 
mpc82xx_sys.c for 8xx and 82xx respectively.
	- Fixed a bug in identification by name - if the name was not found, it 
returned -1 instead of default deviceless ppc_spec.
	- fixed devices amount in the 8xx platform system descriptions


Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>

-- 
Sincerely,
Vitaly

[-- Attachment #2: 1.patch --]
[-- Type: text/x-patch, Size: 3539 bytes --]

diff --git a/arch/ppc/platforms/fads.h b/arch/ppc/platforms/fads.h
--- a/arch/ppc/platforms/fads.h
+++ b/arch/ppc/platforms/fads.h
@@ -25,6 +25,8 @@
 
 #if defined(CONFIG_MPC86XADS)
 
+#define BOARD_CHIP_NAME "MPC86X"
+
 /* U-Boot maps BCSR to 0xff080000 */
 #define BCSR_ADDR		((uint)0xff080000)
 
diff --git a/arch/ppc/platforms/mpc885ads.h b/arch/ppc/platforms/mpc885ads.h
--- a/arch/ppc/platforms/mpc885ads.h
+++ b/arch/ppc/platforms/mpc885ads.h
@@ -88,5 +88,7 @@
 #define SICR_ENET_MASK	((uint)0x00ff0000)
 #define SICR_ENET_CLKRT	((uint)0x002c0000)
 
+#define BOARD_CHIP_NAME "MPC885"
+
 #endif /* __ASM_MPC885ADS_H__ */
 #endif /* __KERNEL__ */
diff --git a/arch/ppc/syslib/m8260_setup.c b/arch/ppc/syslib/m8260_setup.c
--- a/arch/ppc/syslib/m8260_setup.c
+++ b/arch/ppc/syslib/m8260_setup.c
@@ -62,6 +62,9 @@ m8260_setup_arch(void)
 	if (initrd_start)
 		ROOT_DEV = Root_RAM0;
 #endif
+	
+	identify_ppc_sys_by_name_and_id(BOARD_CHIP_NAME, in_be32(CPM_MAP_ADDR + CPM_IMMR_OFFSET));
+	
 	m82xx_board_setup();
 }
 
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -403,7 +403,9 @@ platform_init(unsigned long r3, unsigned
 		*(char *)(r7+KERNELBASE) = 0;
 		strcpy(cmd_line, (char *)(r6+KERNELBASE));
 	}
-
+	
+	identify_ppc_sys_by_name(BOARD_CHIP_NAME);
+	
 	ppc_md.setup_arch		= m8xx_setup_arch;
 	ppc_md.show_percpuinfo		= m8xx_show_percpuinfo;
 	ppc_md.irq_canonicalize	= NULL;
diff --git a/arch/ppc/syslib/mpc8xx_sys.c b/arch/ppc/syslib/mpc8xx_sys.c
--- a/arch/ppc/syslib/mpc8xx_sys.c
+++ b/arch/ppc/syslib/mpc8xx_sys.c
@@ -24,7 +24,7 @@ struct ppc_sys_spec ppc_sys_specs[] = {
 		.ppc_sys_name	= "MPC86X",
 		.mask 		= 0xFFFFFFFF,
 		.value 		= 0x00000000,
-		.num_devices	= 2,
+		.num_devices	= 7,
 		.device_list	= (enum ppc_sys_devices[])
 		{
 			MPC8xx_CPM_FEC1,
@@ -40,7 +40,7 @@ struct ppc_sys_spec ppc_sys_specs[] = {
 		.ppc_sys_name	= "MPC885",
 		.mask 		= 0xFFFFFFFF,
 		.value 		= 0x00000000,
-		.num_devices	= 3,
+		.num_devices	= 8,
 		.device_list	= (enum ppc_sys_devices[])
 		{
 			MPC8xx_CPM_FEC1,
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -69,6 +69,9 @@ static int __init find_chip_by_name_and_
 			matched[j++] = i;
 		i++;
 	}
+
+	ret = i;
+
 	if (j != 0) {
 		for (i = 0; i < j; i++) {
 			if ((ppc_sys_specs[matched[i]].mask & id) ==
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -1087,6 +1087,9 @@ typedef struct im_idma {
 #define SCCR_PCIDF_MSK	0x00000078	/* PCI division factor	*/
 #define SCCR_PCIDF_SHIFT 3
 
+#ifndef CPM_IMMR_OFFSET
+#define CPM_IMMR_OFFSET	0x101a8
+#endif
 
 #endif /* __CPM2__ */
 #endif /* __KERNEL__ */
diff --git a/include/asm-ppc/mpc8260.h b/include/asm-ppc/mpc8260.h
--- a/include/asm-ppc/mpc8260.h
+++ b/include/asm-ppc/mpc8260.h
@@ -92,6 +92,10 @@ enum ppc_sys_devices {
 extern unsigned char __res[];
 #endif
 
+#ifndef BOARD_CHIP_NAME
+#define BOARD_CHIP_NAME ""
+#endif
+
 #endif /* CONFIG_8260 */
 #endif /* !__ASM_PPC_MPC8260_H__ */
 #endif /* __KERNEL__ */
diff --git a/include/asm-ppc/mpc8xx.h b/include/asm-ppc/mpc8xx.h
--- a/include/asm-ppc/mpc8xx.h
+++ b/include/asm-ppc/mpc8xx.h
@@ -113,6 +113,10 @@ enum ppc_sys_devices {
 	MPC8xx_CPM_USB,
 };
 
+#ifndef BOARD_CHIP_NAME
+#define BOARD_CHIP_NAME ""
+#endif
+
 #endif /* !__ASSEMBLY__ */
 #endif /* CONFIG_8xx */
 #endif /* __CONFIG_8xx_DEFS */

Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx

[Marcelo Tosatti]

Hi Vitaly,

> This patch fixes a numbers of issues regarding to that both 8xx and 82xx 
> began to use ppc_sys model:
> 	- Platform is now identified by default deviceless SOC, if no 
> BOARD_CHIP_NAME is specified in the bard-specific header. For the list 
> of supported names refer to (arch/ppc/syslib/) mpc8xx_sys.c and 
> mpc82xx_sys.c for 8xx and 82xx respectively.
> 	- Fixed a bug in identification by name - if the name was not found, 
> 	it returned -1 instead of default deviceless ppc_spec.
> 	- fixed devices amount in the 8xx platform system descriptions

Patch looks good. 

For 8xx, I was wondering if the PARTNUM field of the IMMR 
(section 10.4.1 of MPC860UM.pdf) does have meaningful 
information which could be used to identify the CPU.

Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx

[Dan Malek]

On Oct 18, 2005, at 10:24 AM, Marcelo Tosatti wrote:

> For 8xx, I was wondering if the PARTNUM field of the IMMR
> (section 10.4.1 of MPC860UM.pdf) does have meaningful
> information which could be used to identify the CPU.

It has meaningful information, but not the way you want
to use it :-)  The PARTNUM/MASKNUM is only useful
once you know the type of processor (like 823, 850, 885, etc)
The PARTNUM is only useful within the "family."  For
example, the 860 and 880 are two different families, and
will contain the similar PARTNUM values through their life.
I believe it's tied to the fabrication process.

You may as well stop looking for an easy (or possibly
any) way to differentiate these parts in software, but
due to they way they are fabricated, I don't think that's
ever going to happen. :-)


	-- Dan

Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx

[Christopher Cordahi]

On 18/10/05, Dan Malek <dan@embeddededge.com> wrote:
>
> On Oct 18, 2005, at 10:24 AM, Marcelo Tosatti wrote:
>
> > For 8xx, I was wondering if the PARTNUM field of the IMMR
> > (section 10.4.1 of MPC860UM.pdf) does have meaningful
> > information which could be used to identify the CPU.
>
> It has meaningful information, but not the way you want
> to use it :-)  The PARTNUM/MASKNUM is only useful
> once you know the type of processor (like 823, 850, 885, etc)
> The PARTNUM is only useful within the "family."  For
> example, the 860 and 880 are two different families, and
> will contain the similar PARTNUM values through their life.
> I believe it's tied to the fabrication process.

I don't understand in what way Marcelo wants to use it, but
from my understanding and a quick look of the Freescale product
summary pages it's the opposite of what you're indicating.
I believe the PARTNUM identifies the family not the part.
You can't tell an 885 from an 870 (IMMR contains 0x09xx).
Similarly you can't tell an 860EN from an 860T (IMMR
contains 0x00xx or 0x05xx).
But you can tell an 860 from an 880 which are in different
families.  Note that it's not always obvious which parts
are in the same family.

> You may as well stop looking for an easy (or possibly
> any) way to differentiate these parts in software, but
> due to they way they are fabricated, I don't think that's
> ever going to happen. :-)
Also just because a feature isn't supposed to be present
doesn't mean it's not.
We bought 860EN (4 SCCs) parts but Motorola accidentily
shipped us 860DE (2 SCCs) parts.  We installed, tested and
shipped a few of these parts using all 4 SCCs without
problem.  It wasn't until another unrelated problem occurred
that we noticed that we had used a tray of the wrong part.

Chris

Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx

[Dan Malek]

On Oct 19, 2005, at 8:29 PM, Christopher Cordahi wrote:

> I don't understand in what way Marcelo wants to use it, but
> from my understanding and a quick look of the Freescale product
> summary pages it's the opposite of what you're indicating.

OK.  I can't find an up to date one any more.  From the processor
manuals there are overlapping numbers (unless that was just
an oversight during editing).

> Also just because a feature isn't supposed to be present
> doesn't mean it's not.

Yeah, some people have tried probing peripherals to discover
the type of processor, but that was quickly proven to not work.

Thanks.

	-- Dan