PPC 405GPr support in linux 2.4.32

PPC 405GPr support in linux 2.4.32

[Stephen Williams]

... seems completely missing in the linux-2.3.32 tree from kernel.org.
This used to be in the linuxppc-2.4 BK tree that no longer exists, so
what happened to the ppc405GPr support?!


-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Re: PPC 405GPr support in linux 2.4.32

[Matt Porter]

On Wed, Apr 26, 2006 at 04:19:23PM -0700, Stephen Williams wrote:
> ... seems completely missing in the linux-2.3.32 tree from kernel.org.
> This used to be in the linuxppc-2.4 BK tree that no longer exists, so
> what happened to the ppc405GPr support?!

There's some stuff that never got submitted upstream to kernel.org
during 2.4 due partially to 2.5 appearing. All upstream devel
moved to 2.5/2.6 and no effort was made to merge stuff from the
linuxppc-2.4 tree to linux-2.4. Oh, and Marcelo didn't want
to take "new stuff" into linux-2.4 at that time either.

There's still rsync://source.mvista.com/linuxppc-2.4 available with
the 405gpr/sycamore support.

-Matt

Re: PPC 405GPr support in linux 2.4.32

[Tolunay Orkun]

Stephen Williams wrote:
> ... seems completely missing in the linux-2.3.32 tree from kernel.org.
> This used to be in the linuxppc-2.4 BK tree that no longer exists, so
> what happened to the ppc405GPr support?!

I guess nobody sent patches upstream and development shifted to 2.6 
kernel. 405Gpr is not alone. 405EP and a number of other CPU support 
that was present never got its way up kernel.org sources.

Re: PPC 405GPr support in linux 2.4.32

[Stephen Williams]

Matt Porter wrote:
> On Wed, Apr 26, 2006 at 04:19:23PM -0700, Stephen Williams wrote:
>> ... seems completely missing in the linux-2.3.32 tree from kernel.org.
>> This used to be in the linuxppc-2.4 BK tree that no longer exists, so
>> what happened to the ppc405GPr support?!
> 
> There's some stuff that never got submitted upstream to kernel.org
> during 2.4 due partially to 2.5 appearing. All upstream devel
> moved to 2.5/2.6 and no effort was made to merge stuff from the
> linuxppc-2.4 tree to linux-2.4. Oh, and Marcelo didn't want
> to take "new stuff" into linux-2.4 at that time either.
> 
> There's still rsync://source.mvista.com/linuxppc-2.4 available with
> the 405gpr/sycamore support.

Well then I guess for 405GPr support and the SystemACE drivers
I'm on my own. Is there a git tree for main line 2.4 maintenance
(against which I could maintain patches) or am I on my own there
too?

It should be easy enough to rescue the gpr support form the bk
working dir that I have (or the mvista repository as you point
out) and make up patches.
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Re: PPC 405GPr support in linux 2.4.32

[Stephen Williams]

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

Stephen Williams wrote:
> ... seems completely missing in the linux-2.3.32 tree from kernel.org.
> This used to be in the linuxppc-2.4 BK tree that no longer exists, so
> what happened to the ppc405GPr support?!

The attached patch adds the ibm405gpr support files from various
places and adds the core support to Linux 2.4. Although this diff
was done relative Marcelo's git tree, it actually touches no C files,
only a few config and make files (Plus it adds the gpr support c/h
files) so it should apply to any recent 2.4 kernel tree.

I'm almost ready with a patch that does a similar thing with
the SystemACE driver.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

