* [PATCH][PPC32] Add uImage to default targets
From: Matt Porter @ 2004-12-15 18:49 UTC (permalink / raw)
To: akpm, linux-kernel; +Cc: linuxppc-dev
We'd like to get a uImage when just using 'make' on many
targets. After some discussion, it made sense to simply
add uImage to the default targets since it adds minimal
build overhead and will work on all platforms. Also,
fix a dependency in the boot stuff.
Signed-off-by: Matt Porter <mporter@kernel.crashing.org>
===== arch/ppc/Makefile 1.66 vs edited =====
--- 1.66/arch/ppc/Makefile 2004-10-05 17:28:57 -07:00
+++ edited/arch/ppc/Makefile 2004-12-15 10:27:30 -07:00
@@ -68,7 +68,7 @@
.PHONY: $(BOOT_TARGETS)
-all: zImage
+all: uImage zImage
CPPFLAGS_vmlinux.lds := -Upowerpc
===== arch/ppc/boot/simple/misc.c 1.24 vs edited =====
--- 1.24/arch/ppc/boot/simple/misc.c 2004-10-08 02:57:32 -07:00
+++ edited/arch/ppc/boot/simple/misc.c 2004-12-15 10:25:10 -07:00
@@ -102,7 +102,7 @@
com_port = serial_init(0, NULL);
#endif
-#ifdef CONFIG_44x
+#if defined(CONFIG_44x) && defined(PPC44x_EMAC0_MR0)
/* Reset MAL */
mtdcr(DCRN_MALCR(DCRN_MAL_BASE), MALCR_MMSR);
/* Wait for reset */
^ permalink raw reply
* Re: FW: I2C + Linux 2.6 on MPC880/MPC885 based board(s)
From: Wolfgang Denk @ 2004-12-15 18:15 UTC (permalink / raw)
To: Povolotsky, Alexander; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <313680C9A886D511A06000204840E1CF0A6473A1@whq-msgusr-02.pit.comms.marconi.com>
In message <313680C9A886D511A06000204840E1CF0A6473A1@whq-msgusr-02.pit.comms.marconi.com> you wrote:
>
> Firstly, I have a (hardware related) question: - how I2C is supported on
> MPC880/MPC885 basede boards
> and for what purposes/functions it (I2C) is typically used there ?
Why are you psting the same question to several mailing lists? I
already answered your questions on the etux@embeddedtux.org list.
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
How many QA engineers does it take to screw in a lightbulb? 3: 1 to
screw it in and 2 to say "I told you so" when it doesn't work.
^ permalink raw reply
* Re: Initialization of Timer Clock on the MPC8260
From: annamaya @ 2004-12-15 17:18 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: linuxppc-embedded
In-Reply-To: <20041215162843.8DFC4C1430@atlas.denx.de>
Hello Wolfgang,
I will surely post this in the U-Boot forums. I just
did not know where it was but I think I've found it
now. I still had the address to the PPCBOOT mailist
lists. I miss the good old days. :-)
And to answer you questions, yes, I did look at the
GPIO pins for all the 8260 boards and not one of them
was configured to be a clock. And I was unable to find
the setbrg() routine elsewhere to set brgc1 to be the
input for timerclk.
-Navin.
--- Wolfgang Denk <wd@denx.de> wrote:
> In message
> <20041214230712.79751.qmail@web53805.mail.yahoo.com>
> you wrote:
> > I am not sure if this is the right place to ask
> this
> > question since this may be a U-Boot question. I am
>
> Why do you ask here and not on the U-Boot mailing
> list then?
>
> > trying to understand how the source for the timer
> > clock is selected on this processor. Figure 4-3
> tries
> > to explain this but I am unable to find code in
> U-Boot
> > that actually sets either BRG1 or one of the GPIO
> pins
> > to act as inputs for the timer clock generation.
> Can
> > someone point me to the right place in the code
> where
>
> Well, did you check the place where all GPIO pins
> get initialized, i. e. board/<name>/<name>.c ?
>
> 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
> "To take a significant step forward, you must make a
> series of finite
> improvements." - Donald J. Atwood, General Motors
>
__________________________________
Do you Yahoo!?
The all-new My Yahoo! - Get yours free!
http://my.yahoo.com
^ permalink raw reply
* Re: I2C + Linux 2.6 on MPC880/MPC885 based board(s)
From: Dan Malek @ 2004-12-15 16:54 UTC (permalink / raw)
To: Povolotsky, Alexander; +Cc: 'linuxppc-embedded@ozlabs.org'
In-Reply-To: <313680C9A886D511A06000204840E1CF0A6473A1@whq-msgusr-02.pit.comms.marconi.com>
On Dec 15, 2004, at 11:04 AM, Povolotsky, Alexander wrote:
> Firstly, I have a (hardware related) question: - how I2C is supported
> on
> MPC880/MPC885 basede boards
> and for what purposes/functions it (I2C) is typically used there ?
If you read the archives :-) .......
Anyway, the one thing you need to be careful about is the overhead
of using the CPM I2C. If you are sending/receiving large messages
on the I2C, it's probably useful to use the CPM. If you are only
sending
a few bytes, the over head of set up/interrupt/clean up is substantial.
Normally, I just use the I2C pins as GPIO and use the bit-bang
algorithm. It's a trivial interface to configure for any board, gets
you going to more important things.
Otherwise, it looks like someone that has an interest in
using the CPM I2C (which isn't me) will need to port it first to 2.6,
then provide the board specific functions for set up and control.
On top of this, if you want to run the SMBus protocols, you will
need a much more complex CPM I2C functions.
-- Dan
^ permalink raw reply
* Re: MEMORY PROBLEM
From: ppclinux @ 2004-12-15 16:51 UTC (permalink / raw)
To: Jerry Van Baren; +Cc: linuxppc-embedded
In-Reply-To: <41BF5607.8040609@smiths-aerospace.com>
> Your SDRAM initialization is suspect
Thx for that. Those words made me go through the SDRAM
initialization once again and BINGO the PSDMR register had
an address line setting wrong.
The thing is that we have boards with 128M and 256M and the
PSDMR register settings was the same for both. Other involved
registers were modified by the book.
THX!
Cheers // Matias
> ppclinux@sundmangroup.com wrote:
>> Hello,
>> I have a Freescale-PPC8270 ( Former Motorola ) based board with 256Megs
>> of
>> RAM.
>>
>> I am using the Montavista Vista Kernel 2.4.20.
>>
>> When the system is handling larger files ~100M when NFS mounted and ~20M
>> when RAMDISKed the kernel crashes since things are being overwritten in
>> memory.
>>
>> The crash happens when handling/creating large files by measn of e.g.
>> * dd
>> * gunzip
>> * sftp download
>> etc. it seems to be a general memory handling problem.
>>
>> When looking at the memory though there are plenty of free space, or
>> there
>> should be plenty of free space but for some reason things are
>> overwritten...
>>
>> The Kernel reports actually 256M of memory. Top also shows that there is
>> o
>> r should be more than enough free memory for the operations I am trying
>> to
>> pull :-))
>>
>> Can you give me suggestions where to start digging into this problem?
>>
>> Best Regards // Matias
>
> Your SDRAM initialization is suspect
> http://www.denx.de/twiki/bin/view/DULG/LinuxCrashesRandomly
> http://www.denx.de/twiki/bin/view/DULG/SDRAM
> http://www.denx.de/twiki/bin/view/DULG/UBootCrashAfterRelocation
>
> gvb
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: Initialization of Timer Clock on the MPC8260
From: Wolfgang Denk @ 2004-12-15 16:28 UTC (permalink / raw)
To: annamaya; +Cc: linuxppc-embedded
In-Reply-To: <20041214230712.79751.qmail@web53805.mail.yahoo.com>
In message <20041214230712.79751.qmail@web53805.mail.yahoo.com> you wrote:
> I am not sure if this is the right place to ask this
> question since this may be a U-Boot question. I am
Why do you ask here and not on the U-Boot mailing list then?
> trying to understand how the source for the timer
> clock is selected on this processor. Figure 4-3 tries
> to explain this but I am unable to find code in U-Boot
> that actually sets either BRG1 or one of the GPIO pins
> to act as inputs for the timer clock generation. Can
> someone point me to the right place in the code where
Well, did you check the place where all GPIO pins
get initialized, i. e. board/<name>/<name>.c ?
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
"To take a significant step forward, you must make a series of finite
improvements." - Donald J. Atwood, General Motors
^ permalink raw reply
* FW: I2C + Linux 2.6 on MPC880/MPC885 based board(s)
From: Povolotsky, Alexander @ 2004-12-15 16:04 UTC (permalink / raw)
To: 'linuxppc-embedded@ozlabs.org'
-----Original Message-----
From: Povolotsky, Alexander
Sent: Wednesday, December 15, 2004 9:51 AM
To: 'linuxppc-embedded@lists.linuxppc.org'
Subject: I2C + Linux 2.6 on MPC880/MPC885 based board(s)
Hi,
Firstly, I have a (hardware related) question: - how I2C is supported on
MPC880/MPC885 basede boards
and for what purposes/functions it (I2C) is typically used there ?
Specifically my question is - what is the relevance (if any) of 8xx i2c
algorithm(s) to boards with MPC880/MPC885 processors ?
Further (pardon me if the question is silly ...) - what is the relevance(if
any)of RPX adapter driver to boards with MPC880/MPC885 processors ?
I would appreciate very much indeed, if someone on this list could spare
some (little) of his valuable time to answer on above stated questions !
On a software (Linux 2.6) side ...
Did anyone on this list deal with Linux 2.6 + MPC880/MPC885 (or at least any
MPC8xx) ?
If yes, what I2C settings in .config were used for successful kernel build ?
I am having a problem building it (see below attached) ... - that is why I
am trying to understand
(from the hardware point of view - hence my h/w related questions ...)
importance of I2C.
Thanks,
Best Regards,
Alex
***************
-----Original Message-----
From: Povolotsky, Alexander
Sent: Tuesday, December 14, 2004 6:13 PM
To: 'Greg KH'; Jean Delvare
Subject: RE: 8xx i2c drivers (cross)compilation errors on Linux 2.6.8
Hi,
>Alexander, what arch are you building for?
PPC ->8xx ->MPC880 (Motorola -> FreeScale Semiconductor)
http://www.freescale.com/webapp/sps/site/prod_summary.jsp?code=MPC885&nodeId
=018rH3bTdG4204
Thanks,
Best Regards,
Alex
PPS I have attached my original e-mail in its entirety (at the end ).
-----Original Message-----
From: Greg KH [mailto:greg@kroah.com]
Sent: Tuesday, December 14, 2004 4:50 PM
To: Jean Delvare
Cc: Alexander.Povolotsky@marconi.com
Subject: Re: 8xx i2c drivers (cross)compilation errors on Linux 2.6.8
On Tue, Dec 14, 2004 at 10:38:00AM +0100, Jean Delvare wrote:
>
> On 2004-12-14, Alexander Povolotsky wrote:
>
> > Hi,
> >
> > I have the following .config setup:
> > (...)
> > CONFIG_I2C_RPXLITE=y
> > (...)
> >
> > Originally I was getting error:
> > CC drivers/i2c/busses/i2c-rpx.o
> > drivers/i2c/busses/i2c-rpx.c:20:32: linux/i2c-algo-8xx.h: No such file
or
> > directory - why I am missing it - any hint ?
>
> Hm, looks like the 8xx i2c algorithm was never ported to Linux 2.6. Greg,
> how come that the RPX adapter driver is present in the tree and the
> algorithm it depends on isn't?
Because no one ever sent me the patch with those files in it? :)
I have no idea, I've not cross built this driver before.
> Greg, could it be that an arch-specific (m68k? don't know what this
> rpx/8xx thing is) variant of the Linux tree already has the i2c-algo-8xx
> driver ported to 2.6? We probably want to import it into the main tree
> if this is the case (having adapter drivers that won't compile doesn't
> sound good...)
It might, I've seen i2c drivers in different arch specific trees (like
sh for example I know has a few.)
Alexander, what arch are you building for?
thanks,
greg k-h
*************
-----Original Message-----
From: Jean Delvare [mailto:khali@linux-fr.org]
Sent: Tuesday, December 14, 2004 4:38 AM
To: Alexander.Povolotsky@marconi.com; greg@kroah.com
Subject: Re: 8xx i2c drivers (cross)compilation errors on Linux 2.6.8
On 2004-12-14, Alexander Povolotsky wrote:
> Hi,
>
> I have the following .config setup:
> (...)
> CONFIG_I2C_RPXLITE=y
> (...)
>
> Originally I was getting error:
> CC drivers/i2c/busses/i2c-rpx.o
> drivers/i2c/busses/i2c-rpx.c:20:32: linux/i2c-algo-8xx.h: No such file or
> directory - why I am missing it - any hint ?
Hm, looks like the 8xx i2c algorithm was never ported to Linux 2.6. Greg,
how come that the RPX adapter driver is present in the tree and the
algorithm it depends on isn't?
> So I copied the i2c-algo-8xx.h file from Linux 2.4.26 distribution ...
> could I use it ?
> (if not - could you send me the correct i2c-algo-8xx.h file ? - TIA !)
I don't think it'll work. The header file is one thing, the algorithm
driver is another and you would need to port both (they proabbly won't
work out of the box due to important changes in the i2c subsystem
between 2.4 and 2.6 kernels). Also, obviously the RPX adapter driver
couldn't be used so far so it was possibly never tested. There will
probably be much porting and debugging work if you want to get it to
work.
Greg, could it be that an arch-specific (m68k? don't know what this
rpx/8xx thing is) variant of the Linux tree already has the i2c-algo-8xx
driver ported to 2.6? We probably want to import it into the main tree
if this is the case (having adapter drivers that won't compile doesn't
sound good...)
Alexander, at any rate, there's not much I can do myself, as I don't
have compatible hardware to port/test/debug the i2c-algo-8xx and i2c-rpx
drivers. Sorry.
Thanks,
--
Jean Delvare
-----Original Message-----
From: Povolotsky, Alexander
Sent: Monday, December 13, 2004 10:22 PM
To: 'khali@linux-fr.org'
Subject: 8xx i2c drivers (cross)compilation errors on Linux 2.6.8
Hi,
I have the following .config setup:
.....
# I2C Hardware Bus support
#
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ISA is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
CONFIG_I2C_RPXLITE=y
# CONFIG_SCx200_ACB is not set
#
# Hardware Sensors Chip support
#
# CONFIG_I2C_SENSOR is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
#
# Other I2C Chip support
#
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_RTC8564 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
...............
Originally I was getting error:
CC drivers/i2c/busses/i2c-rpx.o
drivers/i2c/busses/i2c-rpx.c:20:32: linux/i2c-algo-8xx.h: No such file or
directory - why I am missing it - any hint ?
So I copied the i2c-algo-8xx.h file from Linux 2.4.26 distribution ... could
I use it ?
(if not - could you send me the correct i2c-algo-8xx.h file ? - TIA !)
Then I started to get another error:
CC drivers/i2c/busses/i2c-rpx.o
In file included from drivers/i2c/busses/i2c-rpx.c:20:
include/linux/i2c-algo-8xx.h:15: warning: type defaults to `int' in
declaration of `i2c8xx_t'
include/linux/i2c-algo-8xx.h:15: warning: no semicolon at end of struct or
union
include/linux/i2c-algo-8xx.h:15: error: parse error before '*' token
include/linux/i2c-algo-8xx.h:16: error: parse error before '*' token
include/linux/i2c-algo-8xx.h:16: warning: type defaults to `int' in
declaration of `iip'
include/linux/i2c-algo-8xx.h:16: warning: data definition has no type or
storage class
include/linux/i2c-algo-8xx.h:17: error: parse error before '*' token
include/linux/i2c-algo-8xx.h:17: warning: type defaults to `int' in
declaration of `cp'
include/linux/i2c-algo-8xx.h:17: warning: data definition has no type or
storage class
include/linux/i2c-algo-8xx.h:25: error: parse error before '}' token
drivers/i2c/busses/i2c-rpx.c: In function `rpx_iic_init':
drivers/i2c/busses/i2c-rpx.c:34: error: dereferencing pointer to incomplete
type
drivers/i2c/busses/i2c-rpx.c:38: error: dereferencing pointer to incomplete
type
drivers/i2c/busses/i2c-rpx.c:38: error: dereferencing pointer to incomplete
type
drivers/i2c/busses/i2c-rpx.c:39: error: dereferencing pointer to incomplete
type
drivers/i2c/busses/i2c-rpx.c:39: error: dereferencing pointer to incomplete
type
drivers/i2c/busses/i2c-rpx.c:41: error: dereferencing pointer to incomplete
type
drivers/i2c/busses/i2c-rpx.c:42: error: dereferencing pointer to incomplete
type
drivers/i2c/busses/i2c-rpx.c:53: error: dereferencing pointer to incomplete
type
drivers/i2c/busses/i2c-rpx.c:56: error: dereferencing pointer to incomplete
type
drivers/i2c/busses/i2c-rpx.c: At top level:
drivers/i2c/busses/i2c-rpx.c:67: error: variable `rpx_data' has initializer
but incomplete type
drivers/i2c/busses/i2c-rpx.c:68: error: unknown field `setisr' specified in
initializer
drivers/i2c/busses/i2c-rpx.c:69: warning: excess elements in struct
initializer
drivers/i2c/busses/i2c-rpx.c:69: warning: (near initialization for
`rpx_data')
drivers/i2c/busses/i2c-rpx.c:67: error: storage size of `rpx_data' isn't
known
make[3]: *** [drivers/i2c/busses/i2c-rpx.o] Error 1
make[2]: *** [drivers/i2c/busses] Error 2
make[1]: *** [drivers/i2c] Error 2
make: *** [drivers] Error 2
Here is the listing of i2c-algo-8xx.h I have (from Linux 2.4.26 distribution
)
/* ------------------------------------------------------------------------
/* i2c-algo-8xx.h i2c driver algorithms for MPX8XX CPM
/* ------------------------------------------------------------------------
/* $Id$ */
#ifndef I2C_ALGO_8XX_H
#define I2C_ALGO_8XX_H 1
#include <linux/i2c.h>
struct i2c_algo_8xx_data {
uint dp_addr;
int reloc;
volatile i2c8xx_t *i2c;
volatile iic_t *iip;
volatile cpm8xx_t *cp;
int (*setisr) (int irq,
void (*func)(int, void *, struct pt_regs *),
const char *name,
void *data);
u_char temp[513];
};
int i2c_8xx_add_bus(struct i2c_adapter *);
int i2c_8xx_del_bus(struct i2c_adapter *);
#endif /* I2C_ALGO_8XX_H */
Thanks,
Best Regards,
I will highly Appreciate your response/help !
Alex Povolotsky
-
^ permalink raw reply
* [PATCH] Compile 6xx specific code only for 6xx machines
From: tglx @ 2004-12-15 14:21 UTC (permalink / raw)
To: trini; +Cc: linuxppc-embedded
The 6xx specific mmu functions in arch/boot/common/util.S break the compile for
other platforms. Compile them for 6xx only.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
---
util.S | 2 ++
1 files changed, 2 insertions(+)
---
Index: 2.6.10-rc3/arch/ppc/boot/common/util.S
===================================================================
--- 2.6.10-rc3/arch/ppc/boot/common/util.S (revision 11)
+++ 2.6.10-rc3/arch/ppc/boot/common/util.S (working copy)
@@ -27,6 +27,7 @@
.text
+#ifdef CONFIG_6xx
.globl disable_6xx_mmu
disable_6xx_mmu:
/* Establish default MSR value, exception prefix 0xFFF.
@@ -94,6 +95,7 @@
sync
isync
blr
+#endif
.globl _setup_L2CR
_setup_L2CR:
^ permalink raw reply
* Re: [PATCH] Compile 6xx specific code only for 6xx machines
From: Thomas Gleixner @ 2004-12-15 15:18 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <366A345A-4EAC-11D9-9441-000393DBC2E8@freescale.com>
On Wed, 2004-12-15 at 09:15 -0600, Kumar Gala wrote:
> One reason for this is that we dont have boot/common code for e500. Up
> to this point we've been using uImage's which causes code in
> boot/common not to get built.
>
> Maybe someone will be motivated to right e500/85xx boot/common code :)
>
> - kumar
By adding this fix I can use the code in boot/simple. It works nice :)
tglx
^ permalink raw reply
* Re: [PATCH] Compile 6xx specific code only for 6xx machines
From: Kumar Gala @ 2004-12-15 15:15 UTC (permalink / raw)
To: tglx; +Cc: linuxppc-embedded
In-Reply-To: <1103122166.3406.174.camel@tglx.tec.linutronix.de>
One reason for this is that we dont have boot/common code for e500. Up=20=
to this point we've been using uImage's which causes code in=20
boot/common not to get built.
Maybe someone will be motivated to right e500/85xx boot/common code :)
- kumar
On Dec 15, 2004, at 8:49 AM, Thomas Gleixner wrote:
> On Wed, 2004-12-15 at 07:35 -0700, Tom Rini wrote:
> > On Wed, Dec 15, 2004 at 03:21:43PM +0100, tglx@linutronix.de wrote:
> >
> > > The 6xx specific mmu functions in arch/boot/common/util.S break=20
> the compile for
> > > other platforms. Compile them for 6xx only.
> >
> > They, er, do?=A0 Can you please post a log?=A0 And what toolchain =
are you
> > using?=A0 I'd make a quick guess that the binutils folks are being=20=
> overly
> > 'helpful' again, but perhaps I'm just jaded. :)
>
> I'm compiling for 8540 (e500)
>
> =A0 AS=A0=A0=A0=A0=A0 arch/ppc/boot/common/util.o
> /home/tglx/work/repos/linux-ebrain/2.6.10-
> rc3/arch/ppc/boot/common/util.S: Assembler messages:
> /home/tglx/work/repos/linux-ebrain/2.6.10-
> rc3/arch/ppc/boot/common/util.S:76: Error: Unrecognized opcode:=20
> `mtsrin'
> make[3]: *** [arch/ppc/boot/common/util.o] Error 1
> make[2]: *** [arch/ppc/boot/common] Error 2
> make[1]: *** [zImage] Error 2
> make: *** [_all] Error 2
>
> Toolchain is built with crosstool
>
> binutils-2.15
> gcc-3.4.2
> glibc-2.3.3
>
> tglx
>
>
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* [PATCH 2.6.10-rc3] ppc32: Compile classic PPC specific ASM only on CONFIG_6xx
From: Tom Rini @ 2004-12-15 15:06 UTC (permalink / raw)
To: Andrew Morton, Kernel Mailing List, Linus Torvalds; +Cc: linuxppc-embedded
[ I hope this can go in prior to 2.6.10 ]
Newer binutils (2.15) when they know they aren't assembling for a
classic target (say e500 instead of 750) disallow certain opcodes,
causing the compile to fail.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Tom Rini <trini@kernel.crashing.org>
---
util.S | 2 ++
1 files changed, 2 insertions(+)
---
Index: 2.6.10-rc3/arch/ppc/boot/common/util.S
===================================================================
--- 2.6.10-rc3/arch/ppc/boot/common/util.S (revision 11)
+++ 2.6.10-rc3/arch/ppc/boot/common/util.S (working copy)
@@ -27,6 +27,7 @@
.text
+#ifdef CONFIG_6xx
.globl disable_6xx_mmu
disable_6xx_mmu:
/* Establish default MSR value, exception prefix 0xFFF.
@@ -94,6 +95,7 @@
sync
isync
blr
+#endif
.globl _setup_L2CR
_setup_L2CR:
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* Re: [PATCH] Compile 6xx specific code only for 6xx machines
From: Thomas Gleixner @ 2004-12-15 14:49 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20041215143518.GC22316@smtp.west.cox.net>
On Wed, 2004-12-15 at 07:35 -0700, Tom Rini wrote:
> On Wed, Dec 15, 2004 at 03:21:43PM +0100, tglx@linutronix.de wrote:
>
> > The 6xx specific mmu functions in arch/boot/common/util.S break the compile for
> > other platforms. Compile them for 6xx only.
>
> They, er, do? Can you please post a log? And what toolchain are you
> using? I'd make a quick guess that the binutils folks are being overly
> 'helpful' again, but perhaps I'm just jaded. :)
I'm compiling for 8540 (e500)
AS arch/ppc/boot/common/util.o
/home/tglx/work/repos/linux-ebrain/2.6.10-
rc3/arch/ppc/boot/common/util.S: Assembler messages:
/home/tglx/work/repos/linux-ebrain/2.6.10-
rc3/arch/ppc/boot/common/util.S:76: Error: Unrecognized opcode: `mtsrin'
make[3]: *** [arch/ppc/boot/common/util.o] Error 1
make[2]: *** [arch/ppc/boot/common] Error 2
make[1]: *** [zImage] Error 2
make: *** [_all] Error 2
Toolchain is built with crosstool
binutils-2.15
gcc-3.4.2
glibc-2.3.3
tglx
^ permalink raw reply
* Re: [PATCH] Compile 6xx specific code only for 6xx machines
From: Tom Rini @ 2004-12-15 14:35 UTC (permalink / raw)
To: tglx; +Cc: linuxppc-embedded
In-Reply-To: <20041215152142.1.patchmail@tglx>
On Wed, Dec 15, 2004 at 03:21:43PM +0100, tglx@linutronix.de wrote:
> The 6xx specific mmu functions in arch/boot/common/util.S break the compile for
> other platforms. Compile them for 6xx only.
They, er, do? Can you please post a log? And what toolchain are you
using? I'd make a quick guess that the binutils folks are being overly
'helpful' again, but perhaps I'm just jaded. :)
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply
* [Patch] Full Duplex DM9161 MII support on MPC8272ADS
From: alebas @ 2004-12-15 13:31 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
Hi,
This patch tries to add MII support for the DM9161 PHY
used in the mpc8272ads boards. I have literally copied
this from the driver in kernel 2.4
I have also included modifications nedded to support
both PHYs on the board (as done in kernel 2.4).
Two more minor changes are also in the patch
- PHY_INTERRUPT is changed from IRQ7 to IRQ5 in mpc8272ads
- Access to BCSR to enable the second console in function
m82xx_board_init is commented out (it was generating
an exception).
Best regards
Alex Bastos
[-- Attachment #2: dm9161_mii_and_mpc8272.diff --]
[-- Type: application/octet-stream, Size: 10065 bytes --]
--- snapshot/arch/ppc/8260_io/fcc_enet.c 2004-12-15 13:07:39.000000000 +0100
+++ linuxppc/arch/ppc/8260_io/fcc_enet.c 2004-12-14 20:28:00.000000000 +0100
@@ -86,6 +86,18 @@
const phy_cmd_t *shutdown;
} phy_info_t;
+/* Register definitions for the PHY. */
+
+#define MII_REG_CR 0 /* Control Register */
+#define MII_REG_SR 1 /* Status Register */
+#define MII_REG_PHYIR1 2 /* PHY Identification Register 1 */
+#define MII_REG_PHYIR2 3 /* PHY Identification Register 2 */
+#define MII_REG_ANAR 4 /* A-N Advertisement Register */
+#define MII_REG_ANLPAR 5 /* A-N Link Partner Ability Register */
+#define MII_REG_ANER 6 /* A-N Expansion Register */
+#define MII_REG_ANNPTR 7 /* A-N Next Page Transmit Register */
+#define MII_REG_ANLPRNPR 8 /* A-N Link Partner Received Next Page Reg. */
+
/* values for phy_status */
#define PHY_CONF_ANE 0x0001 /* 1 auto-negotiation enabled */
@@ -287,6 +299,12 @@
#define PC_MDCK ((uint)0x00000000)
#endif /* ifdef CONFIG_USE_MDIO */
+/* PHY addresses */
+/* default to dynamic config of phy addresses */
+#define FCC1_PHY_ADDR 0
+#define FCC2_PHY_ADDR 2
+#define FCC3_PHY_ADDR 3
+
/* A table of information for supporting FCCs. This does two things.
* First, we know how many FCCs we have and they are always externally
* numbered from zero. Second, it holds control register and I/O
@@ -294,6 +312,7 @@
*/
typedef struct fcc_info {
uint fc_fccnum;
+ uint fc_phyaddr;
uint fc_cpmblock;
uint fc_cpmpage;
uint fc_proff;
@@ -307,7 +326,7 @@
static fcc_info_t fcc_ports[] = {
#ifdef CONFIG_FCC1_ENET
- { 0, CPM_CR_FCC1_SBLOCK, CPM_CR_FCC1_PAGE, PROFF_FCC1, SIU_INT_FCC1,
+ { 0, FCC1_PHY_ADDR, CPM_CR_FCC1_SBLOCK, CPM_CR_FCC1_PAGE, PROFF_FCC1, SIU_INT_FCC1,
(PC_F1RXCLK | PC_F1TXCLK), CMX1_CLK_ROUTE, CMX1_CLK_MASK,
# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)
PC_MDIO, PC_MDCK },
@@ -316,7 +335,7 @@
# endif
#endif
#ifdef CONFIG_FCC2_ENET
- { 1, CPM_CR_FCC2_SBLOCK, CPM_CR_FCC2_PAGE, PROFF_FCC2, SIU_INT_FCC2,
+ { 1, FCC2_PHY_ADDR, CPM_CR_FCC2_SBLOCK, CPM_CR_FCC2_PAGE, PROFF_FCC2, SIU_INT_FCC2,
(PC_F2RXCLK | PC_F2TXCLK), CMX2_CLK_ROUTE, CMX2_CLK_MASK,
# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)
PC_MDIO, PC_MDCK },
@@ -327,7 +346,7 @@
# endif
#endif
#ifdef CONFIG_FCC3_ENET
- { 2, CPM_CR_FCC3_SBLOCK, CPM_CR_FCC3_PAGE, PROFF_FCC3, SIU_INT_FCC3,
+ { 2, FCC3_PHY_ADDR, CPM_CR_FCC3_SBLOCK, CPM_CR_FCC3_PAGE, PROFF_FCC3, SIU_INT_FCC3,
(PC_F3RXCLK | PC_F3TXCLK), CMX3_CLK_ROUTE, CMX3_CLK_MASK,
# if defined(CONFIG_TQM8260) || defined(CONFIG_ADS8272)
PC_MDIO, PC_MDCK },
@@ -1203,6 +1222,148 @@
#endif /* CONFIG_FEC_DM9131 */
+#if defined (CONFIG_FCC_DM9161)
+/* ------------------------------------------------------------------------- */
+/* DM9161 Control register values */
+#define MIIM_DM9161_CR_STOP 0x0400
+#define MIIM_DM9161_CR_RSTAN 0x1200
+
+#define MIIM_DM9161_SCR 0x10
+#define MIIM_DM9161_SCR_INIT 0x0610
+
+/* DM9161 Specified Configuration and Status Register */
+#define MIIM_DM9161_SCSR 0x11
+#define MIIM_DM9161_SCSR_100F 0x8000
+#define MIIM_DM9161_SCSR_100H 0x4000
+#define MIIM_DM9161_SCSR_10F 0x2000
+#define MIIM_DM9161_SCSR_10H 0x1000
+/* DM9161 10BT register */
+#define MIIM_DM9161_10BTCSR 0x12
+#define MIIM_DM9161_10BTCSR_INIT 0x7800
+/* DM9161 Interrupt Register */
+#define MIIM_DM9161_INTR 0x15
+#define MIIM_DM9161_INTR_PEND 0x8000
+#define MIIM_DM9161_INTR_DPLX_MASK 0x0800
+#define MIIM_DM9161_INTR_SPD_MASK 0x0400
+#define MIIM_DM9161_INTR_LINK_MASK 0x0200
+#define MIIM_DM9161_INTR_MASK 0x0100
+#define MIIM_DM9161_INTR_DPLX_CHANGE 0x0010
+#define MIIM_DM9161_INTR_SPD_CHANGE 0x0008
+#define MIIM_DM9161_INTR_LINK_CHANGE 0x0004
+#define MIIM_DM9161_INTR_INIT 0x0000
+#define MIIM_DM9161_INTR_STOP \
+(MIIM_DM9161_INTR_DPLX_MASK | MIIM_DM9161_INTR_SPD_MASK \
+ | MIIM_DM9161_INTR_LINK_MASK | MIIM_DM9161_INTR_MASK)
+
+static void mii_parse_dm9161_sr(uint mii_reg, struct net_device * dev)
+{
+ volatile struct fcc_enet_private *fep = dev->priv;
+ uint regstat, timeout=0xffff;
+
+ while(!(mii_reg & 0x0020) && timeout--)
+ {
+ regstat=mk_mii_read(MII_REG_SR);
+ regstat |= fep->phy_addr <<23;
+ mii_reg = mii_send_receive(fep->fip,regstat);
+ }
+
+ mii_parse_sr(mii_reg, dev);
+}
+
+static void mii_parse_dm9161_scsr(uint mii_reg, struct net_device * dev)
+{
+ volatile struct fcc_enet_private *fep = dev->priv;
+ uint s = fep->phy_status;
+ s &= ~(PHY_STAT_SPMASK);
+ switch((mii_reg >>12) & 0xf) {
+ case 1:
+ {
+ s |= PHY_STAT_10HDX;
+ printk("10BaseT Half Duplex\n");
+ break;
+ }
+ case 2:
+ {
+ s |= PHY_STAT_10FDX;
+ printk("10BaseT Full Duplex\n");
+ break;
+ }
+ case 4:
+ {
+ s |= PHY_STAT_100HDX;
+ printk("100BaseT Half Duplex\n");
+ break;
+ }
+ case 8:
+ {
+ s |= PHY_STAT_100FDX;
+ printk("100BaseT Full Duplex\n");
+ break;
+ }
+ }
+
+ fep->phy_status = s;
+
+}
+
+static void mii_dm9161_wait(uint mii_reg, struct net_device *dev)
+{
+ int timeout = HZ;
+
+ /* Davicom takes a bit to come up after a reset,
+ * so wait here for a bit */
+ set_current_state(TASK_UNINTERRUPTIBLE);
+ schedule_timeout(timeout);
+}
+
+static phy_info_t phy_info_dm9161 = {
+ 0x00181b88,
+ "Davicom DM9161E",
+ (const phy_cmd_t[]) { /* config */
+ { mk_mii_write(MII_REG_CR, MIIM_DM9161_CR_STOP), NULL},
+ /* Do not bypass the scrambler/descrambler */
+ { mk_mii_write(MIIM_DM9161_SCR, MIIM_DM9161_SCR_INIT), NULL},
+ /* Configure 10BTCSR register */
+ { mk_mii_write(MIIM_DM9161_10BTCSR, MIIM_DM9161_10BTCSR_INIT),NULL},
+ /* Configure some basic stuff */
+ { mk_mii_write(MII_REG_CR, 0x1000), NULL},
+ { mk_mii_read(MII_REG_CR), mii_parse_cr },
+ { mk_mii_read(MII_REG_ANAR), mii_parse_anar },
+ { mk_mii_end,}
+ },
+ (const phy_cmd_t[]) { /* startup */
+ /* Restart Auto Negotiation */
+ { mk_mii_write(MII_REG_CR, MIIM_DM9161_CR_RSTAN), NULL},
+ /* Status is read once to clear old link state */
+ { mk_mii_read(MII_REG_SR), mii_dm9161_wait},
+ /* Auto-negotiate */
+ { mk_mii_read(MII_REG_SR), mii_parse_dm9161_sr},
+ /* Read the status */
+ { mk_mii_read(MIIM_DM9161_SCSR), mii_parse_dm9161_scsr},
+ /* Clear any pending interrupts */
+ { mk_mii_read(MIIM_DM9161_INTR), NULL},
+ /* Enable Interrupts */
+ { mk_mii_write(MIIM_DM9161_INTR, MIIM_DM9161_INTR_INIT), NULL},
+ { mk_mii_end,}
+ },
+ (const phy_cmd_t[]) { /* ack_int */
+ { mk_mii_read(MIIM_DM9161_INTR), NULL},
+#if 0
+ { mk_mii_read(MII_REG_SR), NULL},
+ { mk_mii_read(MII_REG_SR), mii_parse_dm9161_sr},
+ { mk_mii_read(MIIM_DM9161_SCSR), mii_parse_dm9161_scsr},
+#endif
+ { mk_mii_end,}
+ },
+ (const phy_cmd_t[]) { /* shutdown */
+ { mk_mii_read(MIIM_DM9161_INTR),NULL},
+ { mk_mii_write(MIIM_DM9161_INTR, MIIM_DM9161_INTR_STOP), NULL},
+ { mk_mii_end,}
+ },
+};
+
+
+#endif /* CONFIG_FEC_DM9161 */
static phy_info_t *phy_info[] = {
@@ -1222,6 +1383,10 @@
&phy_info_dm9131,
#endif /* CONFIG_FEC_DM9131 */
+#if defined (CONFIG_FCC_DM9161)
+ &phy_info_dm9161,
+#endif
+
#ifdef CONFIG_FCC_GENERIC_PHY
/* Generic PHY support. This must be the last PHY in the table.
* It will be used to support any PHY that doesn't match a previous
@@ -1596,7 +1761,7 @@
* remainder of the interface.
*/
cep->phy_id_done = 0;
- cep->phy_addr = 0;
+ cep->phy_addr = fip->fc_phyaddr;
mii_queue(dev, mk_mii_read(MII_PHYSID1), mii_discover_phy);
INIT_WORK(&cep->phy_relink, mii_display_status, dev);
INIT_WORK(&cep->phy_display_config, mii_display_config, dev);
@@ -1954,6 +2119,10 @@
printk("Can't get FCC IRQ %d\n", fip->fc_interrupt);
#ifdef PHY_INTERRUPT
+#ifdef CONFIG_ADS8272
+ if (request_irq(PHY_INTERRUPT, mii_link_interrupt, SA_SHIRQ,
+ "mii", dev) < 0)
+#else
/* Make IRQn edge triggered. This does not work if PHY_INTERRUPT is
* on Port C.
*/
@@ -1962,6 +2131,7 @@
if (request_irq(PHY_INTERRUPT, mii_link_interrupt, 0,
"mii", dev) < 0)
+#endif
printk("Can't get MII IRQ %d\n", PHY_INTERRUPT);
#endif /* PHY_INTERRUPT */
@@ -1984,6 +2154,8 @@
*/
*(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_FETHIEN;
*(volatile uint *)(BCSR_ADDR + 4) |= BCSR1_FETH_RST;
+ *(volatile uint *)(BCSR_ADDR + 12) &= ~BCSR3_FETHIEN2;
+ *(volatile uint *)(BCSR_ADDR + 12) |= BCSR3_FETH2_RST;
#endif
#if defined(CONFIG_USE_MDIO) || defined(CONFIG_TQM8260)
--- snapshot/arch/ppc/platforms/pq2ads.h 2004-12-15 13:07:40.000000000 +0100
+++ linuxppc/arch/ppc/platforms/pq2ads.h 2004-12-14 14:58:39.000000000 +0100
@@ -40,8 +40,14 @@
#define BCSR1_FETH_RST ((uint)0x04000000) /* 0 == reset */
#define BCSR1_RS232_EN1 ((uint)0x02000000) /* 0 == enable */
#define BCSR1_RS232_EN2 ((uint)0x01000000) /* 0 == enable */
+#define BCSR3_FETHIEN2 ((uint)0x10000000) /* 0 == enable */
+#define BCSR3_FETH2_RST ((uint)0x80000000) /* 0 == reset */
+#ifdef CONFIG_ADS8272
+#define PHY_INTERRUPT SIU_INT_IRQ5
+#else
#define PHY_INTERRUPT SIU_INT_IRQ7
+#endif
#ifdef CONFIG_PCI
/* PCI interrupt controller */
--- snapshot/arch/ppc/platforms/pq2ads.c 2004-12-15 13:07:43.000000000 +0100
+++ linuxppc/arch/ppc/platforms/pq2ads.c 2004-11-25 09:59:05.000000000 +0100
@@ -22,5 +22,5 @@
m82xx_board_init(void)
{
/* Enable the 2nd UART port */
- *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;
+ /* *(volatile uint *)(BCSR_ADDR + 4) &= ~BCSR1_RS232_EN2;*/
}
--- snapshot/arch/ppc/8260_io/Kconfig 2004-12-15 13:07:43.000000000 +0100
+++ linuxppc/arch/ppc/8260_io/Kconfig 2004-12-09 12:56:31.000000000 +0100
@@ -53,6 +53,12 @@
config FCC_QS6612
bool "QS6612"
+config FCC_DM9131
+ bool "DM9131"
+
+config FCC_DM9161
+ bool "DM9161"
+
endchoice
endmenu
^ permalink raw reply
* kernel's booting hangs on SCC2
From: Alireza Sadri @ 2004-12-15 12:52 UTC (permalink / raw)
To: linuxppc-embedded
Hi ,
i use kernel v2.4.24 , and i used make
menuconfig and for MPC8260 (custom EST8260 board) I
chosed SCC for console .
I have only one SCC1 port on my board (it has only two
pins Rx,Tx) but i cannot configure kernel to search
only for one console while booting, it hangs after
searching for the second SCC:
Uncompressing Kernel Image ... OK
Memory BAT mapping: BAT2=64Mb, BAT3=0Mb, residual: 0Mb
Linux version 2.4.24-pre2 (root@Setareh2) (gcc version
...
...
...
Initializing RT netlink socket
Starting kswapd
CPM UART driver version 0.01
ttyS0 on SCC1 at 0x8000, BRG7
ttyS1 on SCC2
and hangs here , can anyone please tell me what is my
problem? here is my menuconfig MPC8260 CPM
configuration:
[*] Enable SCC console
[ ] CPM SCC Ethernet
[*] CPM FCC Ethernet
[*] Ethernet on FCC1
[*] Ethernet on FCC2
[*] Ethernet on FCC3
[ ] Use MDIO for PHY configuration
[ ] Support LXT970 PHY
[*] Support LXT971 PHY
[ ] Support QS6612 PHY
[ ] Support AMD79C873 PHY
[ ] Support DM9131 PHY
[ ] Simple CPM SPI Support
--- SCC UART h/w handshaking options
--- SCC1
(None) CTS signal for SCC1
(None) RTS signal for SCC1
(None) CD signal for SCC1
(None) DTR signal port for SCC1
--- SCC2
(None) CTS signal for SCC2
(None) RTS signal for SCC2
(None) CD signal for SCC2
(None) DTR signal port for SCC2
--- SCC3
(None) CTS signal for SCC3
(None) RTS signal for SCC3
(None) CD signal for SCC3
(None) DTR signal port for SCC3
--- SCC4
(None) CTS signal for SCC4
(None) RTS signal for SCC4
(None) CD signal for SCC4
(None) DTR signal port for SCC4
Best regards,
Alireza Sadri
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
^ permalink raw reply
* Re: [PATCH] Fix __res data type (PPC 85xx) 2nd version
From: Thomas Gleixner @ 2004-12-15 0:37 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <2A28D57A-4E27-11D9-B992-000393DBC2E8@freescale.com>
[-- Attachment #1: Type: text/plain, Size: 442 bytes --]
Kumar,
On Tue, 2004-12-14 at 17:23 -0600, Kumar Gala wrote:
> Thomas,
>
> This generally looks good, I would like to apply the patch and do some
> testing. In the future please CC: linuxppc-embedded@ozlabs.org (this
> will allow us to manage the patches @ http://ozlabs.org/ppc32-patches/)
The attached patch contains the previous one and the resulting changes
for syslib/ppc85xx_setup.c. It's a correct -p1 patch now.
Thanks,
tglx
[-- Attachment #2: res-2.diff --]
[-- Type: text/x-patch, Size: 8276 bytes --]
Index: 2.6.10-rc3/include/asm-ppc/mpc85xx.h
===================================================================
--- 2.6.10-rc3/include/asm-ppc/mpc85xx.h (revision 8)
+++ 2.6.10-rc3/include/asm-ppc/mpc85xx.h (working copy)
@@ -47,7 +47,7 @@
* The "residual" board information structure the boot loader passes
* into the kernel.
*/
-extern unsigned char __res[];
+extern bd_t __res;
/* Internal IRQs on MPC85xx OpenPIC */
/* Not all of these exist on all MPC85xx implementations */
Index: 2.6.10-rc3/arch/ppc/platforms/85xx/sbc85xx.c
===================================================================
--- 2.6.10-rc3/arch/ppc/platforms/85xx/sbc85xx.c (revision 11)
+++ 2.6.10-rc3/arch/ppc/platforms/85xx/sbc85xx.c (working copy)
@@ -48,7 +48,7 @@
#include <platforms/85xx/sbc85xx.h>
-unsigned char __res[sizeof (bd_t)];
+bd_t __res;
#ifndef CONFIG_PCI
unsigned long isa_io_base = 0;
@@ -120,11 +120,10 @@
{
uint pvid, svid, phid1;
uint memsize = total_memory;
- bd_t *binfo = (bd_t *) __res;
unsigned int freq;
/* get the core frequency */
- freq = binfo->bi_intfreq;
+ freq = __res.bi_intfreq;
pvid = mfspr(PVR);
svid = mfspr(SVR);
@@ -159,10 +158,9 @@
void __init
sbc8560_init_IRQ(void)
{
- bd_t *binfo = (bd_t *) __res;
/* Determine the Physical Address of the OpenPIC regs */
phys_addr_t OpenPIC_PAddr =
- binfo->bi_immr_base + MPC85xx_OPENPIC_OFFSET;
+ __res.bi_immr_base + MPC85xx_OPENPIC_OFFSET;
OpenPIC_Addr = ioremap(OpenPIC_PAddr, MPC85xx_OPENPIC_SIZE);
OpenPIC_InitSenses = sbc8560_openpic_initsenses;
OpenPIC_NumInitSenses = sizeof (sbc8560_openpic_initsenses);
Index: 2.6.10-rc3/arch/ppc/platforms/85xx/mpc85xx_ads_common.c
===================================================================
--- 2.6.10-rc3/arch/ppc/platforms/85xx/mpc85xx_ads_common.c (revision 11)
+++ 2.6.10-rc3/arch/ppc/platforms/85xx/mpc85xx_ads_common.c (working copy)
@@ -56,7 +56,7 @@
extern unsigned long total_memory; /* in mm/init */
-unsigned char __res[sizeof (bd_t)];
+bd_t __res;
/* Internal interrupts are all Level Sensitive, and Positive Polarity */
@@ -120,11 +120,10 @@
{
uint pvid, svid, phid1;
uint memsize = total_memory;
- bd_t *binfo = (bd_t *) __res;
unsigned int freq;
/* get the core frequency */
- freq = binfo->bi_intfreq;
+ freq = __res.bi_intfreq;
pvid = mfspr(PVR);
svid = mfspr(SVR);
@@ -159,10 +158,9 @@
void __init
mpc85xx_ads_init_IRQ(void)
{
- bd_t *binfo = (bd_t *) __res;
/* Determine the Physical Address of the OpenPIC regs */
phys_addr_t OpenPIC_PAddr =
- binfo->bi_immr_base + MPC85xx_OPENPIC_OFFSET;
+ __res.bi_immr_base + MPC85xx_OPENPIC_OFFSET;
OpenPIC_Addr = ioremap(OpenPIC_PAddr, MPC85xx_OPENPIC_SIZE);
OpenPIC_InitSenses = mpc85xx_ads_openpic_initsenses;
OpenPIC_NumInitSenses = sizeof (mpc85xx_ads_openpic_initsenses);
Index: 2.6.10-rc3/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
===================================================================
--- 2.6.10-rc3/arch/ppc/platforms/85xx/mpc85xx_cds_common.c (revision 11)
+++ 2.6.10-rc3/arch/ppc/platforms/85xx/mpc85xx_cds_common.c (working copy)
@@ -64,7 +64,7 @@
extern unsigned long total_memory; /* in mm/init */
-unsigned char __res[sizeof (bd_t)];
+bd_t __res;
static int cds_pci_slot = 2;
static volatile u8 * cadmus;
@@ -161,11 +161,10 @@
{
uint pvid, svid, phid1;
uint memsize = total_memory;
- bd_t *binfo = (bd_t *) __res;
unsigned int freq;
/* get the core frequency */
- freq = binfo->bi_intfreq;
+ freq = __res.bi_intfreq;
pvid = mfspr(PVR);
svid = mfspr(SVR);
@@ -204,7 +203,7 @@
void __init
mpc85xx_cds_init_IRQ(void)
{
- bd_t *binfo = (bd_t *) __res;
+ bd_t *binfo = &__res;
#ifdef CONFIG_CPM2
volatile cpm2_map_t *immap = cpm2_immr;
int i;
@@ -337,7 +336,7 @@
{
struct ocp_def *def;
struct ocp_gfar_data *einfo;
- bd_t *binfo = (bd_t *) __res;
+ bd_t *binfo = &__res;
unsigned int freq;
/* get the core frequency */
@@ -411,13 +410,13 @@
* residual data area.
*/
if (r3) {
- memcpy((void *) __res, (void *) (r3 + KERNELBASE),
+ memcpy((void *) &__res, (void *) (r3 + KERNELBASE),
sizeof (bd_t));
}
#ifdef CONFIG_SERIAL_TEXT_DEBUG
{
- bd_t *binfo = (bd_t *) __res;
+ bd_t *binfo = &__res;
/* Use the last TLB entry to map CCSRBAR to allow access to DUART regs */
settlbcam(NUM_TLBCAMS - 1, binfo->bi_immr_base,
Index: 2.6.10-rc3/arch/ppc/platforms/85xx/mpc8540_ads.c
===================================================================
--- 2.6.10-rc3/arch/ppc/platforms/85xx/mpc8540_ads.c (revision 11)
+++ 2.6.10-rc3/arch/ppc/platforms/85xx/mpc8540_ads.c (working copy)
@@ -102,7 +102,7 @@
{
struct ocp_def *def;
struct ocp_gfar_data *einfo;
- bd_t *binfo = (bd_t *) __res;
+ bd_t *binfo = &__res;
unsigned int freq;
/* get the core frequency */
@@ -175,12 +175,12 @@
* residual data area.
*/
if (r3) {
- memcpy((void *) __res, (void *) (r3 + KERNELBASE),
+ memcpy((void *) &__res, (void *) (r3 + KERNELBASE),
sizeof (bd_t));
}
#ifdef CONFIG_SERIAL_TEXT_DEBUG
{
- bd_t *binfo = (bd_t *) __res;
+ bd_t *binfo = &__res;
/* Use the last TLB entry to map CCSRBAR to allow access to DUART regs */
settlbcam(NUM_TLBCAMS - 1, binfo->bi_immr_base,
Index: 2.6.10-rc3/arch/ppc/platforms/85xx/mpc8560_ads.c
===================================================================
--- 2.6.10-rc3/arch/ppc/platforms/85xx/mpc8560_ads.c (revision 11)
+++ 2.6.10-rc3/arch/ppc/platforms/85xx/mpc8560_ads.c (working copy)
@@ -97,7 +97,7 @@
{
struct ocp_def *def;
struct ocp_gfar_data *einfo;
- bd_t *binfo = (bd_t *) __res;
+ bd_t *binfo = &__res;
unsigned int freq;
cpm2_reset();
@@ -200,7 +200,7 @@
* residual data area.
*/
if (r3) {
- memcpy((void *) __res, (void *) (r3 + KERNELBASE),
+ memcpy((void *) &__res, (void *) (r3 + KERNELBASE),
sizeof (bd_t));
}
Index: 2.6.10-rc3/arch/ppc/platforms/85xx/sbc8560.c
===================================================================
--- 2.6.10-rc3/arch/ppc/platforms/85xx/sbc8560.c (revision 11)
+++ 2.6.10-rc3/arch/ppc/platforms/85xx/sbc8560.c (working copy)
@@ -127,7 +127,7 @@
{
struct ocp_def *def;
struct ocp_gfar_data *einfo;
- bd_t *binfo = (bd_t *) __res;
+ bd_t *binfo = &__res;
unsigned int freq;
/* get the core frequency */
@@ -193,7 +193,7 @@
* residual data area.
*/
if (r3) {
- memcpy((void *) __res, (void *) (r3 + KERNELBASE),
+ memcpy((void *) &__res, (void *) (r3 + KERNELBASE),
sizeof (bd_t));
}
Index: 2.6.10-rc3/arch/ppc/syslib/ppc85xx_setup.c
===================================================================
--- 2.6.10-rc3/arch/ppc/syslib/ppc85xx_setup.c (revision 11)
+++ 2.6.10-rc3/arch/ppc/syslib/ppc85xx_setup.c (working copy)
@@ -36,22 +36,17 @@
unsigned long __init
mpc85xx_find_end_of_memory(void)
{
- bd_t *binfo;
-
- binfo = (bd_t *) __res;
-
- return binfo->bi_memsize;
+ return __res.bi_memsize;
}
/* The decrementer counts at the system (internal) clock freq divided by 8 */
void __init
mpc85xx_calibrate_decr(void)
{
- bd_t *binfo = (bd_t *) __res;
unsigned int freq, divisor;
/* get the core frequency */
- freq = binfo->bi_busfreq;
+ freq = __res.bi_busfreq;
/* The timebase is updated every 8 bus clocks, HID0[SEL_TBCLK] = 0 */
divisor = 8;
@@ -74,7 +69,7 @@
mpc85xx_early_serial_map(void)
{
struct uart_port serial_req;
- bd_t *binfo = (bd_t *) __res;
+ bd_t *binfo = &__res;
phys_addr_t duart_paddr = binfo->bi_immr_base + MPC85xx_UART0_OFFSET;
/* Setup serial port access */
@@ -138,7 +133,7 @@
volatile struct ccsr_pci *pci;
volatile struct ccsr_guts *guts;
unsigned short temps;
- bd_t *binfo = (bd_t *) __res;
+ bd_t *binfo = &__res;
pci = ioremap(binfo->bi_immr_base + MPC85xx_PCI1_OFFSET,
MPC85xx_PCI1_SIZE);
@@ -250,7 +245,7 @@
#ifdef CONFIG_85xx_PCI2
struct pci_controller *hose_b;
#endif
- bd_t *binfo = (bd_t *) __res;
+ bd_t *binfo = &__res;
hose_a = pcibios_alloc_controller();
^ permalink raw reply
* Initialization of Timer Clock on the MPC8260
From: annamaya @ 2004-12-14 23:07 UTC (permalink / raw)
To: linuxppc-embedded
I am not sure if this is the right place to ask this
question since this may be a U-Boot question. I am
trying to understand how the source for the timer
clock is selected on this processor. Figure 4-3 tries
to explain this but I am unable to find code in U-Boot
that actually sets either BRG1 or one of the GPIO pins
to act as inputs for the timer clock generation. Can
someone point me to the right place in the code where
this is done? I think I know how to do it but I fail
to understand where this is being actually done. All I
see is the settings of PISCR and TMCNT registers in
cpu initialization code. Thanks for your help in advance.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* [PATCH][PPC32] Fix SPE state corruption on e500
From: Kumar Gala @ 2004-12-14 22:26 UTC (permalink / raw)
To: linus; +Cc: akpm, linux-kernel, linuxppc-embedded
Linus,
Unfortunately the restoring of SPE state was causing data corruption since
we were restoring based on the size of the altivec context and not
the SPE context. Also, fixed setting of last_task_used_spe on
start_thread, flush_thread, and exit_thread.
Patch should go in for 2.6.10.
Signed-off-by: Kumar Gala <kumar.gala@freescale.com>
--
diff -Nru a/arch/ppc/kernel/process.c b/arch/ppc/kernel/process.c
--- a/arch/ppc/kernel/process.c 2004-12-14 15:59:07 -06:00
+++ b/arch/ppc/kernel/process.c 2004-12-14 15:59:07 -06:00
@@ -321,7 +321,7 @@
trap = TRAP(regs);
if (trap == 0x300 || trap == 0x600)
printk("DAR: %08lX, DSISR: %08lX\n", regs->dar, regs->dsisr);
- printk("TASK = %p[%d] '%s' THREAD: %p",
+ printk("TASK = %p[%d] '%s' THREAD: %p\n",
current, current->pid, current->comm, current->thread_info);
printk("Last syscall: %ld ", current->thread.last_syscall);
@@ -370,6 +370,10 @@
last_task_used_math = NULL;
if (last_task_used_altivec == current)
last_task_used_altivec = NULL;
+#ifdef CONFIG_SPE
+ if (last_task_used_spe == current)
+ last_task_used_spe = NULL;
+#endif
}
void flush_thread(void)
@@ -378,6 +382,10 @@
last_task_used_math = NULL;
if (last_task_used_altivec == current)
last_task_used_altivec = NULL;
+#ifdef CONFIG_SPE
+ if (last_task_used_spe == current)
+ last_task_used_spe = NULL;
+#endif
}
void
@@ -480,6 +488,10 @@
last_task_used_math = NULL;
if (last_task_used_altivec == current)
last_task_used_altivec = NULL;
+#ifdef CONFIG_SPE
+ if (last_task_used_spe == current)
+ last_task_used_spe = NULL;
+#endif
memset(current->thread.fpr, 0, sizeof(current->thread.fpr));
current->thread.fpscr = 0;
#ifdef CONFIG_ALTIVEC
diff -Nru a/arch/ppc/kernel/signal.c b/arch/ppc/kernel/signal.c
--- a/arch/ppc/kernel/signal.c 2004-12-14 15:59:07 -06:00
+++ b/arch/ppc/kernel/signal.c 2004-12-14 15:59:07 -06:00
@@ -319,7 +319,7 @@
if (!__get_user(msr, &sr->mc_gregs[PT_MSR]) && (msr & MSR_SPE) != 0) {
/* restore spe registers from the stack */
if (__copy_from_user(current->thread.evr, &sr->mc_vregs,
- sizeof(sr->mc_vregs)))
+ ELF_NEVRREG * sizeof(u32)))
return 1;
} else if (current->thread.used_spe)
memset(¤t->thread.evr, 0, ELF_NEVRREG * sizeof(u32));
^ permalink raw reply
* Re: MEMORY PROBLEM
From: Jerry Van Baren @ 2004-12-14 21:07 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <62302.213.114.195.235.1103055907.squirrel@webmail1.unisite.se>
ppclinux@sundmangroup.com wrote:
> Hello,
> I have a Freescale-PPC8270 ( Former Motorola ) based board with 256Megs of
> RAM.
>
> I am using the Montavista Vista Kernel 2.4.20.
>
> When the system is handling larger files ~100M when NFS mounted and ~20M
> when RAMDISKed the kernel crashes since things are being overwritten in
> memory.
>
> The crash happens when handling/creating large files by measn of e.g.
> * dd
> * gunzip
> * sftp download
> etc. it seems to be a general memory handling problem.
>
> When looking at the memory though there are plenty of free space, or there
> should be plenty of free space but for some reason things are
> overwritten...
>
> The Kernel reports actually 256M of memory. Top also shows that there is o
> r should be more than enough free memory for the operations I am trying to
> pull :-))
>
> Can you give me suggestions where to start digging into this problem?
>
> Best Regards // Matias
Your SDRAM initialization is suspect
http://www.denx.de/twiki/bin/view/DULG/LinuxCrashesRandomly
http://www.denx.de/twiki/bin/view/DULG/SDRAM
http://www.denx.de/twiki/bin/view/DULG/UBootCrashAfterRelocation
gvb
^ permalink raw reply
* MEMORY PROBLEM
From: ppclinux @ 2004-12-14 20:25 UTC (permalink / raw)
To: linuxppc-embedded
Hello,
I have a Freescale-PPC8270 ( Former Motorola ) based board with 256Megs of
RAM.
I am using the Montavista Vista Kernel 2.4.20.
When the system is handling larger files ~100M when NFS mounted and ~20M
when RAMDISKed the kernel crashes since things are being overwritten in
memory.
The crash happens when handling/creating large files by measn of e.g.
* dd
* gunzip
* sftp download
etc. it seems to be a general memory handling problem.
When looking at the memory though there are plenty of free space, or there
should be plenty of free space but for some reason things are
overwritten...
The Kernel reports actually 256M of memory. Top also shows that there is o
r should be more than enough free memory for the operations I am trying to
pull :-))
Can you give me suggestions where to start digging into this problem?
Best Regards // Matias
^ permalink raw reply
* Re: state of 8xx
From: Dan Malek @ 2004-12-14 16:51 UTC (permalink / raw)
To: Kalle Pokki; +Cc: linuxppc-embedded
In-Reply-To: <41BE908C.2060608@iki.fi>
On Dec 14, 2004, at 2:04 AM, Kalle Pokki wrote:
> ..... Is anyone looking into this, or do you have any idea when 8xx
> could be working again?
I'm working on it as time permits, but have not had much free time
lately. I have an upcoming 8xx project that will force me to spend
the time in the near future. Don't expect something from me until
after the new year.
-- Dan
^ permalink raw reply
* IBM750CXe 600MHz problem
From: Marcin Dawidowicz @ 2004-12-14 13:12 UTC (permalink / raw)
To: linuxppc-embedded
Greetings all,
I have two boards that are very similar. They base on IBM750cx/cxe processor
and XPC107A bridge/memory controller. Both are initialized in the same manner
(the same bootloader).
One of them has IBM750cx 400MHz (PVR: 0x0008 2214) on that one everything
works fine.
The other one has IBM750cxe 600MHz (PVR: 0x0008 3311) and here I have some
strange behavior.
PCI doesn't work fine if it uses memory mapped IO. If driver uses PIO instead
of MMIO it works fine - I observed such situation with ethernet driver for
i82553 (eepro100.c). I thought, there should be no difference on PPC between
memory and io-ports.
The other strange thing is problem with loading modules. On 600MHz version
trying loading module cause system hangup or kernel stack overflow oops -
like following:
......
Kernel stack overflow in process dfad8000, r1=dfad8390
NIP: C000DFE4 XER: 20000000 LR: C000D80C SP: DFAD8390 REGS: dfad82e0 TRAP:
0300 Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: 00000033, DSISR: 40000000
TASK = dfad8000[25] 'insmod' Last syscall: 128
last math dfad8000 last altivec 00000000
GPR00: FFFFFFFF DFAD8390 DFAD8000 00000000 00000033 0000000B DFA19008 C000DFE4
GPR08: FFFFFFFF FFFFFFFF FFFFFFF7 FFFFFFFF 48004482 100B0AFC 00000000 00000000
GPR16: 00000000 00000001 00000003 00000000 00009032 1FAD8450 00000000 C0003E54
GPR24: 00000000 C0156120 00030001 DFAD8460 40000000 00000033 0000000B DFAD8460
Call backtrace:
DFE41040 C000D6B4 C0003E54 00000000 C000D6B4 C0003E54 4BFFFEEC
C000D6B4 C0003E54 00000000 C000D6B4 C0003E54 00000000 C000D6B4
C0003E54 00000000 C000D6B4 C0003E54 00000000 C000D6B4 C0003E54
00000000 C000D6B4 C0003E54 0FFEDF88 C000D6B4 C0003E54 00000000
C000D6B4 C0003E54 00000000 C000D6B4 C0003E54
Kernel panic: kernel stack overflow
<0>Rebooting in 180 seconds..
......
The module has just module_init function that only returns value and empty
module_cleanup function.
Additionally, I've disabled in HID_0 some features (SGE = 0, SPD = 1, BTIC =
0, BHT = 0) during processor setup but it didn't help.
Running system has HID_0 as 0x8090c200
Does anyone have any idea what the problem may be? Thanks in advance for any
suggestions.
Marcin
^ permalink raw reply
* Re: CONFIG_DUMMY_CONSOLE question
From: alebas @ 2004-12-14 13:04 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-embedded
In-Reply-To: <20041213223841.GW18825@smtp.west.cox.net>
Tom Rini <trini@kernel.crashing.org> wrote:
> It's not a "dummy" VGA console, it's a "dummy" console. IIRC, this is
> selected with CONFIG_VT (or is it CONFIG_VT_CONSOLE?). IIRC, the real
> problem is that when you have dummy console, it steals the console even
> if you would have had console on some sort of serial port.
>
> The bottom line is that if you don't have some sort of video device,
> just disable CONFIG_VT.
>
Thanks. Finally your clue guided me to the problem. All those configs
(CONFIG_VT, CONFIG_VT_CONSOLE, CONFIG_DUMMY_CONSOLE, etc) defaults to Y
when CONFIG_EMBEDDED is not set. I was working with this option unset
(accidentally), so this was the problem.
Alex
P.S. CONFIG_DUMMY_CONSOLE is selected only if CONFIG_VGA_CONSOLE is
not set. That's why I had called it "dummy vga console". sorry about
the confusion.
^ permalink raw reply
* Re: [BUG?] [PPC/403/IBM] compile error 2.6.9 and earlier
From: Gerhard Jaeger @ 2004-12-14 8:31 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Nico Schottelius
In-Reply-To: <20041213213743.GA2487@schottelius.org>
Hi,
On Monday 13 December 2004 22:37, Nico Schottelius wrote:
> [repost: posted on linux-kernel before / hit the wrong list]
>
> Hello!
>
> I didn't find linux-ppc list on vger, so I hope this list is correct:
>
> When trying to compile a kernel for my ibm thinclient, which has a
> 403 PPC processor, I get the attached compile error.
>
> The error exists since 2.6.X, but the times before I tried to cross-compile,
> this time I tried to built the kernel from my 'new' g3-ibook, which
> failed again (so this is not a cross-compile error).
>
> Thanks for any hints,
>
> Nico
>
> P.S.: See http://marc.theaimsgroup.com/?l=linux-kernel&m=110293175523284&w=2
> for one 'possible answer' to my question. If that's true, is anyone
> out there who wants me to guide to fix it? I'd really love to let the
> IBM thinclients live with Linux.
when having a closer look at the ppc4xx_pic.c you might find out, that there
are two "sections" one for CONFIG_403 and another for the other 4xx parts.
I'm not familiar with the 403 ones, but I think you should concentrate your work
on the config options there. Selecting "OAK" sets CONFIG_403GCX but not CONFIG_403,
correct me if I'm wrong, but regarding the IRQ stuff they should be more or less
the same chips...
After fixing that, you also have to fix oak.c, as this is also somewhat broken, but
should be no big deal.
Hope this helps a bit.
Gerhard
--
Gerhard Jaeger <gjaeger@sysgo.com>
SYSGO AG Embedded and Real-Time Software
www.sysgo.com | www.elinos.com | www.osek.de | www.imerva.com
^ permalink raw reply
* state of 8xx
From: Kalle Pokki @ 2004-12-14 7:04 UTC (permalink / raw)
To: linuxppc-embedded
Hi,
I have tried to compile Linux 2.6 for my custom 8xx board, but the
support for 8xx seems to be broken at the moment. Searching the lists
indicates there was at least some problem with memory management a
couple of months ago. Is anyone looking into this, or do you have any
idea when 8xx could be working again?
^ 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