Support for Arctic platform (405LP based)

Support for Arctic platform (405LP based)

[David Gibson]

The patch below adds support for IBM's Arctic-II development system,
based on the 405LP processor.  For now this is just the core support,
more drivers coming soon.  Are there any objections, or suggestions
for doing things better before I commit this to linuxppc_2_4_devel?

In particular, I'd welcome comments on the handling of the bootstrap
for Arctic:  the normal bootloader is PIBS, which is quite different
from IBM OpenBIOS, but uses the same image format.  For now I'm *not*
defining CONFIG_IBM_OPENBIOS, but duplicating the targets in the
arch/ppc/boot/simple/Makefile so that we get a treeboot image.

diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/boot/simple/Makefile linux-bartholomew/arch/ppc/boot/simple/Makefile
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/boot/simple/Makefile	2002-10-03 12:09:32.000000000 +1000
+++ linux-bartholomew/arch/ppc/boot/simple/Makefile	2002-12-12 14:32:18.000000000 +1100
@@ -19,6 +19,12 @@
 # Normally, we use the 'misc-simple.c' file for decompress_kernel and
 # whatnot.  Sometimes we need to override this however.
 MISC				:= ../common/misc-simple.o
+ifeq ($(CONFIG_ARCTIC2),y)
+ZIMAGE				:= zImage-TREE
+ZIMAGEINITRD			:= zImage.initrd-TREE
+TFTPIMAGE			:= /tftpboot/zImage.embedded
+MISC				:= misc-embedded.o
+endif
 ifeq ($(CONFIG_IBM_OPENBIOS),y)
 ZIMAGE				:= zImage-TREE
 ZIMAGEINITRD			:= zImage.initrd-TREE
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/boot/simple/embed_config.c linux-bartholomew/arch/ppc/boot/simple/embed_config.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/boot/simple/embed_config.c	2002-12-04 10:44:50.000000000 +1100
+++ linux-bartholomew/arch/ppc/boot/simple/embed_config.c	2002-12-12 14:32:27.000000000 +1100
@@ -941,6 +941,68 @@
 #endif /* CONFIG_BEECH */
 #endif /* CONFIG_IBM_OPENBIOS */

+#ifdef CONFIG_ARCTIC2
+/* Several bootloaders have been used on the Arctic.  We assume either
+ * SSX or PIBS */
+
+#define SSX_BIOS_ADDR 		0xFFFF0000
+#define SSX_BIOS_GET_BOARD_INFO 0
+#define	PIBS_BOARD_INFO_VECTOR	0xFFF62004
+
+struct ssx_bios_id {
+	unsigned int boot_branch;	/* Branch to bootcode */
+	char ssx_bios[8];		/* "SSX BIOS" (no \0) */
+	void (*bios_entry_point)(unsigned int, bd_t *); /* Call bios_entry_point(cmd, &data) */
+};
+
+extern int memcmp(const void *s1, const void *s2, size_t n);
+
+static void get_board_info(bd_t **bdp)
+{
+	struct ssx_bios_id *ssx = (struct ssx_bios_id *)SSX_BIOS_ADDR;
+
+	/* Check for SSX signature */
+
+	if (memcmp(&ssx->ssx_bios, "SSX BIOS", 8) == 0) {
+		ssx->bios_entry_point(SSX_BIOS_GET_BOARD_INFO, *bdp);
+	} else {
+		/* It's not SSX, so assume PIBS */
+		typedef void (*PFV)(bd_t *bd);
+		((PFV)(*(unsigned long *)PIBS_BOARD_INFO_VECTOR))(*bdp);
+	}
+}
+
+void embed_config(bd_t **bdp)
+{
+        *bdp = &bdinfo;
+	get_board_info(bdp);
+	/* HACK! PIBS seems to get the UART clock wrong at the moment */
+	mtdcr(DCRN_CPC0_CGCR0, (mfdcr(DCRN_CPC0_CGCR0) & ~0x003e0000) | 0x00160000);
+#if 0
+	/* Enable RefClk/4 mode for both UARTs */
+	mtdcr(DCRN_CPC0_CR0, mfdcr(DCRN_CPC0_CR0) | 0x30000000);
+#endif
+}
+
+#endif
+
+#ifdef CONFIG_BEECH
+static void
+get_board_info(bd_t **bdp)
+{
+	typedef void (*PFV)(bd_t *bd);
+	((PFV)(*(unsigned long *)BOARD_INFO_VECTOR))(*bdp);
+	return;
+}
+
+void
+embed_config(bd_t **bdp)
+{
+        *bdp = &bdinfo;
+	get_board_info(bdp);
+}
+#endif
+
 #ifdef CONFIG_EP405
 #include <linux/serial_reg.h>

diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/config.in linux-bartholomew/arch/ppc/config.in
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/config.in	2002-10-03 12:09:32.000000000 +1000
+++ linux-bartholomew/arch/ppc/config.in	2002-12-11 16:17:18.000000000 +1100
@@ -73,7 +73,8 @@

 if [ "$CONFIG_40x" = "y" ]; then
     choice 'Machine Type'			\
-	"Ash		CONFIG_ASH		\
+	"Arctic-II	CONFIG_ARCTIC2		\
+	 Ash		CONFIG_ASH		\
 	 Ceder		CONFIG_CEDER		\
 	 Beech		CONFIG_BEECH		\
 	 CPCI405	CONFIG_CPCI405 		\
@@ -309,10 +310,14 @@
     define_bool CONFIG_IBM405_ERR77 y
     define_bool CONFIG_IBM_OCP y
   fi
+  if [ "$CONFIG_ARCTIC2" = "y" ]; then
+    define_bool CONFIG_405LP y
+    define_bool CONFIG_IBM405_ERR77 y
+    define_bool CONFIG_IBM_OCP y
+  fi
   if [ "$CONFIG_SYCAMORE" = "y" ]; then
     define_bool CONFIG_405GPR y
     define_bool CONFIG_BIOS_FIXUP y
-    define_bool CONFIG_IBM_OPENBIOS y
     define_bool CONFIG_IBM405_ERR77 y
     define_bool CONFIG_IBM_OCP y
   fi
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/Makefile linux-bartholomew/arch/ppc/platforms/Makefile
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/Makefile	2002-08-08 15:04:56.000000000 +1000
+++ linux-bartholomew/arch/ppc/platforms/Makefile	2002-12-11 16:00:06.000000000 +1100
@@ -40,6 +40,7 @@
 obj-$(CONFIG_RAINIER)		+= rainier.o ibmnp4gs.o
 obj-$(CONFIG_APUS)		+= apus_setup.o
 obj-$(CONFIG_BEECH)		+= beech.o ibm405lp.o
