* [PATCH 5/6] bootwrapper: Add support for the DINK firmware
From: Mark A. Greer @ 2006-07-19 23:14 UTC (permalink / raw)
To: linuxppc-dev
This patch adds the firmware operations that support the DINK firmware
from Freescale.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
dink.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 56 insertions(+)
--
diff --git a/arch/powerpc/boot/dink.c b/arch/powerpc/boot/dink.c
new file mode 100644
index 0000000..aa446e2
--- /dev/null
+++ b/arch/powerpc/boot/dink.c
@@ -0,0 +1,56 @@
+/*
+ * Sandpoint specific fixups.
+ *
+ * Author: Mark A. Greer <mgreer@mvista.com>
+ *
+ * 2006 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "string.h"
+#include "stdio.h"
+#include "page.h"
+#include "ops.h"
+
+#define MB (1024*1024)
+
+extern char _end[];
+
+static u32 cur_base;
+static u32 end_of_ram = 32 * MB;
+
+static void *
+dink_malloc(u32 size)
+{
+ void *area = NULL;
+ static u8 first_time = 1;
+
+ if (first_time) {
+ cur_base = _ALIGN_UP((unsigned long)_end, MB);
+ first_time = 0;
+ }
+
+ if ((cur_base + size) < end_of_ram) {
+ area = (void *)cur_base;
+ cur_base += _ALIGN_UP(size, MB);
+ }
+
+ return area;
+}
+
+static struct fw_ops dink_fw_ops;
+
+struct fw_ops *
+dink_init(void)
+{
+ dink_fw_ops.malloc = dink_malloc;
+ dink_fw_ops.free = NULL;
+ dink_fw_ops.exit = NULL;
+
+ return &dink_fw_ops;
+}
^ permalink raw reply related
* [PATCH 6/6] bootwrapper: Add support for the sandpoint platform
From: Mark A. Greer @ 2006-07-19 23:17 UTC (permalink / raw)
To: linuxppc-dev
This patch adds support for the Freescale Sandpoint platform
to the bootwrapper.
Signed-off-by: Mark A. Greer <mgreer@mvista.com>
--
Makefile | 3 +
mpc10x.c | 109 ++++++++++++++++++++++++++++++++++++++++++++
sandpoint.c | 147 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 259 insertions(+)
--
diff --git a/arch/powerpc/boot/Makefile b/arch/powerpc/boot/Makefile
index 3e767e5..daad857 100644
--- a/arch/powerpc/boot/Makefile
+++ b/arch/powerpc/boot/Makefile
@@ -40,6 +40,9 @@ src-boot := crt0.S string.S stdio.c main
ifeq ($(CONFIG_PPC_MULTIPLATFORM),y)
src-boot += of.c
endif
+ifeq ($(CONFIG_SANDPOINT),y)
+src-boot += sandpoint.c mpc10x.c dink.c serial.c ns16550.c util.S
+endif
src-boot += $(zlib)
src-boot := $(addprefix $(obj)/, $(src-boot))
obj-boot := $(addsuffix .o, $(basename $(src-boot)))
diff --git a/arch/powerpc/boot/mpc10x.c b/arch/powerpc/boot/mpc10x.c
new file mode 100644
index 0000000..3e4de93
--- /dev/null
+++ b/arch/powerpc/boot/mpc10x.c
@@ -0,0 +1,109 @@
+/*
+ * Freescale mpc10[67] & mpc824[015] specific code.
+ *
+ * Author: Mark A. Greer <mgreer@mvista.com>
+ *
+ * 2001 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "string.h"
+#include "stdio.h"
+#include "io.h"
+
+/* Map B (CHRP Map) Defines */
+#define MPC10X_MAPB_CNFG_ADDR 0xfec00000
+#define MPC10X_MAPB_CNFG_DATA 0xfee00000
+
+/* Define offsets for the memory controller registers in the config space */
+#define MPC10X_MCTLR_MEM_START_1 0x80 /* Banks 0-3 */
+#define MPC10X_MCTLR_MEM_START_2 0x84 /* Banks 4-7 */
+#define MPC10X_MCTLR_EXT_MEM_START_1 0x88 /* Banks 0-3 */
+#define MPC10X_MCTLR_EXT_MEM_START_2 0x8c /* Banks 4-7 */
+
+#define MPC10X_MCTLR_MEM_END_1 0x90 /* Banks 0-3 */
+#define MPC10X_MCTLR_MEM_END_2 0x94 /* Banks 4-7 */
+#define MPC10X_MCTLR_EXT_MEM_END_1 0x98 /* Banks 0-3 */
+#define MPC10X_MCTLR_EXT_MEM_END_2 0x9c /* Banks 4-7 */
+
+#define MPC10X_MCTLR_MEM_BANK_ENABLES 0xa0
+
+#define PCI_DEVFN(slot,func) ((((slot) & 0x1f) << 3) | ((func) & 0x07))
+
+/* Indirect PCI config space access routines */
+static inline void
+pci_indirect_read_config_byte(u32 *cfg_addr, u32 *cfg_data, int devfn,
+ int offset, u8 *val)
+{
+ out_be32(cfg_addr,
+ ((offset & 0xfc) << 24) | (devfn << 16) | (0 << 8) | 0x80);
+ *val = in_8((u8 *)(cfg_data + (offset & 3)));
+ return;
+}
+
+static inline void
+pci_indirect_read_config_dword(u32 *cfg_addr, u32 *cfg_data, int devfn,
+ int offset, u32 *val)
+{
+ out_be32(cfg_addr,
+ ((offset & 0xfc) << 24) | (devfn << 16) | (0 << 8) | 0x80);
+ *val = in_le32(cfg_data + (offset & 3));
+ return;
+}
+
+/*
+ * Read the memory controller registers to determine the amount of memory in
+ * the system. This assumes that the firmware has correctly set up the memory
+ * controller registers.
+ * Assume memory map B (CHRP).
+ */
+u32
+mpc10x_get_mem_size(void)
+{
+ u32 *config_addr, *config_data, val;
+ u32 start, end, total, offset, i;
+ u8 bank_enables;
+
+ config_addr = (u32 *)MPC10X_MAPB_CNFG_ADDR;
+ config_data = (u32 *)MPC10X_MAPB_CNFG_DATA;
+
+ pci_indirect_read_config_byte(config_addr, config_data, PCI_DEVFN(0,0),
+ MPC10X_MCTLR_MEM_BANK_ENABLES, &bank_enables);
+
+ total = 0;
+
+ for (i=0; i<8; i++) {
+ if (bank_enables & (1 << i)) {
+ offset = MPC10X_MCTLR_MEM_START_1 + ((i > 3) ? 4 : 0);
+ pci_indirect_read_config_dword(config_addr, config_data,
+ PCI_DEVFN(0,0), offset, &val);
+ start = (val >> ((i & 3) << 3)) & 0xff;
+
+ offset = MPC10X_MCTLR_EXT_MEM_START_1 + ((i>3) ? 4 : 0);
+ pci_indirect_read_config_dword(config_addr, config_data,
+ PCI_DEVFN(0,0), offset, &val);
+ val = (val >> ((i & 3) << 3)) & 0x03;
+ start = (val << 28) | (start << 20);
+
+ offset = MPC10X_MCTLR_MEM_END_1 + ((i > 3) ? 4 : 0);
+ pci_indirect_read_config_dword(config_addr, config_data,
+ PCI_DEVFN(0,0), offset, &val);
+ end = (val >> ((i & 3) << 3)) & 0xff;
+
+ offset = MPC10X_MCTLR_EXT_MEM_END_1 + ((i > 3) ? 4 : 0);
+ pci_indirect_read_config_dword(config_addr, config_data,
+ PCI_DEVFN(0,0), offset, &val);
+ val = (val >> ((i & 3) << 3)) & 0x03;
+ end = (val << 28) | (end << 20) | 0xfffff;
+
+ total += (end - start + 1);
+ }
+ }
+
+ return total;
+}
diff --git a/arch/powerpc/boot/sandpoint.c b/arch/powerpc/boot/sandpoint.c
new file mode 100644
index 0000000..b5a5462
--- /dev/null
+++ b/arch/powerpc/boot/sandpoint.c
@@ -0,0 +1,147 @@
+/*
+ * Sandpoint specific fixups.
+ *
+ * Author: Mark A. Greer <mgreer@mvista.com>
+ *
+ * 2006 (c) MontaVista, Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+
+#include <stdarg.h>
+#include <stddef.h>
+#include "types.h"
+#include "string.h"
+#include "stdio.h"
+#include "io.h"
+#include "ops.h"
+
+#define CPU_824X 0
+#define CPU_7XX 1
+#define CPU_7457 2
+#define CPU_NUM 3
+
+static u32 cpu_pll[CPU_NUM][32] = {
+ [CPU_824X] = { /* 824x */
+ 5, 6, 9, 4, 4, 5, 2, 6, 6, 4, 9, 6, 5, 7, 6, 7,
+ 4, 5, 4, 6, 7, 8, 8, 4, 6, 5, 8, 6, 6, 5, 7, 0
+ },
+ [CPU_7XX] = { /* 750/755 */
+ 0, 15, 14, 2, 4, 13, 20, 9, 6, 11, 8, 10, 16, 12, 7, 0,
+ 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
+
+ },
+ [CPU_7457] = { /* 7457 */
+ 23, 34, 15, 30, 14, 36, 2, 40, 4, 42, 13, 26, 17, 48, 19, 18,
+ 6, 21, 11, 22, 8, 20, 10, 24, 16, 28, 12, 32, 27, 56, 0, 25
+ }
+};
+
+static struct processor_info {
+ u32 pvr;
+ u32 mask;
+ u32 bus_freq;
+ u32 hid1_shift;
+ u32 hid1_mask;
+ u32 pll_tbl_idx;
+ u32 max_mem; /* DINK still sets up mem ctlr wrong */
+} processor_info_tbl[] = { /* From cputable -- MHz are only guesses */
+ /* 824x */
+ { 0x00810000, 0x7fff0000, 100000000, 27, 0x1f, CPU_824X, 0x08000000 },
+ /* 750 */
+ { 0x00084202, 0xffffffff, 100000000, 28, 0xf, CPU_7XX, 0x08000000 },
+ /* 745/755 */
+ { 0x00083000, 0xfffff000, 100000000, 28, 0xf, CPU_7XX, 0x08000000 },
+ /* 7447/7457 Rev 1.0 */
+ { 0x80020100, 0xffffffff, 100000000, 12, 0x1f, CPU_7457, 0x04000000 },
+ /* 7447/7457 Rev 1.1 */
+ { 0x80020101, 0xffffffff, 100000000, 12, 0x1f, CPU_7457, 0x04000000 },
+ /* 7447/7457 Rev 1.2 & up*/
+ { 0x80020000, 0xffff0000, 100000000, 12, 0x1f, CPU_7457, 0x04000000 },
+ /* 7447A */
+ { 0x80030000, 0xffff0000, 100000000, 12, 0x1f, CPU_7457, 0x80000000 },
+};
+
+static struct processor_info *
+get_processor_info(u32 pvr)
+{
+ struct processor_info *pit = processor_info_tbl;
+ u32 i;
+
+ for (i=0; i<ARRAY_SIZE(processor_info_tbl); i++, pit++)
+ if (pit->pvr == (pvr & pit->mask))
+ return pit;
+ return NULL;
+}
+
+#define __stringify_1(x) #x
+#define __stringify(x) __stringify_1(x)
+
+#define SPRN_PVR 0x11F /* Processor Version Register */
+#define SPRN_HID1 0x3F1 /* Hardware Implementation Register 1 */
+#define mfspr(rn) ({unsigned long rval; \
+ asm volatile("mfspr %0," __stringify(rn) \
+ : "=r" (rval)); rval;})
+
+static void
+sandpoint_fixups(void)
+{
+ u32 i, v[2], hid1, max_mem = 0xffffffff;
+ void *devp;
+ struct processor_info *pit;
+ extern u32 mpc10x_get_mem_size(void);
+
+ /* Update cpu's clock-frequency & timebase-frequency in fdt */
+ if ((pit = get_processor_info(mfspr(SPRN_PVR)))
+ && (devp = finddevice("/cpus/PowerPC,603e"))) {
+
+ max_mem = pit->max_mem;
+
+ hid1 = (mfspr(SPRN_HID1) >> pit->hid1_shift) & pit->hid1_mask;
+ v[0] = pit->bus_freq * cpu_pll[pit->pll_tbl_idx][hid1]/2;
+ setprop(devp, "clock-frequency", v, sizeof(v[0]));
+
+ v[0] = pit->bus_freq / 4;
+ setprop(devp, "timebase-frequency", v, sizeof(v[0]));
+ }
+
+ /* Get the RAM size from the memory controller & update fdt */
+ if ((devp = finddevice("/memory"))) {
+ i = mpc10x_get_mem_size();
+ v[0] = 0;
+ v[1] = min(i, max_mem);
+ setprop(devp, "reg", v, sizeof(v));
+ }
+
+ /* XXXX stuff from platforms/.../sandpoint.c should be here */
+}
+
+static void
+sandpoint_reset(void)
+{
+ void _nmask_and_or_msr(unsigned long nmask, unsigned long or_val);
+ _nmask_and_or_msr(0, (1<<6)); /* Set exception prefix high - firmware */
+
+ /* Reset system via Port 92 */
+ out_8((volatile unsigned char *)0xfe000092, 0x00);
+ out_8((volatile unsigned char *)0xfe000092, 0x01);
+
+ for(;;); /* Spin until reset happens */
+}
+
+static struct ops sandpoint_ops;
+static struct platform_ops sandpoint_platform_ops;
+
+struct ops *
+platform_init(void *promptr)
+{
+ sandpoint_platform_ops.fixups = sandpoint_fixups;
+ sandpoint_platform_ops.exit = sandpoint_reset;
+
+ sandpoint_ops.platform_ops = &sandpoint_platform_ops;
+ sandpoint_ops.fw_ops = dink_init();
+ sandpoint_ops.console_ops = ns16550_init();
+
+ return &sandpoint_ops;
+}
^ permalink raw reply related
* Re: [PATCH 5/6] bootwrapper: Add support for the DINK firmware
From: Mark A. Greer @ 2006-07-19 23:33 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-dev
In-Reply-To: <20060719231421.GF3887@mag.az.mvista.com>
On Wed, Jul 19, 2006 at 04:14:21PM -0700, Mark A. Greer wrote:
> This patch adds the firmware operations that support the DINK firmware
> from Freescale.
>
> Signed-off-by: Mark A. Greer <mgreer@mvista.com>
> --
>
> dink.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 56 insertions(+)
> --
>
> diff --git a/arch/powerpc/boot/dink.c b/arch/powerpc/boot/dink.c
> new file mode 100644
> index 0000000..aa446e2
> --- /dev/null
> +++ b/arch/powerpc/boot/dink.c
> @@ -0,0 +1,56 @@
> +/*
> + * Sandpoint specific fixups.
Obviously an incorrect comment. Will fix.
Mark
--
^ permalink raw reply
* Re: [HACK] add sandpoint + flattened dt support to arch/powerpc/boot
From: Mark A. Greer @ 2006-07-20 0:39 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.60.0607200008560.9110@poirot.grange>
On Thu, Jul 20, 2006 at 12:29:04AM +0200, Guennadi Liakhovetski wrote:
> On Wed, 19 Jul 2006, Mark A. Greer wrote:
> >
> > Ben and I have talked a little bit privately and the ball is in my court
> > to produce a set of patches. To that end, I have them ready so expect to
> > see them shortly.
>
> Great! So, I can really relax and enjoy my holiday next week in beautiful
> Eifel:-) And as your patches arrive we'll see how best to integrate
> kurobox with them.
Okay, but don't be in too much of a rush. I'm sure there will be
comments that will induce changes to those patches.
> One question so far. Looking at your sandpoint.dts pci map:
>
> ranges = <80000000 80000000 70000000 /* pci mem space */
> fc000000 fc000000 00100000 /* EUMB */
> fe000000 fe000000 00c00000 /* pci i/o space */
> fec00000 fec00000 00300000 /* pci cfg regs */
> fef00000 fef00000 00100000>; /* pci iack */
>
> I can match hardware addresses against defines in
> include/asm-ppc/mpc10x.h,
Don't spend a lot of time in ppc, powerpc is where you need to live now.
> but virtual one - is the map above just an
> example and anyway-not-used, or is it a new mapping, or am I missing
> something and it has always been like that (1-to-1)? At least this comment
The above mapping are physical addresses and are a part of the hardware
description passed into the kernel (i.e., the fdt). It knows nothing
about virtual addresses.
> * MAP B (CHRP Map)
> * Processor: 0xfe000000 - 0xfebfffff -> PCI I/O: 0x00000000 - 0x00bfffff
> * Processor: 0x80000000 - 0xbfffffff -> PCI MEM: 0x80000000 - 0xbfffffff
> * PCI MEM: 0x00000000 -> Processor System Memory: 0x00000000
This table is telling you how the hardware maps processor physical
memory space to/from PCI I/O and MEM space. For example, if the
processor reads physical location 0xfe000000 that will go across the
hostbridge and read PCI I/O location/register 0 (assuming there is a
PCI device set to respond to that PCI I/O address). If a PCI device
reads PCI MEM address 0 it will go across the hostbridge and read
address 0 of the processor's physical address space (i.e., system
memory address 0).
> * EUMB mapped to: ioremap_base - 0x00100000 (ioremap_base - 1 MB)
>
> seems to contradict with the above map in pci io area, as well as this
> one:
>
> * Want processor accesses of 0xFDxxxxxx to be mapped
> * to PCI memory space at 0x00000000. Do not want
>
> Actually, I cannot even match these 2 together?
You need to read the "Address Map B Options Register" section of the
824x or 10x manuals. This is talking about an alias capability of the
hardware that I enabled...but as I think about it, I probably shouldn't
have. 8-P Anyway, if you get confused by a comment, read the code--code
doesn't lie...it may be wrong, but it doesn't lie. ;)
Mark
--
^ permalink raw reply
* Re: reboot on PQ2FADS board.
From: Lei Sun @ 2006-07-20 2:45 UTC (permalink / raw)
To: Mathieu Deschamps; +Cc: linuxppc-embedded
In-Reply-To: <200607191833.32693.mathieu.deschamps@com2gether.net>
On 7/19/06, Mathieu Deschamps <mathieu.deschamps@com2gether.net> wrote:
> Hi,
>
> On Wednesday 19 July 2006 16:12, Lei Sun wrote:
> > Hi :
> > I tried your approach last ight, (in fact I copied part of the
> > do_reboot() code from u-boot and put it in m8260_restart() function in
> > the kernel). The only difference is the first line,
> > volatile immap_t *immap = (immap_t *) IMAP_ADDR;
> > in my case it is
> > volatile immap_t * immap = cpm2_immr;
> > I am using different source tree.
> > it simply hangs, rather then reset.
> >
> [...]
>
> Give a try to :
> startaddr = 0xff000104;
That address was in the code before for warm-reset. It didn't work, I
tried the CheckStop approach, it didn't work either.
thanks
lei
^ permalink raw reply
* Re: reboot on PQ2FADS board.
From: Lei Sun @ 2006-07-20 3:46 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20060719063317.86A66352681@atlas.denx.de>
Hi :
The following is the version I am using, it's pretty much same as
do_reset() code in u-boot -1.1.4 for m8260 target. However the machine
just hangs.
I wonder if there are any difference between Power on Reset and Hard
reset? in my case maybe the machine did get reset, but the u-boot
didn't get executed correctly in the case of hard reset ? It doesn't
explain the fact that i can run "reset" in u-boot console though.
Any comments are highly appreciated! I am stucked in here now.
m8260_restart(char * cmd)
uint startaddr;
unsigned long msr;
char badval;
volatile cpm2_map_t *immap = cpm2_immr;
/* Enable CheckStop reset. */
immap->im_clkrst.car_rmr |= 0x00000001;
/* Interrupts and MMU off */
__asm__ __volatile__("mfmsr %0":"=r" (msr):);
msr &= ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR);
__asm__ __volatile__("mtmsr %0":: "r" (msr));
startaddr = 0x04400000; /* this is taken from u-boot-1.1.4 */
/* Access bad address.*/
((void (*)(void)) startaddr) ();
return 1;
}
On 7/19/06, Wolfgang Denk <wd@denx.de> wrote:
> In message <4879B0C6C249214CBE7AB04453F84E4D050B0F@zch01exm20.fsl.freescale.net> you wrote:
> >
> > > command cause machine check and kernel ooops. The problem seems in
> > > the "m8260_gorom" in head.S. The restart() function in m8260_setup.c
> > > passed 2 parameters to that assembly code, r3 is the bd_info , r4 is
> > > the warm start address, I changed it to 0xFF800100, that's where the
> > > u-boot's _start_warm lives, I have verified that address by typing "g
> > > ff800100" in u-boot console, which cause the board reset.
> >
> > Are you sure ff800100 is _start_warm lives? In latest u-boot
>
> Trying to jump to some boot rom address is IMHO always a bad approach
> to reboot a system. You should always try to cause a reset condition
> for the CPU, and thus for all the associated hardware. On 8xx / 8260
> systems this is usually done by going through a machine check. We
> have the following code in our linuxppc_2_4_devel tree, which works
> on ALL 8260 systems, no matter whioch boot loder they use:
>
> static void
> m8260_restart(char *cmd)
> {
> __volatile__ unsigned char dummy;
> ulong msr;
>
> cli();
> volatile immap_t *immap = (immap_t *) IMAP_ADDR;
>
> immap->im_clkrst.car_rmr = 1; /* Checkstop Reset enable */
>
> /* Interrupts and MMU off */
> __asm__ __volatile__ ("mfmsr %0":"=r" (msr):);
>
> msr &= ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR);
> __asm__ __volatile__ ("mtmsr %0"::"r" (msr));
>
> dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
>
> printk("Restart failed\n");
> for (;;);
> }
>
>
> Best regards,
>
> Wolfgang Denk
>
> --
> Software Engineering: Embedded and Realtime Systems, Embedded Linux
> Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
> If a group of N persons implements a COBOL compiler, there will be
> N-1 passes. Someone in the group has to be the manager. - T. Cheatham
>
^ permalink raw reply
* export-objs in spi Makefile broke in latest linuxppc_2_4_deve l [r eposted]?
From: Heiko Schocher @ 2006-07-20 4:55 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Chad.Rowan
Hello Chad
> linuxppc_2_4_devel is alive and well.
>
> http://www.denx.de/cgi-bin/gitweb.cgi?p=linuxppc_2_4_devel.git;a=shortlog
You speak from the DENX linuxppc_2_4_devel Kernel? If so, I think you are right.
I had the same problem, some days ago. I made a SPI bitbanging algorithm, but
I dont know, if this goes in the git repository from DENX ... Wolfgang?
> -----Original Message-----
> From: Kumar Gala [mailto:galak at kernel.crashing.org]
> Sent: Wednesday, July 19, 2006 4:17 PM
> To: Rowan, Chad
> Cc: linuxppc-embedded at ozlabs.org
> Subject: Re: export-objs in spi Makefile broke in latest linuxppc_2_4_devel
> [r eposted]?
>
>
> > On Jul 19, 2006, at 2:13 PM, Rowan, Chad wrote:
> >
> > Shouldn't export-objs in drivers/spi be:
> >
> > export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5xxx-psc.o \
> > spi-iti5200.o spi-eval.o
> >
> > instead of:
> >
> > export-objs := spi-core.o spi-algo-mpc5xxx.o spi-algo-mpc5200psc.o \
> > spi-iti5200.o spi-eval.o
> >
> > I believe the spi-algo-mpc5200psc.o should be spi-algo-mpc5xxx-psc.o,
> > correct?
>
> Are you really serious about linuxppc_2_4_devel? I can't believe
> linuxppc_2_4_devel has changed in months (if not over a year).
Commit: 98b663155ab7ab07dd85a8d03f437ab4fc29476b
Author: Wolfgang Denk <wd@pollux.denx.de> Thu, 13 Jul 2006 20:17:25 +0200
MCC200: fix QuadUART I/O addressing and interrupt init on new H/W
Patch by Johann Glaser, 13 Jul 2006
It progresses ;-)
Best regards
Heiko
^ permalink raw reply
* RE: [PATCH] Add USB to MPC8349 PB platform support
From: Li Yang-r58472 @ 2006-07-20 6:32 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <C3A460A5-612C-4B0D-9DDA-EB1AE3FEF6EB@kernel.crashing.org>
> -----Original Message-----
> From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On =
Behalf
Of Kumar
> Gala
> Sent: Thursday, July 20, 2006 4:09 AM
> To: Li Yang-r58472
> Cc: linuxppc-dev@ozlabs.org; linux-usb-devel@lists.sourceforge.net
> Subject: Re: [PATCH] Add USB to MPC8349 PB platform support
>=20
>=20
> On Jul 14, 2006, at 6:52 AM, Li Yang wrote:
>=20
> > This adds USB platform support to MPC8349 PB. It works with the
> > fsl_usb2_udc driver.
> >
> > Signed-off-by: Li Yang <leoli@freescale.com>
> > ---
> >
> > arch/powerpc/platforms/83xx/Kconfig | 4 ++
> > arch/powerpc/platforms/83xx/mpc834x_sys.c | 72 +++++++++++++++++++
> > ++++++++++
> > arch/powerpc/platforms/83xx/mpc834x_sys.h | 24 ++++++++++
> > 3 files changed, 113 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/platforms/83xx/Kconfig b/arch/powerpc/
> > platforms/83xx/Kconfig
> > index 7675e67..8404cdf 100644
> > --- a/arch/powerpc/platforms/83xx/Kconfig
> > +++ b/arch/powerpc/platforms/83xx/Kconfig
> > @@ -24,4 +31,14 @@ config MPC834x
> > select PPC_INDIRECT_PCI
> > default y if MPC834x_SYS
> >
> > +config 834x_USB_SUPPORT
> > + bool
> > + default y if MPC834x_SYS && (USB || USB_GADGET)
> > +
> > endmenu
>=20
> I dont think we need this, we should be able to use the USB, and 834x
> CONFIG options in the code.
>=20
> > diff --git a/arch/powerpc/platforms/83xx/mpc834x_sys.c b/arch/
> > powerpc/platforms/83xx/mpc834x_sys.c
> > index 7e789d2..f10d4ae 100644
> > --- a/arch/powerpc/platforms/83xx/mpc834x_sys.c
> > +++ b/arch/powerpc/platforms/83xx/mpc834x_sys.c
> > @@ -36,6 +36,7 @@ #include <asm/irq.h>
> > #include <asm/prom.h>
> > #include <asm/udbg.h>
> > #include <sysdev/fsl_soc.h>
> > +#include <linux/fsl_devices.h>
> > #include "mpc83xx.h"
> > @@ -71,6 +72,72 @@ mpc83xx_map_irq(struct pci_dev *dev, uns
> > }
> > #endif /* CONFIG_PCI */
> > +#ifdef CONFIG_834x_USB_SUPPORT
>=20
> Just make it dependent on CONFIG_USB_EHCI_HCD or something like that.
Will need to check EHCI_HCD/GADGET and their _MODULE variations though.
Not very neat I think. Anyway, it's your call.
>=20
> > +void mpc834x_usb_board_cfg(void)
> > +{
> > + unsigned char __iomem *bcsr;
> > + volatile unsigned char *bcsr5_p;
> > +
> > + /*
> > + * if SYS board is plug into PIB board,
> > + * force to use the PHY on SYS board
> > + * */
> > + bcsr =3D ioremap(BCSR_PHYS_ADDR, BCSR_SIZE);
> > + bcsr5_p =3D bcsr + BCSR5_OFF;
> > + if ( (*bcsr5_p & BCSR5_INT_USB) =3D=3D 0 )
> > + *bcsr5_p =3D (*bcsr5_p | BCSR5_INT_USB);
> > + iounmap(bcsr);
> > +}
> > +
> > +/* Note: This is only for PB, not for PB+PIB
> > + * On PB only port0 is connected using ULPI */
> > +static int mpc834x_usb_cfg(void)
> > +{
> > + unsigned long sccr, sicrl;
> > + volatile unsigned long *p;
> > + unsigned long __iomem *immap;
> > + struct device_node *np =3D NULL;
> > + int port0_is_dr =3D 0;
> > +
> > + if ((np =3D of_find_compatible_node(np, "usb", "fsl-usb2-dr")) =
!=3D
> > NULL)
> > + port0_is_dr =3D 1;
> > + if ((np =3D of_find_compatible_node(np, "usb", "fsl-usb2-mph")) =
!=3D
> > NULL){
> > + if (port0_is_dr) {
> > + printk(KERN_WARNING
> > + "There is only one USB port on PB board!
\n");
> > + return -1;
> > + } else if (!port0_is_dr)
> > + /* No usb port enabled */
> > + return -1;
> > + }
> > +
> > + immap =3D ioremap(get_immrbase(), 0x100000);
> > +
> > + /* Configure clock */
> > + p =3D (volatile unsigned long *)((u32)immap + MPC83XX_SCCR_OFFS);
> > + sccr =3D *p;
> > + if (port0_is_dr)
> > + sccr |=3D MPC83XX_SCCR_USB_DRCM_11; /* 1:3 */
> > + else
> > + sccr |=3D MPC83XX_SCCR_USB_MPHCM_11; /* 1:3 */
> > + *p =3D sccr;
>=20
> This really needs to take into account the platform frequency. I
> guess technically, at 1:3 we will always be below the max 133Mhz.
Generally, I assume the user is using a core frequency around the
recommended frequency in spec. In some special cases, they do need to
use a lower core frequency. But, I think it's too special to be
addressed here. Anyway it's easy to change for users.
>=20
> > +
> > + /* Configure Pin */
> > + p =3D (volatile unsigned long *)((u32)immap + MPC83XX_SICRL_OFFS);
> > + sicrl =3D *p;
> > + /* set port0 only */
> > + if (port0_is_dr) + sicrl |=3D MPC83XX_SICRL_USB0;
> > + else + sicrl &=3D ~(MPC83XX_SICRL_USB0);
> > + *p =3D sicrl;
> > +
>=20
> Why dont we just do all this in fsl_usb_of_init
It's easier to do in fsl_usb_of_init. But do you think it's ok to put
834x specific code there?
>=20
> > + iounmap(immap);
> > + return 0;
> > +}
> > +
> > +#endif /* CONFIG_834x_USB_SUPPORT */
> > +
> > /*
> >
**********************************************************************
> > **
> > *
> > * Setup the architecture
> > @@ -102,6 +169,11 @@ #ifdef CONFIG_PCI
> > ppc_md.pci_exclude_device =3D mpc83xx_exclude_device;
> > #endif
> > +#ifdef CONFIG_834x_USB_SUPPORT
> > + mpc834x_usb_cfg();
> > + mpc834x_usb_board_cfg();
> > +#endif
> > +
> > #ifdef CONFIG_ROOT_NFS
> > ROOT_DEV =3D Root_NFS;
> > #else
> > diff --git a/arch/powerpc/platforms/83xx/mpc834x_sys.h b/arch/
> > powerpc/platforms/83xx/mpc834x_sys.h
> > index fedecb7..30e45e8 100644
> > --- a/arch/powerpc/platforms/83xx/mpc834x_sys.h
> > +++ b/arch/powerpc/platforms/83xx/mpc834x_sys.h
> > @@ -20,4 +20,28 @@ #define PIRQB MPC83xx_IRQ_EXT5
> > #define PIRQC MPC83xx_IRQ_EXT6
> > #define PIRQD MPC83xx_IRQ_EXT7
> > +#define BCSR_PHYS_ADDR ((uint)0xf8000000)
> > +#define BCSR_SIZE ((uint)(32 * 1024))
> > + +#define BCSR5_OFF 0x05
> > +#define BCSR5_INT_USB 0x02
> > +
> > +#define MPC83XX_SCCR_OFFS 0xA08
> > +#define MPC83XX_SCCR_USB_MPHCM_11 0x00c00000
> > +#define MPC83XX_SCCR_USB_MPHCM_01 0x00400000
> > +#define MPC83XX_SCCR_USB_MPHCM_10 0x00800000
> > +#define MPC83XX_SCCR_USB_DRCM_11 0x00300000
> > +#define MPC83XX_SCCR_USB_DRCM_01 0x00100000
> > +#define MPC83XX_SCCR_USB_DRCM_10 0x00200000
> > +
> > +/* system i/o configuration register low */
> > +#define MPC83XX_SICRL_OFFS 0x114
> > +#define MPC83XX_SICRL_USB0 0x40000000
> > +#define MPC83XX_SICRL_USB1 0x20000000
> > +
> > +/* system i/o configuration register high */
> > +#define MPC83XX_SICRH_OFFS 0x118
> > +#define MPC83XX_SICRH_USB_UTMI 0x00020000
>=20
> Are these really generic to all MPC83XX? We should move these to
> include something like asm-ppc/mpc83xx.h
No, probably need to change the naming to MPC834x_*. The offsets are
generic, but the USB bits are not. If there is an asm/mpc834x.h, it
will be better there.
>=20
> > +
> > +
> > #endif /* __MACH_MPC83XX_SYS_H__ */
>=20
> - kumar
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* RE: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform support
From: Li Yang-r58472 @ 2006-07-20 6:45 UTC (permalink / raw)
To: Pete Zaitcev; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <20060719121922.ef989b1d.zaitcev@redhat.com>
> -----Original Message-----
> From: Pete Zaitcev [mailto:zaitcev@redhat.com]
> Sent: Thursday, July 20, 2006 3:19 AM
> To: Li Yang-r58472
> Cc: dan@embeddedalley.com; linuxppc-dev@ozlabs.org;
galak@kernel.crashing.org;
> linux-usb-devel@lists.sourceforge.net; zaitcev@redhat.com
> Subject: Re: [linux-usb-devel] [PATCH] Add USB to MPC8349 PB platform
support
>=20
> On Thu, 20 Jul 2006 02:59:44 +0800, "Li Yang" <LeoLi@freescale.com>
wrote:
>=20
> > But why? Most embedded products facing end-user wouldn't like users
> > to modify the system by themselves.
>=20
> Certainly vendors won't like to give consumers extra freedoms.
> However, consumers like those freedoms, even if they would not
> use them in any specific instance.
>=20
> > Sometimes they even put effort in preventing user to do so.
>=20
> Jerks and criminals, that's what they are. Why would Linux developers
> care about needs of these people?
>=20
> Free software is about protecting the rights of users against
> vendors who "wouldn't like" users doing what they want with the
> product they bought.
>=20
> > The only kind of products I can think of, which
> > want the users to modify the code is reference boards, IMHO.
>=20
> Ever heard of WRT54? But in fact, every product out there may provide
> its owner an additional value when customized. I'd love to fix some
> bugs in my microwave, for instance. The silly thing will not start
> the timer if the door is open. It probably uses the same function
> which prevents cooking from starting (it also has a hardware interlock
> that cuts the magnetron, but this is different).
You are right. We really need to stick up for the freedom of software
as Richard Stallman advocated. :) However, I was talking about code
that goes into public kernel source tree. It's ok to distribute the
code with CD or web link. But if the code is not generic enough or
can't be reused, it won't qualify to be included in mainstream kernel
tree, I think.
-- Leo
^ permalink raw reply
* Re: reboot on PQ2FADS board.
From: Wolfgang Denk @ 2006-07-20 6:46 UTC (permalink / raw)
To: Lei Sun; +Cc: linuxppc-embedded
In-Reply-To: <f9a7e7a80607192046s3f17e8a5s4cfba43f1747e9ec@mail.gmail.com>
In message <f9a7e7a80607192046s3f17e8a5s4cfba43f1747e9ec@mail.gmail.com> you wrote:
>
> m8260_restart(char * cmd)
...
> startaddr = 0x04400000; /* this is taken from u-boot-1.1.4 */
This is a random address which happens to be not mapped in the
specific board (MPC8260ADS.h). The approach taken here is strongly
deprecated - it is juat an examp[le of a badly maintained board. In-
stead, I recommend to use an addrress which causes a checkstop on all
boards, idependently of the cspecific memory map. This is what we do
here:
> > dummy = ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
In the end, the effect is the same.
And I have no idea why it would not work on your board. Attach a
debugger and find out where exactly the code is hanging.
Ummm... and if you run under a debugger, *detach* it and check if
reset starts to work...
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It's certainly convenient the way the crime (or condition) of
stupidity carries with it its own punishment, automatically
admisistered without remorse, pity, or prejudice. :-)
-- Tom Christiansen in <559seq$ag1$1@csnews.cs.colorado.edu>
^ permalink raw reply
* Re: [PATCH] Add USB to MPC8349 PB platform support
From: Marc Leeman @ 2006-07-20 7:21 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <4AC92920-4642-4899-B8CA-8EE5A1CDE0B3@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2302 bytes --]
> >Though I do agree that there is a gap: it would be nice to have some
> >place to submit the kernel patches;
>
> This should be the kernel. The general rule of thumb I've used is if
> its useful to more than one other person its worth trying to get into
> the kernel. However, I can see if you are doing a one off kernel for
That is about the same rule that I use; luckily (a credit to the Linux
kernel and other developers); I don't have to change much stuff like
that.
> your embedded product that getting your changes into the kernel
> wouldn't be worth while. You have to have a desire to interact with
> the community if you want to get your code in.
There is a grey zone, but let's talk about a specific case:
In my current queue, I have to write a Host Port Interface (HPI) protocol
(serial) to a TI DSP. I would imagine that this is a useful
contribution. However, using HPI is almost by nature limited to specific
embedded designs (most of which differ slightly from one another).
Furthermore; I will need to use a number of GPIO pins on a 834x
processor. Using this needs to be backed by configuration settings in
U-Boot. If someone else makes a similar design; it would most likely be
with another processor family; and even then; they'll have other pins
connected/used.
Though the protocol would be a real nice addition; the physical
connection/configuration make including it in the main kernel tree
difficult.
> Personally, I see it useful if for no other reason that someone will
> fixup my board port if/when they change something which will make my
> moving to a newer kernel release that much easier.
Even though I would welcome this; our boards are included in larger
expensive systems that would just be shipped back in case of problems;
but we've never had functional (linux) problems (yet).
Come to think of it, I have a number of minor patches for 8349SYS based
configurations; where can I find the last devel code (next to 2.6.17)
for patch creation (and to whom to send them back)?
--
greetz, marc
If you must address me, do so as Your Supreme Eminence. Which you
should be doing anyway.
Rygel - Throne for a Loss
scorpius.homelinux.org 2.6.17 #2 PREEMPT Thu Jun 22 07:18:33 CEST 2006 GNU/Linux
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* RE: reboot on PQ2FADS board.
From: Liu Dave-r63238 @ 2006-07-20 7:22 UTC (permalink / raw)
To: Wolfgang Denk, Li Yang-r58472; +Cc: linuxppc-embedded
In-Reply-To: <20060719063317.86A66352681@atlas.denx.de>
This way maybe can not work. when the MMU turn off,=20
the next instructions maybe can not be fetched if these instructions
didn't exist cache.=20
so it is possible these instruction can not executed. =20
>=20
> Trying to jump to some boot rom address is IMHO always a bad=20
> approach to reboot a system. You should always try to cause a=20
> reset condition for the CPU, and thus for all the=20
> associated hardware. On 8xx / 8260 systems this is usually=20
> done by going through a machine check. We have the =20
> following code in our linuxppc_2_4_devel tree, which works on=20
> ALL 8260 systems, no matter whioch boot loder they use:
>=20
> static void
> m8260_restart(char *cmd)
> { =20
> __volatile__ unsigned char dummy;
> ulong msr;
> =20
> cli();
> volatile immap_t *immap =3D (immap_t *) IMAP_ADDR;
> =20
> immap->im_clkrst.car_rmr =3D 1; /* Checkstop Reset enable =
*/
> =20
> /* Interrupts and MMU off */
> __asm__ __volatile__ ("mfmsr %0":"=3Dr" (msr):);
> =20
> msr &=3D ~(MSR_ME | MSR_EE | MSR_IR | MSR_DR);
> __asm__ __volatile__ ("mtmsr %0"::"r" (msr));=20
> =20
Now the MMU trun off, is real address mode. But the PC still is
0xC00xxxx.. It is old effective address.
> dummy =3D ((immap_t *)IMAP_ADDR)->im_clkrst.res[0];
These instructions will locate on the real address space...... It is
0xC00xxxx- KERNELBASE
> =20
> printk("Restart failed\n");
> for (;;);
> } =20
>=20
^ permalink raw reply
* regarding MAL
From: Sangameshwar Pujari @ 2006-07-20 8:03 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 214 bytes --]
Hi,
i am porting a EMAC driver from NetBSD to my Xilinix ML403 embeddded board . NETBSD code is Having a Media Access Layer (MAL) , which i want to know bit , is it the same MAC layer .
regards
sangamesh
[-- Attachment #2: Type: text/html, Size: 703 bytes --]
^ permalink raw reply
* Re: MPC8260 SCC UART hardware flow control
From: Mathieu Deschamps @ 2006-07-20 8:18 UTC (permalink / raw)
To: Laurent Pinchart; +Cc: linuxppc-embedded
In-Reply-To: <200607191718.00328.laurent.pinchart@tbox.biz>
Hi Laurent,
On Wednesday 19 July 2006 17:18, Laurent Pinchart wrote:
> Hi everybody,
>
> I was wondering if anyone had implemented hardware flow control support in
> the cpm_uart driver. If not, I would appreciate pointers regarding how to
> do so.
>
> Best regards,
>
> Laurent Pinchart
>
I had. PQ2 CPM is a dedicated part which handles this aspect for you via
its microcode. This also means you can't play with it the old way and making
your own HHS with a CD/DSR :). Back to seriousness, rather this means you
needn't adding modem signal handling in cpm_uart driver. So don't define
modem_something that's an ancient reliq from the times, I guess, no CPM was
put auxillary.
So how to tell CPM to cope with HHS ? Simple, you "just" have to put SCC's
Dedicated pins the right way which depends on your board type. Remember you
can't do any HHS with SMC. Refer to Dedicated Pins chapter in the litterature
[41.4.2]. Also take a look at SCC GSMR register [20.8] and to SCC UART mode
PSMR register [21-14] to maybe use protocol specificities.
When you'll have your kernel ready, you would do probably something like :
stty -F $port crtscts $SPEED
As Wolfgang said HHS works for DTE-DCE only (roughly but visually you must
have plugs opposite gender on both ends), trying DTE-DTE HHS dialog is bound
to failure despite time spend on it.
Cdy,
Mathieu Deschamps
Com2gether Design Center
Electronic and Embedded Engineering Services
www.com2gether.net
^ permalink raw reply
* RE: Linux bin Commands download
From: Li Yang-r58472 @ 2006-07-20 8:54 UTC (permalink / raw)
To: andreas Sotirakopoulos; +Cc: linuxppc-embedded
In-Reply-To: <200607201134.02445.menwn@yahoo.co.uk>
So you are using embedded powerpc platform? There are several embedded
Linux distributions, e.g. from montavista, denx, and Freescale. You can
google them yourself.
If you are using Freescale powerpc, I would recommend the LTIB BSP
packages which can be downloaded at www.freescale.com
Best Regards,
Leo
> -----Original Message-----
> From: andreas Sotirakopoulos [mailto:menwn@yahoo.co.uk]
> Sent: Thursday, July 20, 2006 4:34 PM
> To: Li Yang-r58472
> Subject: Re: Linux bin Commands download
>=20
> On Wednesday 19 July 2006 08:31, you wrote:
> Thanks, I would like though to know... is rpm suitable for the purpose
i want
> them?
> I want to store the commands (lets say the command ls) in a directory
> on a FreeBSD 6 box (i386) and export this directory for NFS so as to
mount it
> bfrom the powerpc and run the commands from that directory.
> thanks in advance
> andreas
> > > -----Original Message-----
> > > From: linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org
> > > [mailto:linuxppc-dev-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf
> >
> > Of none
> >
> > > none
> > > Sent: Tuesday, July 18, 2006 8:35 PM
> > > To: linuxppc-dev@ozlabs.org
> > > Subject: Linux bin Commands download
> > >
> > > Hi
> > > I would like to download precompiled linux commands
> > > and programs for powerPC but i cannot find any
> > > binaries anyware. Are there any links?
> >
> > You can find rpm at http://rpmfind.net. And there are also a couple
of
> > powerpc distributions out there.
> >
> > > thanks in advance
> > > sotirakopoulos andreas
>=20
>=20
>=20
>=20
> ___________________________________________________________
> All new Yahoo! Mail "The new Interface is stunning in its simplicity
and ease of
> use." - PC Magazine
> http://uk.docs.yahoo.com/nowyoucan.html
^ permalink raw reply
* loading large lkm is so slow on ppc linux
From: Miao Qingjun @ 2006-07-20 9:17 UTC (permalink / raw)
To: linuxppc-embedded, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 222 bytes --]
Hi,
It seems module_frob_arch_sections()/count_relocs() spent so much time when loading large lkm.
Can just "return 0" in ppc version of module_frob_arch_sections()?
or just "return num" in count_relocs()?
thanks
[-- Attachment #2: Type: text/html, Size: 759 bytes --]
^ permalink raw reply
* mpc8360sar
From: Alex Zeffertt @ 2006-07-20 10:39 UTC (permalink / raw)
To: linuxppc-embedded, linux-atm-general
Hi lists,
I'm writing to announce a new project http://mpc8360sar.sourceforge.net .
This is an ATM driver for the QUICC Engine (QE) of the PowerQUICC II Pro
range of processors. It is based on Tony Li's fsl-atm driver and my
mpc8260sar driver. I've basically used Tony's driver for the most low level
stuff and ported a lot of extra functionality from my PQII driver.
You will need the Linux BSP from Freescale to build this driver.
I have only tested this driver on mpc832xe-mds, but it should also work on
the mpc8360e-pb board.
If you use mpc8360sar, please let me know how you get on. In particular
let me know if you work out how to stop the QE occaisionally corrupting the
TCT when using external channels.
Regards,
Alex
^ permalink raw reply
* RE: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB hostdependency
From: Li Yang-r58472 @ 2006-07-20 11:42 UTC (permalink / raw)
To: Kumar Gala, gregkh; +Cc: linuxppc-dev, linux-usb-devel
In-Reply-To: <6DFEB2BB-05AB-441E-854E-297987B97A0E@kernel.crashing.org>
Another one in header file.
---
diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
index 679c1cd..8da2774 100644
--- a/drivers/usb/host/ehci.h
+++ b/drivers/usb/host/ehci.h
@@ -642,7 +642,7 @@ #endif
=20
/*----------------------------------------------------------------------
---*/
-#ifdef CONFIG_PPC_83xx
+#ifdef CONFIG_MPC834x
/* Some Freescale processors have an erratum in which the TT
* port number in the queue head was 0..N-1 instead of 1..N.
*/
> -----Original Message-----
> From: linux-usb-devel-bounces@lists.sourceforge.net
> [mailto:linux-usb-devel-bounces@lists.sourceforge.net] On Behalf Of
Kumar Gala
> Sent: Friday, July 14, 2006 9:52 PM
> To: Li Yang-r58472
> Cc: linuxppc-dev@ozlabs.org; gregkh@suse.de;
> linux-usb-devel@lists.sourceforge.net
> Subject: Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB
hostdependency
>=20
> Acked-by: Kumar Gala <galak@kernel.crashing.org>
>=20
> On Jul 14, 2006, at 6:58 AM, Li Yang wrote:
>=20
> > The high-speed USB SOC only exists on MPC834x family not MPC83xx
> > family.
> >
> > Signed-off-by: Li Yang <leoli@freescale.com>
> >
> > ---
> >
> > drivers/usb/host/ehci-hcd.c | 2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-
> > hcd.c index 79f2d8b..3af1844 100644
> > --- a/drivers/usb/host/ehci-hcd.c
> > +++ b/drivers/usb/host/ehci-hcd.c
> > @@ -892,7 +892,7 @@ #include "ehci-pci.c"
> > #define EHCI_BUS_GLUED
> > #endif
> >
> > -#ifdef CONFIG_PPC_83xx
> > +#ifdef CONFIG_MPC834x
> > #include "ehci-fsl.c"
> > #define EHCI_BUS_GLUED
> > #endif
^ permalink raw reply related
* RE: [Linux-ATM-General] mpc8360sar
From: Li Tony-r64360 @ 2006-07-20 12:07 UTC (permalink / raw)
To: Alex Zeffertt, linuxppc-embedded, linux-atm-general
In-Reply-To: <44BF5D6D.1070400@cambridgebroadband.com>
Hi, alex
I am tony li. I am glad to know that you add many features support.
Do you have test the UBR and AAL0 ? I am lack of enviroment test them
now.
I have not read your code detailly.:)
And which ltib release version is your base ? I have updated my code a
little which contain a workaround for a bug.
Tony.li =20
-----Original Message-----
From: linux-atm-general-bounces@lists.sourceforge.net
[mailto:linux-atm-general-bounces@lists.sourceforge.net] On Behalf Of
Alex Zeffertt
Sent: Thursday, July 20, 2006 6:40 PM
To: linuxppc-embedded@ozlabs.org;
linux-atm-general@lists.sourceforge.net
Subject: [Linux-ATM-General] mpc8360sar
Hi lists,
I'm writing to announce a new project http://mpc8360sar.sourceforge.net
.
This is an ATM driver for the QUICC Engine (QE) of the PowerQUICC II Pro
range of processors. It is based on Tony Li's fsl-atm driver and my
mpc8260sar driver. I've basically used Tony's driver for the most low
level stuff and ported a lot of extra functionality from my PQII driver.
You will need the Linux BSP from Freescale to build this driver.
I have only tested this driver on mpc832xe-mds, but it should also work
on the mpc8360e-pb board.
If you use mpc8360sar, please let me know how you get on. In particular
let me know if you work out how to stop the QE occaisionally corrupting
the TCT when using external channels.
Regards,
Alex
------------------------------------------------------------------------
-
Take Surveys. Earn Cash. Influence the Future of IT Join
SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D=
DEVDE
V
_______________________________________________
Linux-atm-general mailing list
Linux-atm-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-atm-general
^ permalink raw reply
* RE: AltiVec in the kernel
From: Matt Sealey @ 2006-07-20 12:31 UTC (permalink / raw)
To: 'Linas Vepstas', 'Paul Mackerras'
Cc: 'linuxppc-dev list'
In-Reply-To: <20060719181047.GL5905@austin.ibm.com>
> But perhaps, in principle, couldn't one run four independent
> streams in parallel? Thus, for example, on an SSL-enabled
> web server, one could service multiple encryption/decryption
> threads at once.
>
> In practice, I don't beleive the infrastructure for that kind
> of parallelism is in place. I'm struggling to find a reason
> to develop that kind of infrastructure. Mumble something about Cell.
If not AltiVec there is potential to use some features which come
with AltiVec like the data stream functionality. Or even the standard
PPC cache control stuff would work.
What's the case in the kernel for the memcpy functions etc., are
they optimized for doing things like longword copies rather than
byte-per-byte etc.? We found glibc sucked for that.
--
Matt Sealey <matt@genesi-usa.com>
Manager, Genesi, Developer Relations
^ permalink raw reply
* Re: [Linux-ATM-General] mpc8360sar
From: Alex Zeffertt @ 2006-07-20 12:35 UTC (permalink / raw)
To: Li Tony-r64360; +Cc: linux-atm-general, linuxppc-embedded
In-Reply-To: <995B09A8299C2C44B59866F6391D2635058751@zch01exm21.fsl.freescale.net>
Hi,
Yes, UBR and AAL0 work. I've also added support for the qos parameters
min_pcr, pcr, and max_pcr.
I used ltib-mpc832xemds-20060615 as my base. More details are on the
website.
BTW, I left all your code in. There's a simple config option now which
allows you to choose between the two drivers.
Alex
PS Thanks!
Li Tony-r64360 wrote:
> Hi, alex
> I am tony li. I am glad to know that you add many features support.
> Do you have test the UBR and AAL0 ? I am lack of enviroment test them
> now.
> I have not read your code detailly.:)
> And which ltib release version is your base ? I have updated my code a
> little which contain a workaround for a bug.
>
> Tony.li
>
> -----Original Message-----
> From: linux-atm-general-bounces@lists.sourceforge.net
> [mailto:linux-atm-general-bounces@lists.sourceforge.net] On Behalf Of
> Alex Zeffertt
> Sent: Thursday, July 20, 2006 6:40 PM
> To: linuxppc-embedded@ozlabs.org;
> linux-atm-general@lists.sourceforge.net
> Subject: [Linux-ATM-General] mpc8360sar
>
> Hi lists,
>
> I'm writing to announce a new project http://mpc8360sar.sourceforge.net
> .
> This is an ATM driver for the QUICC Engine (QE) of the PowerQUICC II Pro
> range of processors. It is based on Tony Li's fsl-atm driver and my
> mpc8260sar driver. I've basically used Tony's driver for the most low
> level stuff and ported a lot of extra functionality from my PQII driver.
>
> You will need the Linux BSP from Freescale to build this driver.
>
> I have only tested this driver on mpc832xe-mds, but it should also work
> on the mpc8360e-pb board.
>
> If you use mpc8360sar, please let me know how you get on. In particular
> let me know if you work out how to stop the QE occaisionally corrupting
> the TCT when using external channels.
>
> Regards,
>
> Alex
>
> ------------------------------------------------------------------------
> -
> Take Surveys. Earn Cash. Influence the Future of IT Join
> SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys -- and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
> V
> _______________________________________________
> Linux-atm-general mailing list
> Linux-atm-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-atm-general
^ permalink raw reply
* Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB hostdependency
From: Kumar Gala @ 2006-07-20 12:59 UTC (permalink / raw)
To: Li Yang-r58472; +Cc: linuxppc-dev, gregkh, linux-usb-devel
In-Reply-To: <4879B0C6C249214CBE7AB04453F84E4D07064D@zch01exm20.fsl.freescale.net>
On Jul 20, 2006, at 6:42 AM, Li Yang-r58472 wrote:
> Another one in header file.
>
> ---
> diff --git a/drivers/usb/host/ehci.h b/drivers/usb/host/ehci.h
> index 679c1cd..8da2774 100644
> --- a/drivers/usb/host/ehci.h
> +++ b/drivers/usb/host/ehci.h
> @@ -642,7 +642,7 @@ #endif
>
>
> /
> *---------------------------------------------------------------------
> -
> ---*/
>
> -#ifdef CONFIG_PPC_83xx
> +#ifdef CONFIG_MPC834x
> /* Some Freescale processors have an erratum in which the TT
> * port number in the queue head was 0..N-1 instead of 1..N.
> */
Do we really want to make this change. What harm is there in having
the ehci support for MPC834x build on all 83xx processors? I can't
imagine we are going to config in support for ehci on anything that
is MPC834x at this point and if you do, your device tree isn't going
to have nodes in it so the drivers not going to bind against anything.
Finally, I got to believe Freescale's going to build some MPC83xx in
the future with the high speed USB IP.
- kumar
>
>> -----Original Message-----
>> From: linux-usb-devel-bounces@lists.sourceforge.net
>> [mailto:linux-usb-devel-bounces@lists.sourceforge.net] On Behalf Of
> Kumar Gala
>> Sent: Friday, July 14, 2006 9:52 PM
>> To: Li Yang-r58472
>> Cc: linuxppc-dev@ozlabs.org; gregkh@suse.de;
>> linux-usb-devel@lists.sourceforge.net
>> Subject: Re: [linux-usb-devel] [PATCH] Fix Freescale high-speed USB
> hostdependency
>>
>> Acked-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> On Jul 14, 2006, at 6:58 AM, Li Yang wrote:
>>
>>> The high-speed USB SOC only exists on MPC834x family not MPC83xx
>>> family.
>>>
>>> Signed-off-by: Li Yang <leoli@freescale.com>
>>>
>>> ---
>>>
>>> drivers/usb/host/ehci-hcd.c | 2 +-
>>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>>
>>> diff --git a/drivers/usb/host/ehci-hcd.c b/drivers/usb/host/ehci-
>>> hcd.c index 79f2d8b..3af1844 100644
>>> --- a/drivers/usb/host/ehci-hcd.c
>>> +++ b/drivers/usb/host/ehci-hcd.c
>>> @@ -892,7 +892,7 @@ #include "ehci-pci.c"
>>> #define EHCI_BUS_GLUED
>>> #endif
>>>
>>> -#ifdef CONFIG_PPC_83xx
>>> +#ifdef CONFIG_MPC834x
>>> #include "ehci-fsl.c"
>>> #define EHCI_BUS_GLUED
>>> #endif
>
^ permalink raw reply
* Re: export-objs in spi Makefile broke in latest linuxppc_2_4_deve l [r eposted]?
From: Kumar Gala @ 2006-07-20 13:12 UTC (permalink / raw)
To: hs; +Cc: Chad.Rowan, linuxppc-embedded
In-Reply-To: <1153371343.6004.16.camel@Zeus.EmbLux>
On Jul 19, 2006, at 11:55 PM, Heiko Schocher wrote:
> Hello Chad
>
>> linuxppc_2_4_devel is alive and well.
>>
>> http://www.denx.de/cgi-bin/gitweb.cgi?
>> p=linuxppc_2_4_devel.git;a=shortlog
>
> You speak from the DENX linuxppc_2_4_devel Kernel? If so, I think
> you are right.
> I had the same problem, some days ago. I made a SPI bitbanging
> algorithm, but
> I dont know, if this goes in the git repository from DENX ...
> Wolfgang?
I think this issue should be taken off list.
- k
^ permalink raw reply
* Re: [Linux-ATM-General] mpc8360sar
From: Kumar Gala @ 2006-07-20 13:13 UTC (permalink / raw)
To: Alex Zeffertt; +Cc: linux-atm-general, linuxppc-embedded, Li Tony-r64360
In-Reply-To: <44BF787F.3020203@cambridgebroadband.com>
On Jul 20, 2006, at 7:35 AM, Alex Zeffertt wrote:
> Hi,
>
> Yes, UBR and AAL0 work. I've also added support for the qos
> parameters
> min_pcr, pcr, and max_pcr.
>
> I used ltib-mpc832xemds-20060615 as my base. More details are on the
> website.
>
> BTW, I left all your code in. There's a simple config option now
> which
> allows you to choose between the two drivers.
>
> Alex
>
> PS Thanks!
Any reason we dont try to get your work up stream into the mainline
kernel?
- kumar
> Li Tony-r64360 wrote:
>> Hi, alex
>> I am tony li. I am glad to know that you add many features support.
>> Do you have test the UBR and AAL0 ? I am lack of enviroment test them
>> now.
>> I have not read your code detailly.:)
>> And which ltib release version is your base ? I have updated my
>> code a
>> little which contain a workaround for a bug.
>>
>> Tony.li
>>
>> -----Original Message-----
>> From: linux-atm-general-bounces@lists.sourceforge.net
>> [mailto:linux-atm-general-bounces@lists.sourceforge.net] On Behalf Of
>> Alex Zeffertt
>> Sent: Thursday, July 20, 2006 6:40 PM
>> To: linuxppc-embedded@ozlabs.org;
>> linux-atm-general@lists.sourceforge.net
>> Subject: [Linux-ATM-General] mpc8360sar
>>
>> Hi lists,
>>
>> I'm writing to announce a new project http://
>> mpc8360sar.sourceforge.net
>> .
>> This is an ATM driver for the QUICC Engine (QE) of the PowerQUICC
>> II Pro
>> range of processors. It is based on Tony Li's fsl-atm driver and my
>> mpc8260sar driver. I've basically used Tony's driver for the most
>> low
>> level stuff and ported a lot of extra functionality from my PQII
>> driver.
>>
>> You will need the Linux BSP from Freescale to build this driver.
>>
>> I have only tested this driver on mpc832xe-mds, but it should also
>> work
>> on the mpc8360e-pb board.
>>
>> If you use mpc8360sar, please let me know how you get on. In
>> particular
>> let me know if you work out how to stop the QE occaisionally
>> corrupting
>> the TCT when using external channels.
>>
>> Regards,
>>
>> Alex
>>
>> ---------------------------------------------------------------------
>> ---
>> -
>> Take Surveys. Earn Cash. Influence the Future of IT Join
>> SourceForge.net's Techsay panel and you'll get the chance to share
>> your
>> opinions on IT & business topics through brief surveys -- and earn
>> cash
>> http://www.techsay.com/default.php?
>> page=join.php&p=sourceforge&CID=DEVDE
>> V
>> _______________________________________________
>> Linux-atm-general mailing list
>> Linux-atm-general@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/linux-atm-general
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* RE: [PATCH] clean up pseries hcall interfaces
From: Levand, Geoffrey @ 2006-07-20 13:14 UTC (permalink / raw)
To: Anton Blanchard ,
linuxppc-dev-bounces+geoffrey.levand=am.sony.com, linuxppc-dev
Cc: paulus
> From: Anton Blanchard
>=20
> Our pseries hcall interfaces are out of control:
Seems like this in needed too... Untested.
Change the scope of some pSeries routines now called through
ppc_md to static.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
--
Index: a/arch/powerpc/platforms/pseries/lpar.c
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- a.orig/arch/powerpc/platforms/pseries/lpar.c 2006-07-18
12:37:47.000000000 -0700
+++ a/arch/powerpc/platforms/pseries/lpar.c 2006-07-20
05:18:59.000000000 -0700
@@ -268,7 +268,7 @@
cpu, hwcpu, vpa, ret);
}
=20
-long pSeries_lpar_hpte_insert(unsigned long hpte_group,
+static long pSeries_lpar_hpte_insert(unsigned long hpte_group,
unsigned long va, unsigned long pa,
unsigned long rflags, unsigned long
vflags,
int psize)
@@ -494,7 +494,7 @@
* Take a spinlock around flushes to avoid bouncing the hypervisor
tlbie
* lock.
*/
-void pSeries_lpar_flush_hash_range(unsigned long number, int local)
+static void pSeries_lpar_flush_hash_range(unsigned long number, int
local)
{
int i;
unsigned long flags =3D 0;
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox