* Re: PowerPC: Sleeping function called from invalid context at emulate_instruction()
From: Paul Mackerras @ 2006-02-23 22:57 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev list, Linux Kernel, Michael Buesch
In-Reply-To: <7A04DCF5-C5CF-46E2-A133-A7743BD83B17@kernel.crashing.org>
Kumar Gala writes:
> Last time this was brought up we left it wondering why you had made
> program_check_exception() run with interrupts disabled. Any further
> ideas on that one?
I think it was so that if we are entering the kernel debugger, we do
so on the same cpu that the exception was generated on. This should
fix it.
Paul.
diff --git a/arch/powerpc/kernel/traps.c b/arch/powerpc/kernel/traps.c
index 7509aa6..98660ae 100644
--- a/arch/powerpc/kernel/traps.c
+++ b/arch/powerpc/kernel/traps.c
@@ -814,6 +814,8 @@ void __kprobes program_check_exception(s
return;
}
+ local_irq_enable();
+
/* Try to emulate it if we should. */
if (reason & (REASON_ILLEGAL | REASON_PRIVILEGED)) {
switch (emulate_instruction(regs)) {
^ permalink raw reply related
* Looping SPIMISO and SPIMOSI pins
From: dibacco @ 2006-02-23 21:54 UTC (permalink / raw)
To: linuxppc-embedded
What could happen if I loop SPIMISO and SPIMOSI on my board expansion con=
nector? I think I should receive the messages I send on the SPI bus. SPI =
is
full duplex?
Best regards,
Antonio.
^ permalink raw reply
* Fix for CFI Flash Driver bug in 2.4 Kernel
From: Matsen, Dean (WA26) @ 2006-02-23 21:33 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 4070 bytes --]
All,
This patch applies to 2.4.22 from Monta Vista. We started seeing a
kernel panic due to the really SLOOOOW 29LV641MH-120 flash parts.
Interestingly, the same part with 90mS access time (29LV641MH-120) are
about 10 times faster erasing and programming.
Turns out there are two problems in the driver code:
1- the timeout is calculated incorrectly, based on HZ/100, which is zero
on my system 'cuz "HZ" is equal to 100
2- when the timeout occurs, the code erroneously releases a spinlock
twice.
I have not checked to see if there is a similar problem in the 2.6
kernel
Regards,
Dean Matsen
Software Architect
Alerton Honeywell
dean.matsen@honeywell.com
Patch follows:
------------------------------------------------------------------------
----------------------
diff --unified --recursive
ppc-linux-kernel.org/drivers/mtd/chips/cfi_cmdset_0002.c
ppc-linux-kernel/drivers/mtd/chips/cfi_cmdset_0002.c
--- ppc-linux-kernel.org/drivers/mtd/chips/cfi_cmdset_0002.c Sat
Jul 12 01:08:17 2003
+++ ppc-linux-kernel/drivers/mtd/chips/cfi_cmdset_0002.c Thu Feb 23
12:50:34 2006
@@ -10,6 +10,15 @@
*
* $Id: cfi_cmdset_0002.c,v 1.1.1.1 2003/07/12 08:08:17 dean Exp $
*
+ * - 2006/02/23 : Dean Matsen (dean.matsen@honeywell.com) Fixed write
+ * timeout bug: timeout was based on HZ/1000 before (which is equal
to
+ * zero in my system), also the exit path unlocked the spinlock
twice.
+ * Increased timeout from 1mS to 100mS, because new 100K write
flashes
+ * such as 29LV641MH say "TBD" in the data sheet for worst case
programming
+ * time. Problem was detected due to the really slow 29LV641MH-120
part,
+ * which erases and programs 10 times slower than any other flash
we've
+ * ever encountered (including the 29LV641MH-90, which is in the same
+ * 100K write family of parts!).
*/
#include <linux/module.h>
@@ -511,7 +520,7 @@
or tells us why it failed. */
dq6 = CMD(1<<6);
dq5 = CMD(1<<5);
- timeo = jiffies + (HZ/1000); /* setting timeout to 1ms for now */
+ timeo = jiffies + (HZ/10); /* setting timeout to 100ms for now */
oldstatus = cfi_read(map, adr);
status = cfi_read(map, adr);
@@ -532,10 +541,10 @@
}
if( (status & dq6) != (oldstatus & dq6) ) {
- /* The erasing didn't stop?? */
+ /* The writing didn't stop?? */
if( (status & dq5) == dq5 ) {
/* When DQ5 raises, we must check once again
- if DQ6 is toggling. If not, the erase has been
+ if DQ6 is toggling. If not, the write has been
completed OK. If not, reset chip. */
oldstatus = cfi_read(map, adr);
status = cfi_read(map, adr);
@@ -543,7 +552,7 @@
if ( (oldstatus & 0x00FF) == (status & 0x00FF) ) {
printk(KERN_WARNING "Warning: DQ5 raised while
program operation was in progress, however operation completed OK\n" );
} else {
- /* DQ5 is active so we can do a reset and stop
the erase */
+ /* DQ5 is active so we can do a reset and stop
the write */
cfi_write(map, CMD(0xF0), chip->start);
printk(KERN_WARNING "Internal flash device
timeout occurred or write operation was performed while flash was
programming.\n" );
}
@@ -554,7 +563,7 @@
wake_up(&chip->wq);
cfi_spin_unlock(chip->mutex);
DISABLE_VPP(map);
- ret = -EIO;
+ return -EIO;
}
}
------------------------------------------------------------------------
-----------------------------------
[-- Attachment #2: Type: text/html, Size: 18299 bytes --]
^ permalink raw reply
* Re: Gianfar is slower than fcc_enet on MPC8541 ???
From: Andy Fleming @ 2006-02-23 20:08 UTC (permalink / raw)
To: Laurent Lagrange; +Cc: linuxppc-embedded
In-Reply-To: <000001c6389e$980f0ff0$5201a8c0@GEG2400>
On Feb 23, 2006, at 11:28, Laurent Lagrange wrote:
> Hi everybody,
>
> I tried the below Andy's idea. It works fine.
> It is my TCP clients which now slow the traffic.
>
> But I don't know why the default timeouts are so high.
> If the traffic is high, the timeout does not fire.
> If the traffic is low, the timeout seems too long (???).
The answer there is simple: stupidity! :) I just didn't carefully
test the values for performance when I chose them. I probably also
did the math wrong, because I was more concerned about seeing if it
worked at all. It's also possible it got set that way to see a
measurable difference to prove it was working, and then got left as
the default. Rest assured, there was not a deliberate reason. We
submitted a patch once this performance issue was discovered.
^ permalink raw reply
* RE: Gianfar is slower than fcc_enet on MPC8541 ???
From: Laurent Lagrange @ 2006-02-23 17:28 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <000701c6389b$49e30960$5201a8c0@GEG2400>
Hi everybody,
Sorry to reply so late. I was out of office.
I tried the below Andy's idea. It works fine.
It is my TCP clients which now slow the traffic.
But I don't know why the default timeouts are so high.
If the traffic is high, the timeout does not fire.
If the traffic is low, the timeout seems too long (???).
Thanks all for your ideas and works.
Best regards
Laurent
> De la part de Andy Fleming
> Envoye : mar. 14 fevrier 2006 18:37
> A : Laurent Lagrange
> Cc : linuxppc-embedded@ozlabs.org
> Objet : Re: Gianfar is slower than fcc_enet on MPC8541 ???
>
> My guess is that you are measuring latency. By default, interrupt
> coalescing is on, and used to be set to very poor default
> values. In drivers/net/gianfar.h, change the defaults to look like this:
>
> #define DEFAULT_TX_COALESCE 1
> #define DEFAULT_TXCOUNT 16
> #define DEFAULT_TXTIME 4
>
> #define DEFAULT_RX_COALESCE 1
> #define DEFAULT_RXCOUNT 16
> #define DEFAULT_RXTIME 4
>
> The problem was that the timeout was quite long, so a small number of
> packets would have to wait a whole millisecond (or more!) to get
> processed. While it wouldn't affect bandwidth tests, which send many
> packets, it would affect a simple test like ping.
>
> If you don't feel like recompiling the kernel, you can use ethtool to
> change the timeout values.
^ permalink raw reply
* Re: yaboot 1.3.14 release candidate 1
From: David Woodhouse @ 2006-02-23 17:22 UTC (permalink / raw)
To: Paul Nasrat; +Cc: linuxppc-dev list
In-Reply-To: <1140021795.2824.12.camel@enki.eridu>
On Wed, 2006-02-15 at 11:43 -0500, Paul Nasrat wrote:
> No, thanks for passing this on to me it looks sane, I'll test a little
> then probably commit. Currently I've been doing this on macs with an
> ofboot script checking 64-bit, but this is probably better.
... and will work on CHRP for 32 vs. 64, which we can't do in
bootinfo.txt because of problems with the IBM firmware.
--
dwmw2
^ permalink raw reply
* Re: yaboot 1.3.14 release candidate 1
From: David Woodhouse @ 2006-02-23 17:21 UTC (permalink / raw)
To: Paul Nasrat; +Cc: linuxppc-dev list
In-Reply-To: <1139538538.3638.14.camel@enki.eridu>
On Thu, 2006-02-09 at 21:28 -0500, Paul Nasrat wrote:
> Amiga partition support (Sven Luther),
Does this still have an off-by-one bug in the partition numbering which
coincidentally matches a similar bug in the Pegasos OpenFirmware? If so,
we should fix it before any proper release.
--
dwmw2
^ permalink raw reply
* Re: boot failure on lite5200b board
From: Marty @ GMail @ 2006-02-23 17:10 UTC (permalink / raw)
To: tnt, lijianggan, linuxppc-embedded
PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQo+IEZyb206IFN5bHZhaW4gTXVuYXV0IFttYWls
dG86dG50QDI0NnROdC5jb21dCj4gU2VudDogVGh1IDIvMjMvMjAwNiAxNTozOAo+IFRvOiAjTEkg
SklBTkdHQU4jCj4gQ2M6IGxpbnV4cHBjLWVtYmVkZGVkQG96bGFicy5vcmcKPiBTdWJqZWN0OiBS
ZTogYm9vdCBmYWlsdXJlIG9uIGxpdGU1MjAwYiBib2FyZAo+Cj4gI0xJIEpJQU5HR0FOIyB3cm90
ZToKPiA+IEhlbGxvIGFsbCwKPiA+Cj4gPiBGb3IgbXkgZW5kLW9mLXN0dWR5IHByb2plY3QsIEkg
YW0gd29ya2luZyBvbiBhbiBlbWJlZGRlZCBzeXN0ZW0gd2l0aAo+ID4gcmVmZXJlbmNlIG9mIGZy
ZWVzY2FsZSdzIGxpdGU1MjAwYiByZWZlcmVuY2UgYm9hcmQuIEkgd2FzIHRyeWluZyB0byBib290
Cj4gPiBMaW51eCAyLjYuMTUgb24gdGhlIGJvYXJkICh3aXRoIHRoZSBmZWMgYW5kIGJlc3Rjb21t
IGNvcnJlY3RlZCkuIGhvd2V2ZXIKPiA+IHRoZSBib290aW5nIHdhcyBzdHVjayBhdCB0aGUgZm9s
bG93aW5nIHN0YWdlOgo+Cj4gSW4gYWRkaXRpb24gdG8gd2hhdCBoYXMgYWxyZWFkeSBiZWVuIHNh
aWQgKHVzZSBhIGhpZ2hlciBhZGRyZXNzIGZvciB0aGUKPiBpbWFnZSBhbmQgZG9uJ3QgZm9yZ2V0
IGNvbnNvbGU9dHR5UFNDMCBpbiBrZXJuZWwgY29tbWFuZCBsaW5lKSwgbWFrZQo+IHN1cmUgeW91
IHVzZSB0aGUga2VybmVsIGZyb20gbXkgZ2l0IHRyZWUsIGl0IGNvbnRhaW5zIGEgZmV3IHBhdGNo
ZXMgZnJvbQo+IEpvaG4gUmlnYnkgdG8gYWRkIHN1cHBvcnQgZm9yIHRoZSBsaXRlNTIwMGIuCj4K
PiBQbGVhc2UgcmVwb3J0IGlmIGl0IHdvcmtzLCBJJ3ZlIG5vdCBiZWVuIGFibGUgdG8gdGVzdCB0
aG9zZSBteXNlbGYgc2luY2UKPiBpJ20gc3RpbGwgb24gbGl0ZTUyMDAuCj4KPgo+IAlTeWx2YWlu
CgoKClRoZSBwcm9ibGVtIG1pZ2h0IGJlIGluIHRoZSBVLUJvb3QgZW52aXJvbm1lbnQgdmFyaWFi
bGVzClNlZSBtaW5lIGJlbG93LgoKTk9URToKdGhhdCB0aGUgYm9vdF9jbWQgZXhlY3V0ZXMgdGhl
IGNvbW1hbmQgcnVuIG5ldF9uZnMgYW5kCnRoYXQgdGhlIG5ldF9uZnMgdGZ0cCdzIHRoZSBrZXJu
ZWwsIHRoZW4gZXhlY3V0cyB0aGUgcnVuIHNldGNvbnNvbGUKbmZzYXJncyBhZGRpcCBiZWZvcmUg
aXQgYm9vdHMgdGhlIGtlcm5lbAoKSG9wZSB0aGF0IGhlbHBzCgpNYXJ0aW4KCgoKClUtQm9vdCAx
LjEuNCAoRmViIDIyIDIwMDYgLSAxNDo0MjowNSkKCkNQVTogICBNUEM1MjAwIHYyLjIgYXQgNDYy
IE1IegogICAgICAgQnVzIDEzMiBNSHosIElQQiAxMzIgTUh6LCBQQ0kgMzMgTUh6CkJvYXJkOiBG
cmVlc2NhbGUgTVBDNTIwMCAoTGl0ZTUyMDBCKQpJMkM6ICAgODUga0h6LCByZWFkeQpEUkFNOiAg
MjU2IE1CCkZMQVNIOiAzMiBNQgpQQ0k6ICAgQnVzIERldiBWZW5JZCBEZXZJZCBDbGFzcyBJbnQK
ICAgICAgICAwMCAgMWEgIDEwNTcgIDU4MDkgIDA2ODAgIDAwCkluOiAgICBzZXJpYWwKT3V0OiAg
IHNlcmlhbApFcnI6ICAgc2VyaWFsCk5ldDogICBGRUMgRVRIRVJORVQKSURFOiAgIEJ1cyAwOiBP
SwogIERldmljZSAwOiBub3QgYXZhaWxhYmxlCiAgRGV2aWNlIDE6IG5vdCBhdmFpbGFibGUKClR5
cGUgInJ1biBmbGFzaF9uZnMiIHRvIG1vdW50IHJvb3QgZmlsZXN5c3RlbSBvdmVyIE5GUwoKSGl0
IGFueSBrZXkgdG8gc3RvcCBhdXRvYm9vdDogIDAKPT4gcHJpbnRlbnYKYm9vdGNtZD1ydW4gbmV0
X25mcwpib290ZGVsYXk9NQpiYXVkcmF0ZT0xMTUyMDAKcHJlYm9vdD1lY2hvO2VjaG8gVHlwZSAi
cnVuIGZsYXNoX25mcyIgdG8gbW91bnQgcm9vdCBmaWxlc3lzdGVtIG92ZXIgTkZTO2VjaG8KYmF1
ZHJhdGU9MTE1MjAwCm5ldGRldj1ldGgwCmFkZGlwPXNldGVudiBib290YXJncyAkKGJvb3Rhcmdz
KQppcD0kKGlwYWRkcik6JChzZXJ2ZXJpcCk6JChnYXRld2F5aXApOiQobmV0bWFzayk6JChob3N0
bmFtZSk6JChuZXRkZXYpOm9mZgpwYW5pNWV0aGFjdD1GRUMgRVRIRVJORVQKc2VydmVyaXA9MTky
LjE2OC4xMDAuMzMKZ2F0ZXdheWlwPTE5Mi4xNjguMTAwLjEKbmV0bWFzaz0yNTUuMjU1LjI1NS4w
CnJvb3RwYXRoPS9vcHQvZWxkay9wcGNfNnh4CmlwYWRkcj0xOTIuMTY4LjEwMC4yOQpyYW1hcmdz
PXNldGVudiBib290YXJncyByb290PS9kZXYvcmFtIHJ3Cm5ldF9uZnM9dGZ0cCAyMDAwMDAgJChi
b290ZmlsZSk7cnVuIHNldGNvbnNvbGUgbmZzYXJncyBhZGRpcDtib290bQpzZXRjb25zb2xlPXNl
dGVudiBib290YXJncyAkKGNvbnNvbGUpCm5mc2FyZ3M9c2V0ZW52IGJvb3RhcmdzICQoYm9vdGFy
Z3MpIHJvb3Q9L2Rldi9uZnMgcncKbmZzcm9vdD0kKHNlcnZlcmlwKTokKHJvb3QpYm9vdGZpbGU9
TVBDNTIwMC91SW1hZ2UKaG9zdG5hbWU9d2VlZHdoYWNrZXIKYm9vdGRlbGF5PTUKY29uc29sZT1j
b25zb2xlPXR0eVBTQzAsMTE1MjAwbjggY29uc29sZT10dHkxCmZsYXNoX25mcz1ydW4gc2V0Y29u
c29sZSBuZnNhcmdzIGFkZGlwO2Jvb3RtCmF1dG9sb2FkPW5vCmV0aGFkZHI9MDA6MDQ6OWY6MDA6
Mjc6MzUKc3RkaW49c2VyaWFsCnN0ZG91dD1zZXJpYWwKc3RkZXJyPXNlcmlhbAoKRW52aXJvbm1l
bnQgc2l6ZTogODY4LzY1NTMyIGJ5dGVzCj0+IGJvb3QKVXNpbmcgRkVDIEVUSEVSTkVUIGRldmlj
ZQpURlRQIGZyb20gc2VydmVyIDE5Mi4xNjguMTAwLjMzOyBvdXIgSVAgYWRkcmVzcyBpcyAxOTIu
MTY4LjEwMC4yOQpGaWxlbmFtZSAnTVBDNTIwMC91SW1hZ2UnLgpMb2FkIGFkZHJlc3M6IDB4MjAw
MDAwCkxvYWRpbmc6ICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjCiAgICAgICAgICMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjCiAgICAgICAgICMjIyMjIyMj
IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIwpk
b25lCkJ5dGVzIHRyYW5zZmVycmVkID0gOTg2NDcyIChmMGQ2OCBoZXgpCiMjIEJvb3RpbmcgaW1h
Z2UgYXQgMDAyMDAwMDAgLi4uCiAgIEltYWdlIE5hbWU6ICAgTGludXgtMi42LjE2LXJjMS1nYWY0
Zjc1ZmQtZGlydHkKICAgSW1hZ2UgVHlwZTogICBQb3dlclBDIExpbnV4IEtlcm5lbCBJbWFnZSAo
Z3ppcCBjb21wcmVzc2VkKQogICBEYXRhIFNpemU6ICAgIDk4NjQwOCBCeXRlcyA9IDk2My4zIGtC
CiAgIExvYWQgQWRkcmVzczogMDAwMDAwMDAKICAgRW50cnkgUG9pbnQ6ICAwMDAwMDAwMAogICBW
ZXJpZnlpbmcgQ2hlY2tzdW0gLi4uIE9LCiAgIFVuY29tcHJlc3NpbmcgS2VybmVsIEltYWdlIC4u
LiBPSwppZCBtYWNoKCk6IGRvbmUKTU1VOmVudGVyCk1NVTpodyBpbml0Ck1NVTptYXBpbgpNTVU6
c2V0aW8KTU1VOmV4aXQKc2V0dXBfYXJjaDogZW50ZXIKc2V0dXBfYXJjaDogYm9vdG1lbQphcmNo
OiBleGl0CkxpbnV4IHZlcnNpb24gMi42LjE2LXJjMS1nYWY0Zjc1ZmQtZGlydHkgKHdlZGVwb2hs
QHVidW50dSkgKGdjYwp2ZXJzaW9uIDQuMC4wICg2QnVpbHQgMSB6b25lbGlzdHMKS2VybmVsIGNv
bW1hbmQgbGluZTogY29uc29sZT10dHlQU0MwLDExNTIwMG44IGNvbnNvbGU9dHR5MQpyb290PS9k
ZXYvbmZzIHJ3IG5mc3hQSUQgaGFzaCB0YWJsZSBlbnRyaWVzOiAyMDQ4IChvcmRlcjogMTEsIDMy
NzY4CmJ5dGVzKQpDb25zb2xlOiBjb2xvdXIgZHVtbXkgZGV2aWNlIDgweDI1CkRlbnRyeSBjYWNo
ZSBoYXNoIHRhYmxlIGVudHJpZXM6IDY1NTM2IChvcmRlcjogNiwgMjYyMTQ0IGJ5dGVzKQpJbm9k
ZS1jYWNoZSBoYXNoIHRhYmxlIGVudHJpZXM6IDMyNzY4IChvcmRlcjogNSwgMTMxMDcyIGJ5dGVz
KQpNZW1vcnk6IDI1NzUzNmsgYXZhaWxhYmxlICgxNTA0ayBrZXJuZWwgY29kZSwgNDk2ayBkYXRh
LCA5NmsgaW5pdCwgMGsgaGlnaG1lbSkKTW91bnQtY2FjaGUgaGFzaCB0YWJsZSBlbnRyaWVzOiA1
MTIKTkVUOiBSZWdpc3RlcmVkIHByb3RvY29sIGZhbWlseSAxNgoKUENJOiBQcm9iaW5nIFBDSSBo
YXJkd2FyZQppbyBzY2hlZHVsZXIgbm9vcCByZWdpc3RlcmVkCmlvIHNjaGVkdWxlciBhbnRpY2lw
YXRvcnkgcmVnaXN0ZXJlZCAoZGVmYXVsdCkKaW8gc2NoZWR1bGVyIGRlYWRsaW5lIHJlZ2lzdGVy
ZWQKaW8gc2NoZWR1bGVyIGNmcSByZWdpc3RlcmVkClNlcmlhbDogTVBDNTJ4eCBQU0MgZHJpdmVy
CnR0eVBTQzAgYXQgTU1JTyAweGYwMDAyMDAwIChpcnEgPSA0MCkgaXMgYSBNUEM1Mnh4IFBTQwpS
QU1ESVNLIGRyaXZlciBpbml0aWFsaXplZDogMTYgUkFNIGRpc2tzIG9mIDQwOTZLIHNpemUgMTAy
NCBibG9ja3NpemUKbWljZTogUFMvMiBtb3VzZSBkZXZpY2UgY29tbW9uIGZvciBhbGwgbWljZQpO
RVQ6IFJlZ2lzdGVyZWQgcHJvdG9jb2wgZmFtaWx5IDIK
^ permalink raw reply
* Re: [PATCH] ppc32: handle Book E debug exceptions on kernel stack
From: Dale Farnsworth @ 2006-02-23 14:23 UTC (permalink / raw)
To: Josh Boyer; +Cc: David Gibson, Paul Mackerras, linuxppc-embedded
In-Reply-To: <1140692043.2892.1.camel@yoda.jdub.homelinux.org>
On Thu, Feb 23, 2006 at 10:54:02AM +0000, Josh Boyer wrote:
> On Wed, 2006-02-22 at 22:19 -0600, Kumar Gala wrote:
> > On Tue, 14 Feb 2006, Dale Farnsworth wrote:
> >
> > > From: Dale Farnsworth <dale@farnsworth.org>
> > >
> > > On PPC Book E processsors, we currently handle debug
> > > exceptions on the critical exception stack (debug stack
> > > for E200). This causes problems with the kgdb single
> > > step handler, which calls smp_processor_id() and spin_lock(),
> > > which reference current_thread_info(), which only works when
> > > we are on the kernel stack.
> > >
> > > We address this by switching to the kernel stack early while
> > > handling debug exceptions. Note that the entry values of r10
> > > and r11 are still saved on the critical exception (or debug) stack.
> > >
> > > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> >
> > Paul,
> >
> > We were wondering if you or David remember why a specific critical
> > exception stack was added in the 40x port from 2.4 to 2.6?
>
> I think Matt did that. And if I remember correctly, it was to avoid
> corruption if you were in the middle of handling a normal interrupt and
> a critical interrupt came in.
Thanks Josh, Matt was one of the "we" who were wondering. If indeed
you are remembering correctly, then I think we're safe to use the
normal kernel stack rather than the critical exception stack.
-Dale
^ permalink raw reply
* please pull powerpc-merge.git
From: Paul Mackerras @ 2006-02-23 12:05 UTC (permalink / raw)
To: torvalds; +Cc: linuxppc-dev
Linus,
Please do a pull from
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc-merge.git
There are 15 commits there: fixes for various bugs and a performance
regression, plus a defconfig update.
Thanks,
Paul.
Alan Curry:
powerpc: fix altivec_unavailable_exception Oopses
Anton Blanchard:
powerpc: Fix runlatch performance issues
powerpc64: remove broken/bitrotted HMT support
Haren Myneni:
powerpc: Trivial fix to set the proper timeout value for kdump
Kelly Daly:
powerpc: disable OProfile for iSeries
Kumar Gala:
powerpc: Enable coherency for all pages on 83xx to fix PCI data corruption
Michael Ellerman:
powerpc: Initialise hvlpevent_queue.lock correctly
powerpc: Only calculate htab_size in one place for kexec
Michal Ostrowski:
Fix race condition in hvc console.
Olaf Hering:
powerpc: change compat shmget size arg to signed
ppc: fix adb breakage in xmon
Olof Johansson:
powerpc: Update {g5,pseries,ppc64}_defconfig
R Sharada:
powerpc64: fix spinlock recursion in native_hpte_clear
Segher Boessenkool:
powerpc: Fix some MPIC + HT APIC buglets
powerpc: Don't re-assign PCI resources on Maple
arch/powerpc/configs/g5_defconfig | 174 ++++++++++--------------
arch/powerpc/configs/ppc64_defconfig | 173 ++++++++++--------------
arch/powerpc/configs/pseries_defconfig | 127 ++++++-----------
arch/powerpc/kernel/crash.c | 4 -
arch/powerpc/kernel/head_32.S | 1
arch/powerpc/kernel/head_64.S | 109 +--------------
arch/powerpc/kernel/machine_kexec_64.c | 10 -
arch/powerpc/kernel/process.c | 32 ++++
arch/powerpc/kernel/prom_init.c | 38 -----
arch/powerpc/kernel/sys_ppc32.c | 2
arch/powerpc/mm/hash_native_64.c | 7 +
arch/powerpc/mm/hash_utils_64.c | 3
arch/powerpc/oprofile/Kconfig | 1
arch/powerpc/platforms/iseries/lpevents.c | 2
arch/powerpc/platforms/iseries/setup.c | 1
arch/powerpc/platforms/maple/pci.c | 4 -
arch/powerpc/platforms/pseries/Kconfig | 7 -
arch/powerpc/sysdev/mpic.c | 9 +
arch/ppc/kernel/head.S | 1
arch/ppc/xmon/adb.c | 212 -----------------------------
arch/ppc/xmon/start.c | 169 -----------------------
arch/ppc/xmon/xmon.c | 108 ---------------
drivers/char/hvc_console.c | 8 +
include/asm-powerpc/cputable.h | 9 +
include/asm-powerpc/mmu.h | 1
include/asm-powerpc/reg.h | 33 -----
include/asm-powerpc/thread_info.h | 4 -
27 files changed, 275 insertions(+), 974 deletions(-)
delete mode 100644 arch/ppc/xmon/adb.c
^ permalink raw reply
* Re: [PATCH] ppc32: handle Book E debug exceptions on kernel stack
From: Josh Boyer @ 2006-02-23 10:54 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded, Paul Mackerras, David Gibson
In-Reply-To: <Pine.LNX.4.44.0602222217220.28948-100000@gate.crashing.org>
On Wed, 2006-02-22 at 22:19 -0600, Kumar Gala wrote:
> On Tue, 14 Feb 2006, Dale Farnsworth wrote:
>
> > From: Dale Farnsworth <dale@farnsworth.org>
> >
> > On PPC Book E processsors, we currently handle debug
> > exceptions on the critical exception stack (debug stack
> > for E200). This causes problems with the kgdb single
> > step handler, which calls smp_processor_id() and spin_lock(),
> > which reference current_thread_info(), which only works when
> > we are on the kernel stack.
> >
> > We address this by switching to the kernel stack early while
> > handling debug exceptions. Note that the entry values of r10
> > and r11 are still saved on the critical exception (or debug) stack.
> >
> > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> >
>
> Paul,
>
> We were wondering if you or David remember why a specific critical
> exception stack was added in the 40x port from 2.4 to 2.6?
I think Matt did that. And if I remember correctly, it was to avoid
corruption if you were in the middle of handling a normal interrupt and
a critical interrupt came in.
josh
^ permalink raw reply
* RE: boot failure on lite5200b board
From: tnt @ 2006-02-23 10:08 UTC (permalink / raw)
To: #LI JIANGGAN#; +Cc: #WONG CHEE KHIN#, linuxppc-embedded
In-Reply-To: <84A109BF918D934CB46ACF33BCE187C002D54D7A@mail02.student.main.ntu.edu. sg>
> Thank you José María and Andrey for your advices, however the problem
> remains. I've tried setting the console (though I remember that our
> previous lite5200 board was working fine on kernel 2.4 without setting the
> console); meantime,
In 2.4 you didn't need to set the console. On 2.6 we don't use the
standard ttyS0 naming for the PSC because it causes conflict when another
serial card was inserted (in a pcmcia slot for ex.).
> I've set the booting image to 0x500000; I have also
> tried using the kernel image come together with the BSP, it's always the
> same error.
> Load address: 0x100000
In the log you sent, you still use a low load address ...
> Sylvain, I've actually using your kernel source, the compiled image is
> around 700k (compared to the 1.4M image from the BSP), but it doesn't
> solve the problem. So I presume that the problem is lying somewhere else.
Do you have a hardware debugger to see where it's stopping ?
I'm at work right now, but I'll have a look when I get home.
Sylvain
^ permalink raw reply
* RE: boot failure on lite5200b board
From: #LI JIANGGAN# @ 2006-02-23 10:13 UTC (permalink / raw)
To: Sylvain Munaut, linuxppc-embedded; +Cc: #WONG CHEE KHIN#
In-Reply-To: <43FD6669.9090405@246tNt.com>
[-- Attachment #1: Type: text/plain, Size: 3026 bytes --]
Thank you José María and Andrey for your advices, however the problem remains. I've tried setting the console (though I remember that our previous lite5200 board was working fine on kernel 2.4 without setting the console); meantime, I've set the booting image to 0x500000; I have also tried using the kernel image come together with the BSP, it's always the same error.
Sylvain, I've actually using your kernel source, the compiled image is around 700k (compared to the 1.4M image from the BSP), but it doesn't solve the problem. So I presume that the problem is lying somewhere else.
A SNAPSHOT OF THE BOOTING MESSAGES:
U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
CPU: MPC5200 v2.2 at 462 MHz
Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
Board: Freescale MPC5200 (Lite5200B)
I2C: 85 kHz, ready
DRAM: 256 MB
FLASH: 32 MB
PCI: Bus Dev VenId DevId Class Int
00 1a 1057 5809 0680 00
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET
IDE: Bus 0: OK
Device 0: not available
Device 1: not available
Autostarting. Press any key to abort..
Hit any key to stop autoboot: 0
Using FEC ETHERNET device
TFTP from server 10.190.3.103; our IP address is 10.190.3.144
Filename 'MPC5200/uImage'.
Load address: 0x100000
Loading: #################################################################
################################################################
done
Bytes transferred = 658114 (a0ac2 hex)
## Booting image at 00100000 ...
Image Name: Linux-2.6.16-rc1
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 658050 Bytes = 642.6 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
arch: exit
I am wondering whether it's a kernel problem or more likely to be a problem lying with the U-boot. It seems to hang when executing setup_arch() function, or maybe there is sth else behind the wall?
Regards,
Jianggan LI
-----Original Message-----
From: Sylvain Munaut [mailto:tnt@246tNt.com]
Sent: Thu 2/23/2006 15:38
To: #LI JIANGGAN#
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: boot failure on lite5200b board
#LI JIANGGAN# wrote:
> Hello all,
>
> For my end-of-study project, I am working on an embedded system with
> reference of freescale's lite5200b reference board. I was trying to boot
> Linux 2.6.15 on the board (with the fec and bestcomm corrected). however
> the booting was stuck at the following stage:
In addition to what has already been said (use a higher address for the
image and don't forget console=ttyPSC0 in kernel command line), make
sure you use the kernel from my git tree, it contains a few patches from
John Rigby to add support for the lite5200b.
Please report if it works, I've not been able to test those myself since
i'm still on lite5200.
Sylvain
[-- Attachment #2: Type: text/html, Size: 4207 bytes --]
^ permalink raw reply
* Re: boot failure on lite5200b board
From: Sylvain Munaut @ 2006-02-23 7:38 UTC (permalink / raw)
To: #LI JIANGGAN#; +Cc: linuxppc-embedded
In-Reply-To: <84A109BF918D934CB46ACF33BCE187C002D54D71@mail02.student.main.ntu.edu.sg>
#LI JIANGGAN# wrote:
> Hello all,
>
> For my end-of-study project, I am working on an embedded system with
> reference of freescale's lite5200b reference board. I was trying to boot
> Linux 2.6.15 on the board (with the fec and bestcomm corrected). however
> the booting was stuck at the following stage:
In addition to what has already been said (use a higher address for the
image and don't forget console=ttyPSC0 in kernel command line), make
sure you use the kernel from my git tree, it contains a few patches from
John Rigby to add support for the lite5200b.
Please report if it works, I've not been able to test those myself since
i'm still on lite5200.
Sylvain
^ permalink raw reply
* Re: PowerPC: Sleeping function called from invalid context at emulate_instruction()
From: Kumar Gala @ 2006-02-23 4:22 UTC (permalink / raw)
To: Paul Mackerras; +Cc: linuxppc-dev list, Linux Kernel, Michael Buesch
In-Reply-To: <200602222129.31700.mbuesch@freenet.de>
On Feb 22, 2006, at 2:29 PM, Michael Buesch wrote:
> Hi,
>
> On a powerPC 32bit, I got the following debugging assertion failure:
>
> [ 733.209827] Debug: sleeping function called from invalid context
> at arch/powerpc/kernel/traps.c:697
> [ 733.210682] in_atomic():0, irqs_disabled():1
> [ 733.211347] Call Trace:
> [ 733.211969] [D6023EB0] [C0007F84] show_stack+0x58/0x174
> (unreliable)
> [ 733.212765] [D6023EE0] [C0022C34] __might_sleep+0xbc/0xd0
> [ 733.213523] [D6023EF0] [C000D158] program_check_exception
> +0x1d8/0x4fc
> [ 733.214309] [D6023F40] [C000E744] ret_from_except_full+0x0/0x4c
> [ 733.215076] --- Exception: 700 at 0x102a7100
> [ 733.215785] LR = 0xdb9ef04
>
> It is caused by the line
> if (get_user(instword, (u32 __user *)(regs->nip)))
> in arch/powerpc/kernel/traps.c:emulate_instruction()
>
> I am not sure, if this is an indication for a bug, or just false
> alarm.
> In case of false alarm, the debugging message should be made quiet
> somehow, though.
Paul,
Last time this was brought up we left it wondering why you had made
program_check_exception() run with interrupts disabled. Any further
ideas on that one?
- kumar
^ permalink raw reply
* Re: [PATCH] ppc32: handle Book E debug exceptions on kernel stack
From: Kumar Gala @ 2006-02-23 4:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: David Gibson, linuxppc-embedded
In-Reply-To: <20060214190700.GB17822@xyzzy.farnsworth.org>
On Tue, 14 Feb 2006, Dale Farnsworth wrote:
> From: Dale Farnsworth <dale@farnsworth.org>
>
> On PPC Book E processsors, we currently handle debug
> exceptions on the critical exception stack (debug stack
> for E200). This causes problems with the kgdb single
> step handler, which calls smp_processor_id() and spin_lock(),
> which reference current_thread_info(), which only works when
> we are on the kernel stack.
>
> We address this by switching to the kernel stack early while
> handling debug exceptions. Note that the entry values of r10
> and r11 are still saved on the critical exception (or debug) stack.
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
>
Paul,
We were wondering if you or David remember why a specific critical
exception stack was added in the 40x port from 2.4 to 2.6?
- kumar
> ---
>
> This is low level code and needs careful review.
> I've only tested it on mpc8548cds.
>
> I didn't find the corresponding code in arch/powerpc,
> so I assume Book E support hasn't been merged yet.
>
> arch/ppc/kernel/head_booke.h | 15 +++++++++------
> 1 file changed, 9 insertions(+), 6 deletions(-)
>
> diff --git a/arch/ppc/kernel/head_booke.h b/arch/ppc/kernel/head_booke.h
> index f3d274c..a5eec51 100644
> --- a/arch/ppc/kernel/head_booke.h
> +++ b/arch/ppc/kernel/head_booke.h
> @@ -92,7 +92,8 @@
> * registers as the normal prolog above. Instead we use a portion of the
> * critical/machine check exception stack at low physical addresses.
> */
> -#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, exc_level_srr1) \
> +#define EXC_LEVEL_EXCEPTION_PROLOG(exc_level, exc_level_srr0, \
> + exc_level_srr1, kernel_sp_reg) \
> mtspr exc_level##_SPRG,r8; \
> BOOKE_LOAD_EXC_LEVEL_STACK(exc_level);/* r8 points to the exc_level stack*/ \
> stw r10,GPR10-INT_FRAME_SIZE(r8); \
> @@ -100,7 +101,7 @@
> mfcr r10; /* save CR in r10 for now */\
> mfspr r11,exc_level_srr1; /* check whether user or kernel */\
> andi. r11,r11,MSR_PR; \
> - mr r11,r8; \
> + mr r11,kernel_sp_reg; \
> mfspr r8,exc_level##_SPRG; \
> beq 1f; \
> /* COMING FROM USER MODE */ \
> @@ -128,11 +129,13 @@
> SAVE_2GPRS(7, r11)
>
> #define CRITICAL_EXCEPTION_PROLOG \
> - EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1)
> + EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1, r8)
> +#define CRITICAL_EXCEPTION_ON_KERNEL_STACK_PROLOG \
> + EXC_LEVEL_EXCEPTION_PROLOG(CRIT, SPRN_CSRR0, SPRN_CSRR1, r1)
> #define DEBUG_EXCEPTION_PROLOG \
> - EXC_LEVEL_EXCEPTION_PROLOG(DEBUG, SPRN_DSRR0, SPRN_DSRR1)
> + EXC_LEVEL_EXCEPTION_PROLOG(DEBUG, SPRN_DSRR0, SPRN_DSRR1, r1)
> #define MCHECK_EXCEPTION_PROLOG \
> - EXC_LEVEL_EXCEPTION_PROLOG(MCHECK, SPRN_MCSRR0, SPRN_MCSRR1)
> + EXC_LEVEL_EXCEPTION_PROLOG(MCHECK, SPRN_MCSRR0, SPRN_MCSRR1, r8)
>
> /*
> * Exception vectors.
> @@ -268,7 +271,7 @@ label:
> #else
> #define DEBUG_EXCEPTION \
> START_EXCEPTION(Debug); \
> - CRITICAL_EXCEPTION_PROLOG; \
> + CRITICAL_EXCEPTION_ON_KERNEL_STACK_PROLOG; \
> \
> /* \
> * If there is a single step or branch-taken exception in an \
>
^ permalink raw reply
* Re: u-boot 1.1.4 using two fecs
From: Stefan Roese @ 2006-02-22 18:01 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <IV3O7I$AE8FCD5B4D0B827DBEFFF524E0D45F85@libero.it>
Hi Antonio,
On Wednesday, 22. February 2006 18:50, dibacco@inwind.it wrote:
> Is it possible in your opinion to use both the fecs on a board in the
> u-boot? I read something saying only one can be the active one.
a) You're on the wrong list. Please ask again on the U-Boot list
b) What hardware (CPU, board, etc) are you referring to? A lot of
Frescale CPU's have FEC's. So please be more specific when asking
on the U-Boot list.
Best regards,
Stefan
^ permalink raw reply
* Re: u-boot 1.1.4 using two fecs
From: Dan Malek @ 2006-02-22 18:01 UTC (permalink / raw)
To: dibacco@inwind.it; +Cc: linuxppc-embedded
In-Reply-To: <IV3O7I$AE8FCD5B4D0B827DBEFFF524E0D45F85@libero.it>
On Feb 22, 2006, at 12:50 PM, dibacco@@inwind..it wrote:
> Is it possible in your opinion to use both the fecs on a board in the
> u-boot?
> I read something saying only one can be the active one.
Yes, it works just fine, and you should be asking such questions
on the u-boot mailing list, not here ........
-- Dan
^ permalink raw reply
* u-boot 1.1.4 using two fecs
From: dibacco @ 2006-02-22 17:50 UTC (permalink / raw)
To: linuxppc-embedded
Is it possible in your opinion to use both the fecs on a board in the u-b=
oot?
I read something saying only one can be the active one.
Best regards,
Antonio.
^ permalink raw reply
* [PATCH] powerpc: Enable coherency for all pages on 83xx to fix PCI data corruption
From: Kumar Gala @ 2006-02-22 15:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, linux-kernel
On the 83xx platform to ensure the PCI inbound memory is handled properly we
have to turn on coherency for all pages in the MMU. Otherwise we see
corruption if inbound "prefetching/streaming" is enabled on the PCI controller.
Signed-off-by: Randy Vinson <rvinson@mvista.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---
(For 2.6.16 if we can get it in)
commit 4b2f4b1585f15d1c30cd2eda6d5f9a2ca7dcf998
tree 7aebf508d10127831cf92fb7ce919230924ad85d
parent 7cfb7344aae902edfd5d51dd5f734cbf2585649c
author Kumar Gala <galak@kernel.crashing.org> Wed, 22 Feb 2006 09:53:34 -0600
committer Kumar Gala <galak@kernel.crashing.org> Wed, 22 Feb 2006 09:53:34 -0600
include/asm-powerpc/cputable.h | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/include/asm-powerpc/cputable.h b/include/asm-powerpc/cputable.h
index 6421054..90d005b 100644
--- a/include/asm-powerpc/cputable.h
+++ b/include/asm-powerpc/cputable.h
@@ -159,9 +159,11 @@ extern void do_cpu_ftr_fixups(unsigned l
#endif
/* We need to mark all pages as being coherent if we're SMP or we
- * have a 74[45]x and an MPC107 host bridge.
+ * have a 74[45]x and an MPC107 host bridge. Also 83xx requires
+ * it for PCI "streaming/prefetch" to work properly.
*/
-#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE)
+#if defined(CONFIG_SMP) || defined(CONFIG_MPC10X_BRIDGE) \
+ || defined(CONFIG_PPC_83xx)
#define CPU_FTR_COMMON CPU_FTR_NEED_COHERENT
#else
#define CPU_FTR_COMMON 0
@@ -277,7 +279,8 @@ enum {
CPU_FTRS_G2_LE = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_HAS_HIGH_BATS,
CPU_FTRS_E300 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_MAYBE_CAN_DOZE |
- CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_HAS_HIGH_BATS,
+ CPU_FTR_USE_TB | CPU_FTR_MAYBE_CAN_NAP | CPU_FTR_HAS_HIGH_BATS |
+ CPU_FTR_COMMON,
CPU_FTRS_CLASSIC32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
CPU_FTR_USE_TB | CPU_FTR_HPTE_TABLE,
CPU_FTRS_POWER3_32 = CPU_FTR_COMMON | CPU_FTR_SPLIT_ID_CACHE |
^ permalink raw reply related
* Re: ppc32: mpc85xx: set pcibios_fixup only #ifdef CONFIG_PCI
From: Dale Farnsworth @ 2006-02-22 14:03 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <Pine.LNX.4.44.0602212343400.2878-100000@gate.crashing.org>
On Tue, Feb 21, 2006 at 11:44:15PM -0600, Kumar Gala wrote:
> On Fri, 17 Feb 2006, Dale Farnsworth wrote:
>
> > From: Dale Farnsworth <dale@farnsworth.org>
> >
> > Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> > ---
>
> This change is already in the kernel tree.
>
> - kumar
Indeed it is. Sorry for the noise.
-Dale
> > arch/ppc/platforms/85xx/mpc85xx_cds_common.c | 6 +++---
> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > Index: linux-2.6.10/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
> > ===================================================================
> > --- linux-2.6.10.orig/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
> > +++ linux-2.6.10/arch/ppc/platforms/85xx/mpc85xx_cds_common.c
> > @@ -456,9 +456,6 @@ mpc85xx_cds_setup_arch(void)
> > mtspr(SPRN_DBCR0, (DBCR0_IDM));
> > mtspr(SPRN_DBSR, 0xffffffff);
> > #endif
> > -
> > - /* VIA IDE configuration */
> > - ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup;
> >
> > #ifdef CONFIG_CPM2
> > cpm2_reset();
> > @@ -480,6 +477,9 @@ mpc85xx_cds_setup_arch(void)
> > loops_per_jiffy = freq / HZ;
> >
> > #ifdef CONFIG_PCI
> > + /* VIA IDE configuration */
> > + ppc_md.pcibios_fixup = mpc85xx_cds_pcibios_fixup;
> > +
> > /* setup PCI host bridges */
> > mpc85xx_setup_hose();
> > #endif
> >
^ permalink raw reply
* Re: [PATCH] powerpc: fix altivec_unavailable_exception Oopses
From: Paul Mackerras @ 2006-02-22 11:46 UTC (permalink / raw)
To: Alan Curry; +Cc: linuxppc-dev, linux-kernel
In-Reply-To: <200602212339.SAA1138491@shell.TheWorld.com>
Alan Curry writes:
> altivec_unavailable_exception is called without setting r3... it looks like
> the r3 that actually gets passed in as struct pt_regs *regs is the
> undisturbed value of r3 at the time the altivec instruction was encountered.
Nice catch!
Thanks,
Paul.
^ permalink raw reply
* hi problem during kernel compilation
From: shivani kirubanandan @ 2006-02-22 9:28 UTC (permalink / raw)
To: linuxppc-embedded
hello all,
i have encountered this error during kernel
compilation FYI the kernel version is 2.4.26
powerpc405 and ml300 board specific
plz help me out
wen i run make zImage
mv zvmlinux ../images/zImage.
mv zvmlinux ../images/zImage.elf
mv: can't stat source zvmlinux
make[2]: *** [zImage] Error 1
make[2]: Leaving directory
`/home/shivani/downloads/linux-2.4.26/arch/ppc/boot/simple'
make[1]: *** [zImage] Error 2
make[1]: Leaving directory
`/home/shivani/downloads/linux-2.4.26/arch/ppc/boot'
make: *** [zImage] Error 2
thanks in advance
shivani
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
^ permalink raw reply
* Re: boot failure on lite5200b board
From: Andrey Volkov @ 2006-02-22 8:24 UTC (permalink / raw)
To: #LI JIANGGAN#; +Cc: linuxppc-embedded
In-Reply-To: <84A109BF918D934CB46ACF33BCE187C002D54D71@mail02.student.main.ntu.edu.sg>
Hello, Jianggan.
On Wednesday, February 22, 2006, #LI JIANGGAN# wrote:
> =20
> =20
> Hello all,
> =20
> For my end-of-study project, I am working on an embedded system
> with reference of freescale's lite5200b reference board. I was
> trying to boot Linux 2.6.15 on the board (with the fec and bestcomm
> corrected). however the booting was stuck at the following stage:
> U-Boot 1.1.3 (Feb=A0 6 2006 - 09:56:46)
> =20
> ## Booting image at 00100000 ...
> =A0=A0 Image Name:=A0=A0 Linux-2.6.16-rc1
> =A0=A0 Image Type:=A0=A0 PowerPC Linux Kernel Image (gzip compressed)
> =A0=A0 Data Size:=A0=A0=A0 658050 Bytes =3D 642.6 kB
> =A0=A0 Load Address: 00000000
> =A0=A0 Entry Point:=A0 00000000
> =A0=A0 Verifying Checksum ... OK
> =A0=A0 Uncompressing Kernel Image ... OK
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> arch: exit
> =20
> I think it's probably the problem of kernel configuration prior to
> compilation. Has anybody got 2.6 kernel working probably lite5200b?
> =20
> THE U-BOOT ENVIRONMENT SETTINGS:
> =20
> =3D> printenv
> baudrate=3D115200
> autoload=3Dno
> ethact=3DFEC ETHERNET
> preboot=3Decho;echo Autostarting. Press any key to abort..;echo
> bootdelay=3D5
> hostname=3Dicecube
> flshroot=3Droot=3D/dev/mtdblock2 rw
> ethaddr=3D00:01:9F:00:27:2F
> rootfs=3Droot=3D/dev/nfs rw nfsroot=3D10.190.3.103:/opt/eldk/rootfs
> filesize=3Df2
> fileaddr=3D100000
> netmask=3D255.255.240.0
> serverip=3D10.190.3.103
> bootcmd=3Dtftp; bootm
> bootfile=3DMPC5200/uImage
> ipaddr=3D10.190.3.144
>=20
> ip=3Dip=3D10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::o=
ff
> nfsroot=3Droot=3D/dev/nfs rw nfsroot=3D10.190.3.103:/opt/eldk/rootfs
> bootargs=3Droot=3D/dev/nfs rw nfsroot=3D10.190.3.103:/opt/eldk/rootfs
> ip=3D10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
> stdin=3Dserial
> stdout=3Dserial
> stderr=3Dserial
> =20
> Environment size: 704/65532 bytes
> =3D>=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0
> =20
> THE WHLOE BOOTING MESSAGE:
> =20
> U-Boot 1.1.3 (Feb=A0 6 2006 - 09:56:46)
> =20
> CPU:=A0=A0 MPC5200 v2.2 at 462 MHz
> =A0=A0=A0=A0=A0=A0 Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
> Board: Freescale MPC5200 (Lite5200B)
> I2C:=A0=A0 85 kHz, ready
> DRAM:=A0 256 MB
> FLASH: 32 MB
> PCI:=A0=A0 Bus Dev VenId DevId Class Int
> =A0=A0=A0=A0=A0=A0=A0 00=A0 1a=A0 1057=A0 5809=A0 0680=A0 00
> In:=A0=A0=A0 serial
> Out:=A0=A0 serial
> Err:=A0=A0 serial
> Net:=A0=A0 FEC ETHERNET
> IDE:=A0=A0 Bus 0: OK
> =A0 Device 0: not available
> =A0 Device 1: not available
> =20
> Autostarting. Press any key to abort..
> =20
> Hit any key to stop autoboot:=A0 0
> Using FEC ETHERNET device
> TFTP from server 10.190.3.103; our IP address is 10.190.3.144
> Filename 'MPC5200/uImage'.
> Load address: 0x100000
> Loading:
> #################################################################
> =A0=A0=A0=A0=A0=A0=A0=A0
> ################################################################
> done
> Bytes transferred =3D 658114 (a0ac2 hex)
> ## Booting image at 00100000 ...
> =A0=A0 Image Name:=A0=A0 Linux-2.6.16-rc1
> =A0=A0 Image Type:=A0=A0 PowerPC Linux Kernel Image (gzip compressed)
> =A0=A0 Data Size:=A0=A0=A0 658050 Bytes =3D 642.6 kB
> =A0=A0 Load Address: 00000000
> =A0=A0 Entry Point:=A0 00000000
> =A0=A0 Verifying Checksum ... OK
> =A0=A0 Uncompressing Kernel Image ... OK
> id mach(): done
> MMU:enter
> MMU:hw init
> MMU:mapin
> MMU:setio
> MMU:exit
> setup_arch: enter
> setup_arch: bootmem
> arch: exit
> =20
> Thanks.
> =20
> Jianggan LI
> =20
> =20
> =20
> =20
First, please DON'T use html in mails, which is addressed to mail
lists.
Now about your problem: you're doesn't setup ttyPSC0 as console device
for the kernel (as I understand, above is snapshot of terminal
output, am I right?).
Add string like this: console=3DttyPSC0,115200n8 console=3Dtty1 to the kern=
el parameters
(as simple hack you could add above string to rootfs enviroment
variable).
As example, here is part of our board config (not lite5200B):
baudrate=3D115200
preboot=3Decho;echo Type "run flash_nfs" to mount root filesystem over NFS;=
echo
netdev=3Deth0
addip=3Dsetenv bootargs $(bootargs)
ip=3D$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):$(netdev):of=
f panic=3D5
ethact=3DFEC ETHERNET
serverip=3D10.0.19.228
gatewayip=3D10.0.19.238
netmask=3D255.255.255.0
rootpath=3D/tftpboot/10.0.19.6
ipaddr=3D10.0.19.6
ntpserverip=3D10.0.19.238
ramargs=3Dsetenv bootargs root=3D/dev/ram rw
net_nfs=3Dtftp 200000 $(bootfile);run setconsole nfsargs addip;bootm
setconsole=3Dsetenv bootargs $(console)
nfsargs=3Dsetenv bootargs $(bootargs) root=3D/dev/nfs rw nfsroot=3D$(server=
ip):$(rootpath)
kernel_addr=3DFE040000
flash_root=3Dtftp 200000 $(bootfile);run setconsole jffs2rootfs addip;bootm
flash_self=3Drun setconsole jffs2rootfs addip;bootm $(kernel_addr)
jffs2rootfs=3Dsetenv bootargs $(bootargs) rootfstype=3Djffs2 root=3D31:2 rw
bootfile=3D/tftpboot/uImage.vec5200
hostname=3Dvec5200-3
bootdelay=3D1
console=3Dconsole=3DttyPSC0,115200n8 console=3Dtty1
flash_nfs=3Drun setconsole nfsargs addip;bootm $(kernel_addr)
tnote_cfg=3Dsetenv serverip 10.0.19.4;setenv gatewayip 10.0.19.4
net_nfs_tnote=3Drun tnote_cfg;run net_nfs
bootcmd=3Drun net_nfs
stdin=3Dserial
stdout=3Dserial
stderr=3Dserial
--=20
Regards,
Andrey Volkov
^ permalink raw reply
* RE: boot failure on lite5200b board
From: TXEMA LOPEZ @ 2006-02-22 7:53 UTC (permalink / raw)
To: #LI JIANGGAN#; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 4022 bytes --]
Hi Li,
I'm working on a lite5200b too but with a 2.4.25 kernel. Anyway, I found some problems to launch the 2.4.25 kernel from the U-Boot version that comes with the board from Freescale. I fixed some bugs in this U-Boot version and sent a patch for the U-Boot 1.1.4 version to the U-Boot users mailing list. The patch is not yet accepted and added to the git repository but I suggest that you apply this patch and try it again.
Another suggestion is not to use a low address to copy the kernel image (in your case 0x100000, try 0x500000 by example). The kernel is decompressed at the 0 address and your kernel could be overlapped.
Good luck,
Jose Maria Lopez.
-----Mensaje original-----
De: linuxppc-embedded-bounces+tlopez=fagorautomation.es@ozlabs.org [mailto:linuxppc-embedded-bounces+tlopez=fagorautomation.es@ozlabs.org]En nombre de #LI JIANGGAN#
Enviado el: miércoles, 22 de febrero de 2006 5:05
Para: linuxppc-embedded@ozlabs.org
Asunto: boot failure on lite5200b board
Hello all,
For my end-of-study project, I am working on an embedded system with reference of freescale's lite5200b reference board. I was trying to boot Linux 2.6.15 on the board (with the fec and bestcomm corrected). however the booting was stuck at the following stage:
U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
## Booting image at 00100000 ...
Image Name: Linux-2.6.16-rc1
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 658050 Bytes = 642.6 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
arch: exit
I think it's probably the problem of kernel configuration prior to compilation. Has anybody got 2.6 kernel working probably lite5200b?
THE U-BOOT ENVIRONMENT SETTINGS:
=> printenv
baudrate=115200
autoload=no
ethact=FEC ETHERNET
preboot=echo;echo Autostarting. Press any key to abort..;echo
bootdelay=5
hostname=icecube
flshroot=root=/dev/mtdblock2 rw
ethaddr=00:01:9F:00:27:2F
rootfs=root=/dev/nfs rw nfsroot=10.190.3.103:/opt/eldk/rootfs
filesize=f2
fileaddr=100000
netmask=255.255.240.0
serverip=10.190.3.103
bootcmd=tftp; bootm
bootfile=MPC5200/uImage
ipaddr=10.190.3.144
ip=ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
nfsroot=root=/dev/nfs rw nfsroot=10.190.3.103:/opt/eldk/rootfs
bootargs=root=/dev/nfs rw nfsroot=10.190.3.103:/opt/eldk/rootfs ip=10.190.3.144:10.190.3.103:10.190.3.103:255.255.240.0:icecube::off
stdin=serial
stdout=serial
stderr=serial
Environment size: 704/65532 bytes
=>
THE WHLOE BOOTING MESSAGE:
U-Boot 1.1.3 (Feb 6 2006 - 09:56:46)
CPU: MPC5200 v2.2 at 462 MHz
Bus 132 MHz, IPB 132 MHz, PCI 33 MHz
Board: Freescale MPC5200 (Lite5200B)
I2C: 85 kHz, ready
DRAM: 256 MB
FLASH: 32 MB
PCI: Bus Dev VenId DevId Class Int
00 1a 1057 5809 0680 00
In: serial
Out: serial
Err: serial
Net: FEC ETHERNET
IDE: Bus 0: OK
Device 0: not available
Device 1: not available
Autostarting. Press any key to abort..
Hit any key to stop autoboot: 0
Using FEC ETHERNET device
TFTP from server 10.190.3.103; our IP address is 10.190.3.144
Filename 'MPC5200/uImage'.
Load address: 0x100000
Loading: #################################################################
################################################################
done
Bytes transferred = 658114 (a0ac2 hex)
## Booting image at 00100000 ...
Image Name: Linux-2.6.16-rc1
Image Type: PowerPC Linux Kernel Image (gzip compressed)
Data Size: 658050 Bytes = 642.6 kB
Load Address: 00000000
Entry Point: 00000000
Verifying Checksum ... OK
Uncompressing Kernel Image ... OK
id mach(): done
MMU:enter
MMU:hw init
MMU:mapin
MMU:setio
MMU:exit
setup_arch: enter
setup_arch: bootmem
arch: exit
Thanks.
Jianggan LI
[-- Attachment #2: Type: text/html, Size: 10595 bytes --]
^ 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