[-- Attachment #2: 0001-Core-ppc405GPr-support.txt --]
[-- Type: text/plain, Size: 12383 bytes --]

>From nobody Mon Sep 17 00:00:00 2001
From: Stephen Williams <steve@wing.icarus.com>
Date: Thu Apr 27 08:45:41 2006 -0700
Subject: [PATCH]  Core ppc405GPr support.

Signed-off-by: Stephen Williams <steve@wing.icarus.com>


---

 arch/ppc/config.in             |    3 -
 arch/ppc/platforms/Makefile    |    1 
 arch/ppc/platforms/ibm405gpr.c |  108 ++++++++++++++++++++++
 arch/ppc/platforms/ibm405gpr.h |  193 ++++++++++++++++++++++++++++++++++++++++
 4 files changed, 304 insertions(+), 1 deletions(-)
 create mode 100644 arch/ppc/platforms/ibm405gpr.c
 create mode 100644 arch/ppc/platforms/ibm405gpr.h

ac23ca9a2f268eec56eea0edd595502ef6e94abc
diff --git a/arch/ppc/config.in b/arch/ppc/config.in
index ade3865..089d479 100644
--- a/arch/ppc/config.in
+++ b/arch/ppc/config.in
@@ -232,7 +232,8 @@ if [ "$CONFIG_4xx" = "y" ]; then
 #
 # Set options based on processor implementation
 #
-  if [ "$CONFIG_405GP" = "y" -o "$CONFIG_STB03xxx" = "y" ]; then
+  if [ "$CONFIG_405GP" = "y" -o "$CONFIG_405GPR" = "y" \
+	-o "$CONFIG_STB03xxx" = "y" ]; then
     define_bool CONFIG_IBM_OCP y
     define_bool CONFIG_PPC_OCP y
     define_bool CONFIG_405 y
diff --git a/arch/ppc/platforms/Makefile b/arch/ppc/platforms/Makefile
index ab84e70..3aaebc6 100644
--- a/arch/ppc/platforms/Makefile
+++ b/arch/ppc/platforms/Makefile
@@ -29,6 +29,7 @@ O_TARGET := platform.o
 export-objs			:= prep_setup.o ibm440gp.o ibm440gx.o
 
 obj-$(CONFIG_405GP)		+= ibm405gp.o
+obj-$(CONFIG_405GPR)		+= ibm405gpr.o
 obj-$(CONFIG_440GP)		+= ibm440gp.o
 obj-$(CONFIG_440GX)		+= ibm440gx.o
 
diff --git a/arch/ppc/platforms/ibm405gpr.c b/arch/ppc/platforms/ibm405gpr.c
new file mode 100644
index 0000000..1e05b7d
--- /dev/null
+++ b/arch/ppc/platforms/ibm405gpr.c
@@ -0,0 +1,108 @@
+/*
+ *
+ *    Copyright 2000-2002 MontaVista Software Inc.
+ *	Current maintainer
+ *      Armin Kuster akuster@mvista.com
+ *
+ *    Module name: ibm405gpr.c
+ *
+ *
+ * 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.
+ *
+ *  THIS  SOFTWARE  IS PROVIDED   ``AS  IS'' AND   ANY  EXPRESS OR   IMPLIED
+ *  WARRANTIES,   INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED WARRANTIES OF
+ *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
+ *  NO  EVENT  SHALL   THE AUTHOR  BE    LIABLE FOR ANY   DIRECT,  INDIRECT,
+ *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *  NOT LIMITED   TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; LOSS OF
+ *  USE, DATA,  OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ *  ANY THEORY OF LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ *  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ *  You should have received a copy of the  GNU General Public License along
+ *  with this program; if not, write  to the Free Software Foundation, Inc.,
+ *  675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/smp.h>
+#include <linux/threads.h>
+#include <linux/param.h>
+#include <linux/string.h>
+#include <platforms/ibm405gpr.h>
+#include <asm/ibm4xx.h>
+#include <asm/ocp.h>
+
+static struct ocp_func_emac_data ibm405gpr_emac0_def = {
+	.zmii_idx	= -1,		/* ZMII device index */
+	.zmii_mux	= 0,		/* ZMII input of this EMAC */
+	.mal_idx	= 0,		/* MAL device index */
+	.mal_rx_chan	= 0,		/* MAL rx channel number */
+	.mal_tx1_chan	= 0,		/* MAL tx channel 1 number */
+	.mal_tx2_chan	= 1,		/* MAL tx channel 2 number */
+	.wol_irq	= BL_MAC_WOL,	/* WOL interrupt number */
+	.mdio_idx	= -1,		/* No shared MDIO */
+};
+
+static struct ocp_func_mal_data ibm405gpr_mal0_def = {
+	.num_tx_chans	= 2*EMAC_NUMS,	/* Number of TX channels */
+	.num_rx_chans	= EMAC_NUMS,	/* Number of RX channels */
+};
+
+struct ocp_def core_ocp[]  __initdata = {
+	{ .vendor	= OCP_VENDOR_IBM,
+	  .function	= OCP_FUNC_OPB,
+	  .index	= 0,
+	  .paddr	= OPB_BASE_START,
+	  .irq		= OCP_IRQ_NA,
+	  .pm		= OCP_CPM_NA,
+	},
+	{ .vendor	= OCP_VENDOR_IBM,
+	  .function	= OCP_FUNC_16550,
+	  .index	= 0,
+	  .paddr	= UART0_IO_BASE,
+	  .irq		= UART0_INT,
+	  .pm		= IBM_CPM_UART0
+	},
+	{ .vendor	= OCP_VENDOR_IBM,
+	  .function	= OCP_FUNC_16550,
+	  .index	= 1,
+	  .paddr	= UART1_IO_BASE,
+	  .irq		= UART1_INT,
+	  .pm		= IBM_CPM_UART1
+	},
+	{ .vendor	= OCP_VENDOR_IBM,
+	  .function	= OCP_FUNC_IIC,
+	  .paddr	= IIC0_BASE,
+	  .irq		= IIC0_IRQ,
+	  .pm		= IBM_CPM_IIC0
+	},
+	{ .vendor	= OCP_VENDOR_IBM,
+	  .function	= OCP_FUNC_GPIO,
+	  .paddr	= GPIO0_BASE,
+	  .irq		= OCP_IRQ_NA,
+	  .pm		= IBM_CPM_GPIO0
+	},
+	{ .vendor	= OCP_VENDOR_IBM,
+	  .function	= OCP_FUNC_MAL,
+	  .paddr	= OCP_PADDR_NA,
+	  .irq		= OCP_IRQ_NA,
+	  .pm		= OCP_CPM_NA,
+	  .additions	= &ibm405gpr_mal0_def,
+	},
+	{ .vendor	= OCP_VENDOR_IBM,
+	  .function	= OCP_FUNC_EMAC,
+	  .index	= 0,
+	  .paddr	= EMAC0_BASE,
+	  .irq		= BL_MAC_ETH0,
+	  .pm		= IBM_CPM_EMAC0,
+	  .additions	= &ibm405gpr_emac0_def,
+	},
+	{ .vendor	= OCP_VENDOR_INVALID
+	}
+};
diff --git a/arch/ppc/platforms/ibm405gpr.h b/arch/ppc/platforms/ibm405gpr.h
new file mode 100644
index 0000000..273274c
--- /dev/null
+++ b/arch/ppc/platforms/ibm405gpr.h
@@ -0,0 +1,193 @@
+/*
+ * ibm405gpr.h
+ *
+ *
+ *      Armin Kuster akuster@mvista.com
+ *      Aug, 2002
+ *
+ *
+ * Copyright 2002 MontaVista Softare Inc.
+ *
+ * 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.
+ *
+ *  THIS  SOFTWARE  IS PROVIDED   ``AS  IS'' AND   ANY  EXPRESS OR   IMPLIED
+ *  WARRANTIES,   INCLUDING, BUT NOT  LIMITED  TO, THE IMPLIED WARRANTIES OF
+ *  MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN
+ *  NO  EVENT  SHALL   THE AUTHOR  BE    LIABLE FOR ANY   DIRECT,  INDIRECT,
+ *  INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ *  NOT LIMITED   TO, PROCUREMENT OF  SUBSTITUTE GOODS  OR SERVICES; LOSS OF
+ *  USE, DATA,  OR PROFITS; OR  BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON
+ *  ANY THEORY OF LIABILITY, WHETHER IN  CONTRACT, STRICT LIABILITY, OR TORT
+ *  (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
+ *  THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ *
+ *  You should have received a copy of the  GNU General Public License along
+ *  with this program; if not, write  to the Free Software Foundation, Inc.,
+ *  675 Mass Ave, Cambridge, MA 02139, USA.
+ *
+ *	Version 1.0 (10/01/02) - A. Kuster
+ *	Initial version	 
+ *
+ */
+
+#ifdef __KERNEL__
+#ifndef __ASM_IBM405GPR_H__
+#define __ASM_IBM405GPR_H__
+
+#include <linux/config.h>
+#include <platforms/ibm_ocp.h>
+
+/* ibm405.h at bottom of this file */
+
+/* PCI
+ * PCI Bridge config reg definitions
+ * see 17-19 of manual
+ */
+
+#define PPC405_PCI_CONFIG_ADDR	0xeec00000
+#define PPC405_PCI_CONFIG_DATA	0xeec00004
+
+#define PPC405_PCI_PHY_MEM_BASE	0x80000000	/* hose_a->pci_mem_offset */
+						/* setbat */
+#define PPC405_PCI_MEM_BASE	PPC405_PCI_PHY_MEM_BASE	/* setbat */
+#define PPC405_PCI_PHY_IO_BASE	0xe8000000	/* setbat */
+#define PPC405_PCI_IO_BASE	PPC405_PCI_PHY_IO_BASE	/* setbat */
+
+#define PPC405_PCI_LOWER_MEM	0x80000000	/* hose_a->mem_space.start */
+#define PPC405_PCI_UPPER_MEM	0xBfffffff	/* hose_a->mem_space.end */
+#define PPC405_PCI_LOWER_IO	0x00000000	/* hose_a->io_space.start */
+#define PPC405_PCI_UPPER_IO	0x0000ffff	/* hose_a->io_space.end */
+
+#define PPC405_ISA_IO_BASE	PPC405_PCI_IO_BASE
+
+#define PPC4xx_PCI_IO_PADDR	((uint)PPC405_PCI_PHY_IO_BASE)
+#define PPC4xx_PCI_IO_VADDR	PPC4xx_PCI_IO_PADDR
+#define PPC4xx_PCI_IO_SIZE	((uint)64*1024)
+#define PPC4xx_PCI_CFG_PADDR	((uint)PPC405_PCI_CONFIG_ADDR)
+#define PPC4xx_PCI_CFG_VADDR	PPC4xx_PCI_CFG_PADDR
+#define PPC4xx_PCI_CFG_SIZE	((uint)4*1024)
+#define PPC4xx_PCI_LCFG_PADDR	((uint)0xef400000)
+#define PPC4xx_PCI_LCFG_VADDR	PPC4xx_PCI_LCFG_PADDR
+#define PPC4xx_PCI_LCFG_SIZE	((uint)4*1024)
+#define PPC4xx_ONB_IO_PADDR	((uint)0xef600000)
+#define PPC4xx_ONB_IO_VADDR	PPC4xx_ONB_IO_PADDR
+#define PPC4xx_ONB_IO_SIZE	((uint)4*1024)
+
+/* serial port defines */
+#define RS_TABLE_SIZE	2
+
+#define UART0_INT	0
+#define UART1_INT	1
+
+#define OPB_BASE_START	0x40000000
+#define EBIU_BASE_START	0xF0100000
+#define PCIL0_BASE	0xEF400000
+#define UART0_IO_BASE	0xEF600300
+#define UART1_IO_BASE	0xEF600400
+#define IIC0_BASE	0xEF600500
+#define OPB0_BASE	0xEF600600
+#define GPIO0_BASE	0xEF600700
+#define EMAC0_BASE	0xEF600800
+#define BL_MAC_WOL	9	/* WOL */
+#define BL_MAL_SERR	10	/* MAL SERR */
+#define BL_MAL_TXDE	13	/* MAL TXDE */
+#define BL_MAL_RXDE	14	/* MAL RXDE */
+#define BL_MAL_TXEOB	11	/* MAL TX EOB */
+#define BL_MAL_RXEOB	12	/* MAL RX EOB */
+#define BL_MAC_ETH0	15	/* MAC */
+
+#define EMAC_NUMS	1
+#define IIC0_IRQ	2
+
+#define IIC_OWN		0x55
+#define IIC_CLOCK	50
+#define BD_EMAC_ADDR(e,i) bi_enetaddr[i]
+
+#define STD_UART_OP(num)					\
+	{ 0, BASE_BAUD, 0, UART##num##_INT,			\
+		(ASYNC_BOOT_AUTOCONF | ASYNC_SKIP_TEST),	\
+		iomem_base: (u8 *)UART##num##_IO_BASE,		\
+		io_type: SERIAL_IO_MEM},
+
+#if defined(CONFIG_UART0_TTYS0)
+#define SERIAL_DEBUG_IO_BASE	UART0_IO_BASE
+#define SERIAL_PORT_DFNS	\
+	STD_UART_OP(0)		\
+	STD_UART_OP(1)
+#endif
+
+#if defined(CONFIG_UART0_TTYS1)
+#define SERIAL_DEBUG_IO_BASE	UART1_IO_BASE
+#define SERIAL_PORT_DFNS	\
+	STD_UART_OP(1)		\
+	STD_UART_OP(0)
+#endif
+
+/* DCR defines */
+#define DCRN_CHCR_BASE		0x0B1
+#define DCRN_CHPSR_BASE		0x0B4
+#define DCRN_CPMSR_BASE		0x0B8
+#define DCRN_CPMFR_BASE		0x0BA
+
+#define CHR0_U0EC	0x00000080	/* Select external clock for UART0 */
+#define CHR0_U1EC	0x00000040	/* Select external clock for UART1 */
+#define CHR0_UDIV	0x0000003E	/* UART internal clock divisor */
+#define CHR1_CETE	0x00800000	/* CPU external timer enable */
+
+#define DCRN_CHPSR_BASE         0x0B4
+#define  PSR_PLL_FWD_MASK        0xC0000000
+#define  PSR_PLL_FDBACK_MASK     0x30000000
+#define  PSR_PLL_TUNING_MASK     0x0E000000
+#define  PSR_PLB_CPU_MASK        0x01800000
+#define  PSR_OPB_PLB_MASK        0x00600000
+#define  PSR_PCI_PLB_MASK        0x00180000
+#define  PSR_EB_PLB_MASK         0x00060000
+#define  PSR_ROM_WIDTH_MASK      0x00018000
+#define  PSR_ROM_LOC             0x00004000
+#define  PSR_PCI_ASYNC_EN        0x00001000
+#define  PSR_PCI_ARBIT_EN        0x00000400
+
+#define IBM_CPM_IIC0		0x80000000	/* IIC interface */
+#define IBM_CPM_PCI		0x40000000	/* PCI bridge */
+#define IBM_CPM_CPU		0x20000000	/* processor core */
+#define IBM_CPM_DMA		0x10000000	/* DMA controller */
+#define IBM_CPM_OPB		0x08000000	/* PLB to OPB bridge */
+#define IBM_CPM_DCP		0x04000000	/* CodePack */
+#define IBM_CPM_EBC		0x02000000	/* ROM/SRAM peripheral controller */
+#define IBM_CPM_SDRAM0		0x01000000	/* SDRAM memory controller */
+#define IBM_CPM_PLB		0x00800000	/* PLB bus arbiter */
+#define IBM_CPM_GPIO0		0x00400000	/* General Purpose IO (??) */
+#define IBM_CPM_UART0		0x00200000	/* serial port 0 */
+#define IBM_CPM_UART1		0x00100000	/* serial port 1 */
+#define IBM_CPM_UIC		0x00080000	/* Universal Interrupt Controller */
+#define IBM_CPM_TMRCLK		0x00040000	/* CPU timers */
+#define IBM_CPM_EMAC0		0x00020000	/* on-chip ethernet MM unit */
+#define DFLT_IBM4xx_PM		~(IBM_CPM_PCI | IBM_CPM_CPU | IBM_CPM_DMA \
+					| IBM_CPM_OPB | IBM_CPM_EBC \
+					| IBM_CPM_SDRAM0 | IBM_CPM_PLB \
+					| IBM_CPM_UIC | IBM_CPM_TMRCLK)
+
+#define DCRN_DMA0_BASE		0x100
+#define DCRN_DMA1_BASE		0x108
+#define DCRN_DMA2_BASE		0x110
+#define DCRN_DMA3_BASE		0x118
+#define DCRNCAP_DMA_SG		1	/* have DMA scatter/gather capability */
+#define DCRN_DMASR_BASE		0x120
+#define DCRN_EBC_BASE		0x012
+#define DCRN_DCP0_BASE		0x014
+#define DCRN_MAL_BASE		0x180
+#define DCRN_OCM0_BASE		0x018
+#define DCRN_PLB0_BASE		0x084
+#define DCRN_PLLMR_BASE		0x0B0
+#define DCRN_POB0_BASE		0x0A0
+#define DCRN_SDRAM0_BASE	0x010
+#define DCRN_UIC0_BASE		0x0C0
+#define UIC0 DCRN_UIC0_BASE
+
+#include <platforms/ibm405.h>
+
+#endif				/* __ASM_IBM405GPR_H__ */
+#endif				/* __KERNEL__ */
-- 
1.2.6

