PPC 405 port complains about 'tlbwe' opcode

[Wolfgang Denk]

In message <348359E2-E78F-11D6-A3F7-003065BFB10E at motorola.com> you wrote:
>
> You need to pass down to the assembler an option to enable 403/405
> instructions.  Add a -Wa,-m405 to the gcc line.

Actually the cross compiler should automatically  set  the  necessary
options  for  the  target,  or you might run into problems because of
missing or inconsistent options for your compiles (kernel, libraries,
applications) - "-msoft-float"  is  another  candidate  for  such  an
option.

> > Please suggest. If you can share a PPC-405 port for
> > linux or any other embedded free OS, please let me
> > know.

for 4xx systems the linuxppc_2_4_devel tree  is  recommended;  either
fetch  it  from the BK server, or form our CVS server. We also have a
working set of cross and native tools  available  for  free  download
(ELDK - soon available in version 2.0).

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd at denx.de
Microsoft Multimedia:
You have nice graphics, sound and animations when the system crashes.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

patch for arch/ppc/8xx_io/fec.c

[Thomas Lange]

Against bk:linuxppc_2_4

Use retry counter (RC) to detect collisions instead of
Defer (DEF).

>From Table 6-29: (MPC860T (Rev. D) Fast Ethernet Controller 0.8)

6 DEF Defer indication, written by FEC (valid if L = 1). Set when the
FEC had to defer while trying to
transmit a frame. This bit is not set if a collision occurs during
transmission.

10-13 RC Retry count, written by FEC (valid if L = 1). Counts retries
needed
to successfully send this frame. If RC = 0, the frame was sent correctly
the first time. If RC = 15, the frame was sent successfully while the
retry
count was at its maximum value. If RL = 1, RC has no meaning.

/Thomas
-- next part --
--- fec.c   2002-10-15 14:58:00.0 +0200
+++ fec_cfix.c  2002-10-24 20:59:20.0 +0200
@@ -502,11 +502,12 @@
if (bdp->cbd_sc & BD_ENET_TX_READY)
printk("HEY! Enet xmit interrupt and TX_READY.\n");
 #endif
-   /* Deferred means some collisions occurred during transmit,
-* but we eventually sent the packet OK.
-*/
-   if (bdp->cbd_sc & BD_ENET_TX_DEF)
-   fep->stats.collisions++;
+   /* Check retry counter, i.e. collision counter */
+   /* Only valid if LAST is set, but it should always be. */
+   if (bdp->cbd_sc & BD_ENET_TX_RCMASK){
+   /* Note that counter cannot go higher than 15 */
+   fep->stats.collisions+=(bdp->cbd_sc & 
BD_ENET_TX_RCMASK)>>2;
+   }

/* Free the sk buffer associated with this last transmit.
 */

8xx i2c refers to unspecified chip errata

[Joakim Tjernlund]

> >
> > Here is a patch against the PPC 2.4 devel tree for the i2c-algo-8xx.c
>
> Can you please split this into logical chunks, or give me a list of each
> fix in here?  Thanks.

ohh, kind of hard to remember all that went into that patch. The path
has evoled over many days, but I can try summarize. I have tested this code
pretty well it does not fail for me. Speed has been between 10-150KHz. The
old code fails as soon you start to stress it a little.

 - replace invalidate_dcache_range with flush_dcache_range, since buffers are
   NOT cache aligned. flush will write to memory AND invalidate the cache.

 - move the chip errata stuff from irq routine into read/write routines. Made
   it default off since it causes lock ups on my I2C device. I think it causes
   a too short STOP condition. If enabled I2C will behave better than before, 
but
   may still cause problems if the read/write is interrupted with a signal while
   microcode is enabled.

 - set default speed to 60 KHz instead.

 - missing/faulty initialization of parameter ram when I2C micro patch is 
active.

 - replaced assingments with mask operations with relevant bits. Example:
  /* Shut down IIC. */
  i2c->i2c_i2mod = 0;
i2c->i2c_i2mod &= ~1;

 - When reading from I2C device, let the receive BD generate interrupt instead 
of
   the dummy trasmit. This is important since the TX interrupt will be too 
early sometimes, before
   the RX BD has closed. There is one case where the RX irq is before the TX 
irq, if iic_mrblr is set
   to match the number of bytes to read. Therefore must the iic_mrblr be one 
byte larger than
   the expected number of bytes.

 - busy wait for small transfers since it's faster.

 - save_flags(flags); cli(); cleanups

 - interruptible_sleep_on_timeout() instead of interruptible_sleep_on() so it 
won't hang forever if an
   irq is lost.

 Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

very minor 405GP and 405GPr PCI difference

[Ralph Blach]

David,

Let me expain

On the 405gp, the PMM0 enable is hardwired 1 and  cannot be overwritten
by software.   This makes the PMM0 region permantly enabled on the
405GP.  I cannot be turned off.

When the technology port was done, the design of the PCI was changed
slightly because the designer made the PMM0 enable bit writable.  It is
still initalized to a 1, but it can written to a 0.

In the current software, the initialization software writes a 0 to PMM0
and to PMM1.  This was fine on the 405gp because the enable bit for PMM0
could not be changed.  On the 405GPr this disabled PMM0 and with PMM1
disabled, bad things happened.

The initialization software simply need to write a 1 to the PMM0 enable
bit and all will be well.

Chip




David Gibson wrote:
> On Tue, Oct 22, 2002 at 02:55:47PM -0700, Todd Poynor wrote:
>
>>David Gibson wrote (regarding Rainier PMM1 bios_fixup in MVL):
>>
>>
>>>Well, it may be in a different place, but it looks like it has the
>>>same problem.  It is still establishing a PCI window at PLB address
>>>0x8000, which is the same address used for the PMM0 window - or is
>>>that also different in the MV kernel?
>>>
>>>I'd be trying to work out what that mapping's actually for, first.  I
>>>still can't see how it can possibly work - if there are overlapping
>>>PMM windows, what actually happens to accesses in that (PLB) range?
>>
>>Yes, it looks like MVL only sets up the one window using PMM1... we've
>>started an effort to have the Rainier-knowedgeable folks get the code
>>sync'ed up with the community and this should happen soon.
>
>
> Hang on, so just to clarify - MVL sets up PMM1 with the code you
> posted, but doesn't set up PMM0 anywhere?  From my reading of that
> code, it sets up a window at the same address as the "standard"
> (Walnut) mapping, except that it is only 128kB instead of 1GB.  Is
> there a reason that Rainier must have such a small window?
>
> --
> David Gibson  | For every complex problem there is a
> david at gibson.dropbear.id.au| solution which is simple, neat and
>   | wrong.
> http://www.ozlabs.org/people/dgibson
>
>
>
> .
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

PrPMC800 interrupt problem

[Anders Blomdell]

When trying to use the linuxppc_2_4_devel on a PrPMC800, the system stops
responding to external interrupts after the first serial interrupt. Many
things works, since the system correctly gets its IP address via DHCP.

The system handles a little more than 100 interrupts that gets routed to
'e100intr', then it starts up my shell that does a write to the console.
This write triggers an interrupt that gets routed to 'rs_interrupt_single'
. After this no more interrupts are received, but 'rs_interrupt_single' is
called from the timer task in the serial driver, but the ethernet is
totally dead. Anybody that has a good idea what to do about this?

Regards

Anders Blomdell


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

[PATCH] arch/ppc/8xx_io/enet.c, version 2

[Joakim Tjernlund]