+obj-$(CONFIG_ARCTIC2)		+= arctic2.o subzero.o ibm405lp.o
 obj-$(CONFIG_SYCAMORE)		+= sycamore.o ibm405gpr.o

 obj-$(CONFIG_EBONY)		+= ebony.o ibm440gp.o
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.c linux-bartholomew/arch/ppc/platforms/arctic2.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.c	Thu Jan 01 10:00:00 1970
+++ linux-bartholomew/arch/ppc/platforms/arctic2.c	Thu Dec 12 17:14:44 2002
@@ -0,0 +1,113 @@
+/*
+ * arch/ppc/platforms/arctic2.c  Platform setup for the IBM Arctic-2 reference platform
+ *					with the Subzero core card and Beech personality card
+ * 				      Based on beech.c by Bishop Brock
+ *
+ * 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Copyright (C) 2002, International Business Machines Corporation
+ * All Rights Reserved.
+ *
+ * Ken Inoue
+ * IBM Thomas J. Watson Research Center
+ * keninoue@us.ibm.com
+ *
+ * David Gibson
+ * IBM Ozlabs, Canberra, Australia
+ * arctic@gibson.dropbear.id.au
+ */
+
+#include <linux/blk.h>
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/param.h>
+#include <linux/rtc.h>
+#include <linux/string.h>
+
+#include <asm/delay.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/page.h>
+#include <asm/processor.h>
+#include <asm/system.h>
+#include <asm/time.h>
+
+#include <platforms/arctic2.h>
+
+void __init
+board_setup_arch(void)
+{
+}
+
+/* All Arctic-2 core physical memory resources are direct-mapped at boot time.
+*  Need to change that. */
+
+void __init
+board_io_mapping(void)
+{
+	/* FIXME: yuck.  Need to get rid of these */
+	io_block_mapping(ARCTIC2_FPGA8_VADDR, ARCTIC2_FPGA8_PADDR,
+			 ARCTIC2_FPGA8_SIZE, _PAGE_IO);
+	io_block_mapping(ARCTIC2_FPGA16_VADDR, ARCTIC2_FPGA16_PADDR,
+			 ARCTIC2_FPGA16_SIZE, _PAGE_IO);
+	io_block_mapping(SUBZERO_BEECH_PCMCIA_VADDR, SUBZERO_BEECH_PCMCIA_PADDR,
+			 SUBZERO_BEECH_PCMCIA_SIZE, _PAGE_IO);
+}
+
+void __init
+board_setup_irq(void)
+{
+}
+
+void __init
+board_init(void)
+{
+#ifdef CONFIG_PPC_RTC
+	ppc_md.time_init = ibm405lp_time_init;
+	ppc_md.set_rtc_time = ibm405lp_set_rtc_time;
+	ppc_md.get_rtc_time = ibm405lp_get_rtc_time;
+#endif
+
+	/* Set up the EBC, then Disable the LCD controller, which may have been
+	   left on by the BIOS. */
+
+	subzero_core_ebc_setup();
+
+	/* Configure the Arctic-II specific EBC banks */
+
+	/* Bank 1: 16-bit FPGA peripherals (ethernet data, SDIO, USB, DOC)
+	 * 1MB, RW, 16-bit at 0xf1000000-0xf10fffff */
+	/* The access parameters are programmed assuming a 33Mhz EBC
+	   clock, which is true for nearly all the operating points we
+	   have defined:
+	   	BME=0, TWT=5, CSN=0, OEN=1, WBN=1, WBF=1 TH=4
+		RE=1, SOR=0, BEM=0, PEN=0
+	 */
+	mtdcri(DCRN_EBC0, BnAP(1), 0x02815900);
+	mtdcri(DCRN_EBC0, BnCR(1), ARCTIC2_FPGA16_PADDR | 0x1a000);
+
+	/* Bank 2: 8-bit FPGA peripherals (switch/control, ethernet regs, TCPA)
+	 * 1MB, RW, 8-bit at 0xf8000000-0xf80fffff */
+	mtdcri(DCRN_EBC0, BnAP(2), 0x02815580);
+	mtdcri(DCRN_EBC0, BnCR(2), ARCTIC2_FPGA8_PADDR | 0x18000);
+
+	mtdcri(DCRN_LCD0, DER, 0);
+}
+
+/*
+ * Local variables:
+ * c-basic-offset: 8
+ * End: */
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.h linux-bartholomew/arch/ppc/platforms/arctic2.h
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.h	Thu Jan 01 10:00:00 1970
+++ linux-bartholomew/arch/ppc/platforms/arctic2.h	Thu Dec 12 16:52:42 2002
@@ -0,0 +1,63 @@
+/*
+ * arch/ppc/platforms/arctic2.h   Platform definitions for the IBM Arctic-II
+ *				based on beech.h by Bishop Brock
+ *
+ * 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Copyright (C) 2002, International Business Machines Corporation
+ * All Rights Reserved.
+ *
+ * Ken Inoue
+ * IBM Thomas J. Watson Research Center
+ * keninoue@us.ibm.com
+ *
+ * David Gibson
+ * IBM Ozlabs, Canberra, Australia
+ * arctic@gibson.dropbear.id.au
+ *
+ */
+
+#ifdef __KERNEL__
+#ifndef __ASM_ARCTIC2_H__
+#define __ASM_ARCTIC2_H__
+
+#include <platforms/subzero.h>
+
+#ifndef __ASSEMBLY__
+
+#define ARCTIC2_FPGA8_PADDR	(0xf8000000)
+#define ARCTIC2_FPGA8_VADDR	ARCTIC2_FPGA8_PADDR
+#define ARCTIC2_FPGA8_SIZE	(768*1024)
+
+#define ARCTIC2_FPGA16_PADDR	(0xf9000000)
+#define ARCTIC2_FPGA16_VADDR	ARCTIC2_FPGA16_PADDR
+#define ARCTIC2_FPGA16_SIZE	(1024*1024)
+
+/* Arctic II uses the internal clock for UART. Note that the OPB
+   frequency must be more than 2x the UART clock frequency. At OPB
+   frequencies less than this the serial port will not function due to
+   the way that SerClk is sampled.  We use 11.1111MHz as the frequency
+   because it can be generated from a wide range of OPB frequencies we
+   want to use. */
+
+#define PPC4xx_SERCLK_FREQ 11111111
+
+#define BASE_BAUD (PPC4xx_SERCLK_FREQ / 16)
+
+#define PPC4xx_MACHINE_NAME	"IBM Arctic II"
+
+#endif /* !__ASSEMBLY__ */
+#endif /* __ASM_ARCTIC2_H__ */
+#endif /* __KERNEL__ */
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/subzero.c linux-bartholomew/arch/ppc/platforms/subzero.c
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/subzero.c	Thu Jan 01 10:00:00 1970
+++ linux-bartholomew/arch/ppc/platforms/subzero.c	Thu Dec 12 14:57:18 2002
@@ -0,0 +1,96 @@
+/*
+ * arch/ppc/platforms/subzero.c  Platform setup for the IBM Subzero CPU core card.
+ *
+ *				Based on arctic1.c by Ken Inoue, which
+ *				was based on beech.c by Bishop Brock
+ *
+ * The source code contained herein is licensed under the IBM Public License
+ * Version 1.0, which has been approved by the Open Source Initiative.
+ * Copyright (C) 2002, International Business Machines Corporation
+ * All Rights Reserved.
+ *
+ * David Gibson
+ * IBM OzLabs, Canberra, Australia
+ * <dwg@au1.ibm.com>
+ */
+
+#include <linux/blk.h>
+#include <linux/config.h>
+#include <linux/init.h>
+#include <linux/module.h>
+#include <linux/param.h>
+#include <linux/rtc.h>
+#include <linux/string.h>
+
+#include <asm/delay.h>
+#include <asm/io.h>
+#include <asm/machdep.h>
+#include <asm/page.h>
+#include <asm/processor.h>
+#include <asm/system.h>
+#include <asm/time.h>
+
+/*
+   Subzero core card physical memory map:
+
+   Main Memory (Initialized by the BIOS)
+   =======================================================================
+
+   SDRAM (32 MB)     0x00000000 - 0x02000000
+
+   OPB Space: (Mapped virtual = physical in ppc4xx_setup.c)
+   =======================================================================
+
+   UART0               	      0xEF600300
+   UART1               	      0xEF600400
+   IIC                 	      0xEF600500
+   OPB Arbiter         	      0xEF600600
+   GPIO Controller     	      0xEF600700
+   CODEC Interface            0xEF600900
+   Touch Panel Controller     0xEF600A00
+   DES Controller             0xEF600B00
+
+
+   EBC Space: (Mapped virtual = physical in board_io_mapping())
+	      (EBC setup for personality cards left to individual card setups)
+   Space             EBC Bank    Physical Addresses  EBC Base Address
+   =========================================================================
+   Boot/Linux Flash      0       FF000000 - FFFFFFFF  FF000000 (16MB)
+
+*/
+
+
+/****************************************************************************
+ * EBC Setup
+ ****************************************************************************/
+
+/* The EBC is set up for Arctic1.  This may simply replicate the setup already
+   done by the IBM BIOS for Arctic1 (possibly with some address map changes), or
+   may be the first initialization if the board is booting from another BIOS.
+   Virtually all that is required to boot Linux on Subzero is that the BIOS
+   enable the memory controller, load a Linux image from flash, and run it.
+
+   For optimal dynamic frequency scaling the EBC settings will also vary as the
+   frequency varies.
+*/
+
+void __init
+subzero_core_ebc_setup(void)
+{
+	ebc0_bnap_t ap;
+
+	/* Set EBC bank 0 for the boot/data flash.
+
+	   Access parameters assume 150ns Intel flash @ 66.66 MHz maximum bus
+	   speed = 10 cycle access with 2 turnaround cycles (30 ns).
+
+	   NB: IBM BIOS sets this bank to burst, however bursting will never
+	   happen in Linux because this region is mapped non-cacheable and
+	   guarded, so it is set non-burst here. */
+	ap.reg = mfdcri(DCRN_EBC0, BnAP(0)) & EBC0_BnAP_MASK;
+	ap.fields.twt = 10;
+	ap.fields.th = 2;
+	mtdcri(DCRN_EBC0, BnAP(0), ap.reg);
+
+}
+
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/subzero.h linux-bartholomew/arch/ppc/platforms/subzero.h
--- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/subzero.h	Thu Jan 01 10:00:00 1970
+++ linux-bartholomew/arch/ppc/platforms/subzero.h	Thu Dec 12 15:22:30 2002
@@ -0,0 +1,114 @@
+/*
+ * arch/ppc/platforms/subzero.h   Platform definitions for the IBM
+ *				Subzero card, based on beech.h by Bishop Brock
+ *
+ * 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 program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ *
+ * Copyright (C) 2002, International Business Machines Corporation
+ * All Rights Reserved.
+ *
+ * David Gibson
+ * IBM OzLabs, Canberra, Australia
+ * <arctic@gibson.dropbear.id.au>
+ *
+ * Ken Inoue
+ * IBM Thomas J. Watson Research Center
+ * <keninoue@us.ibm.com>
+ *
+ */
+
+#ifdef __KERNEL__
+#ifndef __ASM_SUBZERO_CORE_H__
+#define __ASM_SUBZERO_CORE_H__
+
+#include <platforms/ibm405lp.h>
+
+#ifndef __ASSEMBLY__
+
+#include <linux/types.h>
+
+/*
+ * Data structure defining board information maintained by the standard boot
+ * ROM on the IBM Subzero card. An effort has been made to
+ * keep the field names consistent with the 8xx 'bd_t' board info
+ * structures.
+ *
+ * Original Beech BIOS Definition:
+ *
+ * typedef struct board_cfg_data {
+ *    unsigned char     usr_config_ver[4];
+ *    unsigned long     timerclk_freq;
+ *    unsigned char     rom_sw_ver[30];
+ *    unsigned int      mem_size;
+ *    unsigned long     sysclock_period;
+ *    unsigned long     sys_speed;
+ *    unsigned long     cpu_speed;
+ *    unsigned long     vco_speed;
+ *    unsigned long     plb_speed;
+ *    unsigned long     opb_speed;
+ *    unsigned long     ebc_speed;
+ *  } bd_t;
+ */
+
+typedef struct board_info {
+	unsigned char     bi_s_version[4];  /* Version of this structure */
+	unsigned long     bi_tbfreq;        /* Frequency of SysTmrClk */
+	unsigned char     bi_r_version[30]; /* Version of the IBM ROM */
+	unsigned int      bi_memsize;       /* DRAM installed, in bytes */
+	unsigned long     sysclock_period;  /* SysClk period in ns */
+	unsigned long     sys_speed;        /* SysCLk frequency in Hz */
+	unsigned long     bi_intfreq;       /* Processor speed, in Hz */
+	unsigned long     vco_speed;        /* PLL VCO speed, in Hz */
+	unsigned long     bi_busfreq;       /* PLB Bus speed, in Hz */
+	unsigned long     opb_speed;        /* OPB Bus speed, in Hz */
+	unsigned long     ebc_speed;        /* EBC Bus speed, in Hz */
+
+} bd_t;
+
+/* EBC Bank 0 controls the boot flash
+ *
+ * FIXME? these values assume that there is 16MB of flash on the
+ * personality card, in addition to the 16MB on the subzero card
+ * itself */
+#define SUBZERO_BANK0_PADDR      ((uint)0xfe000000)
+#define SUBZERO_BANK0_EBC_SIZE   EBC0_BnCR_BS_32MB
+
+#define SUBZERO_BOOTFLASH_PADDR  (SUBZERO_BANK0_PADDR)
+#define SUBZERO_BOOTFLASH_SIZE   ((uint)(32 * 1024 * 1024))
+
+/* The PCMCIA controller driver 4xx_pccf.c is responsible for the EBC setup of
+   PCMCIA.  Externally, EBC bank selects 3..7 take on PCMCIA functions when
+   PCMCIA is enabled. */
+
+#define SUBZERO_BEECH_PCMCIA_PADDR     ((uint)0xf0000000)
+#define SUBZERO_BEECH_PCMCIA_VADDR     SUBZERO_BEECH_PCMCIA_PADDR
+#define SUBZERO_BEECH_PCMCIA_SIZE      ((uint)(32 * 1024 * 1024))
+
+#define SUBZERO_BEECH_PCMCIA_IO_BASE (SUBZERO_BEECH_PCMCIA_VADDR + 0x01800000)
+
+/* Define _IO_BASE for PCMCIA; other defines are required as well. */
+
+#define _IO_BASE SUBZERO_BEECH_PCMCIA_IO_BASE
+#define _ISA_MEM_BASE 0
+#define PCI_DRAM_OFFSET 0
+
+void *beech_sram_alloc(size_t size);
+int beech_sram_free(void *p);
+
+void subzero_core_ebc_setup(void);
+
+#endif /* !__ASSEMBLY__ */
+#endif /* __ASM_SUBZERO_CORE_H__ */
+#endif /* __KERNEL__ */
diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/include/asm-ppc/ibm4xx.h linux-bartholomew/include/asm-ppc/ibm4xx.h
--- /home/dgibson/kernel/linuxppc_2_4_devel/include/asm-ppc/ibm4xx.h	2002-08-05 10:37:17.000000000 +1000
+++ linux-bartholomew/include/asm-ppc/ibm4xx.h	2002-12-12 15:50:48.000000000 +1100
@@ -109,6 +109,10 @@
 #include <platforms/beech.h>
 #endif