Re: PPC 405GPr support in linux 2.4.32

[Eugene Surovegin]

On Wed, Apr 26, 2006 at 04:57:21PM -0700, Stephen Williams wrote:
> Is there a git tree for main line 2.4 maintenance
> (against which I could maintain patches)

git://git.kernel.org/pub/scm/linux/kernel/git/marcelo/linux-2.4.git

-- 
Eugene

Re: PPC 405GPr support in linux 2.4.32

[Eugene Surovegin]

On Wed, Apr 26, 2006 at 04:35:40PM -0700, Matt Porter wrote:
> linuxppc-2.4 tree to linux-2.4. Oh, and Marcelo didn't want
> to take "new stuff" into linux-2.4 at that time either.
> 
> There's still rsync://source.mvista.com/linuxppc-2.4 available with
> the 405gpr/sycamore support.

There are bigger problems with 4xx support in 2.4 mainline than just 
missing some chips support.

Some parts which are already in 2.4 (e.g. ethernet driver) are of 
non-production quality. 

I can imagine Marcelo agreeing to commit 405GPr/405EP support as this 
change shouldn't break anything, but this will not make 2.4 support 
really useful for real world deployments. I think we are stuck with 
maintaining our own 2.4 trees with backports from 2.6. This is what I 
do myself of all our products (and yeah, diff between stock 2.4.32 and 
my internal version has already grown quite big to be acceptable for 
2.4 inclusion).