>
>
> On Thu, Oct 24, 2002 at 04:23:31PM +0200, Joakim Tjernlund wrote:
>
> > This is the second version of my patch that removes the expensive memcpy of
> > received
> > ethernet frames in interrupt context.
> >
> > I have 1 report(from Ricardo Scop) of 20% increase in packets/second, packet
> > size 1500 when
> > applied to 8260 FEC(needs to be applied manually). But min packet size
> > decreased with 10 %.
> > This version should fix the 10% decrease case.
> >
> > This patch could be adapted 8xx_io/fec.c and 8260_io/enet.c and
> > 8260/fcc_enet.c with little effort.
> >
> > Better fix a bug in set_multicast_list(), move the dmi list forward when
> > walking it(dmi = dmi->next;)
> >
> > New stuff:
> >- Configrable: copy small packets or pass them directly, see
> > COPY_SMALL_FRAMES in code.
> >- Collision reporting fix form Thomas Lange.
> >- Don't pass receive frames which has error upwards.
> >- Report RX_OV errors as fifo errors, not crc errors.
> >
> > Please test and report any problems and performace improvements.
>
> All of this sounds good, but can you please break this one patch up into
> seperate logical patches?

I rather not.

The logical pices in this patch are:
 1) remove the expensive memcpy.
   - This is the main part of the patch.

 2) dmi->next fix, which is a one liner.
Don't pass receive frames which has error upwards.
   - Trival stuff.

 3) Collision reporting fix form Thomas Lange.
Report RX_OV errors as fifo errors, not crc errors.
   - These are just minor accounting fixes.

So I don't think it's worth the effort. Let's just wait a few days and see
if it was success or not.

Folks, please report you findings to the list.

Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

[PATCH] arch/ppc/8xx_io/enet.c, version 2

[Joakim Tjernlund]

Hi

This is the second version of my patch that removes the expensive memcpy of
received
ethernet frames in interrupt context.

I have 1 report(from Ricardo Scop) of 20% increase in packets/second, packet
size 1500 when
applied to 8260 FEC(needs to be applied manually). But min packet size
decreased with 10 %.
This version should fix the 10% decrease case.

This patch could be adapted 8xx_io/fec.c and 8260_io/enet.c and
8260/fcc_enet.c with little effort.

Better fix a bug in set_multicast_list(), move the dmi list forward when
walking it(dmi = dmi->next;)

New stuff:
   - Configrable: copy small packets or pass them directly, see
COPY_SMALL_FRAMES in code.
   - Collision reporting fix form Thomas Lange.
   - Don't pass receive frames which has error upwards.
   - Report RX_OV errors as fifo errors, not crc errors.

Please test and report any problems and performace improvements.

Jocke

--- arch/ppc/8xx_io/enet.c.org  Mon Oct 21 14:35:59 2002
+++ arch/ppc/8xx_io/enet.c  Thu Oct 24 15:48:25 2002
@@ -34,7 +34,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -86,6 +85,14 @@
  * All functions are directly controlled using I/O pins.  See
.
  */

+/* Define COPY_SMALL_FRAMES if you want to save buffer memory for small
packets
+ * at a small performance hit. Note performance testing needed */
+#define COPY_SMALL_FRAMES 1
+
+#ifdef COPY_SMALL_FRAMES
+  #define RX_COPYBREAK (256-16) /* dev_alloc_skb() adds 16 bytes for
internal use */
+#endif
+
 /* The transmitter timeout
  */
 #define TX_TIMEOUT (2*HZ)
@@ -97,19 +104,17 @@
  * the skbuffer directly.
  */
 #ifdef CONFIG_ENET_BIG_BUFFERS
-#define CPM_ENET_RX_PAGES  32
-#define CPM_ENET_RX_FRSIZE 2048
-#define CPM_ENET_RX_FRPPG  (PAGE_SIZE / CPM_ENET_RX_FRSIZE)
-#define RX_RING_SIZE   (CPM_ENET_RX_FRPPG * CPM_ENET_RX_PAGES)
-#define TX_RING_SIZE   64  /* Must be power of two */
-#define TX_RING_MOD_MASK   63  /*   for this to work */
+  #define RX_RING_SIZE 64
+  #define TX_RING_SIZE 64  /* Must be power of two for this to 
work */
 #else