+#if defined(CONFIG_ARCTIC2)
+#include <platforms/arctic2.h>
+#endif
+
 #if defined(CONFIG_SYCAMORE)
 #include <platforms/sycamore.h>
 #endif


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

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

Re: Support for Arctic platform (405LP based)

[Cort Dougan]

Would you be able to commit them to _2_4 instead so they're not in the
wildly divergent _2_4_devel tree?  That would definitely be handy when
trying to find where the working trees are.

} The patch below adds support for IBM's Arctic-II development system,
} based on the 405LP processor.  For now this is just the core support,
} more drivers coming soon.  Are there any objections, or suggestions
} for doing things better before I commit this to linuxppc_2_4_devel?
}
} In particular, I'd welcome comments on the handling of the bootstrap
} for Arctic:  the normal bootloader is PIBS, which is quite different
} from IBM OpenBIOS, but uses the same image format.  For now I'm *not*
} defining CONFIG_IBM_OPENBIOS, but duplicating the targets in the
} arch/ppc/boot/simple/Makefile so that we get a treeboot image.
}
} diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/boot/simple/Makefile linux-bartholomew/arch/ppc/boot/simple/Makefile
} --- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/boot/simple/Makefile	2002-10-03 12:09:32.000000000 +1000
} +++ linux-bartholomew/arch/ppc/boot/simple/Makefile	2002-12-12 14:32:18.000000000 +1100
} @@ -19,6 +19,12 @@
}  # Normally, we use the 'misc-simple.c' file for decompress_kernel and
}  # whatnot.  Sometimes we need to override this however.
}  MISC				:= ../common/misc-simple.o
} +ifeq ($(CONFIG_ARCTIC2),y)
} +ZIMAGE				:= zImage-TREE
} +ZIMAGEINITRD			:= zImage.initrd-TREE
} +TFTPIMAGE			:= /tftpboot/zImage.embedded
} +MISC				:= misc-embedded.o
} +endif
}  ifeq ($(CONFIG_IBM_OPENBIOS),y)
}  ZIMAGE				:= zImage-TREE
}  ZIMAGEINITRD			:= zImage.initrd-TREE
} diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/boot/simple/embed_config.c linux-bartholomew/arch/ppc/boot/simple/embed_config.c
} --- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/boot/simple/embed_config.c	2002-12-04 10:44:50.000000000 +1100
} +++ linux-bartholomew/arch/ppc/boot/simple/embed_config.c	2002-12-12 14:32:27.000000000 +1100
} @@ -941,6 +941,68 @@
}  #endif /* CONFIG_BEECH */
}  #endif /* CONFIG_IBM_OPENBIOS */
}
} +#ifdef CONFIG_ARCTIC2
} +/* Several bootloaders have been used on the Arctic.  We assume either
} + * SSX or PIBS */
} +
} +#define SSX_BIOS_ADDR 		0xFFFF0000
} +#define SSX_BIOS_GET_BOARD_INFO 0
} +#define	PIBS_BOARD_INFO_VECTOR	0xFFF62004
} +
} +struct ssx_bios_id {
} +	unsigned int boot_branch;	/* Branch to bootcode */
} +	char ssx_bios[8];		/* "SSX BIOS" (no \0) */
} +	void (*bios_entry_point)(unsigned int, bd_t *); /* Call bios_entry_point(cmd, &data) */
} +};
} +
} +extern int memcmp(const void *s1, const void *s2, size_t n);
} +
} +static void get_board_info(bd_t **bdp)
} +{
} +	struct ssx_bios_id *ssx = (struct ssx_bios_id *)SSX_BIOS_ADDR;
} +
} +	/* Check for SSX signature */
} +
} +	if (memcmp(&ssx->ssx_bios, "SSX BIOS", 8) == 0) {
} +		ssx->bios_entry_point(SSX_BIOS_GET_BOARD_INFO, *bdp);
} +	} else {
} +		/* It's not SSX, so assume PIBS */
} +		typedef void (*PFV)(bd_t *bd);
} +		((PFV)(*(unsigned long *)PIBS_BOARD_INFO_VECTOR))(*bdp);
} +	}
} +}
} +
} +void embed_config(bd_t **bdp)
} +{
} +        *bdp = &bdinfo;
} +	get_board_info(bdp);
} +	/* HACK! PIBS seems to get the UART clock wrong at the moment */
} +	mtdcr(DCRN_CPC0_CGCR0, (mfdcr(DCRN_CPC0_CGCR0) & ~0x003e0000) | 0x00160000);
} +#if 0
} +	/* Enable RefClk/4 mode for both UARTs */
} +	mtdcr(DCRN_CPC0_CR0, mfdcr(DCRN_CPC0_CR0) | 0x30000000);
} +#endif
} +}
} +
} +#endif
} +
} +#ifdef CONFIG_BEECH
} +static void
} +get_board_info(bd_t **bdp)
} +{
} +	typedef void (*PFV)(bd_t *bd);
} +	((PFV)(*(unsigned long *)BOARD_INFO_VECTOR))(*bdp);
} +	return;
} +}
} +
} +void
} +embed_config(bd_t **bdp)
} +{
} +        *bdp = &bdinfo;
} +	get_board_info(bdp);
} +}
} +#endif
} +
}  #ifdef CONFIG_EP405
}  #include <linux/serial_reg.h>
}
} diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/config.in linux-bartholomew/arch/ppc/config.in
} --- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/config.in	2002-10-03 12:09:32.000000000 +1000
} +++ linux-bartholomew/arch/ppc/config.in	2002-12-11 16:17:18.000000000 +1100
} @@ -73,7 +73,8 @@
}
}  if [ "$CONFIG_40x" = "y" ]; then
}      choice 'Machine Type'			\
} -	"Ash		CONFIG_ASH		\
} +	"Arctic-II	CONFIG_ARCTIC2		\
} +	 Ash		CONFIG_ASH		\
}  	 Ceder		CONFIG_CEDER		\
}  	 Beech		CONFIG_BEECH		\
}  	 CPCI405	CONFIG_CPCI405 		\
} @@ -309,10 +310,14 @@
}      define_bool CONFIG_IBM405_ERR77 y
}      define_bool CONFIG_IBM_OCP y
}    fi
} +  if [ "$CONFIG_ARCTIC2" = "y" ]; then
} +    define_bool CONFIG_405LP y
} +    define_bool CONFIG_IBM405_ERR77 y
} +    define_bool CONFIG_IBM_OCP y
} +  fi
}    if [ "$CONFIG_SYCAMORE" = "y" ]; then
}      define_bool CONFIG_405GPR y
}      define_bool CONFIG_BIOS_FIXUP y
} -    define_bool CONFIG_IBM_OPENBIOS y
}      define_bool CONFIG_IBM405_ERR77 y
}      define_bool CONFIG_IBM_OCP y
}    fi
} diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/Makefile linux-bartholomew/arch/ppc/platforms/Makefile
} --- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/Makefile	2002-08-08 15:04:56.000000000 +1000
} +++ linux-bartholomew/arch/ppc/platforms/Makefile	2002-12-11 16:00:06.000000000 +1100
} @@ -40,6 +40,7 @@
}  obj-$(CONFIG_RAINIER)		+= rainier.o ibmnp4gs.o
}  obj-$(CONFIG_APUS)		+= apus_setup.o
}  obj-$(CONFIG_BEECH)		+= beech.o ibm405lp.o
} +obj-$(CONFIG_ARCTIC2)		+= arctic2.o subzero.o ibm405lp.o
}  obj-$(CONFIG_SYCAMORE)		+= sycamore.o ibm405gpr.o
}
}  obj-$(CONFIG_EBONY)		+= ebony.o ibm440gp.o
} diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.c linux-bartholomew/arch/ppc/platforms/arctic2.c
} --- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.c	Thu Jan 01 10:00:00 1970
} +++ linux-bartholomew/arch/ppc/platforms/arctic2.c	Thu Dec 12 17:14:44 2002
} @@ -0,0 +1,113 @@
} +/*
} + * arch/ppc/platforms/arctic2.c  Platform setup for the IBM Arctic-2 reference platform
} + *					with the Subzero core card and Beech personality card
} + * 				      Based on beech.c by Bishop Brock
} + *
} + * 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 program is distributed in the hope that it will be useful,
} + * but WITHOUT ANY WARRANTY; without even the implied warranty of
} + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
} + * GNU General Public License for more details.
} + *
} + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
} + *
} + * Copyright (C) 2002, International Business Machines Corporation
} + * All Rights Reserved.
} + *
} + * Ken Inoue
} + * IBM Thomas J. Watson Research Center
} + * keninoue@us.ibm.com
} + *
} + * David Gibson
} + * IBM Ozlabs, Canberra, Australia
} + * arctic@gibson.dropbear.id.au
} + */
} +
} +#include <linux/blk.h>
} +#include <linux/config.h>
} +#include <linux/init.h>
} +#include <linux/module.h>
} +#include <linux/param.h>
} +#include <linux/rtc.h>
} +#include <linux/string.h>
} +
} +#include <asm/delay.h>
} +#include <asm/io.h>
} +#include <asm/machdep.h>
} +#include <asm/page.h>
} +#include <asm/processor.h>
} +#include <asm/system.h>
} +#include <asm/time.h>
} +
} +#include <platforms/arctic2.h>
} +
} +void __init
} +board_setup_arch(void)
} +{
} +}
} +
} +/* All Arctic-2 core physical memory resources are direct-mapped at boot time.
} +*  Need to change that. */
} +
} +void __init
} +board_io_mapping(void)
} +{
} +	/* FIXME: yuck.  Need to get rid of these */
} +	io_block_mapping(ARCTIC2_FPGA8_VADDR, ARCTIC2_FPGA8_PADDR,
} +			 ARCTIC2_FPGA8_SIZE, _PAGE_IO);
} +	io_block_mapping(ARCTIC2_FPGA16_VADDR, ARCTIC2_FPGA16_PADDR,
} +			 ARCTIC2_FPGA16_SIZE, _PAGE_IO);
} +	io_block_mapping(SUBZERO_BEECH_PCMCIA_VADDR, SUBZERO_BEECH_PCMCIA_PADDR,
} +			 SUBZERO_BEECH_PCMCIA_SIZE, _PAGE_IO);
} +}
} +
} +void __init
} +board_setup_irq(void)
} +{
} +}
} +
} +void __init
} +board_init(void)
} +{
} +#ifdef CONFIG_PPC_RTC
} +	ppc_md.time_init = ibm405lp_time_init;
} +	ppc_md.set_rtc_time = ibm405lp_set_rtc_time;
} +	ppc_md.get_rtc_time = ibm405lp_get_rtc_time;
} +#endif
} +
} +	/* Set up the EBC, then Disable the LCD controller, which may have been
} +	   left on by the BIOS. */
} +
} +	subzero_core_ebc_setup();
} +
} +	/* Configure the Arctic-II specific EBC banks */
} +
} +	/* Bank 1: 16-bit FPGA peripherals (ethernet data, SDIO, USB, DOC)
} +	 * 1MB, RW, 16-bit at 0xf1000000-0xf10fffff */
} +	/* The access parameters are programmed assuming a 33Mhz EBC
} +	   clock, which is true for nearly all the operating points we
} +	   have defined:
} +	   	BME=0, TWT=5, CSN=0, OEN=1, WBN=1, WBF=1 TH=4
} +		RE=1, SOR=0, BEM=0, PEN=0
} +	 */
} +	mtdcri(DCRN_EBC0, BnAP(1), 0x02815900);
} +	mtdcri(DCRN_EBC0, BnCR(1), ARCTIC2_FPGA16_PADDR | 0x1a000);
} +
} +	/* Bank 2: 8-bit FPGA peripherals (switch/control, ethernet regs, TCPA)
} +	 * 1MB, RW, 8-bit at 0xf8000000-0xf80fffff */
} +	mtdcri(DCRN_EBC0, BnAP(2), 0x02815580);
} +	mtdcri(DCRN_EBC0, BnCR(2), ARCTIC2_FPGA8_PADDR | 0x18000);
} +
} +	mtdcri(DCRN_LCD0, DER, 0);
} +}
} +
} +/*
} + * Local variables:
} + * c-basic-offset: 8
} + * End: */
} diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.h linux-bartholomew/arch/ppc/platforms/arctic2.h
} --- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/arctic2.h	Thu Jan 01 10:00:00 1970
} +++ linux-bartholomew/arch/ppc/platforms/arctic2.h	Thu Dec 12 16:52:42 2002
} @@ -0,0 +1,63 @@
} +/*
} + * arch/ppc/platforms/arctic2.h   Platform definitions for the IBM Arctic-II
} + *				based on beech.h by Bishop Brock
} + *
} + * 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 program is distributed in the hope that it will be useful,
} + * but WITHOUT ANY WARRANTY; without even the implied warranty of
} + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
} + * GNU General Public License for more details.
} + *
} + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
} + *
} + * Copyright (C) 2002, International Business Machines Corporation
} + * All Rights Reserved.
} + *
} + * Ken Inoue
} + * IBM Thomas J. Watson Research Center
} + * keninoue@us.ibm.com
} + *
} + * David Gibson
} + * IBM Ozlabs, Canberra, Australia
} + * arctic@gibson.dropbear.id.au
} + *
} + */
} +
} +#ifdef __KERNEL__
} +#ifndef __ASM_ARCTIC2_H__
} +#define __ASM_ARCTIC2_H__
} +
} +#include <platforms/subzero.h>
} +
} +#ifndef __ASSEMBLY__
} +
} +#define ARCTIC2_FPGA8_PADDR	(0xf8000000)
} +#define ARCTIC2_FPGA8_VADDR	ARCTIC2_FPGA8_PADDR
} +#define ARCTIC2_FPGA8_SIZE	(768*1024)
} +
} +#define ARCTIC2_FPGA16_PADDR	(0xf9000000)
} +#define ARCTIC2_FPGA16_VADDR	ARCTIC2_FPGA16_PADDR
} +#define ARCTIC2_FPGA16_SIZE	(1024*1024)
} +
} +/* Arctic II uses the internal clock for UART. Note that the OPB
} +   frequency must be more than 2x the UART clock frequency. At OPB
} +   frequencies less than this the serial port will not function due to
} +   the way that SerClk is sampled.  We use 11.1111MHz as the frequency
} +   because it can be generated from a wide range of OPB frequencies we
} +   want to use. */
} +
} +#define PPC4xx_SERCLK_FREQ 11111111
} +
} +#define BASE_BAUD (PPC4xx_SERCLK_FREQ / 16)
} +
} +#define PPC4xx_MACHINE_NAME	"IBM Arctic II"
} +
} +#endif /* !__ASSEMBLY__ */
} +#endif /* __ASM_ARCTIC2_H__ */
} +#endif /* __KERNEL__ */
} diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/subzero.c linux-bartholomew/arch/ppc/platforms/subzero.c
} --- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/subzero.c	Thu Jan 01 10:00:00 1970
} +++ linux-bartholomew/arch/ppc/platforms/subzero.c	Thu Dec 12 14:57:18 2002
} @@ -0,0 +1,96 @@
} +/*
} + * arch/ppc/platforms/subzero.c  Platform setup for the IBM Subzero CPU core card.
} + *
} + *				Based on arctic1.c by Ken Inoue, which
} + *				was based on beech.c by Bishop Brock
} + *
} + * The source code contained herein is licensed under the IBM Public License
} + * Version 1.0, which has been approved by the Open Source Initiative.
} + * Copyright (C) 2002, International Business Machines Corporation
} + * All Rights Reserved.
} + *
} + * David Gibson
} + * IBM OzLabs, Canberra, Australia
} + * <dwg@au1.ibm.com>
} + */
} +
} +#include <linux/blk.h>
} +#include <linux/config.h>
} +#include <linux/init.h>
} +#include <linux/module.h>
} +#include <linux/param.h>
} +#include <linux/rtc.h>
} +#include <linux/string.h>
} +
} +#include <asm/delay.h>
} +#include <asm/io.h>
} +#include <asm/machdep.h>
} +#include <asm/page.h>
} +#include <asm/processor.h>
} +#include <asm/system.h>
} +#include <asm/time.h>
} +
} +/*
} +   Subzero core card physical memory map:
} +
} +   Main Memory (Initialized by the BIOS)
} +   =======================================================================
} +
} +   SDRAM (32 MB)     0x00000000 - 0x02000000
} +
} +   OPB Space: (Mapped virtual = physical in ppc4xx_setup.c)
} +   =======================================================================
} +
} +   UART0               	      0xEF600300
} +   UART1               	      0xEF600400
} +   IIC                 	      0xEF600500
} +   OPB Arbiter         	      0xEF600600
} +   GPIO Controller     	      0xEF600700
} +   CODEC Interface            0xEF600900
} +   Touch Panel Controller     0xEF600A00
} +   DES Controller             0xEF600B00
} +
} +
} +   EBC Space: (Mapped virtual = physical in board_io_mapping())
} +	      (EBC setup for personality cards left to individual card setups)
} +   Space             EBC Bank    Physical Addresses  EBC Base Address
} +   =========================================================================
} +   Boot/Linux Flash      0       FF000000 - FFFFFFFF  FF000000 (16MB)
} +
} +*/
} +
} +
} +/****************************************************************************
} + * EBC Setup
} + ****************************************************************************/
} +
} +/* The EBC is set up for Arctic1.  This may simply replicate the setup already
} +   done by the IBM BIOS for Arctic1 (possibly with some address map changes), or
} +   may be the first initialization if the board is booting from another BIOS.
} +   Virtually all that is required to boot Linux on Subzero is that the BIOS
} +   enable the memory controller, load a Linux image from flash, and run it.
} +
} +   For optimal dynamic frequency scaling the EBC settings will also vary as the
} +   frequency varies.
} +*/
} +
} +void __init
} +subzero_core_ebc_setup(void)
} +{
} +	ebc0_bnap_t ap;
} +
} +	/* Set EBC bank 0 for the boot/data flash.
} +
} +	   Access parameters assume 150ns Intel flash @ 66.66 MHz maximum bus
} +	   speed = 10 cycle access with 2 turnaround cycles (30 ns).
} +
} +	   NB: IBM BIOS sets this bank to burst, however bursting will never
} +	   happen in Linux because this region is mapped non-cacheable and
} +	   guarded, so it is set non-burst here. */
} +	ap.reg = mfdcri(DCRN_EBC0, BnAP(0)) & EBC0_BnAP_MASK;
} +	ap.fields.twt = 10;
} +	ap.fields.th = 2;
} +	mtdcri(DCRN_EBC0, BnAP(0), ap.reg);
} +
} +}
} +
} diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/subzero.h linux-bartholomew/arch/ppc/platforms/subzero.h
} --- /home/dgibson/kernel/linuxppc_2_4_devel/arch/ppc/platforms/subzero.h	Thu Jan 01 10:00:00 1970
} +++ linux-bartholomew/arch/ppc/platforms/subzero.h	Thu Dec 12 15:22:30 2002
} @@ -0,0 +1,114 @@
} +/*
} + * arch/ppc/platforms/subzero.h   Platform definitions for the IBM
} + *				Subzero card, based on beech.h by Bishop Brock
} + *
} + * 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 program is distributed in the hope that it will be useful,
} + * but WITHOUT ANY WARRANTY; without even the implied warranty of
} + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
} + * GNU General Public License for more details.
} + *
} + * 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., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
} + *
} + * Copyright (C) 2002, International Business Machines Corporation
} + * All Rights Reserved.
} + *
} + * David Gibson
} + * IBM OzLabs, Canberra, Australia
} + * <arctic@gibson.dropbear.id.au>
} + *
} + * Ken Inoue
} + * IBM Thomas J. Watson Research Center
} + * <keninoue@us.ibm.com>
} + *
} + */
} +
} +#ifdef __KERNEL__
} +#ifndef __ASM_SUBZERO_CORE_H__
} +#define __ASM_SUBZERO_CORE_H__
} +
} +#include <platforms/ibm405lp.h>
} +
} +#ifndef __ASSEMBLY__
} +
} +#include <linux/types.h>
} +
} +/*
} + * Data structure defining board information maintained by the standard boot
} + * ROM on the IBM Subzero card. An effort has been made to
} + * keep the field names consistent with the 8xx 'bd_t' board info
} + * structures.
} + *
} + * Original Beech BIOS Definition:
} + *
} + * typedef struct board_cfg_data {
} + *    unsigned char     usr_config_ver[4];
} + *    unsigned long     timerclk_freq;
} + *    unsigned char     rom_sw_ver[30];
} + *    unsigned int      mem_size;
} + *    unsigned long     sysclock_period;
} + *    unsigned long     sys_speed;
} + *    unsigned long     cpu_speed;
} + *    unsigned long     vco_speed;
} + *    unsigned long     plb_speed;
} + *    unsigned long     opb_speed;
} + *    unsigned long     ebc_speed;
} + *  } bd_t;
} + */
} +
} +typedef struct board_info {
} +	unsigned char     bi_s_version[4];  /* Version of this structure */
} +	unsigned long     bi_tbfreq;        /* Frequency of SysTmrClk */
} +	unsigned char     bi_r_version[30]; /* Version of the IBM ROM */
} +	unsigned int      bi_memsize;       /* DRAM installed, in bytes */
} +	unsigned long     sysclock_period;  /* SysClk period in ns */
} +	unsigned long     sys_speed;        /* SysCLk frequency in Hz */
} +	unsigned long     bi_intfreq;       /* Processor speed, in Hz */
} +	unsigned long     vco_speed;        /* PLL VCO speed, in Hz */
} +	unsigned long     bi_busfreq;       /* PLB Bus speed, in Hz */
} +	unsigned long     opb_speed;        /* OPB Bus speed, in Hz */
} +	unsigned long     ebc_speed;        /* EBC Bus speed, in Hz */
} +
} +} bd_t;
} +
} +/* EBC Bank 0 controls the boot flash
} + *
} + * FIXME? these values assume that there is 16MB of flash on the
} + * personality card, in addition to the 16MB on the subzero card
} + * itself */
} +#define SUBZERO_BANK0_PADDR      ((uint)0xfe000000)
} +#define SUBZERO_BANK0_EBC_SIZE   EBC0_BnCR_BS_32MB
} +
} +#define SUBZERO_BOOTFLASH_PADDR  (SUBZERO_BANK0_PADDR)
} +#define SUBZERO_BOOTFLASH_SIZE   ((uint)(32 * 1024 * 1024))
} +
} +/* The PCMCIA controller driver 4xx_pccf.c is responsible for the EBC setup of
} +   PCMCIA.  Externally, EBC bank selects 3..7 take on PCMCIA functions when
} +   PCMCIA is enabled. */
} +
} +#define SUBZERO_BEECH_PCMCIA_PADDR     ((uint)0xf0000000)
} +#define SUBZERO_BEECH_PCMCIA_VADDR     SUBZERO_BEECH_PCMCIA_PADDR
} +#define SUBZERO_BEECH_PCMCIA_SIZE      ((uint)(32 * 1024 * 1024))
} +
} +#define SUBZERO_BEECH_PCMCIA_IO_BASE (SUBZERO_BEECH_PCMCIA_VADDR + 0x01800000)
} +
} +/* Define _IO_BASE for PCMCIA; other defines are required as well. */
} +
} +#define _IO_BASE SUBZERO_BEECH_PCMCIA_IO_BASE
} +#define _ISA_MEM_BASE 0
} +#define PCI_DRAM_OFFSET 0
} +
} +void *beech_sram_alloc(size_t size);
} +int beech_sram_free(void *p);
} +
} +void subzero_core_ebc_setup(void);
} +
} +#endif /* !__ASSEMBLY__ */
} +#endif /* __ASM_SUBZERO_CORE_H__ */
} +#endif /* __KERNEL__ */
} diff -urN /home/dgibson/kernel/linuxppc_2_4_devel/include/asm-ppc/ibm4xx.h linux-bartholomew/include/asm-ppc/ibm4xx.h
} --- /home/dgibson/kernel/linuxppc_2_4_devel/include/asm-ppc/ibm4xx.h	2002-08-05 10:37:17.000000000 +1000
} +++ linux-bartholomew/include/asm-ppc/ibm4xx.h	2002-12-12 15:50:48.000000000 +1100
} @@ -109,6 +109,10 @@
}  #include <platforms/beech.h>
}  #endif
}
} +#if defined(CONFIG_ARCTIC2)
} +#include <platforms/arctic2.h>
} +#endif
} +
}  #if defined(CONFIG_SYCAMORE)
}  #include <platforms/sycamore.h>
}  #endif
}
}
} --
} David Gibson			| For every complex problem there is a
} david@gibson.dropbear.id.au	| solution which is simple, neat and
} 				| wrong.
} http://www.ozlabs.org/people/dgibson
}

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