-- 
Eugene

Re: PPC 405GPr support in linux 2.4.32

[Stephen Williams]

Eugene Surovegin wrote:
> There are bigger problems with 4xx support in 2.4 mainline than just 
> missing some chips support.
> 
> Some parts which are already in 2.4 (e.g. ethernet driver) are of 
> non-production quality. 
> 
> I can imagine Marcelo agreeing to commit 405GPr/405EP support as this 
> change shouldn't break anything, but this will not make 2.4 support 
> really useful for real world deployments. I think we are stuck with 
> maintaining our own 2.4 trees with backports from 2.6. This is what I 
> do myself of all our products (and yeah, diff between stock 2.4.32 and 
> my internal version has already grown quite big to be acceptable for 
> 2.4 inclusion).
> 

Of course we are going to have to keep our own per-board trees.
but the blatantly common stuff, like the core 405gpr support and
certain drivers, might as well go in if the gatekeeper can be
convinced. You and I both probably have huge drivers for custom
devices hanging off our PPCs, with various hacks to squeeze extra
performance out. These make our transition to 2.6 difficult, and
surely we are not alone.

So 2.4 is going to be around for a while longer for us, so we might
as well make an effort to keep the house in some sort of order. It
serves no one to keep these fixes a secret:-)

In any case, if the patches I sent are rejected, then that's that.
We'll see.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