-#define CPM_ENET_RX_PAGES  4
-#define CPM_ENET_RX_FRSIZE 2048
-#define CPM_ENET_RX_FRPPG  (PAGE_SIZE / CPM_ENET_RX_FRSIZE)
-#define RX_RING_SIZE   (CPM_ENET_RX_FRPPG * CPM_ENET_RX_PAGES)
-#define TX_RING_SIZE   8   /* Must be power of two */
-#define TX_RING_MOD_MASK   7   /*   for this to work */
+  #define RX_RING_SIZE 8
+  #define TX_RING_SIZE 8   /* Must be power of two for this to 
work */
+#endif
+#define TX_RING_MOD_MASK   (TX_RING_SIZE-1)
+
+#define CPM_ENET_RX_FRSIZE 1600 /* must be a multiple of cache line */
+#if CPM_ENET_RX_FRSIZE % L1_CACHE_LINE_SIZE != 0
+#error CPM_ENET_RX_FRSIZE must be a multiple of L1 cache size
 #endif

 /* The CPM stores dest/src/type, data, and checksum for receive packets.
@@ -143,7 +148,7 @@
/* Virtual addresses for the receive buffers because we can't
 * do a __va() on them anymore.
 */
-   unsigned char *rx_vaddr[RX_RING_SIZE];
+   void*rx_vaddr[RX_RING_SIZE];
struct  net_device_stats stats;
uinttx_full;
spinlock_t lock;
@@ -370,11 +375,11 @@

cep->stats.tx_packets++;

-   /* Deferred means some collisions occurred during transmit,
-* but we eventually sent the packet OK.
-*/
-   if (bdp->cbd_sc & BD_ENET_TX_DEF)
-   cep->stats.collisions++;
+   /* Check retry counter, i.e. collision counter */
+   if (bdp->cbd_sc & BD_ENET_TX_RCMASK){
+   /* Note that counter cannot go higher than 15 */
+   cep->stats.collisions+=(bdp->cbd_sc & 
BD_ENET_TX_RCMASK)>>2;
+   }

/* Free the sk buffer associated with this last transmit.
*/
@@ -449,6 +454,7 @@
struct  scc_enet_private *cep;
volatile cbd_t  *bdp;
struct  sk_buff *skb;
+   struct  sk_buff *skb_tmp;
ushort  pkt_len;

cep = (struct scc_enet_private *)dev->priv;
@@ -461,7 +467,8 @@
 for (;;) {
if (bdp->cbd_sc & BD_ENET_RX_EMPTY)
break;
-
+
+#define RX_BD_ERRORS (BD_ENET_RX_LG | BD_ENET_RX_SH | BD_ENET_RX_NO |
BD_ENET_RX_CR | BD_ENET_RX_OV | BD_ENET_RX_CL)
 #ifndef final_version
