Board names for 4xx

Board names for 4xx

[David Gibson]

The patch below allows publishing the type of board the kernel is
running on in /proc/cpuinfo (under "machine") for 4xx machines.  It
displays Walnut boards as "IBM Walnut" and (currently) all others
simply as "4xx".  Adding other boards is trivial - just a #define in
the relevant header file.  It also eliminates a warning in
ppc4xx_setup.c

diff -urN ../linuxppc_2_4_devel/arch/ppc/kernel/ppc4xx_setup.c linux-bungo/arch/ppc/kernel/ppc4xx_setup.c
--- ../linuxppc_2_4_devel/arch/ppc/kernel/ppc4xx_setup.c	Mon Sep 10 11:57:26 2001
+++ linux-bungo/arch/ppc/kernel/ppc4xx_setup.c	Wed Sep 12 16:33:15 2001
@@ -86,7 +86,7 @@
 #endif

 #define BOOT_WDT_DEFAULT_PERIOD		120	/* 2 minutes */
-extern board_setup_arch(void);
+extern void board_setup_arch(void);

 void __init
 ppc4xx_setup_arch(void)
@@ -165,6 +165,8 @@
 	int len = 0;
 	bd_t *bip = (bd_t *)__res;

+	len += sprintf(len + buffer,
+		       "machine\t: %s\n", PPC4xx_MACHINE_NAME);
 #ifdef CONFIG_STB03xxx
 	len += sprintf(len + buffer,
 			"plb bus clock\t: %dMHz\n",
diff -urN ../linuxppc_2_4_devel/include/asm-ppc/walnut.h linux-bungo/include/asm-ppc/walnut.h
--- ../linuxppc_2_4_devel/include/asm-ppc/walnut.h	Thu Aug 16 04:45:34 2001
+++ linux-bungo/include/asm-ppc/walnut.h	Wed Sep 12 16:29:23 2001
@@ -78,6 +78,7 @@
 /* Generic 4xx type
 */
 #define _MACH_4xx (_MACH_walnut)
+#define PPC4xx_MACHINE_NAME	"IBM Walnut"

 #endif /* __WALNUT_H__ */
 #endif /* __KERNEL__ */

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Board names for 4xx

[David Gibson]

On Fri, Sep 14, 2001 at 02:44:03PM +1000, David Gibson wrote:
>
> The patch below allows publishing the type of board the kernel is
> running on in /proc/cpuinfo (under "machine") for 4xx machines.  It
> displays Walnut boards as "IBM Walnut" and (currently) all others
> simply as "4xx".  Adding other boards is trivial - just a #define in
> the relevant header file.  It also eliminates a warning in
> ppc4xx_setup.c

Oops.  The patch below does the same thing, only not broken (forgot a
file the first time around).

diff -urN ../linuxppc_2_4_devel/arch/ppc/kernel/ppc4xx_setup.c linux-bungo/arch/ppc/kernel/ppc4xx_setup.c
--- ../linuxppc_2_4_devel/arch/ppc/kernel/ppc4xx_setup.c	Mon Sep 10 11:57:26 2001
+++ linux-bungo/arch/ppc/kernel/ppc4xx_setup.c	Wed Sep 12 16:33:15 2001
@@ -86,7 +86,7 @@
 #endif

 #define BOOT_WDT_DEFAULT_PERIOD		120	/* 2 minutes */
-extern board_setup_arch(void);
+extern void board_setup_arch(void);

 void __init
 ppc4xx_setup_arch(void)
@@ -165,6 +165,8 @@
 	int len = 0;
 	bd_t *bip = (bd_t *)__res;

+	len += sprintf(len + buffer,
+		       "machine\t: %s\n", PPC4xx_MACHINE_NAME);
 #ifdef CONFIG_STB03xxx
 	len += sprintf(len + buffer,
 			"plb bus clock\t: %dMHz\n",
diff -urN ../linuxppc_2_4_devel/include/asm-ppc/ppc4xx.h linux-bungo/include/asm-ppc/ppc4xx.h
--- ../linuxppc_2_4_devel/include/asm-ppc/ppc4xx.h	Thu Aug 16 04:45:34 2001
+++ linux-bungo/include/asm-ppc/ppc4xx.h	Wed Sep 12 16:30:11 2001
@@ -26,6 +26,10 @@
 #include <asm/walnut.h>
 #endif

+#ifndef PPC4xx_MACHINE_NAME
+#define PPC4xx_MACHINE_NAME	"4xx"
+#endif
+
 /* IO_BASE is for PCI I/O.
  * ISA not supported, just here to resolve copilation.
  */
diff -urN ../linuxppc_2_4_devel/include/asm-ppc/walnut.h linux-bungo/include/asm-ppc/walnut.h
--- ../linuxppc_2_4_devel/include/asm-ppc/walnut.h	Thu Aug 16 04:45:34 2001
+++ linux-bungo/include/asm-ppc/walnut.h	Wed Sep 12 16:29:23 2001
@@ -78,6 +78,7 @@
 /* Generic 4xx type
 */
 #define _MACH_4xx (_MACH_walnut)
+#define PPC4xx_MACHINE_NAME	"IBM Walnut"

 #endif /* __WALNUT_H__ */
 #endif /* __KERNEL__ */


--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Board names for 4xx

[David Gibson]

On Fri, Sep 14, 2001 at 07:28:47AM -0700, Tom Rini wrote:
> On Fri, Sep 14, 2001 at 02:44:03PM +1000, David Gibson wrote:
>
> > The patch below allows publishing the type of board the kernel is
> > running on in /proc/cpuinfo (under "machine") for 4xx machines.  It
> > displays Walnut boards as "IBM Walnut" and (currently) all others
> > simply as "4xx".  Adding other boards is trivial - just a #define in
> > the relevant header file.  It also eliminates a warning in
> > ppc4xx_setup.c
>
> Sounds neat.  But since a number of utils (some distro-specific) parse
> the machine: line, do you think something like:

Yes, the fact that things parse it is the main reason I thought to add
it.

> machine:\t\t<Core>: <Board>
> ie:
> 405GP: IBM Walnut
> 405GP: EmbeddedPlanet
> or
> 403CX: TiVo

I don't see why - this information already appears in the "cpu:"
field and on machines that do have the "machine:" field it doesn't
generally include processor type information.

Below is an updated patch.  It improves the formatting (two '\t's
instead of one), adds information for the Oak and ep405 boards, and
fixes conflicts with some more recent updates.

diff -urN ../linuxppc_2_4_devel/arch/ppc/kernel/ppc4xx_setup.c linux-bungo/arch/ppc/kernel/ppc4xx_setup.c
--- ../linuxppc_2_4_devel/arch/ppc/kernel/ppc4xx_setup.c	Mon Sep 17 10:32:05 2001
+++ linux-bungo/arch/ppc/kernel/ppc4xx_setup.c	Mon Sep 17 12:21:21 2001
@@ -86,7 +86,7 @@
 #endif

 #define BOOT_WDT_DEFAULT_PERIOD		120	/* 2 minutes */
-extern board_setup_arch(void);
+extern void board_setup_arch(void);

 void __init
 ppc4xx_setup_arch(void)
@@ -165,6 +165,8 @@
 	int len = 0;
 	bd_t *bip = (bd_t *)__res;

+	len += sprintf(len + buffer,
+		       "machine\t\t: %s\n", PPC4xx_MACHINE_NAME);
 #ifdef CONFIG_STB03xxx
 	len += sprintf(len + buffer,
 			"plb bus clock\t: %dMHz\n",
diff -urN ../linuxppc_2_4_devel/include/asm-ppc/oak.h linux-bungo/include/asm-ppc/oak.h
--- ../linuxppc_2_4_devel/include/asm-ppc/oak.h	Mon Sep 17 10:32:05 2001
+++ linux-bungo/include/asm-ppc/oak.h	Mon Sep 17 12:22:50 2001
@@ -60,6 +60,8 @@
 	unsigned int	 bi_busfreq;		/* Bus speed, in Hz */
 } bd_t;

+#define PPC4xx_MACHINE_NAME	"IBM Oak"
+
 #endif /* !__ASSEMBLY__ */
 #endif /* __OAK_H__ */
 #endif /* __KERNEL__ */
diff -urN ../linuxppc_2_4_devel/include/asm-ppc/ppc4xx.h linux-bungo/include/asm-ppc/ppc4xx.h
--- ../linuxppc_2_4_devel/include/asm-ppc/ppc4xx.h	Mon Sep 17 10:32:05 2001
+++ linux-bungo/include/asm-ppc/ppc4xx.h	Mon Sep 17 12:23:29 2001
@@ -30,6 +30,10 @@
 #include <asm/ep405.h>
 #endif

+#ifndef PPC4xx_MACHINE_NAME
+#define PPC4xx_MACHINE_NAME	"4xx"
+#endif
+
 /* IO_BASE is for PCI I/O.
  * ISA not supported, just here to resolve copilation.
  */
diff -urN ../linuxppc_2_4_devel/include/asm-ppc/walnut.h linux-bungo/include/asm-ppc/walnut.h
--- ../linuxppc_2_4_devel/include/asm-ppc/walnut.h	Mon Sep 17 10:32:05 2001
+++ linux-bungo/include/asm-ppc/walnut.h	Mon Sep 17 12:19:31 2001
@@ -69,5 +69,7 @@
 #define kbd_write_output(val)  writeb(val, kb_data)
 #define kbd_write_command(val) writeb(val, kb_cs)

+#define PPC4xx_MACHINE_NAME	"IBM Walnut"
+
 #endif /* __WALNUT_H__ */
 #endif /* __KERNEL__ */


--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Board names for 4xx

[Tom Rini]

On Mon, Sep 17, 2001 at 12:28:28PM +1000, David Gibson wrote:

> On Fri, Sep 14, 2001 at 07:28:47AM -0700, Tom Rini wrote:
[snip]
> > machine:\t\t<Core>: <Board>
> > ie:
> > 405GP: IBM Walnut
> > 405GP: EmbeddedPlanet
> > or
> > 403CX: TiVo
>
> I don't see why - this information already appears in the "cpu:"
> field and on machines that do have the "machine:" field it doesn't
> generally include processor type information.

Well, because they usually (at least what I can think of, but I haven't
been on the userland side of things for a while) don't bother with
the cpu field.  Hence I was thinking of being able to case based on
'405GP'* instead of per-board.  Thats just my 2cents tho, take it for what
you will.

I do wish someone else would speak up tho.  Does anyone out there have an
opinion?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Board names for 4xx

[Dan Malek]

Tom Rini wrote:

> I do wish someone else would speak up tho.  Does anyone out there have an
> opinion?

It depends how you want to use this information.  In the kernel, it is very
critical we clearly distinguish between the "core" (the thing that executes
instructions), the peripherals (the real difference among the SOC-type
processors), and the board design (which will determine how the peripherals
are configured).

If the information from /proc is just used for pretty print out of
information, I really don't care.  If there are applications that read
this for some internal configuration and flexibility, we better have a
standard format.


	-- Dan

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Board names for 4xx

[Kenneth Johansson]

Dan Malek wrote:
>
> Tom Rini wrote:
>
> > I do wish someone else would speak up tho.  Does anyone out there have an
> > opinion?
>
> If the information from /proc is just used for pretty print out of
> information, I really don't care.  If there are applications that read
> this for some internal configuration and flexibility, we better have a
> standard format.
>
>         -- Dan

Debian uses /proc/cpuinfo to find out what utility to use for the RTC
(clock,hwclock). This could be fixed if the code from clock was integrated in
hwclock. hwclock tries every method it knows until one works.

--
Kenneth Johansson
Ericsson Business Innovation AB   Tel: +46 8 404 71 83
Viderögatan 3                     Fax: +46 8 404 72 72
164 80 Stockholm                  kenneth.johansson@inn.ericsson.se

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Board names for 4xx

[Tom Rini]

On Mon, Sep 17, 2001 at 06:11:56PM +0200, Kenneth Johansson wrote:
> Dan Malek wrote:
> >
> > Tom Rini wrote:
> >
> > > I do wish someone else would speak up tho.  Does anyone out there have an
> > > opinion?
> >
> > If the information from /proc is just used for pretty print out of
> > information, I really don't care.  If there are applications that read
> > this for some internal configuration and flexibility, we better have a
> > standard format.
> Debian uses /proc/cpuinfo to find out what utility to use for the RTC
> (clock,hwclock). This could be fixed if the code from clock was integrated in
> hwclock. hwclock tries every method it knows until one works.

This is no longer true.  Woody anyways assumes that /dev/rtc will work in
the 'standard' way.  But,, debian does parse for machien type for doing
board/platform specific modules.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Board names for 4xx

[David Gibson]

On Mon, Sep 17, 2001 at 11:33:45AM -0700, Tom Rini wrote:
>
> On Mon, Sep 17, 2001 at 06:11:56PM +0200, Kenneth Johansson wrote:
> > Dan Malek wrote:
> > >
> > > Tom Rini wrote:
> > >
> > > > I do wish someone else would speak up tho.  Does anyone out there have an
> > > > opinion?
> > >
> > > If the information from /proc is just used for pretty print out of
> > > information, I really don't care.  If there are applications that read
> > > this for some internal configuration and flexibility, we better have a
> > > standard format.
> > Debian uses /proc/cpuinfo to find out what utility to use for the RTC
> > (clock,hwclock). This could be fixed if the code from clock was integrated in
> > hwclock. hwclock tries every method it knows until one works.
>
> This is no longer true.  Woody anyways assumes that /dev/rtc will work in
> the 'standard' way.  But,, debian does parse for machien type for doing
> board/platform specific modules.

Yes, but last I checked the util-linux install script would still die
if the machine: field wasn't present at all.  IIRC it was checking for
PReP machines for some reason.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Board names for 4xx

[Tom Rini]

On Tue, Sep 18, 2001 at 10:35:30AM +1000, David Gibson wrote:
>
> On Mon, Sep 17, 2001 at 11:33:45AM -0700, Tom Rini wrote:
> >
> > On Mon, Sep 17, 2001 at 06:11:56PM +0200, Kenneth Johansson wrote:
> > > Dan Malek wrote:
> > > >
> > > > Tom Rini wrote:
> > > >
> > > > > I do wish someone else would speak up tho.  Does anyone out there have an
> > > > > opinion?
> > > >
> > > > If the information from /proc is just used for pretty print out of
> > > > information, I really don't care.  If there are applications that read
> > > > this for some internal configuration and flexibility, we better have a
> > > > standard format.
> > > Debian uses /proc/cpuinfo to find out what utility to use for the RTC
> > > (clock,hwclock). This could be fixed if the code from clock was integrated in
> > > hwclock. hwclock tries every method it knows until one works.
> >
> > This is no longer true.  Woody anyways assumes that /dev/rtc will work in
> > the 'standard' way.  But,, debian does parse for machien type for doing
> > board/platform specific modules.
>
> Yes, but last I checked the util-linux install script would still die
> if the machine: field wasn't present at all.  IIRC it was checking for
> PReP machines for some reason.

util-linux is broken then.  All PPC (save APUS) can have a working
/dev/rtc, via CONFIG_PPC_RTC.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Board names for 4xx

[David Gibson]

On Mon, Sep 17, 2001 at 11:56:10AM -0400, Dan Malek wrote:
>
> Tom Rini wrote:
>
> > I do wish someone else would speak up tho.  Does anyone out there have an
> > opinion?
>
> It depends how you want to use this information.  In the kernel, it is very
> critical we clearly distinguish between the "core" (the thing that executes
> instructions), the peripherals (the real difference among the SOC-type
> processors), and the board design (which will determine how the peripherals
> are configured).
>
> If the information from /proc is just used for pretty print out of
> information, I really don't care.  If there are applications that read
> this for some internal configuration and flexibility, we better have a
> standard format.

I don't see that we need to structure the information in the machine:
field for this purpose though - if the core and peripherals
information turns out to be important it belongs better in other
fields of /proc/cpuinfo, I think.  We already have cpu: and we could
make a core: if it was necessary - or encode the core information into
cpu: it belongs there more than in machine: I think.  Just the board
type (and revision, where we can find that information) seems the
closest match to what machine: gives on more normal PPC machines.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/