Re: Support for Arctic platform (405LP based)

[Gary Thomas]

On Thu, 2002-12-12 at 21:51, Cort Dougan wrote:
>
> Would you be able to commit them to _2_4 instead so they're not in the
> wildly divergent _2_4_devel tree?  That would definitely be handy when
> trying to find where the working trees are.
>
> } The patch below adds support for IBM's Arctic-II development system,
> } based on the 405LP processor.  For now this is just the core support,
> } more drivers coming soon.  Are there any objections, or suggestions
> } for doing things better before I commit this to linuxppc_2_4_devel?
> }

This brings up some really good questions.  I have support for three new
platforms based on the _2_4_devel tree which I'd like to get submitted
soon [so far, I've just been following along]  So,
 * Which tree should be best for new development/ports/etc?
 * What's the best process for proposing changes?  I've seen many
   patches come along on this list, but it's not clear to me if/when
   they made it to any particular tree.

Thanks.

--
------------------------------------------------------------
Gary Thomas                 |
MLB Associates              |  Consulting for the
+1 (970) 229-1963           |    Embedded world
http://www.mlbassoc.com/    |
email: <gary@mlbassoc.com>  |
gpg: http://www.chez-thomas.org/gary/gpg_key.asc
------------------------------------------------------------


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

Re: Support for Arctic platform (405LP based)

[Tom Rini]

On Fri, Dec 13, 2002 at 07:26:02AM -0700, Gary Thomas wrote:

> On Thu, 2002-12-12 at 21:51, Cort Dougan wrote:
> >
> > Would you be able to commit them to _2_4 instead so they're not in the
> > wildly divergent _2_4_devel tree?  That would definitely be handy when
> > trying to find where the working trees are.
> >
> > } The patch below adds support for IBM's Arctic-II development system,
> > } based on the 405LP processor.  For now this is just the core support,
> > } more drivers coming soon.  Are there any objections, or suggestions
> > } for doing things better before I commit this to linuxppc_2_4_devel?
> > }
>
> This brings up some really good questions.  I have support for three new
> platforms based on the _2_4_devel tree which I'd like to get submitted
> soon [so far, I've just been following along]  So,
>  * Which tree should be best for new development/ports/etc?

The _2_4_devel tree at the moment, since that still has generally better
infrastructure for non-pmacs :)  I would also like to see a patch
against the current linuxppc-2.5 tree as well.  It doesn't have to be as
well tested as the 2_4_devel version, and if the tree as a whole doesn't
compile at the time, make a/b/c.o is actually legal in 2.5 so just make
sure your changes still compile.

