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

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

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
participants (2)
-
David Adair
-
Matej Kupljen