Re-configuring busybox that comes with DENX's ELDK SELF

[Randy Smith]

Hello,

I have a weird situation that I am very confused about and I was 
wondering if some kind soul would point me in the right direction?

I have a working powerpc embedded system using the 2.4 kernel built with 
DENX' ELDK and root file system from DENX' SELF.
I am trying to enable some additional applets in the busybox (well, tftp 
anyway) that came with SELF. I am using the ELDK cross toolchain on an 
x86 box to build everything and the powerpc board itself is based on an 
Icecube board. I thought I could do the following...

1. Download the source for busybox and compile it using the cross tools 
from DENX.
2. Install it in my target root file system
3. Make the jffs2 file system image and flash it into the unit under test.

When I do this, the kernel loads and boots just like before and then 
hangs after is says it is freeing unused memory. I am assuming that this 
is where it is trying to run the new init that I just installed, so 
obviously it isn't working like I planned.

Where did I go wrong?

I am thinking that I have a library mismatch/issue and that the new init 
binary can't/won't run with the runtime libraries that come with SELF, 
but I don't know how to go about correcting this if this is the case.

Opinions or urls to tutorials welcome.

Thanks,

-Randy Smith
Software Engineer
Imagemap, Inc.

Re: PPC 405GPr support in linux 2.4.32

[Eugene Surovegin]

On Thu, Apr 27, 2006 at 11:32:45AM -0700, Stephen Williams wrote:
> Eugene Surovegin wrote:
> > There are bigger problems with 4xx support in 2.4 mainline than just 
> > missing some chips support.
> > 
> > Some parts which are already in 2.4 (e.g. ethernet driver) are of 
> > non-production quality. 
> > 
> > I can imagine Marcelo agreeing to commit 405GPr/405EP support as this 
> > change shouldn't break anything, but this will not make 2.4 support 
> > really useful for real world deployments. I think we are stuck with 
> > maintaining our own 2.4 trees with backports from 2.6. This is what I 
> > do myself of all our products (and yeah, diff between stock 2.4.32 and 
> > my internal version has already grown quite big to be acceptable for 
> > 2.4 inclusion).
> > 
> 
> Of course we are going to have to keep our own per-board trees.
> but the blatantly common stuff, like the core 405gpr support and
> certain drivers, might as well go in if the gatekeeper can be
> convinced. You and I both probably have huge drivers for custom
> devices hanging off our PPCs, with various hacks to squeeze extra
> performance out. These make our transition to 2.6 difficult, and
> surely we are not alone.

Well, personally, I don't migrate to 2.6 not because I have many custom 
drivers in my tree (if they are properly written, migration is 
relatively easy), but because 2.6 in my opinion isn't production 
ready, at least for architectures I work with. 2.6 is slower, bigger, 
is constantly being broken by huge amount of changes, etc. I spent 
enough time making 2.4 work on our hardware given limitations and 
requirements put on performance, resources etc. I just don't have time 
to go through this cycle again. And I'm not talking about PPC stuff, I 
mean mostly generic stuff - filesystems, scheduling, networking, etc.

> So 2.4 is going to be around for a while longer for us, so we might
> as well make an effort to keep the house in some sort of order. It
> serves no one to keep these fixes a secret:-)

They aren't secret, but I can understand the simple fact that 2.4 is 
closed for a new stuff, we might not like that (although I do, just 
look at the mess "stable" 2.6 is :).

There is a point in every piece of software life-cycle when you have 
to stop adding features. 2.4 is already at this point, and we should 
accept that.

-- 
Eugene

Re: PPC 405GPr support in linux 2.4.32

[Marcelo Tosatti]

On Thu, Apr 27, 2006 at 11:32:45AM -0700, Stephen Williams wrote:
> Eugene Surovegin wrote:
> > There are bigger problems with 4xx support in 2.4 mainline than just 
> > missing some chips support.
> > 
> > Some parts which are already in 2.4 (e.g. ethernet driver) are of 
> > non-production quality. 
> > 
> > I can imagine Marcelo agreeing to commit 405GPr/405EP support as this 
> > change shouldn't break anything, but this will not make 2.4 support 
> > really useful for real world deployments. I think we are stuck with 
> > maintaining our own 2.4 trees with backports from 2.6. This is what I 
> > do myself of all our products (and yeah, diff between stock 2.4.32 and 
> > my internal version has already grown quite big to be acceptable for 
> > 2.4 inclusion).
> > 
> 
> Of course we are going to have to keep our own per-board trees.
> but the blatantly common stuff, like the core 405gpr support and
> certain drivers, might as well go in if the gatekeeper can be
> convinced. You and I both probably have huge drivers for custom
> devices hanging off our PPCs, with various hacks to squeeze extra
> performance out. These make our transition to 2.6 difficult, and
> surely we are not alone.
> 
> So 2.4 is going to be around for a while longer for us, so we might
> as well make an effort to keep the house in some sort of order. It
> serves no one to keep these fixes a secret:-)
> 
> In any case, if the patches I sent are rejected, then that's that.
> We'll see.

