* [PATCH] powerpc: Make RTAS console init generic
From: Michael Neuling @ 2006-08-16 4:00 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev, anton
The RTAS console doesn't have to be Cell specific. If we have both
the put and get char RTAS functions, init the rtas console.
Signed-off-by: Michael Neuling <mikey@neuling.org>
---
Paulus: This is relatively low risk, so if the Cell guys ack it, it
could be a candidate for 2.6.18.
arch/powerpc/kernel/rtas.c | 5 +++++
arch/powerpc/platforms/cell/setup.c | 4 ----
2 files changed, 5 insertions(+), 4 deletions(-)
Index: linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/kernel/rtas.c
+++ linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
@@ -910,6 +910,11 @@ int __init early_init_dt_scan_rtas(unsig
basep = of_get_flat_dt_prop(node, "get-term-char", NULL);
if (basep)
rtas_getchar_token = *basep;
+
+ if (rtas_putchar_token != RTAS_UNKNOWN_SERVICE &&
+ rtas_getchar_token != RTAS_UNKNOWN_SERVICE)
+ udbg_init_rtas_console();
+
#endif
/* break now */
Index: linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
===================================================================
--- linux-2.6-ozlabs.orig/arch/powerpc/platforms/cell/setup.c
+++ linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
@@ -150,10 +150,6 @@ static int __init cell_probe(void)
!of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
return 0;
-#ifdef CONFIG_UDBG_RTAS_CONSOLE
- udbg_init_rtas_console();
-#endif
-
hpte_init_native();
return 1;
^ permalink raw reply
* [PATCH] Add CONFIG_POWERPC
From: Michael Ellerman @ 2006-08-16 4:16 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
We don't seem to have a top-level config symbol like other archs do. We have
PPC64 and PPC, but I think it'd be cleaner to have just one for cases where
we really mean PPC64 and/or PPC.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/Kconfig | 4 ++++
1 file changed, 4 insertions(+)
Index: git/arch/powerpc/Kconfig
===================================================================
--- git.orig/arch/powerpc/Kconfig
+++ git/arch/powerpc/Kconfig
@@ -11,6 +11,10 @@ config PPC64
This option selects whether a 32-bit or a 64-bit kernel
will be built.
+config POWERPC
+ bool
+ default y
+
config PPC32
bool
default y if !PPC64
^ permalink raw reply
* Re: [PATCH] Add CONFIG_POWERPC
From: Paul Mackerras @ 2006-08-16 4:26 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
In-Reply-To: <20060816041617.690EB67A3F@ozlabs.org>
Michael Ellerman writes:
> We don't seem to have a top-level config symbol like other archs do. We have
> PPC64 and PPC, but I think it'd be cleaner to have just one for cases where
> we really mean PPC64 and/or PPC.
CONFIG_PPC already means either 32-bit or 64-bit PowerPC (always has
done, even before the merge).
Paul.
^ permalink raw reply
* Re: [PATCH] Add CONFIG_POWERPC
From: Michael Ellerman @ 2006-08-16 5:18 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17634.40549.377775.121184@cargo.ozlabs.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
On Wed, 2006-08-16 at 14:26 +1000, Paul Mackerras wrote:
> Michael Ellerman writes:
>
> > We don't seem to have a top-level config symbol like other archs do. We have
> > PPC64 and PPC, but I think it'd be cleaner to have just one for cases where
> > we really mean PPC64 and/or PPC.
>
> CONFIG_PPC already means either 32-bit or 64-bit PowerPC (always has
> done, even before the merge).
Hmm, but won't that also match arch/ppc ?
cheers
--
Michael Ellerman
IBM OzLabs
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: 191 bytes --]
^ permalink raw reply
* [POWERPC] iseries: remove some gcc 4.1 warnings
From: Stephen Rothwell @ 2006-08-16 5:20 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
gcc 4.1 produces some warnings that it is ignoring the packed attribute
on some structure elements, so just remove them.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/main_store.h | 46 ++++++++++++++-------------
1 files changed, 23 insertions(+), 23 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/powerpc/platforms/iseries/main_store.h b/arch/powerpc/platforms/iseries/main_store.h
index 74f6889..4b31658 100644
--- a/arch/powerpc/platforms/iseries/main_store.h
+++ b/arch/powerpc/platforms/iseries/main_store.h
@@ -63,7 +63,7 @@ struct IoHriMainStoreSegment4 {
/* Main Store VPD for Power4 */
struct IoHriMainStoreChipInfo1 {
u32 chipMfgID __attribute((packed));
- char chipECLevel[4] __attribute((packed));
+ char chipECLevel[4];
};
struct IoHriMainStoreVpdIdData {
@@ -74,9 +74,9 @@ struct IoHriMainStoreVpdIdData {
};
struct IoHriMainStoreVpdFruData {
- char fruLabel[8] __attribute((packed));
- u8 numberOfSlots __attribute((packed));
- u8 pluggingType __attribute((packed));
+ char fruLabel[8];
+ u8 numberOfSlots;
+ u8 pluggingType;
u16 slotMapIndex __attribute((packed));
};
@@ -90,8 +90,8 @@ #define MaxAreaAdrRangeBlocks 4
struct IoHriMainStoreArea4 {
u32 msVpdFormat __attribute((packed));
- u8 containedVpdType __attribute((packed));
- u8 reserved1 __attribute((packed));
+ u8 containedVpdType;
+ u8 reserved1;
u16 reserved2 __attribute((packed));
u64 msExists __attribute((packed));
@@ -101,16 +101,16 @@ struct IoHriMainStoreArea4 {
u32 procNodeId __attribute((packed));
u32 numAdrRangeBlocks __attribute((packed));
- struct IoHriMainStoreAdrRangeBlock xAdrRangeBlock[MaxAreaAdrRangeBlocks] __attribute((packed));
+ struct IoHriMainStoreAdrRangeBlock xAdrRangeBlock[MaxAreaAdrRangeBlocks];
- struct IoHriMainStoreChipInfo1 chipInfo0 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo1 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo2 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo3 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo4 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo5 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo6 __attribute((packed));
- struct IoHriMainStoreChipInfo1 chipInfo7 __attribute((packed));
+ struct IoHriMainStoreChipInfo1 chipInfo0;
+ struct IoHriMainStoreChipInfo1 chipInfo1;
+ struct IoHriMainStoreChipInfo1 chipInfo2;
+ struct IoHriMainStoreChipInfo1 chipInfo3;
+ struct IoHriMainStoreChipInfo1 chipInfo4;
+ struct IoHriMainStoreChipInfo1 chipInfo5;
+ struct IoHriMainStoreChipInfo1 chipInfo6;
+ struct IoHriMainStoreChipInfo1 chipInfo7;
void *msRamAreaArray __attribute((packed));
u32 msRamAreaArrayNumEntries __attribute((packed));
@@ -122,22 +122,22 @@ struct IoHriMainStoreArea4 {
u32 numaDimmArrayNumEntries __attribute((packed));
u32 numaDimmArrayEntrySize __attribute((packed));
- struct IoHriMainStoreVpdIdData idData __attribute((packed));
+ struct IoHriMainStoreVpdIdData idData;
u64 powerData __attribute((packed));
u64 cardAssemblyPartNum __attribute((packed));
u64 chipSerialNum __attribute((packed));
u64 reserved3 __attribute((packed));
- char reserved4[16] __attribute((packed));
+ char reserved4[16];
- struct IoHriMainStoreVpdFruData fruData __attribute((packed));
+ struct IoHriMainStoreVpdFruData fruData;
- u8 vpdPortNum __attribute((packed));
- u8 reserved5 __attribute((packed));
- u8 frameId __attribute((packed));
- u8 rackUnit __attribute((packed));
- char asciiKeywordVpd[256] __attribute((packed));
+ u8 vpdPortNum;
+ u8 reserved5;
+ u8 frameId;
+ u8 rackUnit;
+ char asciiKeywordVpd[256];
u32 reserved6 __attribute((packed));
};
--
1.4.1.1
^ permalink raw reply related
* Re: [PATCH] powerpc: Make RTAS console init generic
From: Michael Ellerman @ 2006-08-16 5:21 UTC (permalink / raw)
To: Michael Neuling; +Cc: linuxppc-dev, paulus, anton
In-Reply-To: <20060816040040.1E20967B55@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 1694 bytes --]
On Tue, 2006-08-15 at 23:00 -0500, Michael Neuling wrote:
> The RTAS console doesn't have to be Cell specific. If we have both
> the put and get char RTAS functions, init the rtas console.
>
> Index: linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/kernel/rtas.c
> +++ linux-2.6-ozlabs/arch/powerpc/kernel/rtas.c
> @@ -910,6 +910,11 @@ int __init early_init_dt_scan_rtas(unsig
> basep = of_get_flat_dt_prop(node, "get-term-char", NULL);
> if (basep)
> rtas_getchar_token = *basep;
> +
> + if (rtas_putchar_token != RTAS_UNKNOWN_SERVICE &&
> + rtas_getchar_token != RTAS_UNKNOWN_SERVICE)
> + udbg_init_rtas_console();
> +
> #endif
>
> /* break now */
> Index: linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
> ===================================================================
> --- linux-2.6-ozlabs.orig/arch/powerpc/platforms/cell/setup.c
> +++ linux-2.6-ozlabs/arch/powerpc/platforms/cell/setup.c
> @@ -150,10 +150,6 @@ static int __init cell_probe(void)
> !of_flat_dt_is_compatible(root, "IBM,CPBW-1.0"))
> return 0;
>
> -#ifdef CONFIG_UDBG_RTAS_CONSOLE
> - udbg_init_rtas_console();
> -#endif
> -
I'd like to see it still guarded by UDBG_RTAS_CONSOLE, otherwise there's
no way to select a different type of early console on a machine which
has those tokens in the device tree.
cheers
--
Michael Ellerman
IBM OzLabs
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: 191 bytes --]
^ permalink raw reply
* [POWERPC] iseries: remove const warning
From: Stephen Rothwell @ 2006-08-16 5:24 UTC (permalink / raw)
To: paulus; +Cc: ppc-dev
Just one bit of fallout from the constification of the get_property
return value.
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
arch/powerpc/platforms/iseries/viopath.c | 9 +++++----
1 files changed, 5 insertions(+), 4 deletions(-)
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
diff --git a/arch/powerpc/platforms/iseries/viopath.c b/arch/powerpc/platforms/iseries/viopath.c
index efeb6ae..9baa4ee 100644
--- a/arch/powerpc/platforms/iseries/viopath.c
+++ b/arch/powerpc/platforms/iseries/viopath.c
@@ -117,6 +117,7 @@ static int proc_viopath_show(struct seq_
HvLpEvent_Rc hvrc;
DECLARE_MUTEX_LOCKED(Semaphore);
struct device_node *node;
+ const char *sysid;
buf = kmalloc(HW_PAGE_SIZE, GFP_KERNEL);
if (!buf)
@@ -152,15 +153,15 @@ static int proc_viopath_show(struct seq_
seq_printf(m, "AVAILABLE_VETH=%x\n", vlanMap);
node = of_find_node_by_path("/");
- buf = NULL;
+ sysid = NULL;
if (node != NULL)
- buf = get_property(node, "system-id", NULL);
+ sysid = get_property(node, "system-id", NULL);
- if (buf == NULL)
+ if (sysid == NULL)
seq_printf(m, "SRLNBR=<UNKNOWN>\n");
else
/* Skip "IBM," on front of serial number, see dt.c */
- seq_printf(m, "SRLNBR=%s\n", buf + 4);
+ seq_printf(m, "SRLNBR=%s\n", sysid + 4);
of_node_put(node);
--
1.4.1.1
^ permalink raw reply related
* Re: [POWERPC] iseries: remove some gcc 4.1 warnings
From: Michael Ellerman @ 2006-08-16 5:26 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: ppc-dev, paulus
In-Reply-To: <20060816152032.2407a832.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 488 bytes --]
On Wed, 2006-08-16 at 15:20 +1000, Stephen Rothwell wrote:
> gcc 4.1 produces some warnings that it is ignoring the packed attribute
> on some structure elements, so just remove them.
Why is it ignoring them? Because there's no packing to be done?
cheers
--
Michael Ellerman
IBM OzLabs
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: 191 bytes --]
^ permalink raw reply
* Re: [POWERPC] iseries: remove some gcc 4.1 warnings
From: Stephen Rothwell @ 2006-08-16 5:32 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, paulus
In-Reply-To: <1155705964.12715.8.camel@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 588 bytes --]
On Wed, 16 Aug 2006 15:26:04 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
>
> On Wed, 2006-08-16 at 15:20 +1000, Stephen Rothwell wrote:
> > gcc 4.1 produces some warnings that it is ignoring the packed attribute
> > on some structure elements, so just remove them.
>
> Why is it ignoring them? Because there's no packing to be done?
A patch went into gcc to warn if the thing you are packing is already
minimally aligned. I have not idea why it warns ...
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
http://www.canb.auug.org.au/~sfr/
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [POWERPC] iseries: remove some gcc 4.1 warnings
From: Alan Modra @ 2006-08-16 6:09 UTC (permalink / raw)
To: Stephen Rothwell; +Cc: linuxppc-dev, paulus
In-Reply-To: <20060816153206.5bd2d64e.sfr@canb.auug.org.au>
On Wed, Aug 16, 2006 at 03:32:06PM +1000, Stephen Rothwell wrote:
> On Wed, 16 Aug 2006 15:26:04 +1000 Michael Ellerman <michael@ellerman.id.au> wrote:
> >
> > On Wed, 2006-08-16 at 15:20 +1000, Stephen Rothwell wrote:
> > > gcc 4.1 produces some warnings that it is ignoring the packed attribute
> > > on some structure elements, so just remove them.
> >
> > Why is it ignoring them? Because there's no packing to be done?
>
> A patch went into gcc to warn if the thing you are packing is already
> minimally aligned. I have not idea why it warns ...
http://gcc.gnu.org/ml/gcc-patches/2005-11/msg01883.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21166
--
Alan Modra
IBM OzLabs - Linux Technology Centre
^ permalink raw reply
* Problems dynamically linking busybox with ppc libs.
From: Keith Redfern @ 2006-08-16 8:53 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2099 bytes --]
I am trying to dynamically link busybox with the correct libraries but
run into problems with directory paths and CC/LD flags.
I am using the toolchain supplied with ELDK and my target board is
ppc_8xx based. The busybox version that I am using is 1.1.3.
I see the following in Rules.mak and have been trying different variable
options but with no success.
# To compile vs some other alternative libc, you may need to use/adjust
# the following lines to meet your needs...
#
# If you are using Red Hat 6.x with the compatible RPMs (for developing
under
# Red Hat 5.x and glibc 2.0) uncomment the following. Be sure to read
about
# using the compatible RPMs (compat-*) at http://www.redhat.com !
#LIBCDIR:=/usr/i386-glibc20-linux
#
# For other libraries, you are on your own. But these may (or may not)
help...
#LDFLAGS+=-nostdlib
#LIBRARIES:=$(LIBCDIR)/lib/libc.so.6
#CROSS_CFLAGS+=-nostdinc -I$(LIBCDIR)/include -I$(GCCINCDIR)
-funsigned-char
#GCCINCDIR:=$(shell gcc -print-search-dirs | sed -ne "s/install:
\(.*\)/\1include/gp")
#
# For other libraries, you are on your own. But these may (or may not)
help...
Is this the correct place to make modifications?
Has anyone already figured the changes required to get this to work with
ELDK toolchain?
Any insight would be useful.
......Keith
Legal Disclaimer:
The information contained in this message may be privileged and confidential. It is intended to be read only by the individual or entity to whom it is addressed or by their designee. If the reader of this message is not the intended recipient, you are on notice that any distribution of this message, in any form, is strictly prohibited. If you have received this message in error, please immediately notify the sender and delete or destroy any copy of this message
[-- Attachment #2: Type: text/html, Size: 8370 bytes --]
^ permalink raw reply
* boot kernel 2.6.18 is hang???
From: jie han @ 2006-08-16 9:11 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4719 bytes --]
I am trying to take a working embedded linux system from kernel 2.4 to
2.6. The hardware is a custom board using a mpc8270vr processor.
The working system uses u-boot 1.1.4 with linux kernel 2.4.24.
I am using the same u-boot and I am trying to port linux kernel 2.6.18.
I believe I have done everything required to get the kernel booting. However, the kernel
seems to hang after being uncompressed. Here is what I see after running
bootm from u-boot:
OLT=> tftp 500000 uImage
Using FCC1 ETHERNET device
TFTP from server 192.168.2.45; our IP address is 192.168.2.109
Filename 'uImage'.
Load address: 0x500000
Loading: #################################################################
#################################################################
#################################################################
done
Bytes transferred = 995314 (f2ff2 hex)
OLT=> bootm 500000
## Booting image at 00500000 ...
Image Name: Linux-2.6.18/Ocean BoradBand Ltd
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 995250 Bytes = 971.9 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
log_buf context is
OLT=> md 1b9d60 100
001b9d60: c020c0a4 00004000 00000000 ffffffff . ....@.........
001b9d70: 00000001 c01b9d74 c01b9d74 00000001 .......t...t....
001b9d80: c01b9d80 c01b9d80 ffffffff 61637175 ............acqu
001b9d90: 6972655f 636f6e73 6f6c655f 73656d00 ire_console_sem.
001b9da0: 63616c6c 5f636f6e 736f6c65 5f647269 call_console_dri
001b9db0: 76657273 00000000 ffffffff 00000001 vers............
001b9dc0: 00001388 00000000 00000000 c001571c ..............W.
001b9dd0: 00000000 c001589c 00000000 00000000 ......X.........
001b9de0: 00000000 00000000 00000000 00000000 ................
001b9df0: 00000000 00000000 00000000 00000000 ................
001b9e00: 00000000 00000000 00000000 00000000 ................
001b9e10: 00000000 00000000 00000000 00000000 ................
001b9e20: 00000000 00000000 00000000 00000000 ................
001b9e30: 00000000 00000000 00000001 65786974 ............exit
001b9e40: 5f6d6d00 5f5f6578 69745f73 69676e61 _mm.__exit_signa
001b9e50: 6c000000 72656c65 6173655f 7461736b l...release_task
001b9e60: 00000000 63686f6f 73655f6e 65775f70 ....choose_new_p
001b9e70: 6172656e 74000000 666f7267 65745f6f arent...forget_o
001b9e80: 72696769 6e616c5f 70617265 6e740000 riginal_parent..
001b9e90: 65786974 5f6e6f74 69667900 646f5f65 exit_notify.do_e
001b9ea0: 78697400 646f5f67 726f7570 5f657869 xit.do_group_exi
001b9eb0: 74000000 77616974 5f746173 6b5f636f t...wait_task_co
001b9ec0: 6e74696e 75656400 77616974 5f746173 ntinued.wait_tas
001b9ed0: 6b5f7a6f 6d626965 00000000 77616974 k_zombie....wait
001b9ee0: 5f746173 6b5f7374 6f707065 64000000 _task_stopped...
001b9ef0: 646f5f77 61697400 0000000a 00000001 do_wait.........
001b9f00: c0019b50 00000000 00000000 6370755f ...P........cpu_
001b9f10: 63616c6c 6261636b 00000000 00000001 callback........
001b9f20: 00000001 5f5f6c6f 63616c5f 62685f65 ....__local_bh_e
001b9f30: 6e61626c 65000000 00000001 00000001 nable...........
001b9f40: 5f6c6f63 616c5f62 685f656e 61626c65 _local_bh_enable
001b9f50: 00000000 7461736b 6c65745f 61637469 ....tasklet_acti
001b9f60: 6f6e0000 7461736b 6c65745f 68695f61 on..tasklet_hi_a
001b9f70: 6374696f 6e000000 00000001 00000001 ction...........
001b9f80: 6c6f6361 6c5f6268 5f656e61 626c6500 local_bh_enable.
001b9f90: 00000001 6c6f6361 6c5f6268 5f656e61 ....local_bh_ena
001b9fa0: 626c655f 69700000 00000001 5f5f6c6f ble_ip......__lo
001b9fb0: 63616c5f 62685f64 69736162 6c650000 cal_bh_disable..
001b9fc0: 00000000 ffffffff c018a9b0 00000200 ................
001b9fd0: 00000000 00000000 00000000 00000000 ................
001b9fe0: ffffffff c018a9b8 00000100 00000000 ................
001b9ff0: 00000000 00000000 00000000 c0075590 ..............U.
001ba000: c0075878 00000000 00000000 00000000 ..Xx............
001ba010: 00000000 00000000 00000000 00000000 ................
001ba020: 00000000 00000000 c001a53c 00000000 ...........<....
001ba030: c0075014 00000000 00000000 00000000 ..P.............
001ba040: 00000000 00000000 00000000 00000000 ................
001ba050: 00000000 00000000 00000000 00000000 ................
001ba060: 00000000 00000000 00000000 00000000 ................
001ba070: c0075590 c0075878 00000000 00000000 ..U...Xx........
Any ideas would be appreciated.
Regards,
Jie
---------------------------------
Do you Yahoo!?
Next-gen email? Have it all with the all-new Yahoo! Mail Beta.
[-- Attachment #2: Type: text/html, Size: 5100 bytes --]
^ permalink raw reply
* [PATCH] Gunzip call fix for PPC kernel images >4MB
From: Benjamin Heyne @ 2006-08-16 9:31 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Tom Rini, Paul Mackerras, Milton Miller
If Kernel images for PPC grow >4MB inflating of the kernel fails.
Increasing the link/load address doesn't help. Problem is
solved by replacing the fixed address of the gunzip() call in
misc-embedded.c with CONFIG_BOOT_LOAD.
Signed-off-by: Benjamin Heyne <benjamin.heyne@uni-dortmund.de>
---
--- arch/ppc/boot/simple/misc-embedded.c.orig 2006-08-16 10:56:10.000000000 +0200
+++ arch/ppc/boot/simple/misc-embedded.c 2006-08-16 10:56:55.000000000 +0200
@@ -213,7 +213,7 @@ load_kernel(unsigned long load_addr, int
*cp = 0;
puts("\nUncompressing Linux...");
- gunzip(0, 0x400000, zimage_start, &zimage_size);
+ gunzip(0, CONFIG_BOOT_LOAD, zimage_start, &zimage_size);
flush_instruction_cache();
puts("done.\n");
{
--
Benjamin Heyne
=======================================================
Arbeitsgebiet Datentechnik, Universitaet Dortmund
Information Processing Lab, University of Dortmund
Otto-Hahn-Strasse 4, 44227 Dortmund, Germany
Fon: +49 231 755 7017, Fax: +49 231 755 7019
www.dt.e-technik.uni-dortmund.de, Raum/Room P1-04-217
^ permalink raw reply
* Re: Who cares about PReP?
From: Gabriel Paubert @ 2006-08-16 10:15 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
In-Reply-To: <17622.58559.879330.496619@cargo.ozlabs.ibm.com>
On Mon, Aug 07, 2006 at 04:59:11PM +1000, Paul Mackerras wrote:
> I started looking at moving the PReP code over to arch/powerpc. I am
> struck by how many ifdefs there are in there to set things up for
> particular individual PReP implementations. We can do better than
> that, I'm sure,
hopefully.
> but the issue becomes one of testing. The only PReP I
> have here is an RS/6000 43p-140.
>
> Who else has a PReP system and would be willing to do some testing and
> debugging? If so, what sort of PReP is it?
We are using 20+ MVME boards here so I am interested,
MVME2400/2600/2700 to be precise.
Right now I can test patches and not much more, I'm really
short of time and fighting other issues. Among them my PB
G4 from last December just completely failed (and Apple
told me to bring it to a shop in this city that is closed
for holidays until ... September 4th).
Regards,
Gabriel
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Gabriel Paubert @ 2006-08-16 10:59 UTC (permalink / raw)
To: Paul Mackerras; +Cc: 'Albert Cahalan', debian-powerpc, linuxppc-dev
In-Reply-To: <17633.18057.778991.483461@cargo.ozlabs.ibm.com>
On Tue, Aug 15, 2006 at 01:59:05PM +1000, Paul Mackerras wrote:
> Matt Sealey writes:
>
> > Book I compatible PowerPC's have had a "no-executable" bit in
> > the page protection flags since the dark ages.. see page 7-38
> > and 7-39 of the 'Programming Environments Manual for 32-Bit
> > Microprocessors'.. this document predates even the G3.
>
> What are you referring to? I have a copy of the PEM from pre-G3 days,
> and a copy that I downloaded just now, and neither of them have an N
> bit in the PTE (and yes I just looked carefully through pages 7-38 and
> 7-39).
>
> There is an N bit in the segment register format, and that's what
> Albert is using.
>
> > As far as the documentation goes, you can make the page
> > readable and writable to the LSU, but the N bit causes the
> > instruction fetch to cause a machine check. That's pretty
> > "not-executable" to me at least :)
>
> A machine check is nasty, because it may not be recoverable...
I agree, but I don't know why you believe it would cause
a machine check (0x200): from my docs, it is an ISI (0x400).
BTW, there is one way to make pages non executable: mark
them as guarded, but it will have a significant cost in
terms of performance.
I never understood why PTE entries waste 4 bits (WIMG)
for effectively very few valid combinations.
Regards,
Gabriel
^ permalink raw reply
* Re: PowerPC paxtest results w/ gcc-4.1
From: Paul Mackerras @ 2006-08-16 11:07 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: 'Albert Cahalan', debian-powerpc, linuxppc-dev
In-Reply-To: <20060816105925.GB21865@iram.es>
Gabriel Paubert writes:
> I agree, but I don't know why you believe it would cause
> a machine check (0x200): from my docs, it is an ISI (0x400).
I don't believe it would cause a machine check either, but that is
what Matt Sealey was saying. I don't know where he got that idea.
> BTW, there is one way to make pages non executable: mark
> them as guarded, but it will have a significant cost in
> terms of performance.
Indeed. I guess we could do that as a config option for machines that
really want maximum security at the expense of performance, but I
don't think all users would want that.
Paul.
^ permalink raw reply
* Re: Who cares about PReP?
From: Paul Mackerras @ 2006-08-16 11:22 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev
In-Reply-To: <20060816101527.GA21865@iram.es>
Gabriel Paubert writes:
> We are using 20+ MVME boards here so I am interested,
> MVME2400/2600/2700 to be precise.
If you (and anyone else who is interested) could send me the contents
of /proc/residual, /proc/iomem, /proc/ioports and /proc/interrupts
from your systems (one of each different type) that could be helpful.
Thanks,
Paul.
^ permalink raw reply
* Re: Who cares about PReP?
From: Paul Mackerras @ 2006-08-16 11:57 UTC (permalink / raw)
To: Gabriel Paubert, linuxppc-dev
In-Reply-To: <17634.65529.252720.646039@cargo.ozlabs.ibm.com>
I wrote:
> If you (and anyone else who is interested) could send me the contents
> of /proc/residual, /proc/iomem, /proc/ioports and /proc/interrupts
> from your systems (one of each different type) that could be helpful.
And /proc/cpuinfo would be interesting too.
Paul.
^ permalink raw reply
* [PATCH] Add a helper for calculating RTAS "config_addr" parameters
From: Michael Ellerman @ 2006-08-16 12:04 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev
Several RTAS calls take a "config_addr" parameter, which is a particular
way of specifying a PCI busno, devfn and register number into a 32-bit word.
Currently these are open-coded, and I'll be adding another soon, replace
them with a helper that encapsulates the logic. Be more strict about masking
the busno too, just in case.
Booted on P5 LPAR.
Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
---
arch/powerpc/kernel/rtas_pci.c | 6 ++----
include/asm-powerpc/rtas.h | 16 ++++++++++++++++
2 files changed, 18 insertions(+), 4 deletions(-)
Index: git/arch/powerpc/kernel/rtas_pci.c
===================================================================
--- git.orig/arch/powerpc/kernel/rtas_pci.c
+++ git/arch/powerpc/kernel/rtas_pci.c
@@ -81,8 +81,7 @@ int rtas_read_config(struct pci_dn *pdn,
if (!config_access_valid(pdn, where))
return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = ((where & 0xf00) << 20) | (pdn->busno << 16) |
- (pdn->devfn << 8) | (where & 0xff);
+ addr = rtas_config_addr(pdn->busno, pdn->devfn, where);
buid = pdn->phb->buid;
if (buid) {
ret = rtas_call(ibm_read_pci_config, 4, 2, &returnval,
@@ -134,8 +133,7 @@ int rtas_write_config(struct pci_dn *pdn
if (!config_access_valid(pdn, where))
return PCIBIOS_BAD_REGISTER_NUMBER;
- addr = ((where & 0xf00) << 20) | (pdn->busno << 16) |
- (pdn->devfn << 8) | (where & 0xff);
+ addr = rtas_config_addr(pdn->busno, pdn->devfn, where);
buid = pdn->phb->buid;
if (buid) {
ret = rtas_call(ibm_write_pci_config, 5, 1, NULL, addr,
Index: git/include/asm-powerpc/rtas.h
===================================================================
--- git.orig/include/asm-powerpc/rtas.h
+++ git/include/asm-powerpc/rtas.h
@@ -230,5 +230,21 @@ extern unsigned long rtas_rmo_buf;
#define GLOBAL_INTERRUPT_QUEUE 9005
+/**
+ * rtas_config_addr - Format a busno, devfn and reg for RTAS.
+ * @busno: The bus number.
+ * @devfn: The device and function number as encoded by PCI_DEVFN().
+ * @reg: The register number.
+ *
+ * This function encodes the given busno, devfn and register number as
+ * required for RTAS calls that take a "config_addr" parameter.
+ * See PAPR requirement 7.3.4-1 for more info.
+ */
+static inline u32 rtas_config_addr(int busno, int devfn, int reg)
+{
+ return ((reg & 0xf00) << 20) | ((busno & 0xff) << 16) |
+ (devfn << 8) | (reg & 0xff);
+}
+
#endif /* __KERNEL__ */
#endif /* _POWERPC_RTAS_H */
^ permalink raw reply
* help
From: Hemanth KumarBS @ 2006-08-16 12:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 101 bytes --]
Hi,
I am working on PPC-8248. Is montavista has driver for DMA based SPI
driver ?
Regards
Hemanth
[-- Attachment #2: Type: text/html, Size: 277 bytes --]
^ permalink raw reply
* Did someone have a working SPI Driver for Linux 2.6
From: Keinen Namen @ 2006-08-16 12:52 UTC (permalink / raw)
To: linuxppc-embedded
Hi
Did someone have a working SPI Driver for Linux 2.6 and the MPC82xx from Freescale?
Regards
Fred
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply
* Re: Did someone have a working SPI Driver for Linux 2.6
From: Laurent Pinchart @ 2006-08-16 13:09 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Keinen Namen
In-Reply-To: <20060816125228.98000@gmx.net>
> Did someone have a working SPI Driver for Linux 2.6 and the MPC82xx from
> Freescale?
I'm working on such a driver. I will try to send a patch in a few days. The
driver is being tested on an MMC device, so basic functionalities should be
there, but things are far from being finished.
Laurent Pinchart
^ permalink raw reply
* Re: [POWERPC] iseries: remove some gcc 4.1 warnings
From: Arnd Bergmann @ 2006-08-16 13:15 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, paulus
In-Reply-To: <20060816152032.2407a832.sfr@canb.auug.org.au>
On Wednesday 16 August 2006 07:20, Stephen Rothwell wrote:
> gcc 4.1 produces some warnings that it is ignoring the packed attribute
> on some structure elements, so just remove them.
>
Wouldn't it be nicer to just specify the packed attribute on the
structure instead of each of the members? My reading of the
gcc documentation is that this is functionally the same, but
it makes the source more readable, aside from avoiding this warning.
Arnd <><
^ permalink raw reply
* Re: *** PROBABLY SPAM *** No Clock on SPI
From: Laurent Pinchart @ 2006-08-16 13:22 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: GSM909
In-Reply-To: <20060815164521.230780@gmx.net>
Hi Fred,
> I=C2=B4m writing a Driver for SPI. That is not working now.
> I have a MPC8260 using Linux 2.6.14 (rheap patch).
>
> Did someone else write a driver for SPI on this =C2=B5C or an other drive=
r? So I
> can see what i did wrong?
I'm working on an SPI driver for the MPC8248. I'll try to send a patch in a=
=20
few days.
> My SPCOM[STR] flag isn=C2=B4t cleared automatically after one clock cycle.
> What here going wrong ? ( I know this register is write only)
> There is also no Clock on my SPICLK.
Make sure you programmed the SPMODE register correctly.
> How I have to allocate the Memory for the BD=C2=B4s and the buffer for th=
e BD=C2=B4s?
The buffer descriptors should be allocated from CPM DPRAM using cpm_dpalloc=
().=20
The buffers can be allocated from any DMA-able memory (all system memory).
> Is there something special when I allocate Memory for my Parameter Ram?
You don't need to allocate memory for the parameter RAM. I declared PROFF_S=
PI=20
equal to 192 (I2C parameter RAM is at 128) in include/asm-ppc/cpm2.h:
#define PROFF_SMC1 (0)
#define PROFF_SMC2 (64)
#define PROFF_I2C (128)
#define PROFF_SPI (192)
Don't forget to set CPM_DATAONLY_BASE to 256 instead of 128 in the same fil=
e.
Then, set
*(u16 *)(&immap->im_dprambase[PROFF_SPI_BASE]) =3D PROFF_SPI;
in your driver code, and set the SPI pram resource to
=2Ename =3D "pram",
=2Estart =3D 0x00c0,
=2Eend =3D 0x00ff,
=2Eflags =3D IORESOURCE_MEM,
in arch/ppc/syslib/pq2_devices.c
> Is something wrong with the 2.6 Kernel so i have to use the 2.4 Kernel ?
You should not use 2.4. 2.6 is the way to go.
Laurent Pinchart
^ permalink raw reply
* Re: Problems dynamically linking busybox with ppc libs.
From: Ben Warren @ 2006-08-16 14:13 UTC (permalink / raw)
To: Keith Redfern; +Cc: linuxppc-embedded
In-Reply-To: <367F3B3911959C4DA9991C00166F620C1DE208@EUDUCEX2.europe.ad.flextronics.com>
Keith,
On Wed, 2006-08-16 at 10:53 +0200, Keith Redfern wrote:
> I am trying to dynamically link busybox with the correct libraries but
> run into problems with directory paths and CC/LD flags.
>
> I am using the toolchain supplied with ELDK and my target board is
> ppc_8xx based. The busybox version that I am using is 1.1.3.
>
<snip>
>
> Is this the correct place to make modifications?
>
> Has anyone already figured the changes required to get this to work
> with ELDK toolchain?
>
> Any insight would be useful.
>
>
>
> ...…Keith
I have busybox 1.2 building under ELDK 4.0, and didn't mess at all with
the Make system, and am building for a ppc_6xx- target. I realize this
isn't quite your setup, but is pretty close.
As long as you have the tools listed in your PATH (in my
case /opt/tools/eldk4.0/usr/bin:/opt/tools/eldk4.0/bin), you should be
able to build fine using 'make menuconfig'. Just go to 'Busybox
Settings->Build Options' and select 'Do you want to build BusyBox with a
Cross Compiler?', in your case entering 'ppc_8xx-' or whatever the
prefix is for your CPU.
regards,
Ben
^ 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