/* Since we have allocated space to hold a complete frame, both
 * the first and last indicators should be set.
@@ -470,51 +477,62 @@
(BD_ENET_RX_FIRST | BD_ENET_RX_LAST))
printk("CPM ENET: rcv is not first+last\n");
 #endif
-
-   /* Frame too long or too short.
-   */
-   if (bdp->cbd_sc & (BD_ENET_RX_LG | BD_ENET_RX_SH))
-   cep->stats.rx_length_errors++;
-   if (bdp->cbd_sc & BD_ENET_RX_NO)/* Frame alignment */
-   cep->stats.rx_frame_errors++;
-   if (bdp

PPC 405 port complains about 'tlbwe' opcode

[Kumar Gala]

You need to pass down to the assembler an option to enable 403/405
instructions.  Add a -Wa,-m405 to the gcc line.

- kumar

On Thursday, October 24, 2002, at 03:18  PM, Prakash kanthi wrote:

>
> Hi There,
>
> I am in the process of porting linux-2.4.18 with
> ppc-patch-2.4.18 to make a 405 linux os. For 'make
> bzImage' it complains about 'tlbwe' being Unrecognied
> opcode from head_4xx.S.
>
> ---
> powerpc-eabi-gcc -D__ASSEMBLY__ -D__KERNEL__
> -I/root/ppctest/linux/include -c -o head_4xx.o
> head_4xx.S
> head_4xx.S: Assember messages:
> head_4xx.S:111: Error: Unrecognized opcode: `tlbwe`
> head_4xx.S:112: Error: Unrecognized opcode: `tlbwe`
> make[1]: *** [head_4xx.o] Error 1
> ---
>
> I saw couple of postings saying that 'tlbwe' is not a
> 405 opcode. But it is defined by PPC-405 manual. I am
> not sure what WS value should be, if i have to add
> 'tlbwe' to supported opcodes.
>
> Please suggest. If you can share a PPC-405 port for
> linux or any other embedded free OS, please let me
> know.
>
> thanks in advance,
> Prakash
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

PPC 405 port complains about 'tlbwe' opcode

[Prakash kanthi]

Hi There,

I am in the process of porting linux-2.4.18 with
ppc-patch-2.4.18 to make a 405 linux os. For 'make
bzImage' it complains about 'tlbwe' being Unrecognied
opcode from head_4xx.S.

---
powerpc-eabi-gcc -D__ASSEMBLY__ -D__KERNEL__
-I/root/ppctest/linux/include -c -o head_4xx.o
head_4xx.S
head_4xx.S: Assember messages:
head_4xx.S:111: Error: Unrecognized opcode: `tlbwe`
head_4xx.S:112: Error: Unrecognized opcode: `tlbwe`
make[1]: *** [head_4xx.o] Error 1
---

I saw couple of postings saying that 'tlbwe' is not a
405 opcode. But it is defined by PPC-405 manual. I am
not sure what WS value should be, if i have to add
'tlbwe' to supported opcodes.

Please suggest. If you can share a PPC-405 port for
linux or any other embedded free OS, please let me
know.

thanks in advance,
Prakash


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

[PATCH] arch/ppc/8xx_io/enet.c

[Joakim Tjernlund]

>
> Ricardo Scop wrote:
> >
> > On Wednesday 23 October 2002 05:51, Joakim Tjernlund wrote:
> > > On Monday 21 October 2002 15:13, Joakim Tjernlund wrote:
> > > > Hi
> > > >
> > > > Here is a patch to drop the expensive memcpy of received ethernet frames
> > > > in interrupt context. I have not done any bench marking, but mounting a
> > > > NFS rootfs feels faster.
> > > >
> > > > I am using a heavily modified enet.c in my system, but I think I got the
> > > > patch correct.
> > > >
> > > > Also fixed a bug in set_multicast_list(), move the dmi list forward when
> > > > walking it(dmi = dmi->next;)
> > > >
> > > > Comments? Anyone care to do some benchmarking?
> > >
> > > No comments so far, no one interested in this?
> > I'm interested! Indeed, I adapted and tested your patch in a 8260 FCC fast
> > ethernet driver and it worked fine  I had a 20% increase in routing
> > throughput with the  patch installed!
> > ...
>
> Did I understand that correctly that this patch would work with mith MPC8xx 
> FEC
> as well!?!?

Yes, but you have to adapt it a little.

 Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

[PATCH] arch/ppc/8xx_io/enet.c

[Steven Scholz]

Ricardo Scop wrote:
>
> On Wednesday 23 October 2002 05:51, Joakim Tjernlund wrote:
> > On Monday 21 October 2002 15:13, Joakim Tjernlund wrote:
> > > Hi
> > >
> > > Here is a patch to drop the expensive memcpy of received ethernet frames
> > > in interrupt context. I have not done any bench marking, but mounting a
> > > NFS rootfs feels faster.
> > >
> > > I am using a heavily modified enet.c in my system, but I think I got the
> > > patch correct.
> > >
> > > Also fixed a bug in set_multicast_list(), move the dmi list forward when
> > > walking it(dmi = dmi->next;)
> > >
> > > Comments? Anyone care to do some benchmarking?
> >
> > No comments so far, no one interested in this?
> I'm interested! Indeed, I adapted and tested your patch in a 8260 FCC fast
> ethernet driver and it worked fine  I had a 20% increase in routing
> throughput with the  patch installed!
> ...

Did I understand that correctly that this patch would work with mith MPC8xx FEC
as well!?!?

Cheers,

Steven

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

PrPMC800 interrupt problem

[Tom Rini]

On Thu, Oct 24, 2002 at 07:01:19PM +0200, Anders Blomdell wrote:
>
> When trying to use the linuxppc_2_4_devel on a PrPMC800, the system stops
> responding to external interrupts after the first serial interrupt. Many
> things works, since the system correctly gets its IP address via DHCP.
>
> The system handles a little more than 100 interrupts that gets routed to
> 'e100intr', then it starts up my shell that does a write to the console.
> This write triggers an interrupt that gets routed to 'rs_interrupt_single'
> . After this no more interrupts are received, but 'rs_interrupt_single' is
> called from the timer task in the serial driver, but the ethernet is
> totally dead. Anybody that has a good idea what to do about this?

Did you update the prpmc800_openpic_initsenses[] table and related?
(Look at how the lopec or sandpoint work now).

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

[PATCH] arch/ppc/8xx_io/enet.c

[Joakim Tjernlund]

> > >
> > > Comments? Anyone care to do some benchmarking?
> >
> > No comments so far, no one interested in this?
> I'm interested! Indeed, I adapted and tested your patch in a 8260 FCC fast
> ethernet driver and it worked fine  I had a 20% increase in routing
> throughput with the  patch installed!

Cool!

>
> The bug fix in set_multicast_list worked too. But, since there's a continue
> clause inside the for command in this routine, I would suggest that the
> (dmi=dmi->next) command go inside the for increment clause, instead of the
> place you've put it; that is:
>   for (...;...; i++, dmi = dmi->next) {...}

Yes thats better, thanks.
> >
> > A question, why do enet.c pass bad frames to netif_rx? Only late collisions
> > are disregarded, the rest is passed on.
> IMHO, this is another bug...
me too.

   Jocke


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

8xx i2c refers to unspecified chip errata

[Tom Rini]

On Tue, Oct 22, 2002 at 11:15:38AM +0200, Joakim Tjernlund wrote:
>
> > On Fri, Oct 11, 2002 at 11:12:02AM +0200, Joakim Tjernlund wrote:
> >
> > > OK, here it is.
> > >
> > > Perhaps someone can add it to the ppctree?
> >
> > If you can submit this as a patch vs what's in the i2c CVS tree or the
> > ppctree, than yes, this can be committed there, and to the ppctrees.
>
> Here is a patch against the PPC 2.4 devel tree for the i2c-algo-8xx.c

Can you please split this into logical chunks, or give me a list of each
fix in here?  Thanks.

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Fw: fads mpc860 linux2.4.4 boot problem.

[zhongqx]

- Original Message -
From: "zhongqx" <[EMAIL PROTECTED]>
To: "rekha gvv" 
Sent: Thursday, October 24, 2002 8:30 AM
Subject: Re: fads mpc860 linux2.4.4 boot problem.


>
> - Original Message -
> From: "rekha gvv" 
> To: 
> Sent: Wednesday, October 23, 2002 7:10 PM
> Subject: fads mpc860 linux2.4.4 boot problem.
>
>
> > Hello,
> >  i am facing problems to boot linux..so please try to
> > help me..i got u'r id from the mailing list.In one of
> > the mail u have mentioned that when ->
> >
> > My FADS boards work well without FEC cofigure.But when
> > I make menuconfig ,and select 860T FEC,it has nothing
> > from
> > console like the following:
> > =>bootm 40
> > ## Booting image at 0040 ...
> > Image Name: 2.4.18
> > Image Type: PowerPC Linux Kernel Image (gzip
> > compressed)
> > Data Size: 521671 Bytes = 509 kB = 0 MB
> > Load Address: 
> > Entry Point: 
> > Verifying Checksum ... OK
> > Uncompressing Kernel Image ... OK
> > IS THIS PROBLEM DUE TO MISMATCH IN ETHERNET
> > CONFIGURATION.LATER U HAVE ALSO MENTIONED THAT IF U
> > DISABLE 860T FEC IT WORKS FINE..
> > PLEASE CAN U TELL ME THE ETHERNET CONFIGURATION
> > WHETHER TO USE SCC1 ..ALSO I AM CONFUSED THAT U HAVE
> > NOT SET SMC1 OR SMC2 FOR SERIAL CONSOLE
>
> when u not define SMC2 for console ,uart.c will think console is SMC1 you 
> should read
> /arch/ppc/uart.c
>
>
>  THEN HOW DID
> > LINUX BOOT UP ?
> > # MPC8xx CPM Options
> > #
> > CONFIG_SCC_ENET=y
> > CONFIG_SCC1_ENET=y
> > # CONFIG_SCC2_ENET is not set
> > # CONFIG_SCC3_ENET is not set
> > CONFIG_FEC_ENET=y   ---HERE YOU HAVE SET 860T FEC
> > # CONFIG_USE_MDIO is not set
> > CONFIG_ENET_BIG_BUFFERS=y
> > # CONFIG_SMC2_UART is not set
> > CONFIG_USE_SCC_IO=y  -WHAT IS THIS FOR???
> > # CONFIG_8xx_COPYBACK is not set
> > # CONFIG_8xx_CPU6 is not set
> > # CONFIG_UCODE_PATCH is not set
> >
> > I FOUND THESE LINES ...IN U'R CONFIG FILE
> > CONFIG_CMDLINE_BOOL=y
> > CONFIG_CMDLINE="console=ttyS0,115200"
> >
> > PLEASE TELL ME WHETHER U HAD ADDED THESE LINES OR IT
> > WAS GENERATED BY THE CONFIG FILE ..AS I DONT FIND
> > THESE LINES IN MY CONFIG FILE.DOES THOSE LINES HAVE A
> > ROLE DURING BOOT UP OF LINUX.I AM USING PPCBOOT 1.1.6
> > AND LINUX VERSION 2.4.4 .DOWNLOADED FROM DENX SITE.
> > WE HAVE BURNT PPCBOOT IN 280 IN FLASH.
> > THESE ARE THE ARGUMENTS SET BEFORE DOWNLOADIN THE
> > KERNEL
> > =>printenv
> > bootcmd=bootm 2800100
> this perhaps not right,
> 2800100 is ppcboot in flash can not use bootm command because when use bootm 
> command
> ppcboot have already run.
>
> should like this bootm 0288 0290
> which 0288 is linux kernel  and 0290 is ramdisk image
>
> > baudrate=9600
> > loads_echo=1
> > clocks_in_mhz=1
> > ethaddr=00:fa:ds:mp:86:00
>
> this is wrong, mp is what?
> I use 00:d0:93:00:12:34 should be hex format
>
>
> > filesize=9f5c8
> > netmask=255.255.255.0
> > ipaddr=192.168.1.71
> > bootargs=
> You should have this var to boot frome NFS or Ramdisk
> setenv bootargs root=/dev/ram or root=/dev/nfs
>
> > serverip=192.168.1.175
> > stdin=serial
> > stdout=serial
> > stderr=serial
> >
> > then i do a
> > =>tftpboot 10 pImage
> > =>bootm
> bootm will call bootcmd command which you define it bootm 2800100,
> it cant boot from 10 ,
> this process should be like this:
> tftp 40 linux-2.4.4.ppcboot
> tftp 50 ramdisk.image.ppcboot
> bootm 40 50
>
> you should use vmlinux.gz in /arch/ppcboot/coffboot when you make zImage,
> then you use mkimage like this
> mkimage -n "2.4.4 kernel" -A ppc -O linux -T kernel -C gzip -a 0 -e 0 -d 
> vmlinux.gz /tftpboot/linux-2.4.4.ppcboot
> to create linux-2.4.4.ppcboot
> mkimage -n "ramdisk" -A ppc -O linux -T ramdisk -C gzip -a 0 -e 0 -d 
> ramdisk.image.gz /tftpboot/ramdisk.image.ppcboot
>
> good luck!
>
>
>
>
> > it finally hangs at "uncompressing kernel image ..Ok"
> > THE pImage IS PPCBOOT COMPATIBLE IMAGE CREATED USING
> > MKIMAGE ID THIS FILE FORMAT RIGHT OR WHAT IMAGE
> > SHOULD I DOWNLOAD ..IS IT SREC OR BIN FILE ??
> > PLEASE TELL ME IF THE PROCEDURE I FOLLOWED IS RIGHT
> > AND ANY PARAMETERS TO BE CHANGED IN PPCBOOT BEFORE
> > DOWNLOADING THE KERNEL..i HAVE ATTATCHED MY
> > /include/asm-ppc/fads.h file ..please tell me if any
> > alterations to be made there..
> > Hoping to get some hints
> > thankyou!!!
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> 
>
>
> > #
> > # Automatically generated by make menuconfig: don't edit
> > #
> > # CONFIG_UID16 is not set
> > # CONFIG_RWSEM_GENERIC_SPINLOCK is not set
> > CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> >
> > #
> > # Code maturity level options
> > #
> > CONFIG_EXPERIMENTAL=y
> >
> > #
> > # Loadable module support
> > #
> > CONFIG_MODULES=y
> > # CONFIG_MODVERSIONS is not set
> > CONFIG_KMOD=y
> >
> > #
> > # Platform support
> > #
> > CONFIG_PPC=y
> > # CONFIG_6xx is not set
> > # CONFIG_8240 is not set
> > # CONFIG_4xx is not set
> 

[PATCH] arch/ppc/8xx_io/enet.c, version 2

[Tom Rini]

On Thu, Oct 24, 2002 at 04:23:31PM +0200, Joakim Tjernlund wrote:

> This is the second version of my patch that removes the expensive memcpy of
> received
> ethernet frames in interrupt context.
>
> I have 1 report(from Ricardo Scop) of 20% increase in packets/second, packet
> size 1500 when
> applied to 8260 FEC(needs to be applied manually). But min packet size
> decreased with 10 %.
> This version should fix the 10% decrease case.
>
> This patch could be adapted 8xx_io/fec.c and 8260_io/enet.c and
> 8260/fcc_enet.c with little effort.
>
> Better fix a bug in set_multicast_list(), move the dmi list forward when
> walking it(dmi = dmi->next;)
>
> New stuff:
>- Configrable: copy small packets or pass them directly, see
> COPY_SMALL_FRAMES in code.
>- Collision reporting fix form Thomas Lange.
>- Don't pass receive frames which has error upwards.
>- Report RX_OV errors as fifo errors, not crc errors.
>
> Please test and report any problems and performace improvements.

All of this sounds good, but can you please break this one patch up into
seperate logical patches?

--
Tom Rini (TR1265)
http://gate.crashing.org/~trini/

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

linux booted on fads!!!!

[rekha gvv]

hello all,

Am happy to tell that linux booted up 
the problem was that the  at  the time of low level
initialization the devices rs232,ethernet,irdn has to
be enabled using the BCSR1 register ..simple right ;)
but...kernel
 is hanging at this point ,,
vfs:unable to mount /dev/ram0 
rebooting in 180 seconds ..
to solve this problem  i downloaded  the ramdisk image
from the denx site
ftp://ftp.denx.de/pub/LinuxPPC/usr/src/simple-ramdisk.image.gz.

I put this image in /arc/ppc/mbxboot  i did a
mkimage -n "linuxppc" -A ppc -O linux \
 -T ramdisk -C gzip -a 0 -e 0 -d
simple-ramdisk.image.gz. /tftpboot/ramimg

then
tftpboot 10 linuximg
tftpboot 20 ramimg
bootm 10 20

it hangs after
verifying checksum ok
Loading Ramdisk to 0035b000, end 0075b000...ok
then no output :(

how do i go abt this problem any hints


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/