Folks,

The v2.4 patch acceptance policy has been shifting gradually from
"accept new features" to "critical fixes only", and at this point in
time the goal is to have a minimal amount of modifications as possible.

There should be no need for major patch reworking with reference to new
v2.4 releases.

Willy Tarreau created a repository of useful v2.4 patches for this sort
of situations. Stephen, Eugene, I think the 405GPr patches are good candidates.

http://w.ods.org/linux/kernel/2.4/lkup/hardware.html

Of course that it would be incredibly better for everyone to be happy with
v2.6. I see a lot of embedded users complaining about v2.6.

Cyclades (my former employer) has been using v2.6 in production
environments with 48MHz MPC855T PPC's with no problems at all (actually,
it is faster in certain key situations). This boxes have 128MB, which is
can be considered large, but still, no major problems have been seen in
_several_ different v2.6 versions.

Re: PPC 405GPr support in linux 2.4.32

[Stephen Williams]

Marcelo Tosatti wrote:
> Folks,
> 
> The v2.4 patch acceptance policy has been shifting gradually from
> "accept new features" to "critical fixes only", and at this point in
> time the goal is to have a minimal amount of modifications as possible.
> 
> There should be no need for major patch reworking with reference to new
> v2.4 releases.
> 
> Willy Tarreau created a repository of useful v2.4 patches for this sort
> of situations. Stephen, Eugene, I think the 405GPr patches are good candidates.
> 
> http://w.ods.org/linux/kernel/2.4/lkup/hardware.html

This (and things like it) needs to be *much* better advertised.
I had no idea it existed, or where I would look for such a thing.
It does no one any good if no one thinks to look for it;-)

If course the next major question is how does one submit patches
to this system?
-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."