* Re: [patch 14/16] powerpc: make initialization of OF hooks dependent on PPC_OF
From: Benjamin Herrenschmidt @ 2006-11-02 22:35 UTC (permalink / raw)
To: s.hauer; +Cc: linuxppc-dev
In-Reply-To: <20061102125629.771962000@localhost.localdomain>
On Thu, 2006-11-02 at 13:56 +0100, s.hauer@pengutronix.de wrote:
> plain text document attachment
> (powerpc-head_32.S-remove-MULTIPLATFORM.diff)
> Make initialization of OF hooks dependent on PPC_OF, not on MULTIPLATFORM
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Though see my comment about your previous patch... In fact, they could
be one patch since things might not work/build if you only apply one of
them. So 13 and 14 should be folded into one.
> Index: arch/powerpc/kernel/head_32.S
> ===================================================================
> --- a/arch/powerpc/kernel/head_32.S.orig
> +++ b/arch/powerpc/kernel/head_32.S
> @@ -119,7 +119,7 @@ __start:
> * because OF may have I/O devices mapped into that area
> * (particularly on CHRP).
> */
> -#ifdef CONFIG_PPC_MULTIPLATFORM
> +#ifdef CONFIG_PPC_OF
> cmpwi 0,r5,0
> beq 1f
> bl prom_init
>
> --
> Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Hannoversche Str. 2, 31134 Hildesheim, Germany
> Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [patch 15/16] powerpc: clean up usage of boot_dev
From: Benjamin Herrenschmidt @ 2006-11-02 22:36 UTC (permalink / raw)
To: s.hauer; +Cc: linuxppc-dev
In-Reply-To: <20061102125630.211637000@localhost.localdomain>
On Thu, 2006-11-02 at 13:56 +0100, s.hauer@pengutronix.de wrote:
> plain text document attachment
> (powerpc-pmac-move-boot_dev-to-pmac.diff)
> dev_t boot_dev is declared in arch/powerpc/kernel/setup_32.c
> and in arch/powerpc/kernel/setup_64.c but not used in these files.
> It is only used in arch/powerpc/platforms/powermac/setup.c, so make
> it static in this file
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Index: arch/powerpc/kernel/setup_32.c
> ===================================================================
> --- a/arch/powerpc/kernel/setup_32.c.orig
> +++ b/arch/powerpc/kernel/setup_32.c
> @@ -63,10 +63,6 @@ unsigned int DMA_MODE_WRITE;
>
> int have_of = 1;
>
> -#ifdef CONFIG_PPC_MULTIPLATFORM
> -dev_t boot_dev;
> -#endif /* CONFIG_PPC_MULTIPLATFORM */
> -
> #ifdef CONFIG_VGA_CONSOLE
> unsigned long vgacon_remap_base;
> #endif
> Index: arch/powerpc/kernel/setup_64.c
> ===================================================================
> --- a/arch/powerpc/kernel/setup_64.c.orig
> +++ b/arch/powerpc/kernel/setup_64.c
> @@ -71,7 +71,6 @@
>
> int have_of = 1;
> int boot_cpuid = 0;
> -dev_t boot_dev;
> u64 ppc64_pft_size;
>
> /* Pick defaults since we might want to patch instructions
> Index: arch/powerpc/platforms/powermac/setup.c
> ===================================================================
> --- a/arch/powerpc/platforms/powermac/setup.c.orig
> +++ b/arch/powerpc/platforms/powermac/setup.c
> @@ -361,7 +361,7 @@ char *bootdevice;
> void *boot_host;
> int boot_target;
> int boot_part;
> -extern dev_t boot_dev;
> +static dev_t boot_dev;
>
> #ifdef CONFIG_SCSI
> void __init note_scsi_host(struct device_node *node, void *host)
>
> --
> Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Hannoversche Str. 2, 31134 Hildesheim, Germany
> Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [patch 16/16] powerpc: make nvram_64.o a 64bit-only object
From: Benjamin Herrenschmidt @ 2006-11-02 22:36 UTC (permalink / raw)
To: s.hauer; +Cc: linuxppc-dev
In-Reply-To: <20061102125630.648324000@localhost.localdomain>
On Thu, 2006-11-02 at 13:56 +0100, s.hauer@pengutronix.de wrote:
> plain text document attachment
> (powerpc-make-nvram_64.c-a-64bit-object.diff)
> Make nvram_64.o dependent on 64bit, not on MULTIPLATFORM
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Index: arch/powerpc/kernel/Makefile
> ===================================================================
> --- a/arch/powerpc/kernel/Makefile.orig
> +++ b/arch/powerpc/kernel/Makefile
> @@ -17,7 +17,7 @@ obj-y += vdso32/
> obj-$(CONFIG_PPC64) += setup_64.o binfmt_elf32.o sys_ppc32.o \
> signal_64.o ptrace32.o \
> paca.o cpu_setup_ppc970.o \
> - firmware.o sysfs.o
> + firmware.o sysfs.o nvram_64.o
> obj-$(CONFIG_PPC64) += vdso64/
> obj-$(CONFIG_ALTIVEC) += vecemu.o vector.o
> obj-$(CONFIG_PPC_970_NAP) += idle_power4.o
> @@ -32,7 +32,6 @@ obj-$(CONFIG_LPARCFG) += lparcfg.o
> obj-$(CONFIG_IBMVIO) += vio.o
> obj-$(CONFIG_IBMEBUS) += ibmebus.o
> obj-$(CONFIG_GENERIC_TBSYNC) += smp-tbsync.o
> -obj64-$(CONFIG_PPC_MULTIPLATFORM) += nvram_64.o
> obj-$(CONFIG_CRASH_DUMP) += crash_dump.o
> obj-$(CONFIG_6xx) += idle_6xx.o l2cr_6xx.o cpu_setup_6xx.o
> obj-$(CONFIG_TAU) += tau_6xx.o
>
> --
> Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
> Pengutronix - Linux Solutions for Science and Industry
> Handelsregister: Amtsgericht Hildesheim, HRA 2686
> Hannoversche Str. 2, 31134 Hildesheim, Germany
> Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] spufs: always map local store non-guarded
From: Michael Ellerman @ 2006-11-03 0:28 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel, cbe-oss-dev
In-Reply-To: <200611021346.49473.arnd@arndb.de>
[-- Attachment #1: Type: text/plain, Size: 1796 bytes --]
On Thu, 2006-11-02 at 13:46 +0100, Arnd Bergmann wrote:
> When fixing spufs to map the 'mem' file backing store cacheable,
> I incorrectly set the physical mapping to use both cache-inhibited
> and guarded mapping, which resulted in a serious performance
> degradation.
>
> Accessing the real local store memory needs to be cache-inhibited,
> in order to maintain data consistency, but since it is actual
> RAM, there is no point in a guarded mapping.
>
> Debugged-by: Michael Ellerman <michael@ellerman.id.au>
> Signed-off-by: Arnd Bergmann <arnd.bergmann@de.ibm.com>
> ---
Looks good, cheers
Acked-by: Michael Ellerman <michael@ellerman.id.au>
>
> This fixes a regression in 2.6.19, please merge.
>
> Index: linux-2.6/arch/powerpc/platforms/cell/spufs/file.c
> ===================================================================
> --- linux-2.6.orig/arch/powerpc/platforms/cell/spufs/file.c
> +++ linux-2.6/arch/powerpc/platforms/cell/spufs/file.c
> @@ -104,11 +104,11 @@ spufs_mem_mmap_nopage(struct vm_area_str
>
> if (ctx->state == SPU_STATE_SAVED) {
> vma->vm_page_prot = __pgprot(pgprot_val(vma->vm_page_prot)
> - & ~(_PAGE_NO_CACHE | _PAGE_GUARDED));
> + & ~_PAGE_NO_CACHE);
> page = vmalloc_to_page(ctx->csa.lscsa->ls + offset);
> } else {
> vma->vm_page_prot = __pgprot(pgprot_val(vma->vm_page_prot)
> - | _PAGE_NO_CACHE | _PAGE_GUARDED);
> + | _PAGE_NO_CACHE);
> page = pfn_to_page((ctx->spu->local_store_phys + offset)
> >> PAGE_SHIFT);
> }
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Clear OS / HAL separation
From: M Ptich @ 2006-11-03 3:39 UTC (permalink / raw)
To: linuxppc-dev
I am porting 2.6 kernel from Freescale onto our PPC platform. This is my
first experience with Linux, and I was unpleasantly surprised how poorly OS
and platform code are separated. So I have a question: is there a project
underway, somewhere, that is trying to separate OS and HAL (or Board Support
Package) for the next Linux kernel ?
Would highly appreciate any relevant pointers.
_________________________________________________________________
Stay in touch with old friends and meet new ones with Windows Live Spaces
http://clk.atdmt.com/MSN/go/msnnkwsp0070000001msn/direct/01/?href=http://spaces.live.com/spacesapi.aspx?wx_action=create&wx_url=/friends.aspx&mkt=en-us
^ permalink raw reply
* [PATCH] cell: set ARCH_SPARSEMEM_DEFAULT in Kconfig
From: Geoff Levand @ 2006-11-03 5:08 UTC (permalink / raw)
To: Arnd Bergmann; +Cc: linuxppc-dev
The current cell processor support needs sparsemem, so set it as
the default memory model.
Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com>
--
As noted by Benjamin Herrenschmidt.
Index: cell--common--6/arch/powerpc/Kconfig
===================================================================
--- cell--common--6.orig/arch/powerpc/Kconfig
+++ cell--common--6/arch/powerpc/Kconfig
@@ -734,7 +743,7 @@
config ARCH_SPARSEMEM_DEFAULT
def_bool y
- depends on SMP && PPC_PSERIES
+ depends on (SMP && PPC_PSERIES) || PPC_CELL
config ARCH_POPULATES_NODE_MAP
def_bool y
^ permalink raw reply
* kernel oops in m41t00 rtc routines
From: Phil Nitschke @ 2006-11-03 5:47 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
Some time ago we built a 2.6.17, then a 2.6.18 kernel for our 7448
PowerPC processor using source from kernel.org. However we've suffered
from the following problem whenever the m41t00 code is accessed:
kernel: Oops: kernel access of bad area, sig: 11 [#1]
kernel: NIP: C012DA14 LR: C010B944 CTR: 00000000
kernel: REGS: efd9dd50 TRAP: 0300 Not tainted (2.6.18-pmppc744x)
kernel: MSR: 00009032 <EE,ME,IR,DR> CR: 28002488 XER: 00000000
kernel: DAR: 00000004, DSISR: 40000000
kernel: TASK = efd720b0[55] 'hwclock' THREAD: efd9c000
kernel: GPR00: 00000000 EFD9DE00 EFD720B0 EFD9DE94 00000000 00000000 EFD9DEB4 0FF70500
kernel: GPR08: 40247009 00000000 00000001 EFD8D360 88002488 1001E7F8 00000000 7FF5E6D0
kernel: GPR16: 00000000 00000000 10010000 00000000 EFD9DE14 C0240000 00000000 00000000
kernel: GPR24: 00000000 C024400A 0006E919 40247009 FFFFFFF7 EFCFF960 EFD9DE94 EFD9DE09
kernel: NIP [C012DA14] m41t00_get_rtc_time+0x30/0x268
kernel: LR [C010B944] gen_rtc_ioctl+0xb8/0x338
kernel: Call Trace:
kernel: [EFD9DE00] [EFCFF960] 0xefcff960 (unreliable)
kernel: [EFD9DE70] [C010B944] gen_rtc_ioctl+0xb8/0x338
kernel: [EFD9DED0] [C00760D0] do_ioctl+0x80/0x84
kernel: [EFD9DEE0] [C0076160] vfs_ioctl+0x8c/0x418
kernel: [EFD9DF10] [C007652C] sys_ioctl+0x40/0x74
kernel: [EFD9DF40] [C0004460] ret_from_syscall+0x0/0x38
kernel: Instruction dump:
kernel: 7c0802a6 9421ff90 be810040 3ea0c024 39400001 3be10009 90010074 38000000
kernel: 81356718 3a810014 98010008 38000000 <a1690004> 39210008 b0010016 38000008
We have modified the kernel using a series of patches we've developed
here over time. However, other than adding marvell DMA support, the
patches mostly just create a 'platform' file for the PmPPC7448, which is
almost identical to arch/ppc/platforms/katana.c, so I'm guessing that
(a) the patches we're applying aren't the problem, and (b) the katana
board would suffer the same problem.
I also suspect the M41T00 RTC I2C Client Driver was re-written about the
time that we started seeing problems being introduced...
Has anyone else used recent kernels on these platforms?
Thanks for any suggestions you can offer,
--
Phil
^ permalink raw reply
* Re: Clear OS / HAL separation
From: Grant Likely @ 2006-11-03 6:15 UTC (permalink / raw)
To: M Ptich; +Cc: linuxppc-dev
In-Reply-To: <BAY102-F21F34507B25D8615CACD06A9FE0@phx.gbl>
On 11/2/06, M Ptich <ptich@hotmail.com> wrote:
> I am porting 2.6 kernel from Freescale onto our PPC platform. This is my
> first experience with Linux, and I was unpleasantly surprised how poorly OS
> and platform code are separated. So I have a question: is there a project
> underway, somewhere, that is trying to separate OS and HAL (or Board Support
> Package) for the next Linux kernel ?
Can you elaborate on what you mean? From my perspective there is
quite well defined separation between the kernel proper, the device
drivers, and the board setup code.
However, there is no stable kernel API for you to program against, and
this is by design. For details, read the following file in the kernel
source tree: Documentation/stable_api_nonsense.txt
Now, all that being said, there is separation between bootloader and
kernel responsibilities that is currently evolving. Linux 32 bit PPC
support is slowly being migrated from the arch/ppc directory into
arch/powerpc where it is merging with 64 bit ppc support. The
arch/powerpc tree also uses a device tree (binary data structure) to
pass board configuration information from the bootloader to the
kernel. The bootloader is responsible for initializing the board (ie.
SDRAM and certain devices). Since the device tree informs the kernel
what devices are present, most of the kernel code can be generic and
the kernel will only setup device drivers for devices that are
actually present.
--
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [PATCH 1/3] Fix sparse warning in xmon Cell code
From: Michael Ellerman @ 2006-11-03 7:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
My patch to add spu helpers to xmon (a898497088f46252e6750405504064e2dce53117)
introduced a few sparse warnings, because I was dereferencing an __iomem
pointer.
I think the best way to handle it is to actually use the appropriate in_beXX
functions. Need to rejigger the DUMP macro a little to accomodate that.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
Arnd, it might be nice to merge this for SDK 2.0 if that's still an option,
just so that it matches upstream as much as possible.
arch/powerpc/xmon/xmon.c | 22 +++++++++++++++-------
1 file changed, 15 insertions(+), 7 deletions(-)
Index: cell/arch/powerpc/xmon/xmon.c
===================================================================
--- cell.orig/arch/powerpc/xmon/xmon.c
+++ cell/arch/powerpc/xmon/xmon.c
@@ -2746,13 +2746,13 @@ static void restart_spus(void)
}
#define DUMP_WIDTH 23
-#define DUMP_FIELD(obj, format, field) \
+#define DUMP_VALUE(format, field, value) \
do { \
if (setjmp(bus_error_jmp) == 0) { \
catch_memory_errors = 1; \
sync(); \
printf(" %-*s = "format"\n", DUMP_WIDTH, \
- #field, obj->field); \
+ #field, value); \
sync(); \
__delay(200); \
} else { \
@@ -2763,6 +2763,9 @@ do { \
catch_memory_errors = 0; \
} while (0)
+#define DUMP_FIELD(obj, format, field) \
+ DUMP_VALUE(format, field, obj->field)
+
static void dump_spu_fields(struct spu *spu)
{
printf("Dumping spu fields at address %p:\n", spu);
@@ -2791,13 +2794,18 @@ static void dump_spu_fields(struct spu *
DUMP_FIELD(spu, "0x%p", timestamp);
DUMP_FIELD(spu, "0x%lx", problem_phys);
DUMP_FIELD(spu, "0x%p", problem);
- DUMP_FIELD(spu, "0x%x", problem->spu_runcntl_RW);
- DUMP_FIELD(spu, "0x%x", problem->spu_status_R);
- DUMP_FIELD(spu, "0x%x", problem->spu_npc_RW);
+ DUMP_VALUE("0x%x", problem->spu_runcntl_RW,
+ in_be32(&spu->problem->spu_runcntl_RW));
+ DUMP_VALUE("0x%x", problem->spu_status_R,
+ in_be32(&spu->problem->spu_status_R));
+ DUMP_VALUE("0x%x", problem->spu_npc_RW,
+ in_be32(&spu->problem->spu_npc_RW));
DUMP_FIELD(spu, "0x%p", priv1);
- if (spu->priv1)
- DUMP_FIELD(spu, "0x%lx", priv1->mfc_sr1_RW);
+ if (spu->priv1) {
+ DUMP_VALUE("0x%lx", priv1->mfc_sr1_RW,
+ in_be64(&spu->priv1->mfc_sr1_RW));
+ }
DUMP_FIELD(spu, "0x%p", priv2);
}
^ permalink raw reply
* [PATCH 2/3] Show state of spus as they're stopped in Cell xmon helper
From: Michael Ellerman @ 2006-11-03 7:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <1162538933.650101.682761686374.qpush@cradle>
After stopping spus in xmon I often find myself trawling through the
field dumps to find out which spus were running. The spu stopping
code actually knows what's running, so let's print it out to save
the user some futzing.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
arch/powerpc/xmon/xmon.c | 5 ++++-
1 file changed, 4 insertions(+), 1 deletion(-)
Index: cell/arch/powerpc/xmon/xmon.c
===================================================================
--- cell.orig/arch/powerpc/xmon/xmon.c
+++ cell/arch/powerpc/xmon/xmon.c
@@ -2700,7 +2700,10 @@ static void stop_spus(void)
__delay(200);
spu_info[i].stopped_ok = 1;
- printf("Stopped spu %.2d\n", i);
+
+ printf("Stopped spu %.2d (was %s)\n", i,
+ spu_info[i].saved_spu_runcntl_RW ?
+ "running" : "stopped");
} else {
catch_memory_errors = 0;
printf("*** Error stopping spu %.2d\n", i);
^ permalink raw reply
* [PATCH 3/3] Add a 'sd' command (spu dump) to xmon to dump spu local store
From: Michael Ellerman @ 2006-11-03 7:28 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev, Arnd Bergmann
In-Reply-To: <1162538933.650101.682761686374.qpush@cradle>
Add a command to xmon to dump the memory of a spu's local store.
This mimics the 'd' command which dumps regular memory, but does
a little hand holding by taking the user supplied address and
finding that offset in the local store for the specified spu.
This makes it easy for example to look at what was executing on a spu:
1:mon> ss
...
Stopped spu 04 (was running)
...
1:mon> sf 4
Dumping spu fields at address c0000000019e0a00:
...
problem->spu_npc_RW = 0x228
...
1:mon> sd 4 0x228
d000080080318228 01a00c021cffc408 4020007f217ff488 |........@ ..!...|
Aha, 01a00c02, which is of course rdch $2,$ch24 !
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
arch/powerpc/xmon/xmon.c | 52 ++++++++++++++++++++++++++++++++++++++++++++++-
1 file changed, 51 insertions(+), 1 deletion(-)
Index: cell/arch/powerpc/xmon/xmon.c
===================================================================
--- cell.orig/arch/powerpc/xmon/xmon.c
+++ cell/arch/powerpc/xmon/xmon.c
@@ -217,7 +217,8 @@ Commands:\n\
#ifdef CONFIG_PPC_CELL
" ss stop execution on all spus\n\
sr restore execution on stopped spus\n\
- sf # dump spu fields for spu # (in hex)\n"
+ sf # dump spu fields for spu # (in hex)\n\
+ sd # dump spu local store for spu # (in hex)\n"
#endif
" S print special registers\n\
t print backtrace\n\
@@ -2649,6 +2650,7 @@ struct spu_info {
struct spu *spu;
u64 saved_mfc_sr1_RW;
u32 saved_spu_runcntl_RW;
+ unsigned long dump_addr;
u8 stopped_ok;
};
@@ -2668,6 +2670,8 @@ void xmon_register_spus(struct list_head
spu_info[spu->number].spu = spu;
spu_info[spu->number].stopped_ok = 0;
+ spu_info[spu->number].dump_addr = (unsigned long)
+ spu_info[spu->number].spu->local_store;
}
}
@@ -2813,6 +2817,48 @@ static void dump_spu_fields(struct spu *
DUMP_FIELD(spu, "0x%p", priv2);
}
+static void dump_spu_ls(void)
+{
+ static unsigned long num;
+ unsigned long offset, addr, ls_addr;
+ int rc;
+
+ scanhex(&num);
+ if (num >= XMON_NUM_SPUS || !spu_info[num].spu) {
+ printf("*** Error: invalid spu number\n");
+ return;
+ }
+
+ rc = scanhex(&offset);
+
+ if (setjmp(bus_error_jmp) == 0) {
+ catch_memory_errors = 1;
+ sync();
+
+ ls_addr = (unsigned long)spu_info[num].spu->local_store;
+ if (rc)
+ addr = ls_addr + offset;
+ else
+ addr = spu_info[num].dump_addr;
+
+ if (addr < ls_addr + LS_SIZE) {
+ prdump(addr, 64);
+ spu_info[num].dump_addr = addr + 64;
+ } else {
+ printf("*** Error: address outside of local store\n");
+ last_cmd = NULL;
+ }
+
+ sync();
+ __delay(200);
+ } else {
+ catch_memory_errors = 0;
+ printf("*** Error: dumping local store for spu %d\n", num);
+ }
+
+ catch_memory_errors = 0;
+}
+
static int do_spu_cmd(void)
{
unsigned long num = 0;
@@ -2832,6 +2878,10 @@ static int do_spu_cmd(void)
else
printf("*** Error: invalid spu number\n");
break;
+ case 'd':
+ last_cmd = "sd\n";
+ dump_spu_ls();
+ break;
default:
return -1;
}
^ permalink raw reply
* Re: [PATCH/RFC] powerpc: Add Efika platform support
From: Nicolas DET @ 2006-11-03 7:31 UTC (permalink / raw)
To: Nicolas DET; +Cc: linuxppc-embedded, sl, linuxppc-dev
In-Reply-To: <454A5A61.6080800@bplan-gmbh.de>
[-- Attachment #1: Type: text/plain, Size: 397 bytes --]
Nicolas DET wrote:
> + of_node_put(root);
> +
> + if (pcictrl == NULL) {
> + printk(KERN_WARNING EFIKA_PLATFORM_NAME
> + ": Unable to find the PCI bridge node\n");
> + of_node_put(pcictrl);
> + return;
> + }
Oups...
By the way, take advantage of this one
http://patchwork.ozlabs.org/linuxppc/patch?id=7648
It means, it won't work if you source tree doesn't include this.
Regards,
[-- Attachment #2: archpowerpc_efika.patch --]
[-- Type: text/plain, Size: 9914 bytes --]
--- a/arch/powerpc/platforms/efika/setup.c 1970-01-01 01:00:00.000000000 +0100
+++ b/arch/powerpc/platforms/efika/setup.c 2006-11-03 08:25:34.000000000 +0100
@@ -0,0 +1,166 @@
+/*
+ *
+ * Efika 5K2 platform setup
+ * Some code really inspired from the lite5200b platform.
+ *
+ * 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 <linux/errno.h>
+#include <linux/sched.h>
+#include <linux/kernel.h>
+#include <linux/ptrace.h>
+#include <linux/slab.h>
+#include <linux/user.h>
+#include <linux/interrupt.h>
+#include <linux/reboot.h>
+#include <linux/init.h>
+#include <linux/utsrelease.h>
+#include <linux/module.h>
+#include <linux/pci.h>
+#include <linux/console.h>
+#include <linux/seq_file.h>
+#include <linux/root_dev.h>
+#include <linux/initrd.h>
+#include <linux/module.h>
+#include <linux/timer.h>
+
+#include <asm/pgtable.h>
+#include <asm/prom.h>
+#include <asm/dma.h>
+#include <asm/machdep.h>
+#include <asm/irq.h>
+#include <asm/sections.h>
+#include <asm/time.h>
+#include <asm/rtas.h>
+#include <asm/of_device.h>
+#include <asm/mpc52xx.h>
+
+#include "efika.h"
+
+static void efika_show_cpuinfo(struct seq_file *m)
+{
+ struct device_node *root;
+ const char *revision = NULL;
+ const char *codegendescription = NULL;
+ const char *codegenvendor = NULL;
+
+ root = of_find_node_by_path("/");
+ if (root) {
+ revision = get_property(root, "revision", NULL);
+ codegendescription =
+ get_property(root, "CODEGEN,description", NULL);
+ codegenvendor = get_property(root, "CODEGEN,vendor", NULL);
+ }
+
+ of_node_put(root);
+
+ if (codegendescription)
+ seq_printf(m, "machine\t\t: %s\n", codegendescription);
+ else
+ seq_printf(m, "machine\t\t: Efika\n");
+
+ if (revision)
+ seq_printf(m, "revision\t: %s\n", revision);
+
+ if (codegenvendor)
+ seq_printf(m, "vendor\t\t: %s\n", codegenvendor);
+}
+
+static void __init efika_setup_arch(void)
+{
+ rtas_initialize();
+
+#ifdef CONFIG_BLK_DEV_INITRD
+ initrd_below_start_ok = 1;
+
+ if (initrd_start)
+ ROOT_DEV = Root_RAM0;
+ else
+#endif
+ ROOT_DEV = Root_SDA2; /* sda2 (sda1 is for the kernel) */
+
+ efika_pcisetup();
+
+ if (ppc_md.progress)
+ ppc_md.progress("Linux/PPC " UTS_RELEASE " runnung on Efika ;-)\n", 0x0);
+}
+
+static void __init efika_init_IRQ(void)
+{
+ mpc52xx_init_irq();
+}
+
+static void __init efika_init(void)
+{
+ struct device_node *np;
+ struct device_node *cnp = NULL;
+ const u32 *base;
+ char *name;
+
+ /* Find every child of the SOC node and add it to of_platform */
+ np = of_find_node_by_name(NULL, "builtin");
+ if (np) {
+ while ((cnp = of_get_next_child(np, cnp))) {
+ name = kmalloc(BUS_ID_SIZE, GFP_KERNEL);
+ if (name == NULL)
+ continue;
+
+ strcpy(name, cnp->name);
+
+ base = get_property(cnp, "reg", NULL);
+ if (base == NULL) {
+ kfree(name);
+ continue;
+ }
+
+ sprintf(name+strlen(name), "@%x", *base);
+ of_platform_device_create(cnp, name, NULL);
+
+ printk(KERN_INFO ": Added %s (%s) to the known devices\n", name, cnp->full_name);
+ }
+ }
+
+ if (ppc_md.progress)
+ ppc_md.progress(" Have fun with your Efika! ", 0x7777);
+}
+
+static int __init efika_probe(void)
+{
+ char *model = of_get_flat_dt_prop(of_get_flat_dt_root(),
+ "model", NULL);
+
+ if (model == NULL)
+ return 0;
+ if (strcmp(model, "EFIKA5K2"))
+ return 0;
+
+ ISA_DMA_THRESHOLD = ~0L;
+ DMA_MODE_READ = 0x44;
+ DMA_MODE_WRITE = 0x48;
+
+ return 1;
+}
+
+define_machine(efika)
+{
+ .name = EFIKA_PLATFORM_NAME,
+ .probe = efika_probe,
+ .setup_arch = efika_setup_arch,
+ .init = efika_init,
+ .show_cpuinfo = efika_show_cpuinfo,
+ .init_IRQ = efika_init_IRQ,
+ .get_irq = mpc52xx_get_irq,
+ .restart = rtas_restart,
+ .power_off = rtas_power_off,
+ .halt = rtas_halt,
+ .set_rtc_time = rtas_set_rtc_time,
+ .get_rtc_time = rtas_get_rtc_time,
+ .progress = rtas_progress,
+ .get_boot_time = rtas_get_boot_time,
+ .calibrate_decr = generic_calibrate_decr,
+ .phys_mem_access_prot = pci_phys_mem_access_prot,
+};
--- a/arch/powerpc/platforms/efika/pci.c 1970-01-01 01:00:00.000000000 +0100
+++ b/arch/powerpc/platforms/efika/pci.c 2006-11-03 08:26:08.000000000 +0100
@@ -0,0 +1,119 @@
+
+#include <linux/kernel.h>
+#include <linux/pci.h>
+#include <linux/string.h>
+#include <linux/init.h>
+
+#include <asm/io.h>
+#include <asm/irq.h>
+#include <asm/prom.h>
+#include <asm/machdep.h>
+#include <asm/sections.h>
+#include <asm/pci-bridge.h>
+#include <asm/rtas.h>
+
+#include "efika.h"
+
+#ifdef CONFIG_PCI
+/*
+ * Access functions for PCI config space using RTAS calls.
+ */
+static int rtas_read_config(struct pci_bus *bus, unsigned int devfn, int offset,
+ int len, u32 * val)
+{
+ struct pci_controller *hose = bus->sysdata;
+ unsigned long addr = (offset & 0xff) | ((devfn & 0xff) << 8)
+ | (((bus->number - hose->first_busno) & 0xff) << 16)
+ | (hose->index << 24);
+ int ret = -1;
+ int rval;
+
+ rval = rtas_call(rtas_token("read-pci-config"), 2, 2, &ret, addr, len);
+ *val = ret;
+ return rval ? PCIBIOS_DEVICE_NOT_FOUND : PCIBIOS_SUCCESSFUL;
+}
+
+static int rtas_write_config(struct pci_bus *bus, unsigned int devfn,
+ int offset, int len, u32 val)
+{
+ struct pci_controller *hose = bus->sysdata;
+ unsigned long addr = (offset & 0xff) | ((devfn & 0xff) << 8)
+ | (((bus->number - hose->first_busno) & 0xff) << 16)
+ | (hose->index << 24);
+ int rval;
+
+ rval = rtas_call(rtas_token("write-pci-config"), 3, 1, NULL,
+ addr, len, val);
+ return rval ? PCIBIOS_DEVICE_NOT_FOUND : PCIBIOS_SUCCESSFUL;
+}
+
+static struct pci_ops rtas_pci_ops = {
+ rtas_read_config,
+ rtas_write_config
+};
+
+void __init efika_pcisetup(void)
+{
+ const int *bus_range;
+ int len;
+ struct pci_controller *hose;
+ struct device_node *root;
+ struct device_node *pcictrl;
+
+ root = of_find_node_by_path("/");
+ if (root == NULL) {
+ printk(KERN_WARNING EFIKA_PLATFORM_NAME
+ ": Unable to find the root node\n");
+ return;
+ }
+
+ for (pcictrl = NULL;;) {
+ pcictrl = of_get_next_child(root, pcictrl);
+ if ((pcictrl == NULL) || (strcmp(pcictrl->name, "pci") == 0))
+ break;
+ }
+
+ of_node_put(root);
+
+ if (pcictrl == NULL) {
+ printk(KERN_WARNING EFIKA_PLATFORM_NAME
+ ": Unable to find the PCI bridge node\n");
+ return;
+ }
+
+ bus_range = get_property(pcictrl, "bus-range", &len);
+ if (bus_range == NULL || len < 2 * sizeof(int)) {
+ printk(KERN_WARNING EFIKA_PLATFORM_NAME
+ ": Can't get bus-range for %s\n", pcictrl->full_name);
+ return;
+ }
+
+ if (bus_range[1] == bus_range[0])
+ printk(KERN_INFO EFIKA_PLATFORM_NAME ": PCI bus %d",
+ bus_range[0]);
+ else
+ printk(KERN_INFO EFIKA_PLATFORM_NAME ": PCI buses %d..%d",
+ bus_range[0], bus_range[1]);
+ printk(" controlled by %s\n", pcictrl->full_name);
+ printk("\n");
+
+ hose = pcibios_alloc_controller();
+ if (!hose) {
+ printk(KERN_WARNING EFIKA_PLATFORM_NAME
+ ": Can't allocate PCI controller structure for %s\n",
+ pcictrl->full_name);
+ return;
+ }
+
+ hose->arch_data = of_node_get(pcictrl);
+ hose->first_busno = bus_range[0];
+ hose->last_busno = bus_range[1];
+ hose->ops = &rtas_pci_ops;
+
+ pci_process_bridge_OF_ranges(hose, pcictrl, 0);
+}
+
+#else
+void __init efika_pcisetup(void)
+{}
+#endif
--- a/arch/powerpc/platforms/efika/efika.h 1970-01-01 01:00:00.000000000 +0100
+++ b/arch/powerpc/platforms/efika/efika.h 2006-11-02 17:54:37.000000000 +0100
@@ -0,0 +1,19 @@
+/*
+ * Efika 5K2 platform setup - Header file
+ *
+ * Copyright (C) 2006 bplan GmbH
+ *
+ * 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.
+ *
+ */
+
+#ifndef __ARCH_POWERPC_EFIKA__
+#define __ARCH_POWERPC_EFIKA__
+
+#define EFIKA_PLATFORM_NAME "Efika"
+
+extern void __init efika_pcisetup(void);
+
+#endif
--- a/arch/powerpc/platforms/efika/Makefile 1970-01-01 01:00:00.000000000 +0100
+++ b/arch/powerpc/platforms/efika/Makefile 2006-11-02 17:55:29.000000000 +0100
@@ -0,0 +1 @@
+obj-y += setup.o pci.o
--- a/arch/powerpc/platforms/Makefile 2006-11-01 09:18:43.000000000 +0100
+++ b/arch/powerpc/platforms/Makefile 2006-11-02 17:54:37.000000000 +0100
@@ -6,6 +6,7 @@ obj-$(CONFIG_PPC_PMAC) += powermac/
endif
endif
obj-$(CONFIG_PPC_CHRP) += chrp/
+obj-$(CONFIG_PPC_EFIKA) += efika/
obj-$(CONFIG_4xx) += 4xx/
obj-$(CONFIG_PPC_83xx) += 83xx/
obj-$(CONFIG_PPC_85xx) += 85xx/
--- a/arch/powerpc/boot/Makefile 2006-11-01 09:18:42.000000000 +0100
+++ b/arch/powerpc/boot/Makefile 2006-10-31 12:31:55.000000000 +0100
@@ -115,7 +115,7 @@ endif
quiet_cmd_wrap = WRAP $@
cmd_wrap =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) vmlinux
quiet_cmd_wrap_initrd = WRAP $@
- cmd_wrap_initrd =$(CONFIG_SHELL) $(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
+ cmd_wrap_initrd =$(wrapper) -c -o $@ -p $2 $(CROSSWRAP) \
-i $(obj)/ramdisk.image.gz vmlinux
$(obj)/zImage.chrp: vmlinux $(wrapperbits)
@@ -155,6 +155,7 @@ image-$(CONFIG_PPC_PSERIES) += zImage.p
image-$(CONFIG_PPC_MAPLE) += zImage.pseries
image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
image-$(CONFIG_PPC_CHRP) += zImage.chrp
+image-$(CONFIG_PPC_EFIKA) += zImage.chrp
image-$(CONFIG_PPC_PMAC) += zImage.pmac
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
--- a/arch/powerpc/Kconfig 2006-11-01 09:18:42.000000000 +0100
+++ b/arch/powerpc/Kconfig 2006-11-02 17:55:20.000000000 +0100
@@ -386,6 +386,14 @@ config PPC_CHRP
select PPC_UDBG_16550
default y
+config PPC_EFIKA
+ bool "bPlan Efika 5k2. MPC5200B based computer"
+ depends on PPC_MULTIPLATFORM && PPC32
+ select PPC_RTAS
+ select RTAS_PROC
+ select PPC_MPC52xx
+ default y
+
config PPC_PMAC
bool "Apple PowerMac based machines"
depends on PPC_MULTIPLATFORM
[-- Attachment #3: nd.vcf --]
[-- Type: text/x-vcard, Size: 249 bytes --]
begin:vcard
fn:Nicolas DET ( bplan GmbH )
n:DET;Nicolas
org:bplan GmbH
adr:;;;;;;Germany
email;internet:nd@bplan-gmbh.de
title:Software Entwicklung
tel;work:+49 6171 9187 - 31
x-mozilla-html:FALSE
url:http://www.bplan-gmbh.de
version:2.1
end:vcard
^ permalink raw reply
* Re: [patch 01/16] remove inclusion of asm/processor.h for powerpc
From: Sascha Hauer @ 2006-11-03 8:42 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1162506020.10630.31.camel@localhost.localdomain>
On Fri, Nov 03, 2006 at 09:20:20AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2006-11-02 at 13:55 +0100, s.hauer@pengutronix.de wrote:
> > plain text document attachment
> > (drivers-ide-pci-via82xxx-remove-ppc-ifdef.diff)
> > Remove inclusion of asm/processor.h for powerpc. It was used for
> > some ppc specific hook in this file, but the hook is gone
>
> It's not:
>
> init_hwif_via82cxxx() contains:
>
> #if defined(CONFIG_PPC_CHRP) && defined(CONFIG_PPC32)
> if(machine_is(chrp) && _chrp_type == _CHRP_Pegasos) {
> hwif->irq = hwif->channel ? 15 : 14;
> }
> #endif
>
> Now you can replace CONFIG_PPC_MULTIPLATFORM with CONFIG_PPC_CHRP
>
Oops, missed that one. Here is an updated version:
Remove inclusion of asm/processor.h for powerpc. It was used for
some ppc specific hook in this file, but the hook is gone
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Index: drivers/ide/pci/via82cxxx.c
===================================================================
--- drivers/ide/pci/via82cxxx.c.orig
+++ drivers/ide/pci/via82cxxx.c
@@ -35,7 +35,7 @@
#include <linux/ide.h>
#include <asm/io.h>
-#ifdef CONFIG_PPC_MULTIPLATFORM
+#ifdef CONFIG_PPC_CHRP
#include <asm/processor.h>
#endif
@@ -442,7 +442,7 @@ static void __devinit init_hwif_via82cxx
hwif->speedproc = &via_set_drive;
-#if defined(CONFIG_PPC_CHRP) && defined(CONFIG_PPC32)
+#ifdef CONFIG_PPC_CHRP
if(machine_is(chrp) && _chrp_type == _CHRP_Pegasos) {
hwif->irq = hwif->channel ? 15 : 14;
}
--
Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [patch 04/16] powerpc: remove dead code in iommu.h
From: Sascha Hauer @ 2006-11-03 8:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1162506113.10630.35.camel@localhost.localdomain>
On Fri, Nov 03, 2006 at 09:21:53AM +1100, Benjamin Herrenschmidt wrote:
> On Thu, 2006-11-02 at 13:55 +0100, s.hauer@pengutronix.de wrote:
> > plain text document attachment
> > (powerpc-include-asm-powerpc-iommu_h-remove-dead-code.diff)
> > iommu_setup_pSeries() and iommu_setup_dart() are declared extern but are
> > not implemented, so remove them. iommu_free_table() is pSeries specific,
> > so #ifdef it with CONFIG_PPC_PSERIES and not CONFIG_PPC_MULTIPLATFORM
> >
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> There is no need to #ifdef an extern declaration. Just remove the
> ifdef's and the two obsolete prototypes alltogether
>
Here we go:
iommu_setup_pSeries() and iommu_setup_dart() are declared extern but are
not implemented, so remove them. iommu_free_table() is pSeries specific,
so #ifdef it with CONFIG_PPC_PSERIES and not CONFIG_PPC_MULTIPLATFORM
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Index: include/asm-powerpc/iommu.h
===================================================================
--- a/include/asm-powerpc/iommu.h.orig
+++ b/include/asm-powerpc/iommu.h
@@ -70,17 +70,9 @@ struct iommu_table {
struct scatterlist;
struct device_node;
-#ifdef CONFIG_PPC_MULTIPLATFORM
-
-/* Walks all buses and creates iommu tables */
-extern void iommu_setup_pSeries(void);
-extern void iommu_setup_dart(void);
-
/* Frees table for an individual device node */
extern void iommu_free_table(struct device_node *dn);
-#endif /* CONFIG_PPC_MULTIPLATFORM */
-
/* Initializes an iommu_table based in values set in the passed-in
* structure
*/
--
Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [patch 01/16] remove inclusion of asm/processor.h for powerpc
From: Sascha Hauer @ 2006-11-03 8:52 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1162506020.10630.31.camel@localhost.localdomain>
I Sent a -p0 patch by accident, forget the last one.
There is some PPC_CHRP specific code in drivers/ide/pci/via82cxxx.c,
so #ifdef on CONFIG_PPC_CHRP instead of CONFIG_PPC_MULTIPLATFORM.
Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
Index: drivers/ide/pci/via82cxxx.c
===================================================================
--- a/drivers/ide/pci/via82cxxx.c.orig
+++ b/drivers/ide/pci/via82cxxx.c
@@ -35,7 +35,7 @@
#include <linux/ide.h>
#include <asm/io.h>
-#ifdef CONFIG_PPC_MULTIPLATFORM
+#ifdef CONFIG_PPC_CHRP
#include <asm/processor.h>
#endif
@@ -442,7 +442,7 @@ static void __devinit init_hwif_via82cxx
hwif->speedproc = &via_set_drive;
-#if defined(CONFIG_PPC_CHRP) && defined(CONFIG_PPC32)
+#ifdef CONFIG_PPC_CHRP
if(machine_is(chrp) && _chrp_type == _CHRP_Pegasos) {
hwif->irq = hwif->channel ? 15 : 14;
}
--
Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [patch 08/16] powerpc: remove EMBEDDED6xx Kconfig entry
From: Sascha Hauer @ 2006-11-03 9:12 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <1162505588.10630.27.camel@localhost.localdomain>
On Fri, Nov 03, 2006 at 09:13:08AM +1100, Benjamin Herrenschmidt wrote:
>
> > Then perhaps Efika should also be under platforms/mpc52xx?
>
> Classifying platforms by their processor might not be the best idea... I
> makes some sense when those platforms are basically reference designs
> for the said processor but I yet have to be convinced it's really a good
> thing in the long run :)
>
> There will be a lot of platforms that will consist of basically once
> signle source file. I think we need a directory for those. Maybe
> platform/misc :) Or we could have them at the root of platforms/ in
> fact...
>
In the embedded world there are many vendors of custom boards, so
such a directory might become very big, even if there is only one
file per board. Also I like the idea that I see all affected boards at
first sight when I change something in lets say the mpc52xx interrupt
controller.
I don't know how this performs in the 'big computer world' where vendors
combine a cpu with different chipsets. In the SoC world where every SoC
has the very same interrupt controller and device layout this behaves
quite well. Things become very orthogonal with per SoC directories.
(I'm more familiar with arm, where directories are organized this way,
so you might want to look at arch/arch/mach-* to see what I mean)
Sascha
--
Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Re: [patch 13/16] powerpc: make prom_init.o dependent on PPC_OF
From: Sascha Hauer @ 2006-11-03 9:47 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1162506853.10630.55.camel@localhost.localdomain>
On Fri, Nov 03, 2006 at 09:34:13AM +1100, Benjamin Herrenschmidt wrote:
>
> Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>
> Note that CONFIG_PPC_OF is always set in arch/powerpc since that
> includes support for the flat device-tree... We might want to keep a
> separate option for prom_init.c, though I'm not too big about it right
> now. Maybe CONFIG_PPC_BOOT_FROM_OF :) That would allow custom kernel to
> be shrunk down if they don't need to support platforms that are known
> not to have a real OF (iSeries for example).
>
I don't know yet where the exact boarders are in the code between real
OF and flat device tree. Maybe I can look at it once I have a proper
device tree for my board.
Out of curiosity I just disabled CONFIG_PPC_OF. There were two undefined
references to functions I didn't need at the moment. After commenting
them out the kernel compiled and booted. It saved me ~10k kernelsize,
but ok, I thought I would still have flat tree support.
Sascha
--
Dipl.-Ing. Sascha Hauer | http://www.pengutronix.de
Pengutronix - Linux Solutions for Science and Industry
Handelsregister: Amtsgericht Hildesheim, HRA 2686
Hannoversche Str. 2, 31134 Hildesheim, Germany
Phone: +49-5121-206917-0 | Fax: +49-5121-206917-9
^ permalink raw reply
* Why 8548 reset vector points to 0x00000000?
From: Sam Song @ 2006-11-03 10:39 UTC (permalink / raw)
To: linux linuxppc-embedded
Hi,
I met a problem on a customized 8548 board debug
with BDI2000. After halting e500 core, PC pointed
to 0x0. But the same configuration file does work
on 8548 ref. board well as 0xfffffffc. I checked
all POR settings from registers and didn't find
any clue on it. So far, BDI2000 cannot program
Flash. There is no code on Flash. What could the
problem be?
Thanks in advance,
Sam
___________________________________________________________
Mp3疯狂搜-新歌热歌高速下
http://music.yahoo.com.cn/?source=mail_mailbox_footer
^ permalink raw reply
* RE : minor progress with plb_temac v3.00a, EDK 8.2, & 2.6.18.1
From: alayrac @ 2006-11-03 13:39 UTC (permalink / raw)
To: 'robert corley', 'linux linuxppc-embedded'
In-Reply-To: <20061102222041.16498.qmail@web56312.mail.re3.yahoo.com>
Hi Robert,
Thanks for your contribution.
I would like to know where did you get the kernel source 2.6.18.1?
I've tried from kernel.org, but then temac drivers is not included.
I've then download the temac patch from mvista at following address :
http://source.mvista.com/~ank/paulus-powerpc/20060309/temac.paulus-power
pc.20060309.tgz
When I try to pacth the kernel with following command :
patch -i ppc32_xilinx_edk_temac.patch
the process ask me the file to pacth.
I've try to get the kernel source code from mvista with cg-clone
commande from=20
cg-clone git://source.mvista.com/git/linux-xilinx-26.git=20
and patch command give same message.
Any track to properly applying patch?
Kinds regards
Chris
CRESITT INDUSTRIE
12 Rue de Blois, BP6744
45067 ORLEANS Cedex 2
Tel : 02.38.49.45.59
Fax :02.38.49.45.55
Email : christophe.alayrac@cresitt.com=20
Web : http://www.cresitt.com
<----> -----Message d'origine-----
<----> De=A0: linuxppc-embedded-
<----> bounces+christophe.alayrac=3Dcresitt.com@ozlabs.org
[mailto:linuxppc-
<----> embedded-bounces+christophe.alayrac=3Dcresitt.com@ozlabs.org] De =
la
<----> part de robert corley
<----> Envoy=E9=A0: jeudi 2 novembre 2006 23:21
<----> =C0=A0: linux linuxppc-embedded
<----> Objet=A0: minor progress with plb_temac v3.00a, EDK 8.2, & =
2.6.18.1
<---->=20
<----> For those interested, I have acheived some measure of success
with
<----> the plb_temac driver.
<---->=20
<----> I have attached a txt file of what I had to do to get it working
<----> under 2.6.18.1
<---->=20
<----> I am using the plb_temac in DMA mode 3
<---->=20
<----> Below you will see the boot dump.
<---->=20
<----> For those able to help, can anyone provide insight as to the
failure
<----> of setting PHY link speed?
<---->=20
<----> -cy
<---->=20
<---->=20
<---->=20
<----> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
<---->
---------------------------------------------------------------------
<----> -
<----> 2.6.18.1 kernel with all patches
<----> 11/02/2006 15:30
<----> plb_temac v3.00a
<----> hard_temac v3.00b
<---->=20
<---->=20
<----> loaded at: 00400000 009F1138
<----> board data at: 009EF120 009EF138
<----> relocated to: 004040B4 004040CC
<----> zimage at: 00404EC7 0057C1F2
<----> initrd at: 0057D000 009EE6FE
<----> avail ram: 009F2000 04000000
<---->=20
<---->=20
<----> Linux/PPC load: console=3DttyUL0 single
<----> ip=3D192.168.1.100:192.168.1.144:192.168.1.1:255.255.255.0:nab::
<----> ramdisk_size=3D4660000 root=3D/dev/ram rw
<---->=20
<----> Uncompressing Linux...done.
<---->=20
<----> Now booting the kernel
<---->=20
<----> [ 0.000000] Linux version 2.6.18.1 (rdcorle@athena) (gcc
version
<----> 3.4.2) #2 Thu Nov 2 21:56:32 UTC 2006
<----> [ 0.000000] Xilinx ML403 Reference System (Virtex-4 FX)
<----> [ 0.000000] Built 1 zonelists. Total pages: 16384
<----> [ 0.000000] Kernel command line: console=3DttyUL0 single
<----> ip=3D192.168.1.100:192.168.1.144:192.168.1.1:255.255.255.0:nab::
<----> ramdisk_size=3D4660000 root=3D/dev/ram rw
<----> [ 0.000000] Xilinx INTC #0 at 0xD1000FC0 mapped to 0xFDFFFFC0
<----> [ 0.000000] PID hash table entries: 512 (order: 9, 2048 bytes)
<----> [ 0.000158] Console: colour dummy device 80x25
<----> [ 0.000568] Dentry cache hash table entries: 8192 (order: 3,
32768
<----> bytes)
<----> [ 0.001277] Inode-cache hash table entries: 4096 (order: 2,
16384
<----> bytes)
<----> [ 0.012895] Memory: 57060k available (2548k kernel code, 640k
<----> data, 96k init, 0k highmem)
<----> [ 0.104378] Mount-cache hash table entries: 512
<----> [ 0.106721] checking if image is initramfs...it isn't (no cpio
<----> magic); looks like an initrd
<----> [ 2.414242] Freeing initrd memory: 4549k freed
<----> [ 2.418712] NET: Registered protocol family 16
<----> [ 2.427313] NET: Registered protocol family 2
<----> [ 2.464244] IP route cache hash table entries: 512 (order: -1,
<----> 2048 bytes)
<----> [ 2.465037] TCP established hash table entries: 2048 (order:
1,
<----> 8192 bytes)
<----> [ 2.465205] TCP bind hash table entries: 1024 (order: 0, 4096
<----> bytes)
<----> [ 2.465296] TCP: Hash tables configured (established 2048 bind
<----> 1024)
<----> [ 2.465324] TCP reno registered
<----> [ 2.474633] NTFS driver 2.1.27 [Flags: R/O].
<----> [ 2.475046] JFS: nTxBlock =3D 481, nTxLock =3D 3854
<----> [ 2.477623] SGI XFS with no debug enabled
<----> [ 2.479001] io scheduler noop registered
<----> [ 2.479109] io scheduler anticipatory registered
<----> [ 2.479197] io scheduler deadline registered
<----> [ 2.479402] io scheduler cfq registered (default)
<----> [ 2.517627] uartlite.0: ttyUL0 at MMIO 0xa0000000 (irq =3D 1) =
is
a
<----> uartlite
<----> [ 2.691029] RAMDISK driver initialized: 16 RAM disks of
4660000K
<----> size 1024 blocksize
<----> [ 2.703933] loop: loaded (max 8 devices)
<----> [ 2.709698] XTemac: using sgDMA mode.
<----> [ 2.713493] XTemac: using TxDRE mode
<----> [ 2.717081] XTemac: using RxDRE mode
<----> [ 2.720678] XTemac: buffer descriptor size: 32768 (0x8000)
<----> [ 2.726622] XTemac: (buffer_descriptor_init) phy: 0x580000,
virt:
<----> 0xff100000, size: 0x8000
<----> [ 2.741073] eth0: Xilinx TEMAC #0 at 0x60000000 mapped to
<----> 0xC5050000, irq=3D0
<----> [ 2.748080] eth0: XTemac id 1.0f, block id 5, type 8
<----> [ 2.753636] mice: PS/2 mouse device common for all mice
<----> [ 2.759529] TCP bic registered
<----> [ 3.264317] eth0: XTemac: Options: 0xb8f2
<----> [ 15.227339] eth0: XTemac: Not able to set the speed to 1000
<----> (status: 0x148)
<----> [ 25.200394] eth0: XTemac: Not able to set the speed to 100
<----> (status: 0x148)
<----> [ 35.173357] eth0: XTemac: Not able to set the speed to 10
(status:
<----> 0x148)
<----> [ 35.180122] eth0: XTemac: could not negotiate speed
<----> [ 35.187740] eth0: XTemac: Send Threshold =3D 16, Receive
Threshold =3D
<----> 2
<----> [ 35.194116] eth0: XTemac: Send Wait bound =3D 1, Receive Wait
bound
<----> =3D 1
<----> [ 36.205399] IP-Config: Complete:
<----> [ 36.208459] device=3Deth0, addr=3D192.168.1.100,
<----> mask=3D255.255.255.0, gw=3D192.168.1.1,
<----> [ 36.216339] host=3Dnab, domain=3D, nis-domain=3D(none),
<----> [ 36.221487] bootserver=3D192.168.1.144,
<----> rootserver=3D192.168.1.144, rootpath=3D
<----> [ 36.229826] RAMDISK: Compressed image found at block 0
<----> [ 37.200498] eth0: XTemac: PHY Link carrier lost.
<----> [ 39.097820] VFS: Mounted root (ext2 filesystem).
<----> [ 39.102751] Freeing unused kernel memory: 96k init
<----> [ 39.108356] ulite_startup: UART status =3D 0x0014
<----> [ 39.124619] ulite_startup: UART status =3D 0x0014
<----> [ 39.134313] ulite_startup: UART status =3D 0x0014
<---->=20
<---->=20
<----> BusyBox v1.00-pre9 (2004.04.18-19:53+0000) Built-in shell (ash)
<----> Enter 'help' for a list of built-in commands.
<---->=20
<----> -sh: can't access tty; job control turned off
<---->=20
^ permalink raw reply
* Not show login correct
From: tran vanle @ 2006-11-03 14:27 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2199 bytes --]
Hi all
I have just build kernel and ramdisk for TQM8xxL success. But when I login I receive
[root@h W] , my hostname is van and current directory is /root/bin ,May I receive [root@van bin]
Here is my /etc/inittab and /etc/profile
#/etc/inittab
/////////////////////////////////////////////////////////////
This is run first except when booting in single-user mode.
::sysinit:/etc/rc.sh
#::sysinit:/etc/rc.sysinit
# /bin/sh invocations on selected ttys
#
# Start an "askfirst" shell on /dev/ttyS1
::respawn:/sbin/getty -L 115200 ttyS0 ansi
# ansi
#
# Start internet super daemon; do NOT background!
#::respawn:/usr/sbin/xinetd -stayalive -reuse -pidfile /tmp/xinetd.pid
# Start user application
#::respawn:/bin/application
# Must be last 'respawn' entry to avoid ^C problem
# Start a shell on the console
#::respawn:-/bin/sh
# /etc/profile
//////////////////////////////////////////////////////////////
#echo Exec "/etc/profile" Dir `pwd`
# System wide environment and startup programs
# Functions and aliases go in /etc/bashrc
#alias rm='rm -i'
#alias w='w -u'
HOSTNAME=`/bin/hostname`
PS1="[$USER@\h \W]\\$ "
#ulimit -c 1000000
if [ `id -gn` = `id -un` -a `id -u` -gt 14 ]; then
umask 002
else
umask 022
fi
USER=`id -un`
LOGNAME=$USER
MAIL="/var/spool/mail/$USER"
HISTSIZE=1000
HISTFILESIZE=1000
if [ -e /etc/TIMEZONE ]; then
TZ=`cat /etc/TIMEZONE`; export TZ
else
unset TZ
fi
INPUTRC=/etc/inputrc
PATH=$PATH:/usr/local/bin
export PATH HOSTNAME HISTSIZE HISTFILESIZE USER LOGNAME MAIL INPUTRC PS1
/////////////////////////////////////////////////////////////////////////
//etc/rc.sh
//////////////////////////////////////////////////////////
#!/bin/sh
/sbin/ifconfig lo 127.0.0.1
>/etc/mtab
# mount /proc so "reboot" works
/bin/mount -t proc proc /proc
## try mount PC Card partition
##
## mount read-only by default to prevent corruption
##
#echo /dev/hda1 /mnt >>/etc/fstab
#mkdir -p /mnt
#mount -o ro /dev/hda1 /mnt
#
## run PC Card init script if it exists
#if [ -f /mnt/run.sh ] ; then
#/mnt/run.sh
#fi
/usr/sbin/xinetd -stayalive -reuse -pidfile /tmp/xinetd.pid
Send instant messages to your online friends http://au.messenger.yahoo.com
[-- Attachment #2: Type: text/html, Size: 2631 bytes --]
^ permalink raw reply
* Embedded System / PowerPC / Linux
From: Guillaume FORTAINE @ 2006-11-03 14:51 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: linuxppc-dev
Hello,
We are currently searching people with a strong background in Embedded
System / PowerPC / Linux
We are asking your help to provide us some contacts.
We look forward to your answer,
Best Regards,
Guillaume
^ permalink raw reply
* Fw: [patch 08/16] powerpc: remove EMBEDDED6xx Kconfig entry
From: Stephen Winiecki @ 2006-11-03 15:30 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev, paulus
[-- Attachment #1: Type: text/plain, Size: 4332 bytes --]
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote on 11/02/2006
05:30:25 PM:
>
> > What exactly is the intent of PPC_MULTIPLATFORM - the current desc
> > states "Generic desktop/server/laptop" - which doesn't exactly scream
> > 'embedded' to me either. I guess I saw embedded6xx as a 'catch-all'
> > for everything else.
>
> It's historical. It was the good old prep/chrp/pmac option, meaning that
> more than one board support can be built in the same kernel. I've made
> the policy decision with ARCH=powerpc that we should now make that
> mandatory for new boards (of course provided the CPUs are of the same
> family) since, as Sascha rightfully pointed out, it costs nothing and
> keeps things cleaner.
>
> Thus I'm all about getting rid of the option :)
>
OK - so in this sense PPC_MULTIPLATFORM would be used more to help
categorize (make ppc platforms depend on it in Kconfig) as opposed to
enabling different code/function? (thus some of Sascha's patches getting
rid of CONFIG_PPC_MMULTIPLATFORM ifdefs)
> > This may be slightly off topic - but one other thing I have noticed
> > that the new boot wrapper script supports specific 'types' of zImage
> > files associated w/ 'MUTIPLATFORMS' (PSERIES, CHRP, PREP etc.) and
> > uImage - which is what I think the majority of 'embedded' platforms
> > will use by defining CONFIG_DEFAULT_UIMAGE.
>
> That is not totally clear since they have non-compatible board info.
I should have more properly said "the majority of the existing 'embedded'
platforms (not PSERIES, CHRP, PREP etc.) currently implmented in /power
seem to define CONFIG_DEFAULT_UIMAGE"
> > For IBM boards with PIBS just 'normal' zImage ELF files get loaded -
> > I'm not sure if there should be another type defined/supported for
> > boards which don't fit necessarily into a PSERIES/CHRP/PREP definition
> > and also don't use uboot - CONFIG_DEFAULT_ZIMAGE?
> >
>
> Ask Paulus about the naming but pSeries is just "normal" in the sense
> that it's "booted from a real OF" support.
>
> The problem is despite the ability to do those nice multiplatform kernel
> images, we still have bootloader incompatibilities. Thus we want to move
> those to the zImage wrapper which can produce, from an already built
> vmlinux binary, any zImage that can be supported for a given firmware
> interface.
>
> In the long run, we hope that firmwares will finally get their gears
> together and use either a real OF entry point or a direct flat
> device-tree entry point, which means that a single zImage (the "normal
> one as you call it) will be able to boot everything.
>
> There's also a glitch with real OF zImages due to the fact that IBM
> pSeries OF requires a Notes section forcing OF into real mode while
> Apple OF is allergic to that (it will crash badly) so we need to keep a
> separate zImage for PowerMac. However, the vmlinux are the same so if
> you use something like yaboot, the same vmlinux cna be booted on all
> those machines.
Makes sense. Specific to the current wrapper though - the boot Makefile
currently keys off the following for the different zImage 'types'
image-$(CONFIG_PPC_PSERIES) += zImage.pseries
image-$(CONFIG_PPC_MAPLE) += zImage.pseries
image-$(CONFIG_PPC_IBM_CELL_BLADE) += zImage.pseries
image-$(CONFIG_PPC_CHRP) += zImage.chrp
image-$(CONFIG_PPC_PMAC) += zImage.pmac
image-$(CONFIG_DEFAULT_UIMAGE) += uImage
My original point really was that if I have a ppc 'embedded' board which I
don't want to classify/define as PSERIES/MAPLE/CELL_BLADE/CHRP/PMAC, and I
don't want to generate a uImage, I think there needs to be another
definition, something like CONFIG_DEFAULT_ZIMAGE (similar to how
CONFIG_DEFAULT_UIMAGE is used in some of the existing /power platform defs
to create a uImage) which would be used to produce a 'normal' zImage type
(zImage.pseries?). Basically - a definition analogous to the exisiting
CONFIG_DEFAULT_UIMAGE, but for zImage. It would be used in a similar way -
where any platform could select in its configuration to result in a
'normal' zImage being created (indeed, could PPC_PSERIES/MAPLE/BLADE just
select this more generic definition and the Makefile use it instead?)
[-- Attachment #2: Type: text/html, Size: 5196 bytes --]
^ permalink raw reply
* RE : minor progress with plb_temac v3.00a, EDK 8.2, & 2.6.18.1
From: alayrac @ 2006-11-03 16:14 UTC (permalink / raw)
To: linuxppc-embedded
Hi Robert,
Thanks for your contribution.
I would like to know where did you get the kernel source 2.6.18.1?
I've tried from kernel.org, but then temac drivers is not included.
I've then download the temac patch from mvista at following address :
http://source.mvista.com/~ank/paulus-powerpc/20060309/temac.paulus-power
pc.20060309.tgz
When I try to pacth the kernel with following command :
patch -i ppc32_xilinx_edk_temac.patch
the process ask me the file to pacth.
I've try to get the kernel source code from mvista with cg-clone
commande from
cg-clone git://source.mvista.com/git/linux-xilinx-26.git
and patch command give same message.
Any track to properly applying patch?
Kinds regards
Chris
CRESITT INDUSTRIE
12 Rue de Blois, BP6744
45067 ORLEANS Cedex 2
Tel : 02.38.49.45.59
Fax :02.38.49.45.55
Email : christophe.alayrac@cresitt.com
Web : http://www.cresitt.com
^ permalink raw reply
* RE: MPC834x TSECs/Gianfar w/o MDIO accessible PHYs
From: KRONSTORFER Horst @ 2006-11-03 16:38 UTC (permalink / raw)
To: Andy Fleming, Dan Malek; +Cc: linuxppc-embedded
In-Reply-To: <CAB1644F1C94A24BAC68B05D0F9774635CC913@VIECLEX01.frequentis.frq>
hi!
> on the 1st look this seems to be some kind of caching effect, but then =
...
setting CONFIG_NOT_COHERENT_CACHE=3Dy fixed the problems. what baffles =
me is
that on my
mpc8349emds, which has afaik the same core (e300), =
CONFIG_NOT_COHERENT_CACHE
is _not_
defined and eth comm works fine.
any clues?
thanks
-h
> -----Original Message-----
> From:=20
> linuxppc-embedded-bounces+hkronsto=3Dfrequentis.com@ozlabs.org=20
> [mailto:linuxppc-embedded-bounces+hkronsto=3Dfrequentis.com@ozla
> bs.org] On Behalf Of KRONSTORFER Horst
> Sent: Mittwoch, 25. Oktober 2006 14:48
> To: Andy Fleming; Dan Malek
> Cc: linuxppc-embedded@ozlabs.org
> Subject: RE: MPC834x TSECs/Gianfar w/o MDIO accessible PHYs
>=20
>=20
> andy, dan, thanks for your replies!=20
>=20
> > Look at the driver in drivers/net/phy/fixed.c.
>=20
> i did that w/o luck. the results are 100% the same compared=20
> to the 'remove phy/mdio support' approach. i therefore assume=20
> that the source of the problem must be something else.
>=20
> debugging around gfar_start_xmit() i made the following observations:
>=20
> 1) dumping skb->data i see correct frame data.
>=20
> 2) dumping txbdp->bufPtr (using a bdi) i sometimes see=20
> correct frame data, sometimes the corrupted frame data as i=20
> see it on the wire.
>=20
> 3) regardless of 2) the data of these frames is always=20
> corrupted on the wire.
>=20
> on the 1st look this seems to be some kind of caching effect,=20
> but then ...
>=20
> thanks
> -h
>=20
> > -----Original Message-----
> > From: Andy Fleming [mailto:afleming@freescale.com]
> > Sent: Dienstag, 24. Oktober 2006 20:15
> > To: KRONSTORFER Horst
> > Cc: linuxppc-embedded@ozlabs.org
> > Subject: Re: MPC834x TSECs/Gianfar w/o MDIO accessible PHYs
> >=20
> > Look at the driver in drivers/net/phy/fixed.c. It probably=20
> needs some=20
> > documentation, and Vitaly implied it needed a little=20
> tweaking, but it=20
> > provides the basics of what you need (and what Dan mentioned). =20
> > Essentially, you need to fake the PHY. However, if you wanted, you=20
> > could also get smarter and write a new mdiobus driver,=20
> which handles=20
> > configuring and using the switch.
> >=20
> > I'm not quite sure why your approach isn't working, but I=20
> agree with=20
> > Dan's suspicions that removing the PHY code doesn't just work.
> >=20
> > One thing to check is the adjust_link() function. You need to make=20
> > sure that you have the carrier on, and that the MAC is set to MII=20
> > mode, rather than GMII mode.
> >=20
> > Andy
> >=20
> > On Oct 24, 2006, at 04:16, KRONSTORFER Horst wrote:
> >=20
> > > hi!
> > >
> > > in our design we use an mpc8343 with the 2 tsecs connected to a=20
> > > zarlink zl50411 eth switch in mii mode. the 2 ports of the
> > switch are
> > > running in phy mode (reverse mii) w/o mdio. we're=20
> currently running=20
> > > kernel 2.6.17.13.
> > >
> > > i therefore 'simply' removed the mdio bus and phy support
> > and tested
> > > with ping over tsec0. result: i can see arp requests which
> > are some-
> > > what malformed (dest mac addr is not bcast, source ip addr is=20
> > > incorrect, etc ...) btw: i used the same approach in=20
> u-boot and it=20
> > > works fine.
> > >
> > > i then checked the content of the sk_buff handed over to=20
> > > gfar_start_xmit which is correct (mac addrs, ip addrs, ...)
> > >
> > > i'm currently out of ideas, any kind of help is appreciated!
> > >
> > > thanks
> > > -h
> > > _______________________________________________
> > > Linuxppc-embedded mailing list
> > > Linuxppc-embedded@ozlabs.org
> > > https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> >=20
> >=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
^ permalink raw reply
* Re: Not show login correct
From: Wolfgang Denk @ 2006-11-03 16:45 UTC (permalink / raw)
To: tran vanle; +Cc: linuxppc-embedded
In-Reply-To: <20061103142757.35508.qmail@web33012.mail.mud.yahoo.com>
In message <20061103142757.35508.qmail@web33012.mail.mud.yahoo.com> you wrote:
>
> I have just build kernel and ramdisk for TQM8xxL success. But when I login I receive
> [root@h W] , my hostname is van and current directory is /root/bin ,May I receive [root@van bin]
..
> PS1="[$USER@\h \W]\\$ "
Check if your shell really supports such escape sequences. I guess
you might be running something different than bash which does not
understand this.
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 you fail to plan, plan to fail.
^ 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