>  * What's the best process for proposing changes?  I've seen many
>    patches come along on this list, but it's not clear to me if/when
>    they made it to any particular tree.

If you aren't already on the linuxppc-commit@source.mvista.com list, you
might want to join that.  If a change makes it into any of the
linuxppc_* lists, a msg gets sent there.  If you want to propose a
change cc relevant people (generally Paul and / or myself) and send it
to the linuxppc-dev and / or linuxppc-embedded lists.  Someone will
speak up, even if it's only me to say I'm too busy today. :)

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

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

Re: Support for Arctic platform (405LP based)

[Tom Rini]

On Thu, Dec 12, 2002 at 09:51:26PM -0700, Cort Dougan wrote:

> Would you be able to commit them to _2_4 instead so they're not in the
> wildly divergent _2_4_devel tree?  That would definitely be handy when
> trying to find where the working trees are.

One of my goals for winter break is to try and make the _devel tree less
divergent, at least w.r.t. 'classic' PPCs.  I'm not sure if 4xx support
is in a stage yet that Paul is happy to move it to the _2_4 tree and
then on to Marcelo yet.

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

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

Re: Support for Arctic platform (405LP based)

[Matt Porter]

On Fri, Dec 13, 2002 at 08:18:08AM -0700, Tom Rini wrote:
>
> On Thu, Dec 12, 2002 at 09:51:26PM -0700, Cort Dougan wrote:
>
> > Would you be able to commit them to _2_4 instead so they're not in the
> > wildly divergent _2_4_devel tree?  That would definitely be handy when
> > trying to find where the working trees are.
>
> One of my goals for winter break is to try and make the _devel tree less
> divergent, at least w.r.t. 'classic' PPCs.  I'm not sure if 4xx support
> is in a stage yet that Paul is happy to move it to the _2_4 tree and
> then on to Marcelo yet.

At a minimum, the 4xx DBCR handling via thread struct would need to
be finished to make Paul happy, I believe.  Luckily, I don't need
a debugger so I've had no reason to finish the task that he left
"as an exercise for the reader".

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

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

Re: Support for Arctic platform (405LP based)

[Tom Rini]

On Fri, Dec 13, 2002 at 08:16:43AM -0700, Tom Rini wrote:

[snip]
> If you aren't already on the linuxppc-commit@source.mvista.com list, you
> might want to join that.

And since this is at a possibly non obvious location:
http://source.mvista.com/cgi-bin/mailman/listinfo/linuxppc-commit

<hint>Hopefully PenguinPPC.org will have a link to this somewhere.</hint>

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

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

Re: Support for Arctic platform (405LP based)

[Todd Poynor]

A few comments and questions...

I assume symbol CONFIG_ARCTIC2 is more appropriate than CONFIG_ARCTIC,
with additional symbols possibly to be invented in the future to
distinguish minor changes in board rev 3, 4, ... But mentioning this
just in case it might make future maintenance easier to use a single
symbol for common Arctic family code.

CONFIG_IBM_OPENBIOS is taken out of the CONFIG_SYCAMORE section of
arch/ppc/config.in?

Duplication of the CONFIG_BEECH case in
arch/ppc/boot/simple/embed_config.c: might be trying to enable the SSX
bootloader for Beech, but since CONFIG_IBM_OPENBIOS is on for Beech it
seems we'd have dup definitions?  Would more SSX code would be necessary
anyhow?

CONFIG_PPC_RTC is used to protect RTC code, most of these were
explicitly removed from other platforms some time ago, not sure what the
status of this is since there are a couple platforms that still use it.

I notice the bd_t has no entry for the ethernet MAC address in firmware,
like Beech, but am hoping there's an EEPROM on the device that holds
this info.  On Beech it causes some ugliness because the usual EEPROM is
not provided, so only the bootloader can program the ether dev's MAC.
And consequently the generic ethernet driver is hacked to deal with that.


--
Todd


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

Re: Support for Arctic platform (405LP based)

[David Gibson]

On Fri, Dec 13, 2002 at 11:25:20AM -0800, Todd Poynor wrote:
> A few comments and questions...
>
> I assume symbol CONFIG_ARCTIC2 is more appropriate than CONFIG_ARCTIC,
> with additional symbols possibly to be invented in the future to
> distinguish minor changes in board rev 3, 4, ... But mentioning this
> just in case it might make future maintenance easier to use a single
> symbol for common Arctic family code.

Well... the difference between Artic-1 and Arctic-2 is not just a
board revision - they are quite different devices, with different
peripherals on board.  So there's not much point sharing a cnofig
option for these two.  On the other hand Arctic-3 (if and when it
exists) is likely to be a relatively small revision of Arctic-2, so
we'll probably want to use the CONFIG_ARCTIC2 symbol for it as well.

> CONFIG_IBM_OPENBIOS is taken out of the CONFIG_SYCAMORE section of
> arch/ppc/config.in?

Err... I have no idea what you're asking.  How did SYCAMORE get into
this?

> Duplication of the CONFIG_BEECH case in
> arch/ppc/boot/simple/embed_config.c: might be trying to enable the SSX
> bootloader for Beech, but since CONFIG_IBM_OPENBIOS is on for Beech it
> seems we'd have dup definitions?  Would more SSX code would be necessary
> anyhow?

Again, I'm afraid I'm having trouble parsing that paragraph - what do
you want to know?

> CONFIG_PPC_RTC is used to protect RTC code, most of these were
> explicitly removed from other platforms some time ago, not sure what the
> status of this is since there are a couple platforms that still use it.
>
> I notice the bd_t has no entry for the ethernet MAC address in firmware,
> like Beech, but am hoping there's an EEPROM on the device that holds
> this info.  On Beech it causes some ugliness because the usual EEPROM is
> not provided, so only the bootloader can program the ether dev's MAC.
> And consequently the generic ethernet driver is hacked to deal with that.

The ethernet on the Artic-2 debug board (RTL8019 based - not the same
as the Beech's ethernet - driver coming soon) does indeed have an
EEPROM.

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

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

Re: Support for Arctic platform (405LP based)

[Cort Dougan]

How about killing the _2_4_devel tree?  When I created it I want it to be a
playground for stabilizing then moving things over to 2_4 failry quickly.
It seems to have become the defacto "want board X, you better use
_2_4_devel" tree.

When I went looking for a working 4xx tree recently I had to write a script
that would go through the last year of changesets in _2_4 and _2_4_devel
and try to build them then stick the result into a file.  That ran for 7
days on a 2.0Ghz Dual x86.  Then, that only gave me a list of building
trees.  Knowing that there's only 1 tree would be much easier!

I'll send you some wonderful New Mexico wine in exchange for your efforts!

} One of my goals for winter break is to try and make the _devel tree less
} divergent, at least w.r.t. 'classic' PPCs.  I'm not sure if 4xx support
} is in a stage yet that Paul is happy to move it to the _2_4 tree and
} then on to Marcelo yet.
}
} --
} Tom Rini (TR1265)
} http://gate.crashing.org/~trini/
}

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

Re: Support for Arctic platform (405LP based)

[Tom Rini]

On Sun, Dec 15, 2002 at 12:15:26PM -0700, Cort Dougan wrote:

> How about killing the _2_4_devel tree?  When I created it I want it to be a
> playground for stabilizing then moving things over to 2_4 failry quickly.
> It seems to have become the defacto "want board X, you better use
> _2_4_devel" tree.

That's been the stated goal for quite a number of months now.  The
reason it hasn't 'died' yet is that some changes have taken a while to
get to the point where Paul is happy enough with them to send out to
Marcelo, and / or Marcelo has gotten far along in the -pre releases of
the next release that big arch specific changes aren't a good idea.

Hopefully starting the week of 12/23 I'll have time to get the 'classic'
PPC (and here it's really i8259 / OpenPIC stuff, the CPC700/CPC710
boards can / have gone out) to the _2_4 tree and onto Marcelo.

> When I went looking for a working 4xx tree recently I had to write a script
> that would go through the last year of changesets in _2_4 and _2_4_devel
> and try to build them then stick the result into a file.  That ran for 7
> days on a 2.0Ghz Dual x86.  Then, that only gave me a list of building
> trees.  Knowing that there's only 1 tree would be much easier!

4xx in and of itself has things which still need to be done.  The stock
answer for some time for a 'working' 4xx tree is to use _devel.  I think
that it might be possible to get the basics of 4xx out to Marcelo, if
some of the cleanups done in 2.5 get (a) finished and then (b)
backported to 2.4.  But that would still I suspect leave enet and other
things out at the moment.

> I'll send you some wonderful New Mexico wine in exchange for your efforts!

Woo! :)

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

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

Re: Support for Arctic platform (405LP based)

[Paul Mackerras]

Cort Dougan writes:

> How about killing the _2_4_devel tree?  When I created it I want it to be a
> playground for stabilizing then moving things over to 2_4 failry quickly.
> It seems to have become the defacto "want board X, you better use
> _2_4_devel" tree.

Now that Marcelo is using BK, what I would really like to do is to
kill both the linuxppc_2_4 and linuxppc_2_4_devel trees and move to a
tree that is a child of Marcelo's linux-2.4 tree.

> When I went looking for a working 4xx tree recently I had to write a script
> that would go through the last year of changesets in _2_4 and _2_4_devel
> and try to build them then stick the result into a file.  That ran for 7
> days on a 2.0Ghz Dual x86.  Then, that only gave me a list of building
> trees.  Knowing that there's only 1 tree would be much easier!

4xx in particular is a problem because I'm not convinced about the
approach that has been taken for some of the 4xx infrastructure.  The
ocp stuff seems a lot more complicated than it needs to be, for
instance.  There is no particular reason that I can see why the 8xx
stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.

Paul.

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

Re: Support for Arctic platform (405LP based)

[Cort Dougan]

} Now that Marcelo is using BK, what I would really like to do is to
} kill both the linuxppc_2_4 and linuxppc_2_4_devel trees and move to a
} tree that is a child of Marcelo's linux-2.4 tree.

I've been moving patches from the _2_4 and _2_4_devel ppc trees over to the
marcelo tree.  I've love to see the switch so I don't have to do that!

} 4xx in particular is a problem because I'm not convinced about the
} approach that has been taken for some of the 4xx infrastructure.  The
} ocp stuff seems a lot more complicated than it needs to be, for
} instance.  There is no particular reason that I can see why the 8xx
} stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.

How about a linuxppc_2_4 that is a child of Marcelo's.  Then a
linuxppc_2_4_4xx (and what have you) that is a child of the linuxppc_2_4
tree?  It would make integration much much easier.  Right now the
diff between _2_4 and _2_4_devel seems to be non-monotonically increasing.
I think it would be hard to arrest that growth without switching to a
Macelo based tree.


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

