* Linux-ppc boot problems
From: Srivatsan @ 2004-12-30 5:04 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <20041230010007.B9EC22BF17@ozlabs.org>
[-- Attachment #1: Type: text/plain, Size: 2206 bytes --]
Hi all,
I am sending the whole logbuffer.
00138BD4: 3C 36 3E 4D 65 6D 6F 72 79 20 42 41 54 20 6D 61 |<6>Memory
BATma|
00138BE4: 70 70 69 6E 67 3A 20 42 41 54 32 3D 31 36 4D 62
|pping:BAT2=16Mb|
00138BF4: 2C 20 42 41 54 33 3D 30 4D 62 2C 20 72 65 73 69 |,
BAT3=0Mb,resi|
00138C04: 64 75 61 6C 3A 20 30 4D 62 0A 00 00 00 00 00 00
|dual:0Mb.......|
00138C14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C24: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C34: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C44: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C54: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C64: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C74: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C84: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C94: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138CA4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138CB4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138CC4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............
Any pointers to the above problem. I am not able to see further logs, Is
it that our Linux Kernel is not properly ported? We have been on this
problem for quite some time now, kindly help us to get our system up.
Thanking you all for your support.
With Best Regards,
C.R.Srivatsan
********************************DISCLAIMER**********************************
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.
****************************************************************************
[-- Attachment #2: Type: text/html, Size: 15650 bytes --]
^ permalink raw reply
* [patch] ppc: remove casts in motorola ethernet drivers
From: Domen Puncer @ 2004-12-29 19:53 UTC (permalink / raw)
To: paulus; +Cc: linuxppc-dev
Remove (void *) pointer casts.
arch/ppc/8260_io/enet.c | 12 ++++++------
arch/ppc/8260_io/fcc_enet.c | 28 ++++++++++++++--------------
arch/ppc/8xx_io/enet.c | 12 ++++++------
arch/ppc/8xx_io/fec.c | 6 +++---
4 files changed, 29 insertions(+), 29 deletions(-)
Signed-off-by: Domen Puncer <domen@coderock.org>
diff -pruNX dontdiff c/arch/ppc/8260_io/enet.c a/arch/ppc/8260_io/enet.c
--- c/arch/ppc/8260_io/enet.c 2004-12-25 15:50:14.000000000 +0100
+++ a/arch/ppc/8260_io/enet.c 2004-12-29 20:46:26.000000000 +0100
@@ -167,7 +167,7 @@ scc_enet_open(struct net_device *dev)
static int
scc_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
- struct scc_enet_private *cep = (struct scc_enet_private *)dev->priv;
+ struct scc_enet_private *cep = dev->priv;
volatile cbd_t *bdp;
@@ -238,7 +238,7 @@ scc_enet_start_xmit(struct sk_buff *skb,
static void
scc_enet_timeout(struct net_device *dev)
{
- struct scc_enet_private *cep = (struct scc_enet_private *)dev->priv;
+ struct scc_enet_private *cep = dev->priv;
printk("%s: transmit timed out.\n", dev->name);
cep->stats.tx_errors++;
@@ -281,7 +281,7 @@ scc_enet_interrupt(int irq, void * dev_i
ushort int_events;
int must_restart;
- cep = (struct scc_enet_private *)dev->priv;
+ cep = dev->priv;
/* Get the interrupt events that caused us to be here.
*/
@@ -419,7 +419,7 @@ scc_enet_rx(struct net_device *dev)
struct sk_buff *skb;
ushort pkt_len;
- cep = (struct scc_enet_private *)dev->priv;
+ cep = dev->priv;
/* First, grab all of the stats for the incoming packet.
* These get messed up if we get called due to a busy condition.
@@ -520,7 +520,7 @@ scc_enet_close(struct net_device *dev)
static struct net_device_stats *scc_enet_get_stats(struct net_device *dev)
{
- struct scc_enet_private *cep = (struct scc_enet_private *)dev->priv;
+ struct scc_enet_private *cep = dev->priv;
return &cep->stats;
}
@@ -542,7 +542,7 @@ static void set_multicast_list(struct ne
u_char *mcptr, *tdptr;
volatile scc_enet_t *ep;
int i, j;
- cep = (struct scc_enet_private *)dev->priv;
+ cep = dev->priv;
/* Get pointer to SCC area in parameter RAM.
*/
diff -pruNX dontdiff c/arch/ppc/8260_io/fcc_enet.c a/arch/ppc/8260_io/fcc_enet.c
--- c/arch/ppc/8260_io/fcc_enet.c 2004-12-25 15:50:14.000000000 +0100
+++ a/arch/ppc/8260_io/fcc_enet.c 2004-12-29 20:46:26.000000000 +0100
@@ -369,7 +369,7 @@ static void fcc_stop(struct net_device *
static int
fcc_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
- struct fcc_enet_private *cep = (struct fcc_enet_private *)dev->priv;
+ struct fcc_enet_private *cep = dev->priv;
volatile cbd_t *bdp;
int idx;
@@ -460,7 +460,7 @@ fcc_enet_start_xmit(struct sk_buff *skb,
static void
fcc_enet_timeout(struct net_device *dev)
{
- struct fcc_enet_private *cep = (struct fcc_enet_private *)dev->priv;
+ struct fcc_enet_private *cep = dev->priv;
printk("%s: transmit timed out.\n", dev->name);
cep->stats.tx_errors++;
@@ -502,7 +502,7 @@ fcc_enet_interrupt(int irq, void * dev_i
int must_restart;
int idx;
- cep = (struct fcc_enet_private *)dev->priv;
+ cep = dev->priv;
/* Get the interrupt events that caused us to be here.
*/
@@ -644,7 +644,7 @@ fcc_enet_rx(struct net_device *dev)
struct sk_buff *skb;
ushort pkt_len;
- cep = (struct fcc_enet_private *)dev->priv;
+ cep = dev->priv;
/* First, grab all of the stats for the incoming packet.
* These get messed up if we get called due to a busy condition.
@@ -734,7 +734,7 @@ fcc_enet_close(struct net_device *dev)
static struct net_device_stats *fcc_enet_get_stats(struct net_device *dev)
{
- struct fcc_enet_private *cep = (struct fcc_enet_private *)dev->priv;
+ struct fcc_enet_private *cep = dev->priv;
return &cep->stats;
}
@@ -1352,7 +1352,7 @@ set_multicast_list(struct net_device *de
volatile fcc_enet_t *ep;
int i, j;
- cep = (struct fcc_enet_private *)dev->priv;
+ cep = dev->priv;
return;
/* Get pointer to FCC area in parameter RAM.
@@ -1417,13 +1417,13 @@ return;
*/
int fcc_enet_set_mac_address(struct net_device *dev, void *p)
{
- struct sockaddr *addr= (struct sockaddr *) p;
+ struct sockaddr *addr= p;
struct fcc_enet_private *cep;
volatile fcc_enet_t *ep;
unsigned char *eap;
int i;
- cep = (struct fcc_enet_private *)(dev->priv);
+ cep = dev->priv;
ep = cep->ep;
if (netif_running(dev))
@@ -1610,7 +1610,7 @@ init_fcc_param(fcc_info_t *fip, struct n
volatile cbd_t *bdp;
volatile cpm_cpm2_t *cp;
- cep = (struct fcc_enet_private *)(dev->priv);
+ cep = dev->priv;
ep = cep->ep;
cp = cpmp;
@@ -1624,10 +1624,10 @@ init_fcc_param(fcc_info_t *fip, struct n
/* Allocate space for the buffer descriptors from regular memory.
* Initialize base addresses for the buffer descriptors.
*/
- cep->rx_bd_base = (cbd_t *)kmalloc(sizeof(cbd_t) * RX_RING_SIZE,
+ cep->rx_bd_base = kmalloc(sizeof(cbd_t) * RX_RING_SIZE,
GFP_KERNEL | GFP_DMA);
ep->fen_genfcc.fcc_rbase = __pa(cep->rx_bd_base);
- cep->tx_bd_base = (cbd_t *)kmalloc(sizeof(cbd_t) * TX_RING_SIZE,
+ cep->tx_bd_base = kmalloc(sizeof(cbd_t) * TX_RING_SIZE,
GFP_KERNEL | GFP_DMA);
ep->fen_genfcc.fcc_tbase = __pa(cep->tx_bd_base);
@@ -1809,7 +1809,7 @@ init_fcc_startup(fcc_info_t *fip, struct
volatile fcc_t *fccp;
struct fcc_enet_private *cep;
- cep = (struct fcc_enet_private *)(dev->priv);
+ cep = dev->priv;
fccp = cep->fccp;
fccp->fcc_fcce = 0xffff; /* Clear any pending events */
@@ -1968,7 +1968,7 @@ fcc_stop(struct net_device *dev)
volatile fcc_t *fccp;
struct fcc_enet_private *fcp;
- fcp = (struct fcc_enet_private *)(dev->priv);
+ fcp = dev->priv;
fccp = fcp->fccp;
/* Disable transmit/receive */
@@ -1982,7 +1982,7 @@ fcc_restart(struct net_device *dev, int
volatile fcc_t *fccp;
struct fcc_enet_private *fcp;
- fcp = (struct fcc_enet_private *)(dev->priv);
+ fcp = dev->priv;
fccp = fcp->fccp;
if (duplex)
diff -pruNX dontdiff c/arch/ppc/8xx_io/enet.c a/arch/ppc/8xx_io/enet.c
--- c/arch/ppc/8xx_io/enet.c 2004-12-25 15:50:14.000000000 +0100
+++ a/arch/ppc/8xx_io/enet.c 2004-12-29 20:46:26.000000000 +0100
@@ -197,7 +197,7 @@ scc_enet_open(struct net_device *dev)
static int
scc_enet_start_xmit(struct sk_buff *skb, struct net_device *dev)
{
- struct scc_enet_private *cep = (struct scc_enet_private *)dev->priv;
+ struct scc_enet_private *cep = dev->priv;
volatile cbd_t *bdp;
/* Fill in a Tx ring entry */
@@ -273,7 +273,7 @@ scc_enet_start_xmit(struct sk_buff *skb,
static void
scc_enet_timeout(struct net_device *dev)
{
- struct scc_enet_private *cep = (struct scc_enet_private *)dev->priv;
+ struct scc_enet_private *cep = dev->priv;
printk("%s: transmit timed out.\n", dev->name);
cep->stats.tx_errors++;
@@ -314,7 +314,7 @@ scc_enet_interrupt(void *dev_id, struct
ushort int_events;
int must_restart;
- cep = (struct scc_enet_private *)dev->priv;
+ cep = dev->priv;
/* Get the interrupt events that caused us to be here.
*/
@@ -449,7 +449,7 @@ scc_enet_rx(struct net_device *dev)
struct sk_buff *skb;
ushort pkt_len;
- cep = (struct scc_enet_private *)dev->priv;
+ cep = dev->priv;
/* First, grab all of the stats for the incoming packet.
* These get messed up if we get called due to a busy condition.
@@ -550,7 +550,7 @@ scc_enet_close(struct net_device *dev)
static struct net_device_stats *scc_enet_get_stats(struct net_device *dev)
{
- struct scc_enet_private *cep = (struct scc_enet_private *)dev->priv;
+ struct scc_enet_private *cep = dev->priv;
return &cep->stats;
}
@@ -572,7 +572,7 @@ static void set_multicast_list(struct ne
u_char *mcptr, *tdptr;
volatile scc_enet_t *ep;
int i, j;
- cep = (struct scc_enet_private *)dev->priv;
+ cep = dev->priv;
/* Get pointer to SCC area in parameter RAM.
*/
diff -pruNX dontdiff c/arch/ppc/8xx_io/fec.c a/arch/ppc/8xx_io/fec.c
--- c/arch/ppc/8xx_io/fec.c 2004-12-25 15:50:14.000000000 +0100
+++ a/arch/ppc/8xx_io/fec.c 2004-12-29 20:46:26.000000000 +0100
@@ -781,7 +781,7 @@ fec_enet_mii(struct net_device *dev)
mii_list_t *mip;
uint mii_reg;
- fep = (struct fec_enet_private *)dev->priv;
+ fep = dev->priv;
ep = &(((immap_t *)IMAP_ADDR)->im_cpm.cp_fec);
mii_reg = ep->fec_mii_data;
@@ -1485,7 +1485,7 @@ fec_enet_close(struct net_device *dev)
static struct net_device_stats *fec_enet_get_stats(struct net_device *dev)
{
- struct fec_enet_private *fep = (struct fec_enet_private *)dev->priv;
+ struct fec_enet_private *fep = dev->priv;
return &fep->stats;
}
@@ -1505,7 +1505,7 @@ static void set_multicast_list(struct ne
struct fec_enet_private *fep;
volatile fec_t *ep;
- fep = (struct fec_enet_private *)dev->priv;
+ fep = dev->priv;
ep = &(((immap_t *)IMAP_ADDR)->im_cpm.cp_fec);
if (dev->flags&IFF_PROMISC) {
^ permalink raw reply
* RE: Linux Kernel boot problem
From: Srivatsan @ 2004-12-29 4:56 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
In-Reply-To: <20041228174222.79FC7C14EC@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 2010 bytes --]
Hi Mr.Wolfgang,
I am sending the whole logbuffer.
00138BD4: 3C 36 3E 4D 65 6D 6F 72 79 20 42 41 54 20 6D 61 |<6>Memory
BATma|
00138BE4: 70 70 69 6E 67 3A 20 42 41 54 32 3D 31 36 4D 62
|pping:BAT2=16Mb|
00138BF4: 2C 20 42 41 54 33 3D 30 4D 62 2C 20 72 65 73 69 |,
BAT3=0Mb,resi|
00138C04: 64 75 61 6C 3A 20 30 4D 62 0A 00 00 00 00 00 00
|dual:0Mb.......|
00138C14: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C24: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C34: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C44: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C54: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C64: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C74: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C84: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138C94: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138CA4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138CB4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............|
00138CC4: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
|...............
Hope this is what you had asked for? Thanks again.
With Best Regards,
C.R.Srivatsan
********************************DISCLAIMER**********************************
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.
****************************************************************************
[-- Attachment #2: Type: text/html, Size: 17045 bytes --]
^ permalink raw reply
* [micropatch]mpc852t
From: "김 창식" @ 2004-12-29 1:38 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/html, Size: 1386 bytes --]
^ permalink raw reply
* Re: simple bootloader 2.6.10-rc3 8xx
From: Wolfgang Denk @ 2004-12-28 17:48 UTC (permalink / raw)
To: Povolotsky, Alexander; +Cc: linuxppc-embedded
In-Reply-To: <313680C9A886D511A06000204840E1CF0A647421@whq-msgusr-02.pit.comms.marconi.com>
In message <313680C9A886D511A06000204840E1CF0A647421@whq-msgusr-02.pit.comms.marconi.com> you wrote:
>
> I guess I need some more education - since I am getting my problem right at
> the boot - is
> I-Cache enabled (by default ?) for 8xx on 2.6 at the booting ? - I do not
They get turned on very early.
> see anything in .config
> which controls it (or I am missing it there ?)
No. This is not configurable.
> How (where and at what point during the boot)-) I could disable I-Cache ?
Search for IC_CST in "arch/ppc/kernel/head_8xx.S"
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
Every program has at least one bug and can be shortened by at least
one instruction - from which, by induction, one can deduce that every
program can be reduced to one instruction which doesn't work.
^ permalink raw reply
* RE: simple bootloader 2.6.10-rc3 8xx
From: Steven Rostedt @ 2004-12-28 17:47 UTC (permalink / raw)
To: Povolotsky, Alexander; +Cc: linuxppc-embedded
In-Reply-To: <313680C9A886D511A06000204840E1CF0A647421@whq-msgusr-02.pit.comms.marconi.com>
On Tue, 2004-12-28 at 12:28 -0500, Povolotsky, Alexander wrote:
> Hi! (Thanks !)
>
> I guess I need some more education - since I am getting my problem right at
> the boot - is
> I-Cache enabled (by default ?) for 8xx on 2.6 at the booting ? - I do not
> see anything in .config
> which controls it (or I am missing it there ?)
> How (where and at what point during the boot)-) I could disable I-Cache ?
>
Since you where able to get to the prekernel portion (that was
relocated) I don't think you have a problem with caches, unless for some
reason the pre-kernel can relocate itself, but it doesn't know to
refresh the cache after relocating the actual kernel.
-- Steve
^ permalink raw reply
* Re: Linux Kernel boot problem
From: Wolfgang Denk @ 2004-12-28 17:42 UTC (permalink / raw)
To: Srivatsan; +Cc: linuxppc-embedded
In-Reply-To: <000001c4ecfc$38442400$1269cb0a@bgcw301>
In message <000001c4ecfc$38442400$1269cb0a@bgcw301> you wrote:
>
> We were able to see the log buffer. It gave the following data:
Good.
> It is having the data what should be dumped out of Serial port. Any
> pointers which can lead us to the problem?
Well, what are the last readable messages you can find in the buffer?
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
If I had to live my life again, I'd make the same mistakes, only
sooner. -- Tallulah Bankhead
^ permalink raw reply
* RE: simple bootloader 2.6.10-rc3 8xx
From: Povolotsky, Alexander @ 2004-12-28 17:28 UTC (permalink / raw)
To: 'paul.bilke', Wolfgang Denk; +Cc: linuxppc-embedded
Hi! (Thanks !)
I guess I need some more education - since I am getting my problem right at
the boot - is
I-Cache enabled (by default ?) for 8xx on 2.6 at the booting ? - I do not
see anything in .config
which controls it (or I am missing it there ?)
How (where and at what point during the boot)-) I could disable I-Cache ?
Thanks,
Alex
-----Original Message-----
From: paul.bilke [mailto:listmail@conspiracy.net]
Sent: Tuesday, December 28, 2004 12:13 PM
To: Wolfgang Denk
Cc: Povolotsky, Alexander; linuxppc-embedded@ozlabs.org
Subject: Re: simple bootloader 2.6.10-rc3 8xx
Actually wd is right, one quick check to see if this is the problem is
to disable the I-Cache. The problem only shows up the the I cache
enabled. I ran my 870 with them disabled for months (I know its painful)
until I got the
powers that be to approve wd to spend the time we did not have to fix it.
Some of the best money I ever spent.
Paul
Wolfgang Denk wrote:
>Dear Alex,
>
>in message
<313680C9A886D511A06000204840E1CF0A64741E@whq-msgusr-02.pit.comms.marconi.co
m> you wrote:
>
>
>>
>>
>>
>>>Moving things around in the kernel sometimes
>>>makes this go away but really its just hidden.
>>>In my case it would explode in zlib_inflate also. Putting some output
>>>in the routine would move it ...
>>>
>>>
>>Yes that is exactly what I have observed (but I did'nt have the correct
>>explanation for it)
>>
>>
>
>I think Paul may be right with his suspicion; it sounds like a
>manifestation of the CPU15 problem (but it could also be incorrectly
>initialized SDRAMs which fail during heavy load with burst mode
>accesses, or one more instability of the 2.6 kernel on 8xx systems).
>
>Note that all our work relating to this problem was done on the 2.4
>kernel base, and I make no claims that it might actually help for
>your 2.6 problems.
>
>
>
>>Could this code be used for 2.6 ?
>>
>>
>
>The patch does not apply cleanly as is to the 2.6 tree, but it should
>be simple enough to port.
>
>
>
>>Could someone point me to it, please ?
>>
>>
>
>It's in the linuxppc_2_4_devel tree on our CVS server.
>
>Please find attached the patch to the 2.4 kernel tree which
>implements the workaround, and a test application to reliably
>reproduce the CPU15 errata. It usually takes 1-10 minutes for the
>application to crash, if the workaround is disabled:
>
> bash-2.05b# date; ./cpu15 ; date
> Thu Aug 2 02:02:42 MEST 2001
> Illegal instruction
> Thu Aug 2 02:02:54 MEST 2001
> bash-2.05b# date; ./cpu15 ; date
> Thu Aug 2 02:02:58 MEST 2001
> Illegal instruction
> Thu Aug 2 02:03:48 MEST 2001
> bash-2.05b# date; ./cpu15 ; date
> Thu Aug 2 02:03:54 MEST 2001
> Illegal instruction
> Thu Aug 2 02:03:57 MEST 2001
> bash-2.05b# date; ./cpu15 ; date
> Thu Aug 2 02:04:07 MEST 2001
> Illegal instruction
> Thu Aug 2 02:04:16 MEST 2001
> bash-2.05b#
>
>We noticed that some background activitly, like logging in/out to the
>target via 'telnet', while the application is running over the serial
>console, additionally speeds up the crash.
>
>You can use this command to enable the workaround at run-time (it is
>disabled by default):
>
> bash# sysctl -w kernel.8xx_cpu15=1
>
>Please note that for the h/w problem to show up, the instruction
>cache has to be enabled.
>
>Hope this helps.
>
>Best regards,
>
>Wolfgang Denk
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* Re: simple bootloader 2.6.10-rc3 8xx
From: paul.bilke @ 2004-12-28 17:12 UTC (permalink / raw)
To: Wolfgang Denk; +Cc: Povolotsky, Alexander, linuxppc-embedded
In-Reply-To: <20041228095119.F07EDC1430@atlas.denx.de>
Actually wd is right, one quick check to see if this is the problem is
to disable the I-Cache. The problem only shows up the the I cache
enabled. I ran my
870 with them disabled for months (I know its painful) until I got the
powers that be to approve wd to spend the time we did not have to fix it.
Some of the best money I ever spent.
Paul
Wolfgang Denk wrote:
>Dear Alex,
>
>in message <313680C9A886D511A06000204840E1CF0A64741E@whq-msgusr-02.pit.comms.marconi.com> you wrote:
>
>
>>
>>
>>
>>>Moving things around in the kernel sometimes
>>>makes this go away but really its just hidden.
>>>In my case it would explode in zlib_inflate also. Putting some output
>>>in the routine would move it ...
>>>
>>>
>>Yes that is exactly what I have observed (but I did'nt have the correct
>>explanation for it)
>>
>>
>
>I think Paul may be right with his suspicion; it sounds like a
>manifestation of the CPU15 problem (but it could also be incorrectly
>initialized SDRAMs which fail during heavy load with burst mode
>accesses, or one more instability of the 2.6 kernel on 8xx systems).
>
>Note that all our work relating to this problem was done on the 2.4
>kernel base, and I make no claims that it might actually help for
>your 2.6 problems.
>
>
>
>>Could this code be used for 2.6 ?
>>
>>
>
>The patch does not apply cleanly as is to the 2.6 tree, but it should
>be simple enough to port.
>
>
>
>>Could someone point me to it, please ?
>>
>>
>
>It's in the linuxppc_2_4_devel tree on our CVS server.
>
>Please find attached the patch to the 2.4 kernel tree which
>implements the workaround, and a test application to reliably
>reproduce the CPU15 errata. It usually takes 1-10 minutes for the
>application to crash, if the workaround is disabled:
>
> bash-2.05b# date; ./cpu15 ; date
> Thu Aug 2 02:02:42 MEST 2001
> Illegal instruction
> Thu Aug 2 02:02:54 MEST 2001
> bash-2.05b# date; ./cpu15 ; date
> Thu Aug 2 02:02:58 MEST 2001
> Illegal instruction
> Thu Aug 2 02:03:48 MEST 2001
> bash-2.05b# date; ./cpu15 ; date
> Thu Aug 2 02:03:54 MEST 2001
> Illegal instruction
> Thu Aug 2 02:03:57 MEST 2001
> bash-2.05b# date; ./cpu15 ; date
> Thu Aug 2 02:04:07 MEST 2001
> Illegal instruction
> Thu Aug 2 02:04:16 MEST 2001
> bash-2.05b#
>
>We noticed that some background activitly, like logging in/out to the
>target via 'telnet', while the application is running over the serial
>console, additionally speeds up the crash.
>
>You can use this command to enable the workaround at run-time (it is
>disabled by default):
>
> bash# sysctl -w kernel.8xx_cpu15=1
>
>Please note that for the h/w problem to show up, the instruction
>cache has to be enabled.
>
>Hope this helps.
>
>Best regards,
>
>Wolfgang Denk
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
^ permalink raw reply
* RE: Linux Kernel boot problem
From: Srivatsan @ 2004-12-28 16:42 UTC (permalink / raw)
To: wd; +Cc: linuxppc-embedded
In-Reply-To: <20041228153315.3EF4FC14EC@atlas.denx.de>
[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]
Thanks Mr.Wolfgang.
We were able to see the log buffer. It gave the following data:
00138BD4: 3C 36 3E 4D 65 6D 6F 72 79 20 42 41 54 20 6D 61 |<6>Memory
BAT a|
00138BE4: 70 70 69 6E 67 3A 20 42 41 54 32 3D 31 36 4D 62 |pping:
BAT2=16Mb|
00138BF4: 2C 20 42 41 54 33 3D 30 4D 62 2C 20 72 65 73 69 |, BAT3=0Mb,
resi|
00138C04: 64 75 61 6C 3A 20 30 4D 62 0A 00 00 00 00 00 00 |dual:
0Mb.......|
It is having the data what should be dumped out of Serial port. Any
pointers which can lead us to the problem?
I thanks all of you for your help.
With Best Regards,
C.R.Srivatsan
********************************DISCLAIMER**********************************
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.
****************************************************************************
[-- Attachment #2: Type: text/html, Size: 8562 bytes --]
^ permalink raw reply
* Re: Linux Kernel boot problem
From: Wolfgang Denk @ 2004-12-28 15:33 UTC (permalink / raw)
To: Srivatsan; +Cc: linuxppc-embedded
In-Reply-To: <000601c4eca1$786596f0$1269cb0a@bgcw301>
In message <000601c4eca1$786596f0$1269cb0a@bgcw301> you wrote:
>
> When the Kernel is booted, it prints the following
> Uncompressing Linux.......done
> Now booting the kernel
>
> The kernel hangs(or not detecting the console) after printing the above
> messages. Any pointers would be of great help to us.
See the FAQ section of the DULG, especially:
http://www.denx.de/twiki/bin/view/DULG/LinuxHangsAfterUncompressingKernel
http://www.denx.de/twiki/bin/view/DULG/LinuxPostMortemAnalysis
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
Everyting looks interesting until you do it. Then you find it's just
another job. - Terry Pratchett, _Moving Pictures_
^ permalink raw reply
* Re: simple bootloader 2.6.10-rc3 8xx
From: Wolfgang Denk @ 2004-12-28 9:51 UTC (permalink / raw)
To: Povolotsky, Alexander; +Cc: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 2522 bytes --]
Dear Alex,
in message <313680C9A886D511A06000204840E1CF0A64741E@whq-msgusr-02.pit.comms.marconi.com> you wrote:
>
> >Moving things around in the kernel sometimes
> >makes this go away but really its just hidden.
> >In my case it would explode in zlib_inflate also. Putting some output
> >in the routine would move it ...
>
> Yes that is exactly what I have observed (but I did'nt have the correct
> explanation for it)
I think Paul may be right with his suspicion; it sounds like a
manifestation of the CPU15 problem (but it could also be incorrectly
initialized SDRAMs which fail during heavy load with burst mode
accesses, or one more instability of the 2.6 kernel on 8xx systems).
Note that all our work relating to this problem was done on the 2.4
kernel base, and I make no claims that it might actually help for
your 2.6 problems.
> Could this code be used for 2.6 ?
The patch does not apply cleanly as is to the 2.6 tree, but it should
be simple enough to port.
> Could someone point me to it, please ?
It's in the linuxppc_2_4_devel tree on our CVS server.
Please find attached the patch to the 2.4 kernel tree which
implements the workaround, and a test application to reliably
reproduce the CPU15 errata. It usually takes 1-10 minutes for the
application to crash, if the workaround is disabled:
bash-2.05b# date; ./cpu15 ; date
Thu Aug 2 02:02:42 MEST 2001
Illegal instruction
Thu Aug 2 02:02:54 MEST 2001
bash-2.05b# date; ./cpu15 ; date
Thu Aug 2 02:02:58 MEST 2001
Illegal instruction
Thu Aug 2 02:03:48 MEST 2001
bash-2.05b# date; ./cpu15 ; date
Thu Aug 2 02:03:54 MEST 2001
Illegal instruction
Thu Aug 2 02:03:57 MEST 2001
bash-2.05b# date; ./cpu15 ; date
Thu Aug 2 02:04:07 MEST 2001
Illegal instruction
Thu Aug 2 02:04:16 MEST 2001
bash-2.05b#
We noticed that some background activitly, like logging in/out to the
target via 'telnet', while the application is running over the serial
console, additionally speeds up the crash.
You can use this command to enable the workaround at run-time (it is
disabled by default):
bash# sysctl -w kernel.8xx_cpu15=1
Please note that for the h/w problem to show up, the instruction
cache has to be enabled.
Hope this helps.
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
"Wish not to seem, but to be, the best." - Aeschylus
[-- Attachment #2: patch --]
[-- Type: application/octet-stream , Size: 3305 bytes --]
CVS Root: :pserver:anonymous@www.denx.de:/cvsroot
CVS Module: linuxppc_2_4_devel
PatchSet: 295
Date: 2004/08/25 16:16:30
Log: Implement work-around for CPU15 Silicon Errata on MPC8xx processors.
Signed-off-by: Wolfgang Denk <wd@denx.de>
Index: arch/ppc/8xx_io/Config.in
===================================================================
RCS file: /cvsroot/linuxppc_2_4_devel/arch/ppc/8xx_io/Config.in,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- arch/ppc/8xx_io/Config.in 11 Mar 2004 22:43:31 -0000 1.8
+++ arch/ppc/8xx_io/Config.in 25 Aug 2004 15:16:30 -0000 1.9
@@ -7,6 +7,7 @@
comment 'Generic MPC8xx Options'
bool 'Copy-Back Data Cache (else Writethrough)' CONFIG_8xx_COPYBACK
bool 'CPU6 Silicon Errata (860 Pre Rev. C)' CONFIG_8xx_CPU6
+bool 'CPU15 Silicon Errata' CONFIG_8xx_CPU15
bool 'I2C/SPI Microcode Patch' CONFIG_UCODE_PATCH
if [ "$CONFIG_UCODE_PATCH" = "y" ]; then
bool ' Use MPC850-specific microcode patch' CONFIG_MPC850_UCODE_PATCH
Index: arch/ppc/kernel/head_8xx.S
===================================================================
RCS file: /cvsroot/linuxppc_2_4_devel/arch/ppc/kernel/head_8xx.S,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- arch/ppc/kernel/head_8xx.S 30 Oct 2003 00:32:14 -0000 1.6
+++ arch/ppc/kernel/head_8xx.S 25 Aug 2004 15:16:30 -0000 1.7
@@ -324,6 +324,19 @@
stw r3, 12(r0)
lwz r3, 12(r0)
#endif
+#ifdef CONFIG_8xx_CPU15
+ lis r21, cpu15_fix@h
+ ori r21, r21, cpu15_fix@l
+ tophys(r21,r21)
+ lwz r21, 0(r21) /* value of cpu15 variable */
+ cmpwi r21, 0
+ beq 4f
+ subi r21, r20, 0x1000 /* EA of prev page */
+ tlbie r21
+ addi r21, r20, 0x1000 /* EA of next page */
+ tlbie r21
+4:
+#endif
mtspr MD_EPN, r20 /* Have to use MD_EPN for walk, MI_EPN can't */
mfspr r20, M_TWB /* Get level 1 table entry address */
Index: include/linux/sysctl.h
===================================================================
RCS file: /cvsroot/linuxppc_2_4_devel/include/linux/sysctl.h,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- include/linux/sysctl.h 11 Mar 2004 22:44:32 -0000 1.8
+++ include/linux/sysctl.h 25 Aug 2004 15:16:30 -0000 1.9
@@ -128,6 +128,7 @@
KERN_PPC_L3CR=57, /* l3cr register on PPC */
KERN_EXCEPTION_TRACE=58, /* boolean: exception trace */
KERN_CORE_SETUID=59, /* int: set to allow core dumps of setuid apps */
+ KERN_8XX_CPU15=60, /* boolean: patch cpu15 errata on mpc8xx cpu */
};
Index: kernel/sysctl.c
===================================================================
RCS file: /cvsroot/linuxppc_2_4_devel/kernel/sysctl.c,v
retrieving revision 1.8
retrieving revision 1.9
diff -u -r1.8 -r1.9
--- kernel/sysctl.c 15 Nov 2003 01:37:12 -0000 1.8
+++ kernel/sysctl.c 25 Aug 2004 15:16:30 -0000 1.9
@@ -150,6 +150,10 @@
static void unregister_proc_table(ctl_table *, struct proc_dir_entry *);
#endif
+#ifdef CONFIG_8xx_CPU15
+int cpu15_fix = 0; /* disabled by default */
+#endif
+
/* The default sysctl tables: */
static ctl_table root_table[] = {
@@ -273,6 +277,10 @@
{KERN_EXCEPTION_TRACE,"exception-trace",
&exception_trace,sizeof(int),0644,NULL,&proc_dointvec},
#endif
+#ifdef CONFIG_8xx_CPU15
+ {KERN_8XX_CPU15, "8xx_cpu15", &cpu15_fix, sizeof(int),
+ 0644, NULL, &proc_dointvec},
+#endif
{0}
};
[-- Attachment #3: cpu15.c --]
[-- Type: application/octet-stream , Size: 3411 bytes --]
#include <sys/mman.h>
#include <fcntl.h>
#define MOV(r, val) \
"lis %%"#r", "#val"@h\n" \
"ori %%"#r", %%"#r", "#val"@l\n"
int data = 1; /* read 1 from memory */
void *buffer; /* buffer for code copy */
void test(int copy_code, int offset)
{
asm(
"mflr %%r20\n" /* save lr */
MOV(r24, buffer)
"lwz %%r24, 0(%%r24)\n" /* save buffer address to r24 */
MOV(r22, page0)
MOV(r21, page2)
"sub %%r23, %%r21, %%r22\n" /* page0 code size */
"addi %%r21, %%r24, 0x1000\n" /* page1 */
"sub %%r25, %%r21, %%r23\n" /* save code at end of page0 to r25 */
"cmpwi %1, 0\n"
"beq start\n" /* jump if code_copy == 0 */
"mr %%r21, %%r25\n"
"bl copy\n" /* copy page0 code */
MOV(r22, page2)
MOV(r21, copy)
"sub %%r23, %%r21, %%r22\n" /* page2 code size */
"addi %%r21, %%r24, 0x2000\n" /* page2 */
"bl copy\n" /* copy page2 code */
MOV(r23, 0x10000 / 16) /* buffer size / cache line size */
"mtctr %%r23\n"
"mr %%r21, %%r24\n"
"5:\n"
"dcbst 0, %%r21\n"
"sync\n" /* wait for dcbst to complete on bus */
"icbi 0, %%r21\n"
"sync\n" /* wait for icbi to complete on bus */
"addi %%r21, %%r21, 16\n" /* next cache line */
"bdnz 5b\n"
"isync\n"
"b end\n"
"start:\n"
"bl 4f\n" /* get current pc */
"4:\n"
"mflr %%r26\n"
"addi %%r26, %%r26, end-4b\n" /* save end address to r26 */
"mtlr %%r25\n"
"blr\n" /* jump to page0 code */
"page0:\n"
/* load first cache line at page2 */
"addi %%r21, %%r24, 0x2000+touch-page2\n"
"mtlr %%r21\n"
"blr\n" /* jump to touch */
"1:\n"
/* invalidate first cache line at page1 */
"li %%r23, 0x1000\n"
"icbi %%r24, %%r23\n"
/* trying to make branch address unresolved long enough */
"addi %%r21, %%r24, 0x2000-20\n"
"sub %%r21, %%r21, %0\n" /* add offset */
"li %%r23, 20\n" /* cycle 20 times */
"mtctr %%r23\n"
MOV(r22, data)
"2:\n"
"sync\n"
"lwz %%r23, 0(%%r22)\n" /* add content of data i.e 1 */
"add %%r21, %%r21, %%r23\n"
"bdnz 2b\n"
"mtlr %%r21\n"
"blr\n" /* jump to end of page1 */
"page2:\n"
"b 3f\n" /* invalid or wrong instruction may occur */
"lwz %%r0, 0(%%r0)\n" /* give SIGSEGV */
"touch:\n"
"addi %%r21, %%r25, 1b-page0\n"
"mtlr %%r21\n"
"blr\n" /* jump back to page0 i.e 1b */
"3:\n"
"mtlr %%r26\n"
"blr\n" /* jump to end */
/* memcpy(r21, r22, r23) */
"copy:\n"
"mtctr %%r23\n"
"subi %%r22, %%r22, 1\n"
"subi %%r21, %%r21, 1\n"
"6:\n"
"lbzu %%r23, 1(%%r22)\n"
"stbu %%r23, 1(%%r21)\n"
"bdnz 6b\n"
"blr\n"
"end:\n"
"mtlr %%r20\n" /* restore lr */
: "=r" (offset)
: "r" (copy_code), "r" (offset)
);
}
int main(int argc, char *argv[])
{
int i, fd;
nice(10);
fd = open("cpu15.log", O_CREAT | O_TRUNC | O_RDWR, 0666);
buffer = mmap(0, 0x10000, PROT_READ | PROT_WRITE | PROT_EXEC, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0);
/* fill buffer with bad instructions */
for (i = 0; i < 0x10000 / 4; i++)
#if 0
((int*)buffer)[i] = 0x80000000; /* lwz r0, 0(r0) - give SIGSEGV */
#else
((int*)buffer)[i] = 0x7c0003a6; /* mtspr 0, r0 - give SIGILL */
#endif
/* fill cache line at end of page1 with nop */
for (i = 0; i < 4; i++)
((int*)((int)buffer + 0x1ff0))[i] = 0x60000000; /* nop */
/* copy code to buffer */
test(1, 0);
for (i = 0; ; i++) {
test(0, ((i & 3) << 2) + 4); /* offset 4...16 */
if (i % 1000000 == 0)
write(fd, ".", 1);
}
return 0;
}
^ permalink raw reply
* Re: simple bootloader 2.6.10-rc3 8xx
From: Wolfgang Denk @ 2004-12-28 9:13 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <41D0D368.3080702@conspiracy.net>
In message <41D0D368.3080702@conspiracy.net> Paul Bilke wrote:
>
...
> If you are running a duet variant (870,880,885) there is a CPU errata
> which was the cause in my case.
...
> I hired Wolfgang to implement the suggested work around and I believe he
> has put the necessary code into his 2.4 tree already.
Yes, the CPU15 workaround code is in the linuxppc_2_4_devel tree on
our CVS server:
---------------------
PatchSet 295
Date: 2004/08/25 16:16:30
Author: wd
Branch: HEAD
Tag: (none)
Log:
Implement work-around for CPU15 Silicon Errata on MPC8xx processors.
Members:
arch/ppc/8xx_io/Config.in:1.8->1.9
arch/ppc/kernel/head_8xx.S:1.6->1.7
include/linux/sysctl.h:1.8->1.9
kernel/sysctl.c:1.8->1.9
---------------------
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
Real computer scientists despise the idea of actual hardware. Hard-
ware has limitations, software doesn't. It's a real shame that Turing
machines are so poor at I/O.
^ permalink raw reply
* Out of Office AutoReply: Hi
From: Rich Brian-Q16329 @ 2004-12-28 6:53 UTC (permalink / raw)
To: linuxppc-embedded
I am out of the office until 1/4/05
^ permalink raw reply
* Linux Kernel boot problem
From: Srivatsan @ 2004-12-28 5:52 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1: Type: text/plain, Size: 6617 bytes --]
Hi all,
We are having a Rattler MPC8280 board. We are using Linux Kernel
2.4.21 and the configuration used for building the Linux Kernel is as
given under.
When the Kernel is booted, it prints the following
Uncompressing Linux.......done
Now booting the kernel
The kernel hangs(or not detecting the console) after printing the above
messages. Any pointers would be of great help to us.
With thanks,
C.R.Srivatsan
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_HAVE_DEC_LOCK=y
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
# CONFIG_ADVANCED_OPTIONS is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODVERSIONS=y
CONFIG_KMOD=y
#
# Platform support
#
CONFIG_PPC=y
CONFIG_PPC32=y
CONFIG_6xx=y
# CONFIG_40x is not set
# CONFIG_440 is not set
# CONFIG_POWER3 is not set
# CONFIG_8xx is not set
CONFIG_8260=y
CONFIG_PPC_STD_MMU=y
CONFIG_SERIAL_CONSOLE=y
# CONFIG_ADS8260 is not set
# CONFIG_EST8260 is not set
# CONFIG_SBS8260 is not set
# CONFIG_RPX6 is not set
CONFIG_AM_RATTLER=y
# CONFIG_TQM8260 is not set
# CONFIG_WILLOW is not set
# CONFIG_SMP is not set
CONFIG_REDBOOT=y
CONFIG_EMBEDDEDBOOT=y
#
# General setup
#
# CONFIG_HIGHMEM is not set
# CONFIG_ISA is not set
# CONFIG_EISA is not set
# CONFIG_SBUS is not set
# CONFIG_MCA is not set
# CONFIG_PCI is not set
# CONFIG_8260_PCI9 is not set
# CONFIG_PC_KEYBOARD is not set
CONFIG_NET=y
# CONFIG_SYSCTL is not set
# CONFIG_SYSVIPC is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_KCORE_ELF is not set
# CONFIG_BINFMT_ELF is not set
# CONFIG_KERNEL_ELF is not set
# CONFIG_BINFMT_MISC is not set
# CONFIG_HOTPLUG is not set
# CONFIG_PCMCIA is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=y
# CONFIG_MTD_DEBUG is not set
CONFIG_MTD_PARTITIONS=y
CONFIG_MTD_CONCAT=y
# CONFIG_MTD_REDBOOT_PARTS is not set
# CONFIG_MTD_CMDLINE_PARTS is not set
CONFIG_MTD_CHAR=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_CISS_SCSI_TAPE is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_SIZE=4096
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_BLK_STATS is not set
#
# Networking options
#
# CONFIG_PACKET is not set
# CONFIG_NETLINK_DEV is not set
# CONFIG_NETFILTER is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
# CONFIG_IP_PNP_DHCP is not set
CONFIG_IP_PNP_BOOTP=y
CONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
# CONFIG_INET_ECN is not set
CONFIG_SYN_COOKIES=y
# CONFIG_IPV6 is not set
# CONFIG_KHTTPD is not set
# CONFIG_ATM is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
# CONFIG_MACE is not set
# CONFIG_BMAC is not set
# CONFIG_GMAC is not set
# CONFIG_SUNLANCE is not set
# CONFIG_SUNBMAC is not set
# CONFIG_SUNQE is not set
# CONFIG_SUNGEM is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
# CONFIG_NET_ISA is not set
# CONFIG_NET_PCI is not set
# CONFIG_NET_POCKET is not set
#
# File systems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_ADFS_FS is not set
# CONFIG_ADFS_FS_RW is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BEFS_DEBUG is not set
# CONFIG_BFS_FS is not set
# CONFIG_EXT3_FS is not set
# CONFIG_JBD is not set
# CONFIG_JBD_DEBUG is not set
# CONFIG_FAT_FS is not set
# CONFIG_MSDOS_FS is not set
# CONFIG_UMSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS_FS=y
CONFIG_JFFS_FS_VERBOSE=0
# CONFIG_JFFS_PROC_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
# CONFIG_CRAMFS is not set
CONFIG_TMPFS=y
CONFIG_RAMFS=y
# CONFIG_ISO9660_FS is not set
# CONFIG_JOLIET is not set
# CONFIG_ZISOFS is not set
# CONFIG_JFS_FS is not set
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_NTFS_RW is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_DEVFS_FS is not set
# CONFIG_DEVFS_MOUNT is not set
# CONFIG_DEVFS_DEBUG is not set
# CONFIG_DEVPTS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX4FS_RW is not set
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UDF_FS is not set
# CONFIG_UDF_RW is not set
# CONFIG_UFS_FS is not set
# CONFIG_UFS_FS_WRITE is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_INTERMEZZO_FS is not set
CONFIG_NFS_FS=y
# CONFIG_NFS_V3 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFSD is not set
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not set
# CONFIG_SUNRPC is not set
# CONFIG_LOCKD is not set
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
# CONFIG_NCPFS_PACKET_SIGNING is not set
# CONFIG_NCPFS_IOCTL_LOCKING is not set
# CONFIG_NCPFS_STRONG is not set
# CONFIG_NCPFS_NFS_NS is not set
# CONFIG_NCPFS_OS2_NS is not set
# CONFIG_NCPFS_SMALLDOS is not set
# CONFIG_NCPFS_NLS is not set
# CONFIG_NCPFS_EXTRAS is not set
# CONFIG_ZISOFS_FS is not set
#
# MPC8260 CPM Options
#
CONFIG_SCC_CONSOLE=y
# CONFIG_SCC_ENET is not set
CONFIG_FEC_ENET=y
CONFIG_FCC1_ENET=y
CONFIG_FCC2_ENET=y
# CONFIG_FCC3_ENET is not set
# CONFIG_USE_MDIO is not set
#
# Library routines
#
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
********************************DISCLAIMER**********************************
This e-mail and any attachment is for authorised use by the intended
recipient(s) only. It may contain proprietary material, confidential
information and/or be subject to legal privilege of Deccanet Designs Ltd.
If you have received this message in error, please notify the originator
immediately. If you are not the intended recipient, you are notified that
you are strictly prohibited from retaining, using, copying, altering or
disclosing the contents of this message.
****************************************************************************
[-- Attachment #2: Type: text/html, Size: 70301 bytes --]
^ permalink raw reply
* RE: simple bootloader 2.6.10-rc3 8xx
From: Povolotsky, Alexander @ 2004-12-28 3:52 UTC (permalink / raw)
To: 'paul.bilke'; +Cc: linuxppc-embedded
Thanks - yes, I have 885 !
>Moving things around in the kernel sometimes
>makes this go away but really its just hidden.
>In my case it would explode in zlib_inflate also. Putting some output
>in the routine would move it ...
Yes that is exactly what I have observed (but I did'nt have the correct
explanation for it)
That is what I wrote recently as an observation for myself (but did not
posted it):
"I could see very few debugging outputs.
For example, I need to comment out the section of the load_kernel()
....
while ( *cp )
putc(*cp++);
while (timer++ < 5*1000) {
if (tstc()) {
while ((ch = getc()) != '\n' && ch != '\r') {
if (ch == '\b' || ch == '\177') {
if (cp != cmd_line) {
cp--;
puts("\b \b");
}
} else if (ch == '\030' /* ^x */
|| ch == '\025') { /* ^u */
while (cp != cmd_line) {
cp--;
puts("\b \b");
}
} else {
*cp++ = ch;
putc(ch);
}
}
break; /* Exit 'timer' loop */
}
udelay(1000); /* 1 msec */
}
....
which prints command line string - in order to see my further down debugging
puts() statements in gunzip() ..."
>I hired Wolfgang to implement the suggested work around and I believe he
>has put the necessary code into his 2.4 tree already.
Could this code be used for 2.6 ?
Could someone point me to it, please ?
Thanks,
Best Regards,
Alex
-----Original Message-----
From: paul.bilke [mailto:listmail@conspiracy.net]
Sent: Monday, December 27, 2004 10:31 PM
To: Povolotsky, Alexander
Cc: 'Tom Rini'; 'wd@denx.de'; 'Kumar Gala'; dan@embeddededge.com;
linuxppc-embedded@ozlabs.org
Subject: Re: simple bootloader 2.6.10-rc3 8xx
This sounds extremely familiar to me, and wd has already fixed it for
me, and I suspect for you to.
If you are running a duet variant (870,880,885) there is a CPU errata
which was the cause in my case.
Look here http://www.freescale.com/files/32bit/doc/errata/MPC885CE.pdf
and at the CPU15 section. Moving things around in the kernel sometimes
makes this go away but really its just hidden.
In my case it would explode in zlib_inflate also. Putting some output
in the routine would move it so it did not fail but since
these loops were executed 1000's of times it would take many minutes to
boot.
I hired Wolfgang to implement the suggested work around and I believe he
has put the necessary code into his 2.4 tree already.
It should be possable to port to you kernel, whatever it is. As I
remember it would fail with the instruction pointer always ending in 000.
Hopefully this will help
Paul Bilke
Povolotsky, Alexander wrote:
>Hi,
>
>I have in .config
>...
>CONFIG_ADVANCED_OPTIONS=y
>CONFIG_HIGHMEM_START=0xfe000000
># CONFIG_LOWMEM_SIZE_BOOL is not set
>CONFIG_LOWMEM_SIZE=0x30000000
>CONFIG_KERNEL_START_BOOL=y
>CONFIG_KERNEL_START=0xc0000000
># CONFIG_TASK_SIZE_BOOL is not set
>CONFIG_TASK_SIZE=0x80000000
># CONFIG_CONSISTENT_START_BOOL is not set
>CONFIG_CONSISTENT_START=0xff100000
># CONFIG_CONSISTENT_SIZE_BOOL is not set
>CONFIG_CONSISTENT_SIZE=0x00200000
>CONFIG_BOOT_LOAD_BOOL=y
>CONFIG_BOOT_LOAD=0x00400000
>...
>
>I get (I did not include ramdisk/initrd into the image loaded) :
>
>loaded at: 00180000 00268160
>relocated to: 00400000 004E8160
>board data at: 004E6124 004E6140
>relocated to: 0040509C 004050B8
>zimage at: 00405891 004E5926
>avail ram: 004E9000 02000000
>
>Is above dispostion looks correct ?
>
>Then load_kernel() (in arch/ppc/boot/simple/misc-embedded.c) fails during
>uncompressing kernel whithin:
>
>gunzip(0, 0x400000, zimage_start, &zimage_size);
>
>Specifically within gunzip() (in arch/ppc/boot/common/misc-common.c) it
>fails after successfully passing
>through zlib_inflateInit2() . I think it fails in in zlib_inflate() .
>
>Any ideas/advise ?
>Why second argument while calling gunzip() is set to 0x400000 ?
>
>Thanks,
>Alex
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: simple bootloader 2.6.10-rc3 8xx
From: paul.bilke @ 2004-12-28 3:30 UTC (permalink / raw)
To: Povolotsky, Alexander; +Cc: linuxppc-embedded
In-Reply-To: <313680C9A886D511A06000204840E1CF0A64741C@whq-msgusr-02.pit.comms.marconi.com>
This sounds extremely familiar to me, and wd has already fixed it for
me, and I suspect for you to.
If you are running a duet variant (870,880,885) there is a CPU errata
which was the cause in my case.
Look here http://www.freescale.com/files/32bit/doc/errata/MPC885CE.pdf
and at the CPU15 section. Moving things around in the kernel sometimes
makes this go away but really its just hidden.
In my case it would explode in zlib_inflate also. Putting some output
in the routine would move it so it did not fail but since
these loops were executed 1000's of times it would take many minutes to
boot.
I hired Wolfgang to implement the suggested work around and I believe he
has put the necessary code into his 2.4 tree already.
It should be possable to port to you kernel, whatever it is. As I
remember it would fail with the instruction pointer always ending in 000.
Hopefully this will help
Paul Bilke
Povolotsky, Alexander wrote:
>Hi,
>
>I have in .config
>...
>CONFIG_ADVANCED_OPTIONS=y
>CONFIG_HIGHMEM_START=0xfe000000
># CONFIG_LOWMEM_SIZE_BOOL is not set
>CONFIG_LOWMEM_SIZE=0x30000000
>CONFIG_KERNEL_START_BOOL=y
>CONFIG_KERNEL_START=0xc0000000
># CONFIG_TASK_SIZE_BOOL is not set
>CONFIG_TASK_SIZE=0x80000000
># CONFIG_CONSISTENT_START_BOOL is not set
>CONFIG_CONSISTENT_START=0xff100000
># CONFIG_CONSISTENT_SIZE_BOOL is not set
>CONFIG_CONSISTENT_SIZE=0x00200000
>CONFIG_BOOT_LOAD_BOOL=y
>CONFIG_BOOT_LOAD=0x00400000
>...
>
>I get (I did not include ramdisk/initrd into the image loaded) :
>
>loaded at: 00180000 00268160
>relocated to: 00400000 004E8160
>board data at: 004E6124 004E6140
>relocated to: 0040509C 004050B8
>zimage at: 00405891 004E5926
>avail ram: 004E9000 02000000
>
>Is above dispostion looks correct ?
>
>Then load_kernel() (in arch/ppc/boot/simple/misc-embedded.c) fails during
>uncompressing kernel whithin:
>
>gunzip(0, 0x400000, zimage_start, &zimage_size);
>
>Specifically within gunzip() (in arch/ppc/boot/common/misc-common.c) it
>fails after successfully passing
>through zlib_inflateInit2() . I think it fails in in zlib_inflate() .
>
>Any ideas/advise ?
>Why second argument while calling gunzip() is set to 0x400000 ?
>
>Thanks,
>Alex
>
>_______________________________________________
>Linuxppc-embedded mailing list
>Linuxppc-embedded@ozlabs.org
>https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
^ permalink raw reply
* Re: [FYI] linux 2.6 still not working with PReP (ppc32)
From: Marc Dietrich @ 2004-12-27 21:37 UTC (permalink / raw)
To: Christian; +Cc: linuxppc-dev
In-Reply-To: <41CF77A9.9040405@gmx.net>
[-- Attachment #1: Type: text/plain, Size: 3220 bytes --]
Hallo Christian,
Am Montag, 27. Dezember 2004 03:47 schrieben Sie:
> Marc Dietrich schrieb:
>
> > I also tried to change the irq routings in prep_pci.c like in the latest
> > patch with the sym53c8xx_2 driver,
> > Slot 12 -> IRQ 15 (sym53c825)
> > Slot 15 -> IRQ 11 (dec 21140)
> > but this didn't helped.
>
> i'm still working these out too, gotta find some time...
maybe this helps:
I used the config file you sent me (and added serial console).
when booting a working 2.4.24-pre1 I get:
[...]
PCI: Probing PCI hardware
Setting PCI interrupts for a "Utah (Powerstack II Pro4000)"
PCI: moved device 00:0b.1 resource 4 (101) to 1480
PCI: moved device 00:0b.1 resource 5 (101) to 1490
PCI: moved device 00:11.0 resource 0 (1208) to 0
[...]
SCSI subsystem driver Revision: 1.00
new devtbl [4096] @c049e000.
PCI: Enabling device 00:0c.0 (0000 -> 0003)
sym53c8xx: at PCI bus 0, device 12, function 0
sym53c8xx: setting PCI_COMMAND_MASTER PCI_COMMAND_PARITY...(fix-up)
sym53c8xx: changing PCI_LATENCY_TIMER from 0 to 80.
sym53c8xx: 53c825a detected
sym53c825a-0: rev 0x13 on pci bus 0 device 12 function 0 irq 15
new MPOOL [ 188] @c049f000.
new VTOB [ 12] @c049f100.
new NCB [2408] @c049c000.
new SQUEUE [2336] @c049d000.
new VTOB [ 12] @c049f110.
new DQUEUE [2336] @c049a000.
new TARGTBL [ 256] @c049b000.
new VTOB [ 12] @c049f120.
new SCRIPT [3504] @c0498000.
new SCRIPTH [1504] @c049b800.
new CCB [1300] @c0499000.
sym53c825a-0: ID 7, Fast-10, Parity Checking
while booting a non working 2.6.10 I get:
I already changed the irq of slot 12 to 15 and slot 14 to irq 11.
[...]
PCI: Probing PCI hardware
Setting PCI interrupts for a "Utah (Powerstack II Pro4000)"
PCI: Cannot allocate resource region 5 of device 0000:00:01.1
SCSI subsystem initialized
[...]
PCI: Enabling device 0000:00:02.0 (0000 -> 0003)
sym0: <825a> rev 0x13 at pci 0000:00:02.0 irq 15
new MPOOL [ 180] @c7d99000.
new VTOB [ 12] @c7d99100.
new HCB [1784] @c7d9a000.
sym0: No NVRAM, ID 7, Fast-10, SE, parity checking
new VTOB [ 12] @c7d99110.
new SQUEUE [3600] @c7d9b000.
new VTOB [ 12] @c7d99120.
new DQUEUE [3600] @c7d9c000.
new TARGTBL [ 256] @c7d9a800.
new VTOB [ 12] @c7d99130.
new SCRIPTA0 [3024] @c7d9d000.
new VTOB [ 12] @c7d99140.
new SCRIPTB0 [1324] @c7d9e000.
new SCRIPTZ0 [ 32] @c7d9a900.
new CCBH [1024] @c7d99400.
new CCB [ 988] @c7d9ac00.
new SNS_BBUF [ 32] @c7d9a920.
[...]
new BADLUNTBL [ 256] @c7d9aa00.
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18m
elevator: using anticipatory as default io scheduler
sym0:0:0:ccb @c7d9ac00 using tag 256.
sym0: queuepos=2.
sym0:0:0: ABORT operation started.
sym0:0:0: ABORT operation timed-out.
sym0:0:0: DEVICE RESET operation started.
sym0:0:0: DEVICE RESET operation timed-out.
sym0:0:0: BUS RESET operation started.
sym0:0:0: BUS RESET operation timed-out.
sym0:0:0: HOST RESET operation started.
sym0:0:0:ccb @c7d9ac00 freeing tag 256.
sym0: SCSI BUS has been reset.
[ hangs here ]
Indeed, there seems to be something wrong with the pci resources - but I can't
say what. I attached the compete boot logs. I also attached the lspci -v
output.
Greetings
Marc
[-- Attachment #2: boot.log-2.4.24-pre1.bz2 --]
[-- Type: application/x-bzip2, Size: 3130 bytes --]
[-- Attachment #3: boot.log-2.6.10.bz2 --]
[-- Type: application/x-bzip2, Size: 1181 bytes --]
[-- Attachment #4: lspci-v --]
[-- Type: text/plain, Size: 2348 bytes --]
00:0b.0 ISA bridge: Symphony Labs W83C553 (rev 10)
Flags: bus master, medium devsel, latency 0
00:0b.1 IDE interface: Symphony Labs SL82c105 (rev 05) (prog-if 8f [Master SecP SecO PriP PriO])
Flags: medium devsel
I/O ports at 01f0 [disabled] [size=8]
I/O ports at 03f4 [disabled] [size=4]
I/O ports at 0170 [disabled] [size=8]
I/O ports at 0374 [disabled] [size=4]
I/O ports at 1480 [disabled] [size=16]
I/O ports at 1490 [disabled] [size=16]
00:0c.0 SCSI storage controller: LSI Logic / Symbios Logic 53c825 (rev 13)
Flags: bus master, medium devsel, latency 80, IRQ 15
I/O ports at 1000 [size=256]
Memory at c200c000 (32-bit, non-prefetchable) [size=256]
Memory at c200d000 (32-bit, non-prefetchable) [size=4K]
00:0e.0 Ethernet controller: Digital Equipment Corporation DECchip 21140 [FasterNet] (rev 22)
Flags: bus master, medium devsel, latency 0, IRQ 11
I/O ports at 1400 [size=128]
Memory at c200e000 (32-bit, non-prefetchable) [size=128]
Expansion ROM at c1040000 [disabled] [size=256K]
00:11.0 VGA compatible controller: Cirrus Logic GD 5446 (prog-if 00 [VGA])
Flags: medium devsel, IRQ 11
Memory at c0000000 (32-bit, prefetchable) [size=16M]
Expansion ROM at c2000000 [disabled] [size=32K]
00:12.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
Subsystem: ALi Corporation USB 1.1 Controller
Flags: 66Mhz, medium devsel, IRQ 15
Memory at c2008000 (32-bit, non-prefetchable) [disabled] [size=4K]
Capabilities: <available only to root>
00:12.1 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
Subsystem: ALi Corporation USB 1.1 Controller
Flags: 66Mhz, medium devsel, IRQ 15
Memory at c2009000 (32-bit, non-prefetchable) [disabled] [size=4K]
Capabilities: <available only to root>
00:12.2 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if 10 [OHCI])
Subsystem: ALi Corporation USB 1.1 Controller
Flags: 66Mhz, medium devsel, IRQ 15
Memory at c200a000 (32-bit, non-prefetchable) [disabled] [size=4K]
Capabilities: <available only to root>
00:12.3 USB Controller: ALi Corporation USB 2.0 Controller (rev 01) (prog-if 20 [EHCI])
Subsystem: ALi Corporation USB 2.0 Controller
Flags: 66Mhz, medium devsel, IRQ 15
Memory at c200b000 (32-bit, non-prefetchable) [disabled] [size=256]
Capabilities: <available only to root>
^ permalink raw reply
* simple bootloader 2.6.10-rc3 8xx
From: Povolotsky, Alexander @ 2004-12-27 20:38 UTC (permalink / raw)
To: 'Tom Rini', 'wd@denx.de', 'Kumar Gala',
dan
Cc: linuxppc-embedded
Hi,
I have in .config
...
CONFIG_ADVANCED_OPTIONS=y
CONFIG_HIGHMEM_START=0xfe000000
# CONFIG_LOWMEM_SIZE_BOOL is not set
CONFIG_LOWMEM_SIZE=0x30000000
CONFIG_KERNEL_START_BOOL=y
CONFIG_KERNEL_START=0xc0000000
# CONFIG_TASK_SIZE_BOOL is not set
CONFIG_TASK_SIZE=0x80000000
# CONFIG_CONSISTENT_START_BOOL is not set
CONFIG_CONSISTENT_START=0xff100000
# CONFIG_CONSISTENT_SIZE_BOOL is not set
CONFIG_CONSISTENT_SIZE=0x00200000
CONFIG_BOOT_LOAD_BOOL=y
CONFIG_BOOT_LOAD=0x00400000
...
I get (I did not include ramdisk/initrd into the image loaded) :
loaded at: 00180000 00268160
relocated to: 00400000 004E8160
board data at: 004E6124 004E6140
relocated to: 0040509C 004050B8
zimage at: 00405891 004E5926
avail ram: 004E9000 02000000
Is above dispostion looks correct ?
Then load_kernel() (in arch/ppc/boot/simple/misc-embedded.c) fails during
uncompressing kernel whithin:
gunzip(0, 0x400000, zimage_start, &zimage_size);
Specifically within gunzip() (in arch/ppc/boot/common/misc-common.c) it
fails after successfully passing
through zlib_inflateInit2() . I think it fails in in zlib_inflate() .
Any ideas/advise ?
Why second argument while calling gunzip() is set to 0x400000 ?
Thanks,
Alex
^ permalink raw reply
* Re: PATCH uninorth3 (G5) agp support
From: Benjamin Herrenschmidt @ 2004-12-27 13:52 UTC (permalink / raw)
To: Jerome Glisse; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <41D01309.3000304@free.fr>
> I got some lockup after adding agp support but i don't know if
> it came from my playing with the r300 (most probable
> source :)) or from the cache collision you are talking about.
>
> Anyway it's not time to think to that :) Have good hollydays.
>
> I will look a bit further in this to see if i can find anythings
> that may helps.
One possiblily to fix the potential issue of cache collision would be to
steal the AGP pages from the hugetlb pool (large pages) instead of small
4k pages. This would make it possible to unmap them individually from
the kernel linear mapping...
Ben.
^ permalink raw reply
* Re: PATCH uninorth3 (G5) agp support
From: Jerome Glisse @ 2004-12-27 13:50 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <1104154320.23891.27.camel@gaston>
>Sure. There is still a pending issue though with AGP on the G5. The
>problem is that we create a non-cacheable mapping for the RAM pages of
>the AGP aperture (both in-kernel and for userland) while they already
>have a cacheable mapping via the normal kernel linear mapping of main
>memory.
>
>The result is that there is a potential cache aliasing issue, aggravated
>by the fact that the G5 is quite aggressive on pre-fetching and thuis,
>may end up prefetching some of the AGP cache lines (via the linear
>mapping) even if no actual access is ever done to these pages.
>
>Unfortunately, if a collision occurs (a non-cacheable access to some
>space that do exist in the cache at the same time), the result is
>undefined, and is likely to result in a checkstop (the CPU just stops).
>
>I really don't know of a simple remedy at this point. The problem is
>partially due to the fact that we do the linear mapping using large
>pages, so we can't simply undo the cacheable mapping for the pages that
>ended up beeing allocated for AGP... An option would be to eventually
>reserve the AGP memory early during boot and not include it in the
>linear mapping at all. Another thing to test is that maybe U3 is smart
>enough to snoop AGP accesses, and thus we could have the AGP mappings be
>cacheable as well (though that may require some stronger synchronisation
>directives in the DRM code).
>
>Ben.
>
>
I got some lockup after adding agp support but i don't know if
it came from my playing with the r300 (most probable
source :)) or from the cache collision you are talking about.
Anyway it's not time to think to that :) Have good hollydays.
I will look a bit further in this to see if i can find anythings
that may helps.
best,
Jerome Glisse
^ permalink raw reply
* Re: PATCH uninorth3 (G5) agp support
From: Benjamin Herrenschmidt @ 2004-12-27 13:32 UTC (permalink / raw)
To: Jerome Glisse; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <41D00564.6010507@free.fr>
On Mon, 2004-12-27 at 13:51 +0100, Jerome Glisse wrote:
> I changed the name to proper one :) And masked
> the rev version, Darwin do so to even if it is unlikely
> that such revision have been used for production.
Good !
> thanx for your comments, will you push it too the kernel.
> (after testing) or doI i have to send it elsewhere ? :)
Nah, I'll take care of it when I'm back from vacation.
> Anyway this is not a critical issue but if we manage to
> make the r300 chipset working (even only for 2d accel)
> than this could be usefull for users :)
Sure. There is still a pending issue though with AGP on the G5. The
problem is that we create a non-cacheable mapping for the RAM pages of
the AGP aperture (both in-kernel and for userland) while they already
have a cacheable mapping via the normal kernel linear mapping of main
memory.
The result is that there is a potential cache aliasing issue, aggravated
by the fact that the G5 is quite aggressive on pre-fetching and thuis,
may end up prefetching some of the AGP cache lines (via the linear
mapping) even if no actual access is ever done to these pages.
Unfortunately, if a collision occurs (a non-cacheable access to some
space that do exist in the cache at the same time), the result is
undefined, and is likely to result in a checkstop (the CPU just stops).
I really don't know of a simple remedy at this point. The problem is
partially due to the fact that we do the linear mapping using large
pages, so we can't simply undo the cacheable mapping for the pages that
ended up beeing allocated for AGP... An option would be to eventually
reserve the AGP memory early during boot and not include it in the
linear mapping at all. Another thing to test is that maybe U3 is smart
enough to snoop AGP accesses, and thus we could have the AGP mappings be
cacheable as well (though that may require some stronger synchronisation
directives in the DRM code).
Ben.
^ permalink raw reply
* Re: PATCH uninorth3 (G5) agp support
From: Jerome Glisse @ 2004-12-27 12:51 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <1104137527.5615.20.camel@gaston>
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
I changed the name to proper one :) And masked
the rev version, Darwin do so to even if it is unlikely
that such revision have been used for production.
thanx for your comments, will you push it too the kernel
(after testing) or do i have to send it elsewhere ? :)
Anyway this is not a critical issue but if we manage to
make the r300 chipset working (even only for 2d accel)
than this could be usefull for users :)
best,
Jerome Glisse
[-- Attachment #2: uninorth-patch3 --]
[-- Type: text/plain, Size: 8816 bytes --]
diff -Naur linux/drivers/char/agp/uninorth-agp.c linux-new/drivers/char/agp/uninorth-agp.c
--- linux/drivers/char/agp/uninorth-agp.c 2004-12-26 14:39:28.000000000 +0100
+++ linux-new/drivers/char/agp/uninorth-agp.c 2004-12-27 13:41:04.244856640 +0100
@@ -8,8 +8,37 @@
#include <linux/agp_backend.h>
#include <asm/uninorth.h>
#include <asm/pci-bridge.h>
+#include <asm/sections.h>
+#include <asm/prom.h>
#include "agp.h"
+/*
+ * NOTES for uninorth3 (G5 AGP) supports :
+ *
+ * This are redundant with arch/ppc(64)/platforms/pmac_features.c,
+ * we need to know uninorth_rev any other way ?
+ *
+ * There maybe also possibility to have bigger cache line size for
+ * agp (see pmac_pci.c and look for cache line). Need to be investigated
+ * by someone.
+ *
+ * Darwin seems to add UNI_N_CFG_GART_PERFRD for all agp3 controller but
+ * this seems to work without this, so in order to minimize code differences
+ * between AGP2 & AGP3 uninorth, i do not set this.
+ *
+ * PAGE size are hardcoded but this may change, see asm/page.h.
+ *
+ * Jerome Glisse <j.glisse@free.fr>
+ */
+static struct device_node* uninorth_node __pmacdata;
+static u32 __iomem * uninorth_base __pmacdata;
+static u32 uninorth_rev __pmacdata;
+
+/*
+ * Uninorth reg. access. Note that Uni-N regs are big endian
+ */
+#define UN_REG(r) (uninorth_base + ((r) >> 2))
+
static int uninorth_fetch_size(void)
{
int i;
@@ -17,7 +46,7 @@
struct aper_size_info_32 *values;
pci_read_config_dword(agp_bridge->dev, UNI_N_CFG_GART_BASE, &temp);
- temp &= ~(0xfffff000);
+ temp &= ~PAGE_MASK;
values = A_SIZE_32(agp_bridge->driver->aperture_sizes);
for (i = 0; i < agp_bridge->driver->num_aperture_sizes; i++) {
@@ -73,7 +102,7 @@
/* aperture size and gatt addr */
pci_write_config_dword(agp_bridge->dev,
UNI_N_CFG_GART_BASE,
- (agp_bridge->gatt_bus_addr & 0xfffff000)
+ (agp_bridge->gatt_bus_addr & PAGE_MASK)
| current_size->size_value);
/* HACK ALERT
@@ -111,14 +140,56 @@
}
for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
- agp_bridge->gatt_table[j] = cpu_to_le32((mem->memory[i] & 0xfffff000) | 0x00000001UL);
+ agp_bridge->gatt_table[j] = cpu_to_le32((mem->memory[i] &
+ PAGE_MASK) |
+ 0x00000001UL);
flush_dcache_range((unsigned long)__va(mem->memory[i]),
(unsigned long)__va(mem->memory[i])+0x1000);
}
(void)in_le32((volatile u32*)&agp_bridge->gatt_table[pg_start]);
mb();
flush_dcache_range((unsigned long)&agp_bridge->gatt_table[pg_start],
- (unsigned long)&agp_bridge->gatt_table[pg_start + mem->page_count]);
+ (unsigned long)&agp_bridge->gatt_table[pg_start +
+ mem->page_count]);
+
+ uninorth_tlbflush(mem);
+ return 0;
+}
+
+static int uninorth3_insert_memory(struct agp_memory *mem, off_t pg_start,
+ int type)
+{
+ int i, j, num_entries;
+ void *temp;
+
+ temp = agp_bridge->current_size;
+ num_entries = A_SIZE_32(temp)->num_entries;
+
+ if (type != 0 || mem->type != 0)
+ /* We know nothing of memory types */
+ return -EINVAL;
+ if ((pg_start + mem->page_count) > num_entries)
+ return -EINVAL;
+
+ j = pg_start;
+
+ while (j < (pg_start + mem->page_count)) {
+ if (!PGE_EMPTY(agp_bridge, agp_bridge->gatt_table[j]))
+ return -EBUSY;
+ j++;
+ }
+
+ for (i = 0, j = pg_start; i < mem->page_count; i++, j++) {
+ agp_bridge->gatt_table[j] = ((mem->memory[i] >> PAGE_SHIFT) |
+ 0x80000000UL);
+ flush_dcache_range((unsigned long)__va(mem->memory[i]),
+ (unsigned long)__va(mem->memory[i])+0x1000);
+ }
+ (void)in_le32((volatile u32*)&agp_bridge->gatt_table[pg_start]);
+ mb();
+ flush_dcache_range((unsigned long)&agp_bridge->gatt_table[pg_start],
+ (unsigned long)&agp_bridge->gatt_table[pg_start +
+ mem->page_count]);
uninorth_tlbflush(mem);
return 0;
@@ -134,7 +205,23 @@
&command);
command = agp_collect_device_status(mode, command);
- command |= 0x100;
+ command |= UNI_N_CFG_GART_ENABLE;
+
+ if(uninorth_rev == 0x21) {
+ /*
+ * Darwin disable AGP 4x on this revision, thus we
+ * may assume it's broken. This is an AGP2 controller.
+ */
+ command &= ~AGPSTAT2_4X;
+ }
+
+ if((uninorth_rev >= 0x30) && (uninorth_rev <= 0x33)) {
+ /*
+ * We need to to set REQ_DEPTH to 7 for U3 versions 1.0, 2.1,
+ * 2.2 and 2.3, Darwin do so.
+ */
+ command |= (7 << AGPSTAT_RQ_DEPTH_SHIFT);
+ }
uninorth_tlbflush(NULL);
@@ -146,11 +233,17 @@
pci_read_config_dword(agp_bridge->dev,
agp_bridge->capndx + PCI_AGP_COMMAND,
&scratch);
- } while ((scratch & 0x100) == 0 && ++timeout < 1000);
- if ((scratch & 0x100) == 0)
+ } while ((scratch & UNI_N_CFG_GART_ENABLE) == 0 && ++timeout < 1000);
+ if ((scratch & UNI_N_CFG_GART_ENABLE) == 0)
printk(KERN_ERR PFX "failed to write UniNorth AGP command reg\n");
- agp_device_command(command, 0);
+ if (agp_bridge->dev->device == PCI_DEVICE_ID_APPLE_U3_AGP) {
+ /* This is an AGP V3 */
+ agp_device_command(command, TRUE);
+ } else {
+ /* AGP V2 */
+ agp_device_command(command, FALSE);
+ }
uninorth_tlbflush(NULL);
}
@@ -258,6 +351,22 @@
{4, 1024, 0, 1}
};
+static struct aper_size_info_32 u3_sizes[8] =
+{
+/*
+ * Not sure that uninorth3 supports that high aperture sizes but it
+ * would strange if it did not :)
+ */
+ {512, 131072, 7, 128},
+ {256, 65536, 6, 64},
+ {128, 32768, 5, 32},
+ {64, 16384, 4, 16},
+ {32, 8192, 3, 8},
+ {16, 4096, 2, 4},
+ {8, 2048, 1, 2},
+ {4, 1024, 0, 1}
+};
+
struct agp_bridge_driver uninorth_agp_driver = {
.owner = THIS_MODULE,
.aperture_sizes = (void *)uninorth_sizes,
@@ -299,6 +408,10 @@
.device_id = PCI_DEVICE_ID_APPLE_UNI_N_AGP2,
.chipset_name = "UniNorth 2",
},
+ {
+ .device_id = PCI_DEVICE_ID_APPLE_U3_AGP,
+ .chipset_name = "U3",
+ },
};
static int __devinit agp_uninorth_probe(struct pci_dev *pdev,
@@ -327,6 +440,33 @@
return -ENODEV;
found:
+ /* Locate core99 Uni-N */
+ uninorth_node = of_find_node_by_name(NULL, "uni-n");
+ /* Locate G5 u3 */
+ if (uninorth_node == NULL) {
+ uninorth_node = of_find_node_by_name(NULL, "u3");
+ }
+ if (uninorth_node && uninorth_node->n_addrs > 0) {
+ unsigned long address = uninorth_node->addrs[0].address;
+ uninorth_base = ioremap(address, 0x40000);
+ uninorth_rev = in_be32(UN_REG(UNI_N_VERSION));
+ }
+
+ /*
+ * Set specific functions & values for agp3 controller.
+ */
+ if (pdev->device == PCI_DEVICE_ID_APPLE_U3_AGP) {
+ uninorth_agp_driver.insert_memory = uninorth3_insert_memory;
+ uninorth_agp_driver.aperture_sizes = (void *)u3_sizes;
+ uninorth_agp_driver.num_aperture_sizes = 8;
+ /*
+ * Some revs have some high bits sets in the version register,
+ * mask it thus they won't mess up with the version number
+ */
+ uninorth_rev &= 0x3f;
+ }
+
+
bridge = agp_alloc_bridge();
if (!bridge)
return -ENOMEM;
diff -Naur linux/include/asm/uninorth.h linux-new/include/asm/uninorth.h
--- linux/include/asm/uninorth.h 2004-12-26 14:40:03.000000000 +0100
+++ linux-new/include/asm/uninorth.h 2004-12-27 13:41:16.059060608 +0100
@@ -34,6 +34,11 @@
#define UNI_N_CFG_GART_ENABLE 0x00000100
#define UNI_N_CFG_GART_2xRESET 0x00010000
#define UNI_N_CFG_GART_DISSBADET 0x00020000
+/* The following seems to only be used only on U3 <j.glisse@free.fr> */
+#define U3_N_CFG_GART_SYNCMODE 0x00040000
+#define U3_N_CFG_GART_PERFRD 0x00080000
+#define U3_N_CFG_GART_B2BGNT 0x00200000
+#define U3_N_CFG_GART_FASTDDR 0x00400000
/* My understanding of UniNorth AGP as of UniNorth rev 1.0x,
* revision 1.5 (x4 AGP) may need further changes.
diff -Naur linux/include/asm-ppc/uninorth.h linux-new/include/asm-ppc/uninorth.h
--- linux/include/asm-ppc/uninorth.h 2004-12-26 14:40:03.000000000 +0100
+++ linux-new/include/asm-ppc/uninorth.h 2004-12-27 13:41:16.059060608 +0100
@@ -34,6 +34,11 @@
#define UNI_N_CFG_GART_ENABLE 0x00000100
#define UNI_N_CFG_GART_2xRESET 0x00010000
#define UNI_N_CFG_GART_DISSBADET 0x00020000
+/* The following seems to only be used only on U3 <j.glisse@free.fr> */
+#define U3_N_CFG_GART_SYNCMODE 0x00040000
+#define U3_N_CFG_GART_PERFRD 0x00080000
+#define U3_N_CFG_GART_B2BGNT 0x00200000
+#define U3_N_CFG_GART_FASTDDR 0x00400000
/* My understanding of UniNorth AGP as of UniNorth rev 1.0x,
* revision 1.5 (x4 AGP) may need further changes.
diff -Naur linux/include/linux/pci_ids.h linux-new/include/linux/pci_ids.h
--- linux/include/linux/pci_ids.h 2004-12-26 14:40:05.000000000 +0100
+++ linux-new/include/linux/pci_ids.h 2004-12-27 13:40:50.121003792 +0100
@@ -842,6 +842,7 @@
#define PCI_DEVICE_ID_APPLE_UNI_N_GMAC2 0x0032
#define PCI_DEVIEC_ID_APPLE_UNI_N_ATA 0x0033
#define PCI_DEVICE_ID_APPLE_UNI_N_AGP2 0x0034
+#define PCI_DEVICE_ID_APPLE_U3_AGP 0x0059
#define PCI_DEVICE_ID_APPLE_IPID_ATA100 0x003b
#define PCI_DEVICE_ID_APPLE_KEYLARGO_I 0x003e
#define PCI_DEVICE_ID_APPLE_K2_ATA100 0x0043
^ permalink raw reply
* Re: Linux2.6.10-rc3 for 8xx booting "load_kernel(...)" function problem vs configuring and initializing serial console ?
From: Wolfgang Denk @ 2004-12-27 11:08 UTC (permalink / raw)
To: Raphael Bossek; +Cc: Povolotsky, Alexander, linuxppc-embedded
In-Reply-To: <16008.1104099849@www37.gmx.net>
Dear Raphael,
in message <16008.1104099849@www37.gmx.net> you wrote:
>
> 10th January. Until then can you confirm that the
> arch/ppc/configs/IVMS8_defconfig
> configuration is compiling fine? Can I also boot this kernel with u-boot?
It will not compile. Nobody ported your custom drivers (status LED's,
I/O switches) to 2.6 yet.
> I'm not sure if I find time to make the tests the first week at work but I
> do my best. The simpliest and time saving solution whould be if you can
> provide me a precompiled u-boot ready kernel image file so I do not loose
> time with the build environment...
It takes 5 Minutes to install the ELDK ...
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
The only thing necessary for the triumph of evil is for good men to
do nothing. - Edmund Burke
^ permalink raw reply
* Re: PATCH uninorth3 (G5) agp support
From: Benjamin Herrenschmidt @ 2004-12-27 8:52 UTC (permalink / raw)
To: Jerome Glisse; +Cc: linuxppc-dev list, linuxppc64-dev
In-Reply-To: <41CEC6B0.5020106@free.fr>
> +/* The following seems to only be used only on U3 <j.glisse@free.fr> */
> +#define UNI_N_CFG_GART_SYNCMODE 0x00040000
> +#define UNI_N_CFG_GART_PERFRD 0x00080000
> +#define UNI_N_CFG_GART_B2BGNT 0x00200000
> +#define UNI_N_CFG_GART_FASTDDR 0x00400000
Please, call them U3_*
> /* My understanding of UniNorth AGP as of UniNorth rev 1.0x,
> * revision 1.5 (x4 AGP) may need further changes.
> diff -Naur linux/include/linux/pci_ids.h linux-new/include/linux/pci_ids.h
> --- linux/include/linux/pci_ids.h 2004-12-26 14:40:05.000000000 +0100
> +++ linux-new/include/linux/pci_ids.h 2004-12-26 14:50:19.000000000 +0100
> @@ -842,6 +842,7 @@
> #define PCI_DEVICE_ID_APPLE_UNI_N_GMAC2 0x0032
> #define PCI_DEVIEC_ID_APPLE_UNI_N_ATA 0x0033
> #define PCI_DEVICE_ID_APPLE_UNI_N_AGP2 0x0034
> +#define PCI_DEVICE_ID_APPLE_UNI_N_AGP3 0x0059
> #define PCI_DEVICE_ID_APPLE_IPID_ATA100 0x003b
> #define PCI_DEVICE_ID_APPLE_KEYLARGO_I 0x003e
> #define PCI_DEVICE_ID_APPLE_K2_ATA100 0x0043
Plase, call it PCI_DEVICE_ID_APPLE_U3_AGP
The name of the chip is not "UniNorth 3" but "U3" :) (Same goes with U2
btw).
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox