[U-Boot-Users] trizeps2 SMC lan91c96 (smc9111.c comparison)

[U-Boot-Users] trizeps2 SMC lan91c96 (smc9111.c comparison)

[David Adair]

> Using MAC Address 00:50:C2:0E:C8:D9
> TFTP from server 192.168.0.77; our IP address is 192.168.0.98
> Filename 'trizeps2_kernel.img'.
> Load address: 0xa3000000
> Loading: LAN91C96:smc_hardware_send_packet
> LAN91C96: memory allocation, try 1 failed ...
> LAN91C96: memory allocation, try 2 failed ...


Does this still happen?  To get the SMC91111 to work on my board
I had to add the following -- perhaps 91c96 has the same issue?

Have not really had time to investigate beyond the "Seems to work"
stage, but here is my thinking:

	- Network is busy so RX buffers are full of gunk I don't care
	  about.

	- TFTP starts out with a TX that it expects to send before it
	  starts the polling loop that would throw away the input.  This
	  creates a race between the reset and the first TX.

	- There should be no harm in discarding packets that we cant
	  handle in any case -- should not appear any different to
	  the higher layer protocols than a packet that got lost
	  due to collisions etc??

	- Changing the higher layer code to flush the RX before starting
	  up would require touching a lot more code with potential for
	  unintended consequences on configurations I have no way to test.
	  Also simplistic approach would just narrow the window rather
	  than eliminate it.

Also there were some questions about "Why do full reset for every
operation?"  I played around with this too and gave up on it.  My conclusion
was that without an interrupt driven service routine there were just
too many ways to get wonky results when starting from an unknown state --
for my applications it is better to add a couple seconds and have reliable
operation than get fast but "mostly works."  May have to re-visit this
attitude when I try to combine tftp with net-console ....

David





+        /*
+         * If allocation failed and RX is waiting then we will
+         * probably never get a buffer.  Start discarding input
+         * frames.
+         */
+        if (status & IM_RCV_INT) {
+            int packet_number = SMC_inw( RXFIFO_REG );
+
+            if (! (packet_number & RXFIFO_REMPTY) ) {
+                PRINTK2 ("%s: Discarding packet to free TX memory\n",
+                         SMC_DEV_NAME);
+
+                while ( SMC_inw( MMU_CMD_REG ) & MC_BUSY )
+                    udelay(1); /* Wait until not busy */
+
+                /* tell the card to get rid of this packet */
+                SMC_outw( MC_RELEASE, MMU_CMD_REG );
+
+                while ( SMC_inw( MMU_CMD_REG ) & MC_BUSY )
+                    udelay(1); /* Wait until not busy */
+            }
+        }
	} while (--time_out);
 
 	if (!time_out) {
-		PRINTK2 ("%s: memory allocation, try %d failed ...\n",
-			 SMC_DEV_NAME, try);
+		PRINTK2 ("%s: memory allocation, try %d failed ...\n"
+                 "\tint: 0x%x  ar: 0x%x\n",
+                 SMC_DEV_NAME, try,
+                 status, SMC_inb (AR_REG));
+
 		if (try < SMC_ALLOC_MAX_TRY)
 			goto again;
 		else

[U-Boot-Users] trizeps2 SMC lan91c96 (smc9111.c comparison)

[Matej Kupljen]

Hi

> > LAN91C96: memory allocation, try 1 failed ...
> > LAN91C96: memory allocation, try 2 failed ...

<...snip...>

> +                 SMC_DEV_NAME, try,
> +                 status, SMC_inb (AR_REG));

I remember I had problems with SMC_inb macro (defined in h file).
I tracked it down to be a compiler BUG (or maybe binutils), because it
did not calculate the right address for the offset. I solved it
by replacing this macro with much simpler version. Then I upgraded
my compiler (I cannot remember the compiler version) and I could use
"standard" macro.

Check the generated ASM, or use debugger (BDI2000, if you have one) to
see if the code is O.K.

Hope this helps.

Matej