Re: Support for Arctic platform (405LP based)

[David Gibson]

On Mon, Dec 16, 2002 at 10:43:27AM +1100, Paul Mackerras wrote:
>
> Cort Dougan writes:
>
> > How about killing the _2_4_devel tree?  When I created it I want it to be a
> > playground for stabilizing then moving things over to 2_4 failry quickly.
> > It seems to have become the defacto "want board X, you better use
> > _2_4_devel" tree.
>
> Now that Marcelo is using BK, what I would really like to do is to
> kill both the linuxppc_2_4 and linuxppc_2_4_devel trees and move to a
> tree that is a child of Marcelo's linux-2.4 tree.
>
> > When I went looking for a working 4xx tree recently I had to write a script
> > that would go through the last year of changesets in _2_4 and _2_4_devel
> > and try to build them then stick the result into a file.  That ran for 7
> > days on a 2.0Ghz Dual x86.  Then, that only gave me a list of building
> > trees.  Knowing that there's only 1 tree would be much easier!
>
> 4xx in particular is a problem because I'm not convinced about the
> approach that has been taken for some of the 4xx infrastructure.  The
> ocp stuff seems a lot more complicated than it needs to be, for
> instance.  There is no particular reason that I can see why the 8xx
> stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.

Well, it sounds as if linuxppc_2_4_devel is the place to commit the
Arctic2 code.  Killing that tree off, by whatever means, sounds like a
very good idea, but not actually something that committing my code
elsewhere would help to accomplish.

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

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

Re: Support for Arctic platform (405LP based)

[David Gibson]

On Sun, Dec 15, 2002 at 06:35:49PM +1100, David Gibson wrote:
> > CONFIG_IBM_OPENBIOS is taken out of the CONFIG_SYCAMORE section of
> > arch/ppc/config.in?
>
> Err... I have no idea what you're asking.  How did SYCAMORE get into
> this?
>
> > Duplication of the CONFIG_BEECH case in
> > arch/ppc/boot/simple/embed_config.c: might be trying to enable the SSX
> > bootloader for Beech, but since CONFIG_IBM_OPENBIOS is on for Beech it
> > seems we'd have dup definitions?  Would more SSX code would be necessary
> > anyhow?
>
> Again, I'm afraid I'm having trouble parsing that paragraph - what do
> you want to know?

Gah, ok, now I see what you're talking about:  the diffs to the
SYCMORE config and the extra beech code in my patch.  Yes, as you
probably suspected they were just mistakes - now corrected.

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

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

Re: Discovery II (was Re: Support for Arctic platform (405LP based))

[Mark A. Greer]

Roland Dreier wrote:

>    Tom> ... with the exception of the current gt64260 code, which
>    Tom> will hopefully get an update so that it could move
>    Tom> up-and-out.  But no promises there.
>
>This reminds me... can someone tell me what the status of Discovery II
>(MV64340) is at the moment?
>
>
Rabeeh Khoury from Marvell has done a port to it and put it in the
linux-galileo tree.  I have no hardware to test it but Rabeeh says that
its been working fine for him for some time.

Mark


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

Re: Discovery II (was Re: Support for Arctic platform (405LP based))

[Mark A. Greer]

Roland Dreier wrote:

> Thanks... my next question is where is the linux-galileo tree?  (I'm
>sure this is well-known to people working with Discovery II but please
>forgive my ignorance as I'm just starting to look at this platform)
>
>
No problem, I should have included that.  These should get you started...

http://source.mvista.com/pipermail/linux-galileo/2002-January/000002.html
http://source.mvista.com/

and, IIRC for anon bk:

bk clone bk://source.mvista.com/linuxppc_2_4_galileo

Mark


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

Re: Support for Arctic platform (405LP based)

[Tom Rini]

On Mon, Dec 16, 2002 at 10:43:27AM +1100, Paul Mackerras wrote:

> Cort Dougan writes:
>
> > How about killing the _2_4_devel tree?  When I created it I want it to be a
> > playground for stabilizing then moving things over to 2_4 failry quickly.
> > It seems to have become the defacto "want board X, you better use
> > _2_4_devel" tree.
>
> Now that Marcelo is using BK, what I would really like to do is to
> kill both the linuxppc_2_4 and linuxppc_2_4_devel trees and move to a
> tree that is a child of Marcelo's linux-2.4 tree.

... but old history? :)

[snip]
> ...  There is no particular reason that I can see why the 8xx
> stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.

I'll try and get to that too, once finals are over :)

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

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

Re: Support for Arctic platform (405LP based)

[Tom Rini]

On Sun, Dec 15, 2002 at 05:41:20PM -0700, Cort Dougan wrote:

> } 4xx in particular is a problem because I'm not convinced about the
> } approach that has been taken for some of the 4xx infrastructure.  The
> } ocp stuff seems a lot more complicated than it needs to be, for
> } instance.  There is no particular reason that I can see why the 8xx
> } stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.
>
> How about a linuxppc_2_4 that is a child of Marcelo's.  Then a
> linuxppc_2_4_4xx (and what have you) that is a child of the linuxppc_2_4
> tree?  It would make integration much much easier.  Right now the
> diff between _2_4 and _2_4_devel seems to be non-monotonically increasing.
> I think it would be hard to arrest that growth without switching to a
> Macelo based tree.

I'm not sure how that would stop the growth of the '_devel' tree, it
would just split it up into 4xx, and everything else.  And my goal of
the new few weeks is to try and move everything that's not 4xx that I
can get my hands on to test into the _2_4 tree.  I'm not sure just how
much of that I'll actually be able to do, but I'm going to try.

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

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

Re: Support for Arctic platform (405LP based)

[Tom Rini]

On Mon, Dec 16, 2002 at 08:04:42AM -0700, Tom Rini wrote:
>
> On Sun, Dec 15, 2002 at 05:41:20PM -0700, Cort Dougan wrote:
>
> > } 4xx in particular is a problem because I'm not convinced about the
> > } approach that has been taken for some of the 4xx infrastructure.  The
> > } ocp stuff seems a lot more complicated than it needs to be, for
> > } instance.  There is no particular reason that I can see why the 8xx
> > } stuff in 2_4_devel shouldn't go to Marcelo for 2.4.21.
> >
> > How about a linuxppc_2_4 that is a child of Marcelo's.  Then a
> > linuxppc_2_4_4xx (and what have you) that is a child of the linuxppc_2_4
> > tree?  It would make integration much much easier.  Right now the
> > diff between _2_4 and _2_4_devel seems to be non-monotonically increasing.
> > I think it would be hard to arrest that growth without switching to a
> > Macelo based tree.
>
> I'm not sure how that would stop the growth of the '_devel' tree, it
> would just split it up into 4xx, and everything else.  And my goal of
> the new few weeks is to try and move everything that's not 4xx that I
> can get my hands on to test into the _2_4 tree.  I'm not sure just how
> much of that I'll actually be able to do, but I'm going to try.

... with the exception of the current gt64260 code, which will hopefully
get an update so that it could move up-and-out.  But no promises there.

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

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

Discovery II (was Re: Support for Arctic platform (405LP based))

[Roland Dreier]

    Tom> ... with the exception of the current gt64260 code, which
    Tom> will hopefully get an update so that it could move
    Tom> up-and-out.  But no promises there.

This reminds me... can someone tell me what the status of Discovery II
(MV64340) is at the moment?

Thanks,
  Roland


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

Re: Discovery II (was Re: Support for Arctic platform (405LP based))

[Roland Dreier]

    Roland> This reminds me... can someone tell me what the status of
    Roland> Discovery II (MV64340) is at the moment?

    Mark> Rabeeh Khoury from Marvell has done a port to it and put it
    Mark> in the linux-galileo tree.  I have no hardware to test it
    Mark> but Rabeeh says that its been working fine for him for some
    Mark> time.

Thanks... my next question is where is the linux-galileo tree?  (I'm
sure this is well-known to people working with Discovery II but please
forgive my ignorance as I'm just starting to look at this platform)

Thanks,
  Roland

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

Re: Support for Arctic platform (405LP based)

[Cort Dougan]

} I'm not sure how that would stop the growth of the '_devel' tree, it
} would just split it up into 4xx, and everything else.  And my goal of
} the new few weeks is to try and move everything that's not 4xx that I
} can get my hands on to test into the _2_4 tree.  I'm not sure just how
} much of that I'll actually be able to do, but I'm going to try.

There would be no _devel tree in that case.  They'd all be based on
Marcelo's so moving back and forth would be easier.  There would also be
more trees and smaller patches.

Right now, if you want an embedded board to boot your only chance is to try
the wildly divergent - likely unstable - _devel tree.  Having something
like this would be much nicer:


marcelo ---> linuxppc_2_4 --- linuxppc_2_4_4xx
                  |                 |
		  |		    ---> linuxppc_2_4_4xx_walnut
		  |		    |
		  |		    ---> linuxppc_2_4_4xx_crazystuff
		  |		    |
		  |		    ---> linuxppc_2_4_4xx_some_whacky_port
		  |
		  |
		  |
		  |---> linuxppc_2_4_something

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

PPC Tree structures (Was, at some point: Re: Support for Arctic platform (405LP based))

[Tom Rini]

On Mon, Dec 16, 2002 at 12:49:31PM -0700, Cort Dougan wrote:
> } I'm not sure how that would stop the growth of the '_devel' tree, it
> } would just split it up into 4xx, and everything else.  And my goal of
> } the new few weeks is to try and move everything that's not 4xx that I
> } can get my hands on to test into the _2_4 tree.  I'm not sure just how
> } much of that I'll actually be able to do, but I'm going to try.
>
> There would be no _devel tree in that case.  They'd all be based on
> Marcelo's so moving back and forth would be easier.  There would also be
> more trees and smaller patches.

But more trees with smaller patches doesn't mean that the 'growth'
stops.  Furthermore, there's only 4 things in _devel right now:
1) 4xx - It's "stable", in that there haven't been any big changes for
some time, and as far as I know few "bugs".  But there's still a lot to
be done.
2) 8xx - This can quite probably all go right on up and out, pending
time.
3) OpenPIC / i8259 cleanups, some backported from 2.5 some original, all
of which is quite stable right now.  There's just boards which need
updating still (!!!).  This is ready to go up and out, and will move a
large chunk of code out of _devel with it.
4) gt64260 support.  What's in _devel now is stale, and this doesn't
depend on anything in _devel now anyhow.  FWIW, this exists in its own
tree anyways :)

> Right now, if you want an embedded board to boot your only chance is to try
> the wildly divergent - likely unstable - _devel tree.

But that's just it, it's not "likely unstable" and with a few exceptions
noted above hasn't been for some time (it's either fine or non-compiling
iirc).

> Having something
> like this would be much nicer:
>
>
> marcelo ---> linuxppc_2_4 --- linuxppc_2_4_4xx
>                   |                 |
> 		  |		    ---> linuxppc_2_4_4xx_walnut
> 		  |		    |
> 		  |		    ---> linuxppc_2_4_4xx_crazystuff
> 		  |		    |
> 		  |		    ---> linuxppc_2_4_4xx_some_whacky_port

Far too much division, which also makes moving things up more painful as
each one will conflict on the cpu-specific stuff, the config.in entry,
etc.

But regardless of all of that, there's nothing related to this being a
'marcelo' tree or not as you can't pick and choose bk csets without
everything preceeding it.  Ideally we can get to the point of not really
needing a seperate tree like 2.2 is (which could go if someone wants to
sit down and think about the LongTrail-specific changes in there).

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

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

Re: PPC Tree structures (Was, at some point: Re: Support for Arctic platform (405LP based))

[Cort Dougan]

Right, changes would keep going.  Having many trees all based on the same
root would make moving patches back and forth much easier.

People would be able to grab what they need (a booting walnut, for example)
without pulling in >1 years worth of development and unstable changes.  I
definitely think it would be useful.

} But more trees with smaller patches doesn't mean that the 'growth'
} stops.  Furthermore, there's only 4 things in _devel right now:
} 1) 4xx - It's "stable", in that there haven't been any big changes for
} some time, and as far as I know few "bugs".  But there's still a lot to
} be done.

Exactly my point.  It's mired in the next of _devel right now but should be
shoved up into the stable tree.

} 2) 8xx - This can quite probably all go right on up and out, pending
} time.

Same thing.

} 3) OpenPIC / i8259 cleanups, some backported from 2.5 some original, all
} of which is quite stable right now.  There's just boards which need
} updating still (!!!).  This is ready to go up and out, and will move a
} large chunk of code out of _devel with it.
} 4) gt64260 support.  What's in _devel now is stale, and this doesn't
} depend on anything in _devel now anyhow.  FWIW, this exists in its own
} tree anyways :)

All the more reason for a linuxppc_2_4_galileo tree.

} Far too much division, which also makes moving things up more painful as
} each one will conflict on the cpu-specific stuff, the config.in entry,
} etc.

I don't think so.  It just illustrates what is already the case - it's just
not organized.  Each BK tree is its own node in that graph I drew.  This
just formalizes it a bit so people know where to push/pull from when they
want a specific thing.

} But regardless of all of that, there's nothing related to this being a
} 'marcelo' tree or not as you can't pick and choose bk csets without
} everything preceeding it.  Ideally we can get to the point of not really
} needing a seperate tree like 2.2 is (which could go if someone wants to
} sit down and think about the LongTrail-specific changes in there).

Is there a point to this not being based on the Marcelo tree?  A good
cleanout and shift over to it is certainly worthwhile.

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

Re: Support for Arctic platform (405LP based))

[Tom Rini]

On Mon, Dec 16, 2002 at 01:13:40PM -0700, Cort Dougan wrote:
``
> Right, changes would keep going.  Having many trees all based on the same
> root would make moving patches back and forth much easier.

It's irrelevant what they're based on, Marcelo would never pull from the
'linux-2.4-4xx-walnut' tree, nor the 'linux-2.4-4xx' tree, as there will
be lots of "whoops, lets try it this way now" stuff, etc.

> People would be able to grab what they need (a booting walnut, for example)
> without pulling in >1 years worth of development and unstable changes.  I
> definitely think it would be useful.

But that's just it, the >1 year of "development and unstable changes" is
4xx.  The largest problem with the _devel tree right now is that once
something becomes stable it hasn't moved up and out to Marcelo (and in
some cases, Linus).  It's not because things can't be taken out, it's
been around 80% time / timing, 15% style / cleanliness / minor tweaking,
and maybe 5% of actual unstable code.

> } But more trees with smaller patches doesn't mean that the 'growth'
> } stops.  Furthermore, there's only 4 things in _devel right now:
> } 1) 4xx - It's "stable", in that there haven't been any big changes for
> } some time, and as far as I know few "bugs".  But there's still a lot to
> } be done.
>
> Exactly my point.  It's mired in the next of _devel right now but should be
> shoved up into the stable tree.

4xx should not be shoved up into the 'stable' tree as it's not ready for
Marcelo.  I fully expect Paul to want a largescale backport of a lot of
what's been done in 2.5 for 4xx, once it's done.

> } 3) OpenPIC / i8259 cleanups, some backported from 2.5 some original, all
> } of which is quite stable right now.  There's just boards which need
> } updating still (!!!).  This is ready to go up and out, and will move a
> } large chunk of code out of _devel with it.
> } 4) gt64260 support.  What's in _devel now is stale, and this doesn't
> } depend on anything in _devel now anyhow.  FWIW, this exists in its own
> } tree anyways :)
>
> All the more reason for a linuxppc_2_4_galileo tree.

Where it has been for some time.  IIRC, the linuxpcp_2_4_galileo tree is
rather stable, but in this case it's 99% time of why it hasn't been put
back into _devel where it's more noticable to Paul.

> } Far too much division, which also makes moving things up more painful as
> } each one will conflict on the cpu-specific stuff, the config.in entry,
> } etc.
>
> I don't think so.  It just illustrates what is already the case - it's just
> not organized.  Each BK tree is its own node in that graph I drew.  This
> just formalizes it a bit so people know where to push/pull from when they
> want a specific thing.

But that's just it, the specific thing most people want is a stable 40x
tree so they can modify things for their own custom port.  If all of the
40x code is in one place perhaps they will pick up on a similar change
another port needed, and potentially encourage them to think generically
for some quirk they hit.

Which reminds me of another issue, if we have too many trees things it
makes it even harder to get Paul to potentially notice code and comment
on things.

> } But regardless of all of that, there's nothing related to this being a
> } 'marcelo' tree or not as you can't pick and choose bk csets without
> } everything preceeding it.  Ideally we can get to the point of not really
> } needing a seperate tree like 2.2 is (which could go if someone wants to
> } sit down and think about the LongTrail-specific changes in there).
>
> Is there a point to this not being based on the Marcelo tree?  A good
> cleanout and shift over to it is certainly worthwhile.

A "good cleanout" is bad as we loose all of that history.  It came in
quite handy for me to have a copy of the old linuxppc_2_3 and
linuxppc_2_5 trees (until that drive died) when trying to figure out why
something was done.  I really don't want to see that happen again for
2.4.

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

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

Re: linuxppc-commit mailing list

[Hollis Blanchard]

On Fri, 2002-12-13 at 10:35, Tom Rini wrote:
> > If you aren't already on the linuxppc-commit@source.mvista.com list, you
> > might want to join that.
>
> And since this is at a possibly non obvious location:
> http://source.mvista.com/cgi-bin/mailman/listinfo/linuxppc-commit
>
> <hint>Hopefully PenguinPPC.org will have a link to this somewhere.</hint>

Actually it's already been linked to for a while (at
http://penguinppc.org/dev/kernel.shtml), but I've now made it more
obvious.

-Hollis
--
PowerPC Linux
IBM Linux Technology Center

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

Re: Discovery II (was Re: Support for Arctic platform (405LP based))

[Rabeeh Khoury]

> Rabeeh Khoury from Marvell has done a port to it and put it in the
> linux-galileo tree.  I have no hardware to test it but Rabeeh says that
> its been working fine for him for some time.


I have the DB-64360 (Development board based on MV64360 part) working
fine with the support for the development board and the gigE ethernet.
I mainly have tested this with 7455 CPUs. I also tested it with dual 7455


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

Re: PPC Tree structures (Was, at some point: Re: Support for Arctic platform (405LP based))

[Cort Dougan]

} But regardless of all of that, there's nothing related to this being a
} 'marcelo' tree or not as you can't pick and choose bk csets without
} everything preceeding it.  Ideally we can get to the point of not really
} needing a seperate tree like 2.2 is (which could go if someone wants to
} sit down and think about the LongTrail-specific changes in there).

There's a great advantage to it being based on Marcelo's tree.  I can pull
in several projects that I need along with the PPC changes I need into my
own tree.  I think that would help a lot of people out.

In fact, it should help merging with Marcelo a great deal.  You can easily
pull in main-line changes.

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

Re: Support for Arctic platform (405LP based))

[Tom Rini]

On Thu, Dec 19, 2002 at 11:06:09AM -0700, Cort Dougan wrote:

> } But regardless of all of that, there's nothing related to this being a
> } 'marcelo' tree or not as you can't pick and choose bk csets without
> } everything preceeding it.  Ideally we can get to the point of not really
> } needing a seperate tree like 2.2 is (which could go if someone wants to
> } sit down and think about the LongTrail-specific changes in there).
>
> There's a great advantage to it being based on Marcelo's tree.  I can pull
> in several projects that I need along with the PPC changes I need into my
> own tree.  I think that would help a lot of people out.
>
> In fact, it should help merging with Marcelo a great deal.  You can easily
> pull in main-line changes.

I'll conceed the first part since I know there's at least a few external
projects using BK, and a few that aren't, and so on.

I'm not convinced about merging main-line changes as that only works if
everyonce consistently uses a seperate tree and merges into that.  Just
like we don't have Linus pulling directly from linuxppc-2.5, Marcelo
wouldn't pull from linuxppc-2.4, and right now Paul ends up having to
pick and move things around (even I've fallen out of the habit of having
another 'working' tree for more direct movement, bad me).

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

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