* Re: MPC7447A based board with MV64462 Marvell Discovery III controller
From: Sven Luther @ 2005-10-20 15:37 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20051020152157.GB18972@mag.az.mvista.com>
On Thu, Oct 20, 2005 at 08:21:57AM -0700, Mark A. Greer wrote:
> On Thu, Oct 20, 2005 at 05:04:50PM +0200, Sven Luther wrote:
> > Hey, we have code to boot the Freeserv with chrp/Of, need to clean it up and
> > merge it though. Would this be a good thing to submit for mainline inclusion,
> > it is a couple of lines at most, altough there is some reuse of the interrupt
> > controller code i think, which needs some cleanup.
>
> I don't know what a "Freeserv" is but, sure, push it on up once you're
> happy with it. The more code the merrier. :)
It is also known as HPC1, which is the discovery III based freesscale
reference design, as the HPC2 is the tundra based one.
Friendly,
Sven Luther
^ permalink raw reply
* Re: MPC7447A based board with MV64462 Marvell Discovery III controller
From: Sven Luther @ 2005-10-20 15:04 UTC (permalink / raw)
To: Mark A. Greer; +Cc: linuxppc-embedded
In-Reply-To: <20051013182654.GA18497@mag.az.mvista.com>
On Thu, Oct 13, 2005 at 11:26:54AM -0700, Mark A. Greer wrote:
> On Thu, Oct 13, 2005 at 01:12:19PM +0530, Ashish Bijlani wrote:
> > Hi,
> >
> > I'm trying to bring MPC7447A based board with MV64462 Marvell Discovery III
> > controller up. Can you guide me to Linux-2.6 sources with support for
> > MV64462 Marvell Discovery III controller and MPC7447A PowerPC processor.
> > Support for I2c, dual 10/100/1000 ethernet ports, and relevant platform
> > should be there. I cannot access the bit keeper repositories so please guide
> > me to the linux-2.6 kernel source tree if you can.
>
> Ashish,
>
> Support for both the 7447A and mv64x6x is in the latest 2.6 mainline
> kernel source at kernel.org.
>
> If your board is a chrp/openfirmware board, then you probably want to use
> the Pegasos code as an example. If your board has U-boot or some other
Hey, we have code to boot the Freeserv with chrp/Of, need to clean it up and
merge it though. Would this be a good thing to submit for mainline inclusion,
it is a couple of lines at most, altough there is some reuse of the interrupt
controller code i think, which needs some cleanup.
Friendly,
Sven Luther
^ permalink raw reply
* Re: open firmware
From: Sven Luther @ 2005-10-20 15:17 UTC (permalink / raw)
To: Hollis Blanchard; +Cc: linuxppc-dev
In-Reply-To: <80e720f67822d61a3dcd52cb906996cf@penguinppc.org>
On Fri, Oct 14, 2005 at 10:54:30AM -0500, Hollis Blanchard wrote:
> On Oct 14, 2005, at 10:34 AM, i2a wrote:
>
> >On Fri, 14 Oct 2005 15:17:47 +0200, Segher Boessenkool wrote
> >>
> >>See http://playground.sun.com/1275/
> >
> >Thanks, initially I had no luck with this site (I had find it),
> >http://playground.sun.com/1275/home.html#OFDCoreDoc
> >
> >The two links of the core documentation are dead :(, and there has to
> >be a way
> >to get the documentation without having to buy “the book”.
>
> openbios.org has a better-organized documentation collection.
BTW, anyone know of where to get the CHRP specs in downloadable html or pdf or
something format. Not the chrp OF bindings, but the real CHRP specs ?
Friendly,
Sven Luther
^ permalink raw reply
* Re: MPC7447A based board with MV64462 Marvell Discovery III controller
From: Mark A. Greer @ 2005-10-20 15:21 UTC (permalink / raw)
To: Sven Luther; +Cc: linuxppc-embedded
In-Reply-To: <20051020150450.GA27704@localhost.localdomain>
On Thu, Oct 20, 2005 at 05:04:50PM +0200, Sven Luther wrote:
> Hey, we have code to boot the Freeserv with chrp/Of, need to clean it up and
> merge it though. Would this be a good thing to submit for mainline inclusion,
> it is a couple of lines at most, altough there is some reuse of the interrupt
> controller code i think, which needs some cleanup.
I don't know what a "Freeserv" is but, sure, push it on up once you're
happy with it. The more code the merrier. :)
Mark
^ permalink raw reply
* MPC8270 with preemptible kernel stucks in early console write
From: claus @ 2005-10-20 13:52 UTC (permalink / raw)
To: linuxppc-embedded
Hi there,
I'm porting the 2.6.13.2 kernel to a custom board with a MPC8270.
If I compile the kernel preemptible then it gets stuck at the following
line in the cpm_uart_console_write function:
while ((bdp->cbd_sc & BD_SC_READY) != 0)
;
The early_console output works fine in the beginning of the boot but then
it gets stuck after the line "checking if image is initramfs...it isn't
(no cpio magic); looks like an initrd" is printed. The problem doesn't
seem to have anything to do with the initramfs detection though.
I can see with the debugger that the descriptors are OK and the buffers
are filled with correct data but it seems that the SCC is not sending the
characters and the main core is stuck waiting for a descriptor to be
ready for use.
Everything works fine if the kernel is not configured preemptible.
Has anyone else had similar behavior?
Any ideas?
-Claus-
^ permalink raw reply
* Re: How to make mudules on linux-ppc2.6.12
From: Andy Gospodarek @ 2005-10-20 12:19 UTC (permalink / raw)
To: JohnsonCheng; +Cc: linux-ppc-embedded
In-Reply-To: <20051020110322.A910E6860C@ozlabs.org>
Johnson,
See:
http://lwn.net/Articles/21817/
I found this article to be helpful in the past.
-andy
On 10/20/05, JohnsonCheng <JohnsonCheng@qnap.com.tw> wrote:
>
>
>
> Dear All,
>
>
>
> I just write a "hello world" module code, but I can't compile it for
> ppc2.6.12.
>
> My Makefile is list as following:
>
>
>
> obj-m :=3D test.o
>
> all:
>
> make ARCH=3Dppc CROSS_COMPILE=3Dpowerpc-linux- -C /root/linux-2.6.12.3
> SUBDIR=3D. modules
>
>
>
> When I run make, no error message output, but I find no test.ko modules. =
The
> output message is list as following:
>
>
>
> make ARCH=3Dppc CROSS_COMPILE=3Dpowerpc-linux- -C /root/linux-2.6.1
>
> 2.3 SUBDIR=3D. modules
>
> make[1]: Entering directory `/root/linux-2.6.12.3'
>
> CHK include/linux/version.h
>
> make[2]: `arch/ppc/kernel/asm-offsets.s' is up to date.
>
> Building modules, stage 2.
>
> MODPOST
>
> make[1]: Leaving directory `/root/linux-2.6.12.3'
>
>
>
> Do anyone can give me some help ?
>
>
>
> Thanks,
>
> Johnson Cheng
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* How to make mudules on linux-ppc2.6.12
From: JohnsonCheng @ 2005-10-20 10:56 UTC (permalink / raw)
To: linux-ppc-embedded
[-- Attachment #1: Type: text/plain, Size: 755 bytes --]
Dear All,
I just write a "hello world" module code, but I can't compile it for
ppc2.6.12.
My Makefile is list as following:
obj-m := test.o
all:
make ARCH=ppc CROSS_COMPILE=powerpc-linux- -C /root/linux-2.6.12.3
SUBDIR=. modules
When I run make, no error message output, but I find no test.ko modules. The
output message is list as following:
make ARCH=ppc CROSS_COMPILE=powerpc-linux- -C /root/linux-2.6.1
2.3 SUBDIR=. modules
make[1]: Entering directory `/root/linux-2.6.12.3'
CHK include/linux/version.h
make[2]: `arch/ppc/kernel/asm-offsets.s' is up to date.
Building modules, stage 2.
MODPOST
make[1]: Leaving directory `/root/linux-2.6.12.3'
Do anyone can give me some help ?
Thanks,
Johnson Cheng
[-- Attachment #2: Type: text/html, Size: 6266 bytes --]
^ permalink raw reply
* 8248 SEC
From: Wojciech Kromer @ 2005-10-20 10:58 UTC (permalink / raw)
To: linuxppc-embedded
Is there any driver for security-engine on mpc8248?
If yes, what can it do? where can I found it?
^ permalink raw reply
* Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
From: Dan Malek @ 2005-10-20 4:15 UTC (permalink / raw)
To: Christopher Cordahi; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <a1a7967e0510191729x520b2aeak@mail.gmail.com>
On Oct 19, 2005, at 8:29 PM, Christopher Cordahi wrote:
> I don't understand in what way Marcelo wants to use it, but
> from my understanding and a quick look of the Freescale product
> summary pages it's the opposite of what you're indicating.
OK. I can't find an up to date one any more. From the processor
manuals there are overlapping numbers (unless that was just
an oversight during editing).
> Also just because a feature isn't supposed to be present
> doesn't mean it's not.
Yeah, some people have tried probing peripherals to discover
the type of processor, but that was quickly proven to not work.
Thanks.
-- Dan
^ permalink raw reply
* Re: [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx
From: Christopher Cordahi @ 2005-10-20 0:29 UTC (permalink / raw)
To: Dan Malek; +Cc: Kumar Gala, linuxppc-embedded list
In-Reply-To: <4c41159c3c06e288e5d69469f1e3ce7b@embeddededge.com>
On 18/10/05, Dan Malek <dan@embeddededge.com> wrote:
>
> On Oct 18, 2005, at 10:24 AM, Marcelo Tosatti wrote:
>
> > For 8xx, I was wondering if the PARTNUM field of the IMMR
> > (section 10.4.1 of MPC860UM.pdf) does have meaningful
> > information which could be used to identify the CPU.
>
> It has meaningful information, but not the way you want
> to use it :-) The PARTNUM/MASKNUM is only useful
> once you know the type of processor (like 823, 850, 885, etc)
> The PARTNUM is only useful within the "family." For
> example, the 860 and 880 are two different families, and
> will contain the similar PARTNUM values through their life.
> I believe it's tied to the fabrication process.
I don't understand in what way Marcelo wants to use it, but
from my understanding and a quick look of the Freescale product
summary pages it's the opposite of what you're indicating.
I believe the PARTNUM identifies the family not the part.
You can't tell an 885 from an 870 (IMMR contains 0x09xx).
Similarly you can't tell an 860EN from an 860T (IMMR
contains 0x00xx or 0x05xx).
But you can tell an 860 from an 880 which are in different
families. Note that it's not always obvious which parts
are in the same family.
> You may as well stop looking for an easy (or possibly
> any) way to differentiate these parts in software, but
> due to they way they are fabricated, I don't think that's
> ever going to happen. :-)
Also just because a feature isn't supposed to be present
doesn't mean it's not.
We bought 860EN (4 SCCs) parts but Motorola accidentily
shipped us 860DE (2 SCCs) parts. We installed, tested and
shipped a few of these parts using all 4 SCCs without
problem. It wasn't until another unrelated problem occurred
that we noticed that we had used a tray of the wrong part.
Chris
^ permalink raw reply
* [PATCH] (modified) Merge types.h
From: Becky Bruce @ 2005-10-19 23:45 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev
powerpc: Merge types.h
This patch merges types.h into include/asm-powerpc. The only real change is
the removal of the include of linux/config.h from the 32-bit version - it
doesn't appear to be necessary.
This patch has been built on several different 32 and 64-bit platforms,
and booted on mpc8540_ads.
This patch supersedes the previous patch [PATCH] Merge types.h
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 995fc5087d7f02d7e570c9a904a16453e1d8d307
tree 8326faf3664a5c2912ab28f822d9ab7e84fc8a1b
parent 4746820969c846263fca3f0b54e0c1af883b67ed
author Becky Bruce <becky.bruce@freescale.com> Wed, 19 Oct 2005 11:12:13 -0500
committer Becky Bruce <becky.bruce@freescale.com> Wed, 19 Oct 2005 11:12:13 -0500
include/asm-powerpc/types.h | 104 +++++++++++++++++++++++++++++++++++++++++++
include/asm-ppc/types.h | 69 ------------------------------
include/asm-ppc64/types.h | 79 ----------------------------------
3 files changed, 100 insertions(+), 148 deletions(-)
diff --git a/include/asm-powerpc/types.h b/include/asm-powerpc/types.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/types.h
@@ -0,0 +1,104 @@
+#ifndef _ASM_POWERPC_TYPES_H
+#define _ASM_POWERPC_TYPES_H
+
+#ifndef __ASSEMBLY__
+
+/*
+ * This file is never included by application software unless
+ * explicitly requested (e.g., via linux/types.h) in which case the
+ * application is Linux specific so (user-) name space pollution is
+ * not a major issue. However, for interoperability, libraries still
+ * need to be careful to avoid a name clashes.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+#ifdef __powerpc64__
+typedef unsigned int umode_t;
+#else
+typedef unsigned short umode_t;
+#endif
+
+/*
+ * __xx is ok: it doesn't pollute the POSIX namespace. Use these in the
+ * header files exported to user space
+ */
+
+typedef __signed__ char __s8;
+typedef unsigned char __u8;
+
+typedef __signed__ short __s16;
+typedef unsigned short __u16;
+
+typedef __signed__ int __s32;
+typedef unsigned int __u32;
+
+#ifdef __powerpc64__
+typedef __signed__ long __s64;
+typedef unsigned long __u64;
+#else
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
+#endif
+#endif /* __powerpc64__ */
+
+typedef struct {
+ __u32 u[4];
+} __attribute((aligned(16))) __vector128;
+
+#endif /* __ASSEMBLY__ */
+
+#ifdef __KERNEL__
+/*
+ * These aren't exported outside the kernel to avoid name space clashes
+ */
+#ifdef __powerpc64__
+#define BITS_PER_LONG 64
+#else
+#define BITS_PER_LONG 32
+#endif
+
+#ifndef __ASSEMBLY__
+
+typedef signed char s8;
+typedef unsigned char u8;
+
+typedef signed short s16;
+typedef unsigned short u16;
+
+typedef signed int s32;
+typedef unsigned int u32;
+
+#ifdef __powerpc64__
+typedef signed long s64;
+typedef unsigned long u64;
+#else
+typedef signed long long s64;
+typedef unsigned long long u64;
+#endif
+
+typedef __vector128 vector128;
+
+typedef u32 dma_addr_t;
+typedef u64 dma64_addr_t;
+
+typedef struct {
+ unsigned long entry;
+ unsigned long toc;
+ unsigned long env;
+} func_descr_t;
+
+#ifdef CONFIG_LBD
+typedef u64 sector_t;
+#define HAVE_SECTOR_T
+#endif
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __KERNEL__ */
+
+#endif /* _ASM_POWERPC_TYPES_H */
diff --git a/include/asm-ppc/types.h b/include/asm-ppc/types.h
deleted file mode 100644
--- a/include/asm-ppc/types.h
+++ /dev/null
@@ -1,69 +0,0 @@
-#ifndef _PPC_TYPES_H
-#define _PPC_TYPES_H
-
-#ifndef __ASSEMBLY__
-
-typedef __signed__ char __s8;
-typedef unsigned char __u8;
-
-typedef __signed__ short __s16;
-typedef unsigned short __u16;
-
-typedef __signed__ int __s32;
-typedef unsigned int __u32;
-
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
-typedef __signed__ long long __s64;
-typedef unsigned long long __u64;
-#endif
-
-typedef struct {
- __u32 u[4];
-} __vector128;
-
-/*
- * XXX allowed outside of __KERNEL__ for now, until glibc gets
- * a proper set of asm headers of its own. -- paulus
- */
-typedef unsigned short umode_t;
-
-#endif /* __ASSEMBLY__ */
-
-#ifdef __KERNEL__
-/*
- * These aren't exported outside the kernel to avoid name space clashes
- */
-#define BITS_PER_LONG 32
-
-#ifndef __ASSEMBLY__
-
-#include <linux/config.h>
-
-typedef signed char s8;
-typedef unsigned char u8;
-
-typedef signed short s16;
-typedef unsigned short u16;
-
-typedef signed int s32;
-typedef unsigned int u32;
-
-typedef signed long long s64;
-typedef unsigned long long u64;
-
-typedef __vector128 vector128;
-
-/* DMA addresses are 32-bits wide */
-typedef u32 dma_addr_t;
-typedef u64 dma64_addr_t;
-
-#ifdef CONFIG_LBD
-typedef u64 sector_t;
-#define HAVE_SECTOR_T
-#endif
-
-#endif /* __ASSEMBLY__ */
-
-#endif /* __KERNEL__ */
-
-#endif
diff --git a/include/asm-ppc64/types.h b/include/asm-ppc64/types.h
deleted file mode 100644
--- a/include/asm-ppc64/types.h
+++ /dev/null
@@ -1,79 +0,0 @@
-#ifndef _PPC64_TYPES_H
-#define _PPC64_TYPES_H
-
-#ifndef __ASSEMBLY__
-
-/*
- * This file is never included by application software unless
- * explicitly requested (e.g., via linux/types.h) in which case the
- * application is Linux specific so (user-) name space pollution is
- * not a major issue. However, for interoperability, libraries still
- * need to be careful to avoid a name clashes.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-typedef unsigned int umode_t;
-
-/*
- * __xx is ok: it doesn't pollute the POSIX namespace. Use these in the
- * header files exported to user space
- */
-
-typedef __signed__ char __s8;
-typedef unsigned char __u8;
-
-typedef __signed__ short __s16;
-typedef unsigned short __u16;
-
-typedef __signed__ int __s32;
-typedef unsigned int __u32;
-
-typedef __signed__ long __s64;
-typedef unsigned long __u64;
-
-typedef struct {
- __u32 u[4];
-} __attribute((aligned(16))) __vector128;
-
-#endif /* __ASSEMBLY__ */
-
-#ifdef __KERNEL__
-/*
- * These aren't exported outside the kernel to avoid name space clashes
- */
-#define BITS_PER_LONG 64
-
-#ifndef __ASSEMBLY__
-
-typedef signed char s8;
-typedef unsigned char u8;
-
-typedef signed short s16;
-typedef unsigned short u16;
-
-typedef signed int s32;
-typedef unsigned int u32;
-
-typedef signed long s64;
-typedef unsigned long u64;
-
-typedef __vector128 vector128;
-
-typedef u32 dma_addr_t;
-typedef u64 dma64_addr_t;
-
-typedef struct {
- unsigned long entry;
- unsigned long toc;
- unsigned long env;
-} func_descr_t;
-
-#endif /* __ASSEMBLY__ */
-
-#endif /* __KERNEL__ */
-
-#endif /* _PPC64_TYPES_H */
^ permalink raw reply
* Re: [PATCH] powerpc: merge types.h
From: Becky Bruce @ 2005-10-19 23:41 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <17238.52279.428407.411558@cargo.ozlabs.ibm.com>
Gack! While I doubt that should break anything, I can't promise 100%
that it won't. I'll resubmit with that wrapped up in a nice shiny
ifdef.
Thanks for the catch - I wouldn't want irate users picketing my house :)
Cheers,
B
On Oct 19, 2005, at 5:44 PM, Paul Mackerras wrote:
> Becky Bruce writes:
>
>> This patch merges types.h into include/asm-powerpc. The only real
>> changes
>> here are that umode_t has become short instead of int in the 64-bit
>> case,
>> which appears to match what most other platforms have done.
>
> Ummm, isn't that an ABI change? We don't want to do that unless
> you're completely absolutely positively sure it couldn't possibly
> cause any userspace breakage.
>
> Regards,
> Paul.
^ permalink raw reply
* Re: [PATCH] powerpc: merge types.h
From: Paul Mackerras @ 2005-10-19 22:44 UTC (permalink / raw)
To: Becky Bruce; +Cc: linuxppc64-dev, linuxppc-dev
In-Reply-To: <Pine.LNX.4.61.0510191140350.29058@cde-tx32-ldt329.sps.mot.com>
Becky Bruce writes:
> This patch merges types.h into include/asm-powerpc. The only real changes
> here are that umode_t has become short instead of int in the 64-bit case,
> which appears to match what most other platforms have done.
Ummm, isn't that an ABI change? We don't want to do that unless
you're completely absolutely positively sure it couldn't possibly
cause any userspace breakage.
Regards,
Paul.
^ permalink raw reply
* [PATCH] ppc32: ppc_sys fixes for 8xx and 82xx (whitespaces fixed)
From: Vitaly Bordug @ 2005-10-19 17:57 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Kumar Gala, linuxppc-embedded list
[-- Attachment #1: Type: text/plain, Size: 726 bytes --]
This patch fixes a numbers of issues regarding to that both 8xx and 82xx
began to use ppc_sys model:
- Platform is now identified by default deviceless SOC, if no
BOARD_CHIP_NAME is specified in the bard-specific header. For the list
of supported names refer to (arch/ppc/syslib/) mpc8xx_sys.c and
mpc82xx_sys.c for 8xx and 82xx respectively.
- Fixed a bug in identification by name - if the name was not found, it
returned -1 instead of default deviceless ppc_spec.
- fixed devices amount in the 8xx platform system descriptions
Signed-off-by: Vitaly Bordug <vbordug@ru.mvista.com>
Signed-off-by: Marcelo Tosatti <marcelo.tosatti@cyclades.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
--
Sincerely,
Vitaly
[-- Attachment #2: 2.patch --]
[-- Type: text/x-patch, Size: 3507 bytes --]
diff --git a/arch/ppc/platforms/fads.h b/arch/ppc/platforms/fads.h
--- a/arch/ppc/platforms/fads.h
+++ b/arch/ppc/platforms/fads.h
@@ -25,6 +25,8 @@
#if defined(CONFIG_MPC86XADS)
+#define BOARD_CHIP_NAME "MPC86X"
+
/* U-Boot maps BCSR to 0xff080000 */
#define BCSR_ADDR ((uint)0xff080000)
diff --git a/arch/ppc/platforms/mpc885ads.h b/arch/ppc/platforms/mpc885ads.h
--- a/arch/ppc/platforms/mpc885ads.h
+++ b/arch/ppc/platforms/mpc885ads.h
@@ -88,5 +88,7 @@
#define SICR_ENET_MASK ((uint)0x00ff0000)
#define SICR_ENET_CLKRT ((uint)0x002c0000)
+#define BOARD_CHIP_NAME "MPC885"
+
#endif /* __ASM_MPC885ADS_H__ */
#endif /* __KERNEL__ */
diff --git a/arch/ppc/syslib/m8260_setup.c b/arch/ppc/syslib/m8260_setup.c
--- a/arch/ppc/syslib/m8260_setup.c
+++ b/arch/ppc/syslib/m8260_setup.c
@@ -62,6 +62,10 @@ m8260_setup_arch(void)
if (initrd_start)
ROOT_DEV = Root_RAM0;
#endif
+
+ identify_ppc_sys_by_name_and_id(BOARD_CHIP_NAME,
+ in_be32(CPM_MAP_ADDR + CPM_IMMR_OFFSET));
+
m82xx_board_setup();
}
diff --git a/arch/ppc/syslib/m8xx_setup.c b/arch/ppc/syslib/m8xx_setup.c
--- a/arch/ppc/syslib/m8xx_setup.c
+++ b/arch/ppc/syslib/m8xx_setup.c
@@ -404,6 +404,8 @@ platform_init(unsigned long r3, unsigned
strcpy(cmd_line, (char *)(r6+KERNELBASE));
}
+ identify_ppc_sys_by_name(BOARD_CHIP_NAME);
+
ppc_md.setup_arch = m8xx_setup_arch;
ppc_md.show_percpuinfo = m8xx_show_percpuinfo;
ppc_md.irq_canonicalize = NULL;
diff --git a/arch/ppc/syslib/mpc8xx_sys.c b/arch/ppc/syslib/mpc8xx_sys.c
--- a/arch/ppc/syslib/mpc8xx_sys.c
+++ b/arch/ppc/syslib/mpc8xx_sys.c
@@ -24,7 +24,7 @@ struct ppc_sys_spec ppc_sys_specs[] = {
.ppc_sys_name = "MPC86X",
.mask = 0xFFFFFFFF,
.value = 0x00000000,
- .num_devices = 2,
+ .num_devices = 7,
.device_list = (enum ppc_sys_devices[])
{
MPC8xx_CPM_FEC1,
@@ -40,7 +40,7 @@ struct ppc_sys_spec ppc_sys_specs[] = {
.ppc_sys_name = "MPC885",
.mask = 0xFFFFFFFF,
.value = 0x00000000,
- .num_devices = 3,
+ .num_devices = 8,
.device_list = (enum ppc_sys_devices[])
{
MPC8xx_CPM_FEC1,
diff --git a/arch/ppc/syslib/ppc_sys.c b/arch/ppc/syslib/ppc_sys.c
--- a/arch/ppc/syslib/ppc_sys.c
+++ b/arch/ppc/syslib/ppc_sys.c
@@ -69,6 +69,9 @@ static int __init find_chip_by_name_and_
matched[j++] = i;
i++;
}
+
+ ret = i;
+
if (j != 0) {
for (i = 0; i < j; i++) {
if ((ppc_sys_specs[matched[i]].mask & id) ==
diff --git a/include/asm-ppc/cpm2.h b/include/asm-ppc/cpm2.h
--- a/include/asm-ppc/cpm2.h
+++ b/include/asm-ppc/cpm2.h
@@ -1087,6 +1087,9 @@ typedef struct im_idma {
#define SCCR_PCIDF_MSK 0x00000078 /* PCI division factor */
#define SCCR_PCIDF_SHIFT 3
+#ifndef CPM_IMMR_OFFSET
+#define CPM_IMMR_OFFSET 0x101a8
+#endif
#endif /* __CPM2__ */
#endif /* __KERNEL__ */
diff --git a/include/asm-ppc/mpc8260.h b/include/asm-ppc/mpc8260.h
--- a/include/asm-ppc/mpc8260.h
+++ b/include/asm-ppc/mpc8260.h
@@ -92,6 +92,10 @@ enum ppc_sys_devices {
extern unsigned char __res[];
#endif
+#ifndef BOARD_CHIP_NAME
+#define BOARD_CHIP_NAME ""
+#endif
+
#endif /* CONFIG_8260 */
#endif /* !__ASM_PPC_MPC8260_H__ */
#endif /* __KERNEL__ */
diff --git a/include/asm-ppc/mpc8xx.h b/include/asm-ppc/mpc8xx.h
--- a/include/asm-ppc/mpc8xx.h
+++ b/include/asm-ppc/mpc8xx.h
@@ -113,6 +113,10 @@ enum ppc_sys_devices {
MPC8xx_CPM_USB,
};
+#ifndef BOARD_CHIP_NAME
+#define BOARD_CHIP_NAME ""
+#endif
+
#endif /* !__ASSEMBLY__ */
#endif /* CONFIG_8xx */
#endif /* __CONFIG_8xx_DEFS */
^ permalink raw reply
* PPC 440 / JFFS2 checksum question.
From: Andrew McCarthy @ 2005-10-19 17:36 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2210 bytes --]
We have some PPC440GX based blade servers that boot
from flash. My boss wants me to add
additional checksums somewhere in the JFFS2 partitions
as an overall check of the JFFS2 filesystem images that
we burn to flash. Once the image is burned, that file
system is never written to again. (That's the theory anyway).
So every time they boot they want to read these checksum
out of the flash and use it to decide if they want to/can boot
with that filesystem or fallback to another one.
Each copy of the kernel has its own JFFS2 partition.
The root file system has its own JFFS2 partition. I don't
understand why they don't just write everything to one
JFFS2 partition. They say it is because they are
worried about power failure while writing to the flash and want
to isolate any write failures.
( I tried to tell them that the journaling already handles
that case quite well - but they are non-believers)
Some questions;
1) Is a filesystem-wide checksum really necessary or
is it kind of silly?
1.1) Doesn't JFFS2 already do some integrity checking after
it finishes writing a file? Are there checksums or anything that
serves the same function? They want to avoid having to
checksum the entire filesystem at boot time (due to quick
boot time requirements) - is there some field or fields, or technique that
can quickly tell me if the filesystem is ok?
2) Is there any place within the bounds of a JFFS2
partition that is safe from being overwritten? before and
after checksums could be placed there.
2.1) Is there any way to create such a place? for example,
by appending the checksums to the end of some filesystem-wide
structure like a super block? Or maybe it can be hidden in
a couple of inodes that are never overwritten.
What I'm looking for regarding this adding extra checksums into the
JFFS2 image is:
3.1) How can it be done?
3.2) Why might it be unnecessary or even inadvisable?
3.3) Why can't it be done?
Once I understand the answers to these questions I can
go back and see what they want to do.
In the meantime, I am dumping and analyzing the JFFS2
filesystems we have and reading the code trying to find the
answers.
thanks for your time.
[-- Attachment #2: Type: text/html, Size: 3145 bytes --]
^ permalink raw reply
* [PATCH] powerpc: merge types.h
From: Becky Bruce @ 2005-10-19 16:55 UTC (permalink / raw)
To: linuxppc64-dev, linuxppc-dev
powerpc: Merge types.h
This patch merges types.h into include/asm-powerpc. The only real changes
here are that umode_t has become short instead of int in the 64-bit case,
which appears to match what most other platforms have done. Also, the
32-bit version was #including linux/config.h - I have removed this as it
does not appear necessary.
This patch has been built on several different 32 and 64-bit platforms,
and booted on mpc8540_ads.
Signed-off-by: Becky Bruce <becky.bruce@freescale.com>
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
---
commit 995fc5087d7f02d7e570c9a904a16453e1d8d307
tree 8326faf3664a5c2912ab28f822d9ab7e84fc8a1b
parent 4746820969c846263fca3f0b54e0c1af883b67ed
author Becky Bruce <becky.bruce@freescale.com> Wed, 19 Oct 2005 11:12:13 -0500
committer Becky Bruce <becky.bruce@freescale.com> Wed, 19 Oct 2005 11:12:13 -0500
include/asm-powerpc/types.h | 100 +++++++++++++++++++++++++++++++++++++++++++
include/asm-ppc/types.h | 69 ------------------------------
include/asm-ppc64/types.h | 79 ----------------------------------
3 files changed, 100 insertions(+), 148 deletions(-)
diff --git a/include/asm-powerpc/types.h b/include/asm-powerpc/types.h
new file mode 100644
--- /dev/null
+++ b/include/asm-powerpc/types.h
@@ -0,0 +1,100 @@
+#ifndef _ASM_POWERPC_TYPES_H
+#define _ASM_POWERPC_TYPES_H
+
+#ifndef __ASSEMBLY__
+
+/*
+ * This file is never included by application software unless
+ * explicitly requested (e.g., via linux/types.h) in which case the
+ * application is Linux specific so (user-) name space pollution is
+ * not a major issue. However, for interoperability, libraries still
+ * need to be careful to avoid a name clashes.
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version
+ * 2 of the License, or (at your option) any later version.
+ */
+
+typedef unsigned short umode_t;
+
+/*
+ * __xx is ok: it doesn't pollute the POSIX namespace. Use these in the
+ * header files exported to user space
+ */
+
+typedef __signed__ char __s8;
+typedef unsigned char __u8;
+
+typedef __signed__ short __s16;
+typedef unsigned short __u16;
+
+typedef __signed__ int __s32;
+typedef unsigned int __u32;
+
+#ifdef __powerpc64__
+typedef __signed__ long __s64;
+typedef unsigned long __u64;
+#else
+#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
+typedef __signed__ long long __s64;
+typedef unsigned long long __u64;
+#endif
+#endif /* __powerpc64__ */
+
+typedef struct {
+ __u32 u[4];
+} __attribute((aligned(16))) __vector128;
+
+#endif /* __ASSEMBLY__ */
+
+#ifdef __KERNEL__
+/*
+ * These aren't exported outside the kernel to avoid name space clashes
+ */
+#ifdef __powerpc64__
+#define BITS_PER_LONG 64
+#else
+#define BITS_PER_LONG 32
+#endif
+
+#ifndef __ASSEMBLY__
+
+typedef signed char s8;
+typedef unsigned char u8;
+
+typedef signed short s16;
+typedef unsigned short u16;
+
+typedef signed int s32;
+typedef unsigned int u32;
+
+#ifdef __powerpc64__
+typedef signed long s64;
+typedef unsigned long u64;
+#else
+typedef signed long long s64;
+typedef unsigned long long u64;
+#endif
+
+typedef __vector128 vector128;
+
+typedef u32 dma_addr_t;
+typedef u64 dma64_addr_t;
+
+typedef struct {
+ unsigned long entry;
+ unsigned long toc;
+ unsigned long env;
+} func_descr_t;
+
+#ifdef CONFIG_LBD
+typedef u64 sector_t;
+#define HAVE_SECTOR_T
+#endif
+
+#endif /* __ASSEMBLY__ */
+
+#endif /* __KERNEL__ */
+
+#endif /* _ASM_POWERPC_TYPES_H */
diff --git a/include/asm-ppc/types.h b/include/asm-ppc/types.h
deleted file mode 100644
--- a/include/asm-ppc/types.h
+++ /dev/null
@@ -1,69 +0,0 @@
-#ifndef _PPC_TYPES_H
-#define _PPC_TYPES_H
-
-#ifndef __ASSEMBLY__
-
-typedef __signed__ char __s8;
-typedef unsigned char __u8;
-
-typedef __signed__ short __s16;
-typedef unsigned short __u16;
-
-typedef __signed__ int __s32;
-typedef unsigned int __u32;
-
-#if defined(__GNUC__) && !defined(__STRICT_ANSI__)
-typedef __signed__ long long __s64;
-typedef unsigned long long __u64;
-#endif
-
-typedef struct {
- __u32 u[4];
-} __vector128;
-
-/*
- * XXX allowed outside of __KERNEL__ for now, until glibc gets
- * a proper set of asm headers of its own. -- paulus
- */
-typedef unsigned short umode_t;
-
-#endif /* __ASSEMBLY__ */
-
-#ifdef __KERNEL__
-/*
- * These aren't exported outside the kernel to avoid name space clashes
- */
-#define BITS_PER_LONG 32
-
-#ifndef __ASSEMBLY__
-
-#include <linux/config.h>
-
-typedef signed char s8;
-typedef unsigned char u8;
-
-typedef signed short s16;
-typedef unsigned short u16;
-
-typedef signed int s32;
-typedef unsigned int u32;
-
-typedef signed long long s64;
-typedef unsigned long long u64;
-
-typedef __vector128 vector128;
-
-/* DMA addresses are 32-bits wide */
-typedef u32 dma_addr_t;
-typedef u64 dma64_addr_t;
-
-#ifdef CONFIG_LBD
-typedef u64 sector_t;
-#define HAVE_SECTOR_T
-#endif
-
-#endif /* __ASSEMBLY__ */
-
-#endif /* __KERNEL__ */
-
-#endif
diff --git a/include/asm-ppc64/types.h b/include/asm-ppc64/types.h
deleted file mode 100644
--- a/include/asm-ppc64/types.h
+++ /dev/null
@@ -1,79 +0,0 @@
-#ifndef _PPC64_TYPES_H
-#define _PPC64_TYPES_H
-
-#ifndef __ASSEMBLY__
-
-/*
- * This file is never included by application software unless
- * explicitly requested (e.g., via linux/types.h) in which case the
- * application is Linux specific so (user-) name space pollution is
- * not a major issue. However, for interoperability, libraries still
- * need to be careful to avoid a name clashes.
- *
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU General Public License
- * as published by the Free Software Foundation; either version
- * 2 of the License, or (at your option) any later version.
- */
-
-typedef unsigned int umode_t;
-
-/*
- * __xx is ok: it doesn't pollute the POSIX namespace. Use these in the
- * header files exported to user space
- */
-
-typedef __signed__ char __s8;
-typedef unsigned char __u8;
-
-typedef __signed__ short __s16;
-typedef unsigned short __u16;
-
-typedef __signed__ int __s32;
-typedef unsigned int __u32;
-
-typedef __signed__ long __s64;
-typedef unsigned long __u64;
-
-typedef struct {
- __u32 u[4];
-} __attribute((aligned(16))) __vector128;
-
-#endif /* __ASSEMBLY__ */
-
-#ifdef __KERNEL__
-/*
- * These aren't exported outside the kernel to avoid name space clashes
- */
-#define BITS_PER_LONG 64
-
-#ifndef __ASSEMBLY__
-
-typedef signed char s8;
-typedef unsigned char u8;
-
-typedef signed short s16;
-typedef unsigned short u16;
-
-typedef signed int s32;
-typedef unsigned int u32;
-
-typedef signed long s64;
-typedef unsigned long u64;
-
-typedef __vector128 vector128;
-
-typedef u32 dma_addr_t;
-typedef u64 dma64_addr_t;
-
-typedef struct {
- unsigned long entry;
- unsigned long toc;
- unsigned long env;
-} func_descr_t;
-
-#endif /* __ASSEMBLY__ */
-
-#endif /* __KERNEL__ */
-
-#endif /* _PPC64_TYPES_H */
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: Andrei Konovalov @ 2005-10-19 10:24 UTC (permalink / raw)
To: Kalle Pokki, David H. Lynch Jr; +Cc: linuxppc-embedded
In-Reply-To: <4355E9B5.30106@iki.fi>
Kalle Pokki wrote:
> David H. Lynch Jr wrote:
>
>> Alright I have RAM at physical 0x0 now. I throw a copy of a
>> compressed linux image into RAM (anywhere special ?) load the assorted
>> registers with the appropriate values, fill the board info struct.,
>> and just jump to the start of the image and pray that load text starts
>> coming out my serial port ?
>
> Basically, but the exact thing to do depends which image you take. The
> build process results in a few different image files. I usually just
> take the vmlinux ELF file, and then my own scripts objcopy it to binary,
> compress, objcopy to an object file, and link the compressed image
> directly to the boot loader. The boot loader is then, of course,
> responsible of uncompressing the image to RAM to 0x00000000.
>
> I think the kernel build can also create some "self-extracting" images,
> but I have never tried those.
Yes, this is exactly the way ML300 is booted (as regards to the code
currently in www.kernel.org's 2.6 tree).
Use 'make zImage' or 'make zImage.initrd' to get zImage.elf or zImage.initrd.elf.
> Maybe they don't even work anymore, as
> many (most?) people just use the U-boot images.
There is U-Boot port for ML300 by Peter Ryser from Xilinx,
but I haven't tried using it (yet). IIRC there is an appnote
on Xilinx web site that describes how to boot the 2.4 kernel
with U-Boot (few modifications need to be done to the kernel).
Best regards,
Andrei
^ permalink raw reply
* RE: ELDK 3.1.1 ramdisk
From: Clement Fabien @ 2005-10-19 11:17 UTC (permalink / raw)
To: somshekar chandrashekar kadam, linuxppc-embedded
Hi,
Make sure ROOT_DEV is initialized to the correct device, for instance :
In Sandpoint.c (arch\ppc\platforms): =09
#ifdef CONFIG_ROOT_NFS
ROOT_DEV =3D to_kdev_t(0x00FF); /* /dev/nfs pseudo device */
#endif
There is no default value for it, except if you pass it on command line
Fabien
________________________________________
From: linuxppc-embedded-bounces@ozlabs.org =
[mailto:linuxppc-embedded-bounces@ozlabs.org] On Behalf Of somshekar =
chandrashekar kadam
Sent: lundi 17 octobre 2005 09:52
To: linuxppc-embedded@ozlabs.org
Subject: ELDK 3.1.1 ramdisk
=A0=20
HI ,=20
=A0 I am using MPC862 with 64mb ram , with Denx 3.1.1 eldk=20
with linux-2.4.25 on my custom board.=20
on Uboot i use SMC2 as my serial console , when i load linux i use SCC4 =
as my serisl console , this is becuase i dont have any idea why my SMC2 =
is not working , it works fine on my linux-2.4.18 kernel ,=20
anyways thats not the problem ,
i am using ramdisk_image.gz provided by eldk , and i have configured =
kernel wit intial ramdisk support , i have attachec the config file =
below , and also the booting messages in another file . as i chnages the =
console from smc2 to scc4 from uboot to linux may be intial message is =
not clear ,=20
i always get kernel panic VFS unable to mount root fs , is there =
something else i need to do or i am missing very important configuartion =
, please throw some light=20
thanks in advance=20
Neelu=20
^ permalink raw reply
* Re: openpic/mac-io
From: Benjamin Herrenschmidt @ 2005-10-19 10:35 UTC (permalink / raw)
To: i2a; +Cc: linuxppc-dev
In-Reply-To: <20051018191029.M22134@quicknet.nl>
On Tue, 2005-10-18 at 21:22 +0200, i2a wrote:
> Hi,
>
> I am searching for documentation about the OpenPIC interrupt-controller in mac
> systems. I found this site but most of the links are dead or give no hope on
> real technical documentation :).
> http://www.macbsd.com/openmac/refs.html
>
> Could someone give any pointers or files?
>
> I am also searching for any related documentation on the mac-io device (this
> could be a combo document).
>
> I am trying to do a port as a masters project, and my biggest problem is:
> documentation :(.
Another interesting bit of docs is MacTech.pdf (google for it) which
documents an early version of the mac-io chip that was used on some CHRP
machines.
In general, there is no complete documentation. I would say that the
linux source code is probably the best you can get in this regard.
Feel free to ask me questions about details
Ben.
^ permalink raw reply
* Re: jffs2 robustness against powerfailure
From: David Woodhouse @ 2005-10-19 9:50 UTC (permalink / raw)
To: David Jander; +Cc: linux-mtd, linuxppc-embedded
In-Reply-To: <200510191010.47799.david.jander@protonic.nl>
On Wed, 2005-10-19 at 10:10 +0200, David Jander wrote:
> 2.6 is not an option yet for mpc8xx architecture, so I'll have to stick with
> either what I have now or 2.4.31, but I fear the tradeoff of using vanilla
> 2.4.31 jffs2 will be much slower fs, prohibitively long mount-times, etc...
> am I right?
If it's all running perfectly for you and you have no work to do, then
yes, perhaps you're right. But since that's evidently _not_ the case,
then no, I would disagree.
If I were you, the first thing I'd do would be to get a current kernel
working. It should only take a week or so -- porting from 2.4 to 2.6
really isn't that difficult.
> I am still busy doing experiments, please have a little patience.
> Until now I have turned on debug info in the same kernel as before, and get
> literally tons of log info. My monitor script had a bug, so the board was
> reset a little to soon in several occasions (shouldn't harm, should it), so
> now I have an image of jffs2 which on boot of the system produces a BUG() in
> gc.c line 139.
That should never happen, regardless of when the board is reset.
Assuming it still happens with JFFS2 code I care about (either 2.4 or
2.6), please could I have a copy of this image?
The problem you first reported doesn't seem too worrying to me. Writes
aren't always atomic -- in fact the Linux VFS¹ _guarantees_ that writes
larger than a page are _not_ atomic, because it splits pages up to call
prepare_write() and commit_write() on each one.
JFFS2 will mostly write each page out in a single node, but when there
is only a small amount of space at the end of an eraseblock it will
split writes still further, filling the eraseblock with as much data as
possible before writing the remainder of the page into a new eraseblock.
I suspect that's what happened in the case you showed.
--
dwmw2
¹ Assuming you use generic_file_write()
^ permalink raw reply
* Re: openpic/mac-io
From: Geert Uytterhoeven @ 2005-10-19 9:22 UTC (permalink / raw)
To: i2a; +Cc: Linux/PPC Development
In-Reply-To: <20051018191029.M22134@quicknet.nl>
On Tue, 18 Oct 2005, i2a wrote:
> I am searching for documentation about the OpenPIC interrupt-controller in mac
> systems. I found this site but most of the links are dead or give no hope on
> real technical documentation :).
> http://www.macbsd.com/openmac/refs.html
>
> Could someone give any pointers or files?
http://www.printk.net/pub/docs/openpic/
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: jffs2 robustness against powerfailure
From: David Jander @ 2005-10-19 8:10 UTC (permalink / raw)
To: David Woodhouse; +Cc: linux-mtd, linuxppc-embedded
In-Reply-To: <1129552672.3830.249.camel@baythorne.infradead.org>
On Monday 17 October 2005 14:37, David Woodhouse wrote:
> On Fri, 2005-10-14 at 11:35 +0200, David Jander wrote:
> > We have a custom embedded linux board, based on a MPC852T processor,
> > running 2.4.25 kernel from denx. Jffs2 has certain backported patches
> > after cvs from 03/2005.
>
> That sounds like a recipe for pain. March 2005 wasn't a good time to
> take a snapshot from CVS; that just happens to be the time that we
> stopped bothering to make it build in obsolete kernels.
That's why I posted to the linuxppc-embedded list, because I know there are
quite some people using the same version (denx CVS kernel), and might have
had issues of this kind also, although I mostly hear that it seems pretty
stable and doesn't give problems.
> If you want _stable_ JFFS2 code, you should use the code which is in the
> 2.4.31 kernel, or use the code which is in the 2.6 kernel (perhaps
> updated from current CVS).
2.6 is not an option yet for mpc8xx architecture, so I'll have to stick with
either what I have now or 2.4.31, but I fear the tradeoff of using vanilla
2.4.31 jffs2 will be much slower fs, prohibitively long mount-times, etc...
am I right?
>[...]
> Please could you reproduce on a sane kernel and show the output of the
> checkfs program during your test just before the power down, and also if
> possible take an image of the contents of the flash _before_ mounting it
> again after the power cycle. I'd like to see precisely the log nodes
> which were present on the flash. If it's difficult to take a snapshot
> before remounting, then running with CONFIG_JFFS2_FS_DEBUG=1 and
> capturing all the KERN_DEBUG output via a serial console would suffice.
I am still busy doing experiments, please have a little patience.
Until now I have turned on debug info in the same kernel as before, and get
literally tons of log info. My monitor script had a bug, so the board was
reset a little to soon in several occasions (shouldn't harm, should it), so
now I have an image of jffs2 which on boot of the system produces a BUG() in
gc.c line 139. This is not what I am looking for right now, and I still have
to discard any possibilities that this could have happened due to other
problems (RAM issues, etc). Once I finish sorting this out, I'd be glad to
send you a few megabytes of debug output along with a "broken" jffs2 image if
you like. Actually I'd be very grateful if you could take some time to look
at it and give me your opinion, because I am still slightly clueless about
jffs2.
Greetings,
--
David Jander
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: Kalle Pokki @ 2005-10-19 6:37 UTC (permalink / raw)
To: David H. Lynch Jr; +Cc: linuxppc-embedded
In-Reply-To: <4355D6C1.4030004@comcast.net>
David H. Lynch Jr wrote:
> Alright I have RAM at physical 0x0 now. I throw a copy of a
> compressed linux image into RAM (anywhere special ?) load the assorted
> registers with the appropriate values, fill the board info struct.,
> and just jump to the start of the image and pray that load text starts
> coming out my serial port ?
Basically, but the exact thing to do depends which image you take. The
build process results in a few different image files. I usually just
take the vmlinux ELF file, and then my own scripts objcopy it to binary,
compress, objcopy to an object file, and link the compressed image
directly to the boot loader. The boot loader is then, of course,
responsible of uncompressing the image to RAM to 0x00000000.
I think the kernel build can also create some "self-extracting" images,
but I have never tried those. Maybe they don't even work anymore, as
many (most?) people just use the U-boot images.
^ permalink raw reply
* Parameter RAM Conflict of SCC1 SPI & Ethernet
From: shrisha.prasad @ 2005-10-19 5:09 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 651 bytes --]
Hi all,
The MPC862 UM Errata mentions that there is possiblity to solve
ParameterRAM Conflict without a Microcode patch .
I am working on a SerialEEPROM SPI Driver for mpc862
my driver needs to do is read the chip number from SPROM and calculate
the MAC address
The SPI mpc8xx is interfaced to 9346 eeprom for this and I want to
retrieve the MAC address
The errata tells that no patch required for relocation ,but using some
trick you can avoid it
I am using the UBoot SPI Driver code for MPC8xx ,Do I need to modify the
code in order to suit my requirements
Since I am a newbie in kernel programming ,some help is requested .
Regards
[-- Attachment #2: Type: text/html, Size: 1064 bytes --]
^ permalink raw reply
* Re: Need help Understanding initial memory conditions.
From: David H. Lynch Jr @ 2005-10-19 5:16 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <435557A0.8090505@iki.fi>
Kalle Pokki wrote:
> David H. Lynch Jr. wrote:
>
>> Kalle Pokki wrote:
>>
>>> 1. Put RAM to 0x0000000 and flash to some location it mirrors to
>>> your boot vector. Linux always expects your physical memory to be at
>>> zero. It is then mapped to virtual address 0xC0000000.
>>
>>
>> In both this list and elsewhere I have seen several references to
>> the difficulty setting up Linux with a physical RAM base other than
>> 0x0. I was hoping that I could bypass that by re-arranging physical
>> memory using the BAT's or MMU.
>> I am gathering that while this is possible, that it not sufficient.
>> That if memory is re-arranged after power-on it has to be done by
>> something Linux is not aware of.
>
>
> I'm afraid you cannot fool Linux that way... it will take control of
> the BATs and MMU. Even as a concept, you cannot re-arrange physical
> memory with the MMU at all - it's virtual memory when you do the
> address translation. The only way to arrange physical memory is to
> program the memory controller. I don't know how flexible the OCM
> controller in ppc405 is, but I'd be surprised if one couldn't freely
> set the addresses to whatever suits best.
>
>
I have built a Kernel - that is something I am pretty compitent at.
My system is fairly similar to an abreviated xilinx ml-300, and I have
added it to the Linux configuration and made what adjustments I beleive
were needed (mostly eliminating hardware I do not have or want). The
resulting Kernel is configured and successfully built.
Alright I have RAM at physical 0x0 now. I throw a copy of a compressed
linux image into RAM (anywhere special ?) load the assorted registers
with the appropriate values, fill the board info struct., and just jump
to the start of the image and pray that load text starts coming out my
serial port ?
Once this sucker gets through the code in head_4xx.S I should be in
business, or atleast to a point where I can deal with whatever crops up.
^ 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