LAN91C111 on XSC1BD

Hi,

I'm porting Windows CE 4.2 XSC1BD BSP to a board based on Lubbock. This
board has all features of Lubbock (It has an FPGA that maps all Lubbock
Peripherals). The main difference between this board and Lubbock is
the Ethernet Controller. The board I'm working has a SMSC LAN 91C111
Ethernet Controller.

I'm trying to port the Eboot to this board.

I already have the LAN 91C111 ETHDBG driver ported to Windows CE 4.2.
And it is working in another board.

The Ethernet Controller is mapped on nCS3 (0x0C00_0000), like Lubbock.
And I gave a offset of 0x300 the access it (The registers offset for
SMC 91C111). Without this offset the driver didn't detect the
Ethernet Controller.

To put this detecting the Ethernet Contoller I change the MSC1 register
from 0x3FF1A441 to 0x3FFCA441, changing from SRAM to VLIO.

But when I try to apply it the driver in the board I am working now it
appears to start ok, but it does not communicate well. The driver
detects the Ethernet Controllet ok on SMCInit() routine, but It appears
to fail on SCMSendFrame() or SMCGetFrame() routines.

For example:
If I put DHCP Enabled on the bootloader, the board gets the IP from
server. Then it starts to send BOOTME messages, but Platform Builder
does not detect it.
So, if I put DHCP Disabled and configure IP Manually, when the board
starts do send BOOTME messages, Plaform Builder detect it. But does not
download the image.

I know that this board is working with all features ok on a Linux
Kernel 2.6.11 based on Lubbock Configuration, just changing the driver
for Ethernet Controller.

Thanks,

Marcelo Fornazin

voidcoder
Thu Feb 09 15:51:19 CST 2006

are you sure both chips from the first and second board
have the same revision?

post your SCMSendFrame and SMCGetFrame
code here


"Fornazin" <fornazin@gmail.com> wrote in message
news:1139345707.298983.29040@f14g2000cwb.googlegroups.com...
> Hi,
>
> I'm porting Windows CE 4.2 XSC1BD BSP to a board based on Lubbock. This
> board has all features of Lubbock (It has an FPGA that maps all Lubbock
> Peripherals). The main difference between this board and Lubbock is
> the Ethernet Controller. The board I'm working has a SMSC LAN 91C111
> Ethernet Controller.
>
> I'm trying to port the Eboot to this board.
>
> I already have the LAN 91C111 ETHDBG driver ported to Windows CE 4.2.
> And it is working in another board.
>
> The Ethernet Controller is mapped on nCS3 (0x0C00_0000), like Lubbock.
> And I gave a offset of 0x300 the access it (The registers offset for
> SMC 91C111). Without this offset the driver didn't detect the
> Ethernet Controller.
>
> To put this detecting the Ethernet Contoller I change the MSC1 register
> from 0x3FF1A441 to 0x3FFCA441, changing from SRAM to VLIO.
>
> But when I try to apply it the driver in the board I am working now it
> appears to start ok, but it does not communicate well. The driver
> detects the Ethernet Controllet ok on SMCInit() routine, but It appears
> to fail on SCMSendFrame() or SMCGetFrame() routines.
>
> For example:
> If I put DHCP Enabled on the bootloader, the board gets the IP from
> server. Then it starts to send BOOTME messages, but Platform Builder
> does not detect it.
> So, if I put DHCP Disabled and configure IP Manually, when the board
> starts do send BOOTME messages, Plaform Builder detect it. But does not
> download the image.
>
> I know that this board is working with all features ok on a Linux
> Kernel 2.6.11 based on Lubbock Configuration, just changing the driver
> for Ethernet Controller.
>
> Thanks,
>
> Marcelo Fornazin
>

Fornazin
Mon Feb 13 11:20:18 CST 2006

Hi,

I think both chips have the same revision. At least I didn't see
anything about diferent revisions for LAN91C111 on SMSC website.

Here is my code:

UINT16 SMCSendFrame( BYTE *pBuffer, DWORD length )
{
UINT16 rc = 0;
UINT16 bufferSize, frameHandle;
UINT16 packetNumber;
UINT32 startTime;
static BOOLEAN bAllocRequest = FALSE;

// Calculate the amount of memory needed (must be an even number)
bufferSize = 2 + 2 + (UINT16)length + 1;
if ((bufferSize & 1) != 0) bufferSize++;

switch (GET_CHIP_ID(g_chipRevision)) {
case CHIP_ID_SMC111:
// Make sure there's enough free Tx memory.
OUTPORT16(&g_pSMC->BANKSEL, 0);
if ((INPORT16(&g_pSMC->MIR) >> 8) == 0) {
// No memory? Reset the MMU.
OUTPORT16(&g_pSMC->BANKSEL, 2);
OUTPORT16(&g_pSMC->MMUCR, MMUCR_111_RESET_MMU);
while ((INPORT16(&g_pSMC->MMUCR) & MMUCR_BUSY) != 0);

bAllocRequest = FALSE;
}
// Allocate memory in the buffer for the frame
OUTPORT16(&g_pSMC->BANKSEL, 2);
if (!bAllocRequest)
{
OUTPORT16(&g_pSMC->MMUCR, MMUCR_111_ALLOC_TX);
bAllocRequest = TRUE;
}
break;
default:
// Allocate memory in the buffer for the frame
OUTPORT16(&g_pSMC->BANKSEL, 2);
OUTPORT16(&g_pSMC->MMUCR, MMUCR_ALLOC|(bufferSize >> 8));
}

// Loop until the request is satisfied
startTime = OALGetTickCount();
while ((OALGetTickCount() - startTime) < TIMEOUT_VALUE)
{
if (INPORT16(&g_pSMC->INTR) & INTR_ALLOC)
{
break;
}
}
// If we couldn't satisfy the allocation, abort - we'll give the
// receive side time to free up some space in the MMU, then we'll
// re-check whether the allocation succeeded on the next call.
if ((INPORT16(&g_pSMC->INTR) & INTR_ALLOC) == 0)
{
OALMSGS(OAL_ERROR, (L"ERROR: SMCSendFrame: Timed out allocating
frame.\r\n"));
return(1);
}

bAllocRequest = FALSE;

// Make sure the allocation didn't fail.
if (INPORT16(&g_pSMC->PNRARR) & 0x8000)
{
OALMSGS(OAL_ERROR, (L"ERROR: SMCSendFrame: Failed to allocate
frame.\r\n"));
return(1);
}

// Get frame handle
frameHandle = (0x3f00 & INPORT16(&g_pSMC->PNRARR)) >> 8;

// Now write the frame into the buffer
OUTPORT16(&g_pSMC->PNRARR, frameHandle);
OUTPORT16(&g_pSMC->PTR, PTR_AUTOINC);

// Write status word
OUTPORT16(&g_pSMC->DATA, 0);
// Write the buffer size
OUTPORT16(&g_pSMC->DATA, bufferSize);

// Now write all except possibly the last data byte
while (length > 1) {
OUTPORT16(&g_pSMC->DATA, *(UINT16*)pBuffer);
pBuffer += sizeof(UINT16);
length -= sizeof(UINT16);
}

if (length > 0) {
// If length was odd we can put that just before the control
byte
OUTPORT16(&g_pSMC->DATA, *pBuffer|CTRL_ODD|CTRL_CRC);
} else {
// Otherwise just pad the last byte with 0
OUTPORT16(&g_pSMC->DATA, CTRL_CRC);
}

// Enqueue Frame number into TX FIFO
switch (GET_CHIP_ID(g_chipRevision)) {
case CHIP_ID_SMC111:
OUTPORT16(&g_pSMC->MMUCR, MMUCR_111_ENQUEUE);
break;
default:
OUTPORT16(&g_pSMC->MMUCR, MMUCR_ENQ_TX);
}

// Wait until it is sent or an error is generated.
startTime = OALGetTickCount();
while ((OALGetTickCount() - startTime) < TIMEOUT_VALUE)
{
if (INPORT16(&g_pSMC->INTR) & INTR_TX)
{
break;
}
}

if ((INPORT16(&g_pSMC->INTR) & INTR_TX) == 0)
{
OALMSGS(OAL_ERROR, (L"ERROR: SMCSendFrame: Timed out waiting
for the transfer to complete.\r\n"));
return(1);
}

// Read TXDONE Pkt# from FIFO Port Register
OUTPORT16(&g_pSMC->BANKSEL, 2);
packetNumber = (INPORT16(&g_pSMC->FIFO) & 0x3F);

// Write to Packet Number Register
OUTPORT16(&g_pSMC->PNRARR, packetNumber);

// Retrieve packet status
OUTPORT16(&g_pSMC->PTR, (PTR_AUTOINC | PTR_READ));
OALStall(100);
rc = INPORT16(&g_pSMC->DATA);

// Release the packet
switch (GET_CHIP_ID(g_chipRevision)) {
case CHIP_ID_SMC111:
OUTPORT16(&g_pSMC->MMUCR, MMUCR_111_RELEASE_TX);
break;
default:
OUTPORT16(&g_pSMC->MMUCR, MMUCR_REL_SPEC);
}
while ((INPORT16(&g_pSMC->MMUCR) & MMUCR_BUSY) != 0);

// Clear the tx interrupt status
SETPORT16(&g_pSMC->INTR, INTR_TX);

// Tx error?
if (rc & (EPH_STAT_TXUNRN | EPH_STAT_SQET | EPH_STAT_LOSTCARR |
EPH_STAT_LATCOL | EPH_STAT_16COL))
{
// Display error status.
OALMSGS(OAL_ERROR, (L"ERROR: SMCSendFrame: status = ( "));
if (rc & EPH_STAT_TXUNRN)
{
OALMSGS(OAL_ERROR, (L"TXUNRN "));
}
if (rc & EPH_STAT_SQET)
{
OALMSGS(OAL_ERROR, (L"SQET "));
}
if (rc & EPH_STAT_LOSTCARR)
{
OALMSGS(OAL_ERROR, (L"LOSTCARR "));
}
if (rc & EPH_STAT_LATCOL)
{
OALMSGS(OAL_ERROR, (L"LATCOL "));
}
if (rc & EPH_STAT_16COL)
{
OALMSGS(OAL_ERROR, (L"16COL "));
}
OALMSGS(OAL_ERROR, (L")\r\n"));

// Re-enable TXENA
OUTPORT16(&g_pSMC->BANKSEL, 0);
OUTPORT16(&g_pSMC->TCR, TCR_SWFDUP|TCR_PADEN|TCR_TXEN);

// Failure.
rc = 1;
}
else
{
// Success.
rc = 0;
}

// Clear the statistics registers
OUTPORT16(&g_pSMC->BANKSEL, 0);
INPORT16(&g_pSMC->ECR);

// Set back bank 2
OUTPORT16(&g_pSMC->BANKSEL, 2);

return rc;
}

UINT16 SMCGetFrame( BYTE *pBuffer, UINT16 *pLength )
{
UINT8 *pos = pBuffer;
UINT16 code, pointer;
UINT32 length, count;

// Make sure that bank 2 is actual
OUTPORT16(&g_pSMC->BANKSEL, 2);

length = 0;
while ((INPORT16(&g_pSMC->INTR) & INTR_RX) != 0) {

// Setup pointer address register
pointer = PTR_RCV | PTR_READ;

// Read status
OUTPORT16(&g_pSMC->PTR, pointer);
code = INPORT16(&g_pSMC->DATA);
pointer += sizeof(UINT16);

if ((code & (STAT_ALGNERR|STAT_BADCRC|STAT_LONG|STAT_SHORT)) ==
0) {

// Get packet size
OUTPORT16(&g_pSMC->PTR, pointer);
length = (INPORT16(&g_pSMC->DATA) & 0x07FF) - 6;
pointer += sizeof(UINT16);

// Copy packet
count = length;
while (count > 1) {
OUTPORT16(&g_pSMC->PTR, pointer);
*(UINT16*)pos = INPORT16(&g_pSMC->DATA);
pointer += sizeof(UINT16);
pos += sizeof(UINT16);
count -= sizeof(UINT16);
}

// Get control word (which can contain last byte)
OUTPORT16(&g_pSMC->PTR, pointer);
code = INPORT16(&g_pSMC->DATA);
pointer += sizeof(UINT16);
if ((code & CTRL_ODD) != 0) {
length++;
*pos = (UINT8)code;
}
}

// Release the memory for the received frame
switch (GET_CHIP_ID(g_chipRevision)) {
case CHIP_ID_SMC111:
OUTPORT16(&g_pSMC->MMUCR, MMUCR_111_REM_REL_RX);
break;
default:
OUTPORT16(&g_pSMC->MMUCR, MMUCR_REM_REL_TOP);
}

while ((INPORT16(&g_pSMC->MMUCR) & MMUCR_BUSY) != 0);

// If length is non zero we get a packet
if (length > 0) break;

}

*pLength = (UINT16)length;
return (*pLength);
}

Thanks

Marcelo Fornazin

voidcoder wrote:
> are you sure both chips from the first and second board
> have the same revision?
>
> post your SCMSendFrame and SMCGetFrame
> code here

Voidcoder
Tue Feb 14 15:50:52 CST 2006

The code looks ok, but memory configuration for
CS3 seems to be wrong. Try the following config

MSC1=0x2884A441


"Fornazin" <fornazin@gmail.com> wrote in message news:1139851218.382293.133300@o13g2000cwo.googlegroups.com...
> Hi,
>
> I think both chips have the same revision. At least I didn't see
> anything about diferent revisions for LAN91C111 on SMSC website.
>
> Here is my code:
>
> UINT16 SMCSendFrame( BYTE *pBuffer, DWORD length )
> {
> UINT16 rc = 0;
> UINT16 bufferSize, frameHandle;
> UINT16 packetNumber;
> UINT32 startTime;
> static BOOLEAN bAllocRequest = FALSE;
>
> // Calculate the amount of memory needed (must be an even number)
> bufferSize = 2 + 2 + (UINT16)length + 1;
> if ((bufferSize & 1) != 0) bufferSize++;
>
> switch (GET_CHIP_ID(g_chipRevision)) {
> case CHIP_ID_SMC111:
> // Make sure there's enough free Tx memory.
> OUTPORT16(&g_pSMC->BANKSEL, 0);
> if ((INPORT16(&g_pSMC->MIR) >> 8) == 0) {
> // No memory? Reset the MMU.
> OUTPORT16(&g_pSMC->BANKSEL, 2);
> OUTPORT16(&g_pSMC->MMUCR, MMUCR_111_RESET_MMU);
> while ((INPORT16(&g_pSMC->MMUCR) & MMUCR_BUSY) != 0);
>
> bAllocRequest = FALSE;
> }
> // Allocate memory in the buffer for the frame
> OUTPORT16(&g_pSMC->BANKSEL, 2);
> if (!bAllocRequest)
> {
> OUTPORT16(&g_pSMC->MMUCR, MMUCR_111_ALLOC_TX);
> bAllocRequest = TRUE;
> }
> break;
> default:
> // Allocate memory in the buffer for the frame
> OUTPORT16(&g_pSMC->BANKSEL, 2);
> OUTPORT16(&g_pSMC->MMUCR, MMUCR_ALLOC|(bufferSize >> 8));
> }
>
> // Loop until the request is satisfied
> startTime = OALGetTickCount();
> while ((OALGetTickCount() - startTime) < TIMEOUT_VALUE)
> {
> if (INPORT16(&g_pSMC->INTR) & INTR_ALLOC)
> {
> break;
> }
> }
> // If we couldn't satisfy the allocation, abort - we'll give the
> // receive side time to free up some space in the MMU, then we'll
> // re-check whether the allocation succeeded on the next call.
> if ((INPORT16(&g_pSMC->INTR) & INTR_ALLOC) == 0)
> {
> OALMSGS(OAL_ERROR, (L"ERROR: SMCSendFrame: Timed out allocating
> frame.\r\n"));
> return(1);
> }
>
> bAllocRequest = FALSE;
>
> // Make sure the allocation didn't fail.
> if (INPORT16(&g_pSMC->PNRARR) & 0x8000)
> {
> OALMSGS(OAL_ERROR, (L"ERROR: SMCSendFrame: Failed to allocate
> frame.\r\n"));
> return(1);
> }
>
> // Get frame handle
> frameHandle = (0x3f00 & INPORT16(&g_pSMC->PNRARR)) >> 8;
>
> // Now write the frame into the buffer
> OUTPORT16(&g_pSMC->PNRARR, frameHandle);
> OUTPORT16(&g_pSMC->PTR, PTR_AUTOINC);
>
> // Write status word
> OUTPORT16(&g_pSMC->DATA, 0);
> // Write the buffer size
> OUTPORT16(&g_pSMC->DATA, bufferSize);
>
> // Now write all except possibly the last data byte
> while (length > 1) {
> OUTPORT16(&g_pSMC->DATA, *(UINT16*)pBuffer);
> pBuffer += sizeof(UINT16);
> length -= sizeof(UINT16);
> }
>
> if (length > 0) {
> // If length was odd we can put that just before the control
> byte
> OUTPORT16(&g_pSMC->DATA, *pBuffer|CTRL_ODD|CTRL_CRC);
> } else {
> // Otherwise just pad the last byte with 0
> OUTPORT16(&g_pSMC->DATA, CTRL_CRC);
> }
>
> // Enqueue Frame number into TX FIFO
> switch (GET_CHIP_ID(g_chipRevision)) {
> case CHIP_ID_SMC111:
> OUTPORT16(&g_pSMC->MMUCR, MMUCR_111_ENQUEUE);
> break;
> default:
> OUTPORT16(&g_pSMC->MMUCR, MMUCR_ENQ_TX);
> }
>
> // Wait until it is sent or an error is generated.
> startTime = OALGetTickCount();
> while ((OALGetTickCount() - startTime) < TIMEOUT_VALUE)
> {
> if (INPORT16(&g_pSMC->INTR) & INTR_TX)
> {
> break;
> }
> }
>
> if ((INPORT16(&g_pSMC->INTR) & INTR_TX) == 0)
> {
> OALMSGS(OAL_ERROR, (L"ERROR: SMCSendFrame: Timed out waiting
> for the transfer to complete.\r\n"));
> return(1);
> }
>
> // Read TXDONE Pkt# from FIFO Port Register
> OUTPORT16(&g_pSMC->BANKSEL, 2);
> packetNumber = (INPORT16(&g_pSMC->FIFO) & 0x3F);
>
> // Write to Packet Number Register
> OUTPORT16(&g_pSMC->PNRARR, packetNumber);
>
> // Retrieve packet status
> OUTPORT16(&g_pSMC->PTR, (PTR_AUTOINC | PTR_READ));
> OALStall(100);
> rc = INPORT16(&g_pSMC->DATA);
>
> // Release the packet
> switch (GET_CHIP_ID(g_chipRevision)) {
> case CHIP_ID_SMC111:
> OUTPORT16(&g_pSMC->MMUCR, MMUCR_111_RELEASE_TX);
> break;
> default:
> OUTPORT16(&g_pSMC->MMUCR, MMUCR_REL_SPEC);
> }
> while ((INPORT16(&g_pSMC->MMUCR) & MMUCR_BUSY) != 0);
>
> // Clear the tx interrupt status
> SETPORT16(&g_pSMC->INTR, INTR_TX);
>
> // Tx error?
> if (rc & (EPH_STAT_TXUNRN | EPH_STAT_SQET | EPH_STAT_LOSTCARR |
> EPH_STAT_LATCOL | EPH_STAT_16COL))
> {
> // Display error status.
> OALMSGS(OAL_ERROR, (L"ERROR: SMCSendFrame: status = ( "));
> if (rc & EPH_STAT_TXUNRN)
> {
> OALMSGS(OAL_ERROR, (L"TXUNRN "));
> }
> if (rc & EPH_STAT_SQET)
> {
> OALMSGS(OAL_ERROR, (L"SQET "));
> }
> if (rc & EPH_STAT_LOSTCARR)
> {
> OALMSGS(OAL_ERROR, (L"LOSTCARR "));
> }
> if (rc & EPH_STAT_LATCOL)
> {
> OALMSGS(OAL_ERROR, (L"LATCOL "));
> }
> if (rc & EPH_STAT_16COL)
> {
> OALMSGS(OAL_ERROR, (L"16COL "));
> }
> OALMSGS(OAL_ERROR, (L")\r\n"));
>
> // Re-enable TXENA
> OUTPORT16(&g_pSMC->BANKSEL, 0);
> OUTPORT16(&g_pSMC->TCR, TCR_SWFDUP|TCR_PADEN|TCR_TXEN);
>
> // Failure.
> rc = 1;
> }
> else
> {
> // Success.
> rc = 0;
> }
>
> // Clear the statistics registers
> OUTPORT16(&g_pSMC->BANKSEL, 0);
> INPORT16(&g_pSMC->ECR);
>
> // Set back bank 2
> OUTPORT16(&g_pSMC->BANKSEL, 2);
>
> return rc;
> }
>
> UINT16 SMCGetFrame( BYTE *pBuffer, UINT16 *pLength )
> {
> UINT8 *pos = pBuffer;
> UINT16 code, pointer;
> UINT32 length, count;
>
> // Make sure that bank 2 is actual
> OUTPORT16(&g_pSMC->BANKSEL, 2);
>
> length = 0;
> while ((INPORT16(&g_pSMC->INTR) & INTR_RX) != 0) {
>
> // Setup pointer address register
> pointer = PTR_RCV | PTR_READ;
>
> // Read status
> OUTPORT16(&g_pSMC->PTR, pointer);
> code = INPORT16(&g_pSMC->DATA);
> pointer += sizeof(UINT16);
>
> if ((code & (STAT_ALGNERR|STAT_BADCRC|STAT_LONG|STAT_SHORT)) ==
> 0) {
>
> // Get packet size
> OUTPORT16(&g_pSMC->PTR, pointer);
> length = (INPORT16(&g_pSMC->DATA) & 0x07FF) - 6;
> pointer += sizeof(UINT16);
>
> // Copy packet
> count = length;
> while (count > 1) {
> OUTPORT16(&g_pSMC->PTR, pointer);
> *(UINT16*)pos = INPORT16(&g_pSMC->DATA);
> pointer += sizeof(UINT16);
> pos += sizeof(UINT16);
> count -= sizeof(UINT16);
> }
>
> // Get control word (which can contain last byte)
> OUTPORT16(&g_pSMC->PTR, pointer);
> code = INPORT16(&g_pSMC->DATA);
> pointer += sizeof(UINT16);
> if ((code & CTRL_ODD) != 0) {
> length++;
> *pos = (UINT8)code;
> }
> }
>
> // Release the memory for the received frame
> switch (GET_CHIP_ID(g_chipRevision)) {
> case CHIP_ID_SMC111:
> OUTPORT16(&g_pSMC->MMUCR, MMUCR_111_REM_REL_RX);
> break;
> default:
> OUTPORT16(&g_pSMC->MMUCR, MMUCR_REM_REL_TOP);
> }
>
> while ((INPORT16(&g_pSMC->MMUCR) & MMUCR_BUSY) != 0);
>
> // If length is non zero we get a packet
> if (length > 0) break;
>
> }
>
> *pLength = (UINT16)length;
> return (*pLength);
> }
>
> Thanks
>
> Marcelo Fornazin
>
> voidcoder wrote:
>> are you sure both chips from the first and second board
>> have the same revision?
>>
>> post your SCMSendFrame and SMCGetFrame
>> code here
>

Fornazin
Tue Feb 14 10:06:47 CST 2006

Hi,

I have tried to value for CS3. Now the controller is sending frames,
but it is not receiving. O tried Ethereal to catch the packages on the
network. Ethereal catches all frames sent by the controller. Platform
Builder recognizes the Target, but the transfer doesn't start.

Thanks

Marcelo Fornazin

Voidcoder escreveu:

> The code looks ok, but memory configuration for
> CS3 seems to be wrong. Try the following config
>
> MSC1=0x2884A441

Voidcoder
Tue Feb 14 19:40:04 CST 2006

So you mean you can see now outgoing packets
sent by the PB, but they are not received by the
device? Well, what happens when you just ping
your device from the same PC? Also how much
active network connections do you have on your
development PC (ya, strange question, I know.
but in some cases it does really matter)?







"Fornazin" <fornazin@gmail.com> wrote in message news:1139933207.302965.255440@o13g2000cwo.googlegroups.com...
> Hi,
>
> I have tried to value for CS3. Now the controller is sending frames,
> but it is not receiving. O tried Ethereal to catch the packages on the
> network. Ethereal catches all frames sent by the controller. Platform
> Builder recognizes the Target, but the transfer doesn't start.
>
> Thanks
>
> Marcelo Fornazin
>
> Voidcoder escreveu:
>
>> The code looks ok, but memory configuration for
>> CS3 seems to be wrong. Try the following config
>>
>> MSC1=0x2884A441
>

Fornazin
Tue Feb 14 11:23:08 CST 2006

Hi,

Now I can get the packets using Ethereal or by Platform Builder. It
seems that the Controller is sending frames ok.

I was analyzing SMCGetFrame routine. It seems that SMCGetFrame catches
some packets, but I don't know what theses packets are and what is
happening.

I'm connecting the board and host PC by cross. The board gets DHCP ok
from a DHCP server that I have on host PC. But Platform Builder
doesn't transfer nk.bin file and the Board stays sending messages
Sent BOOTME to 255.255.255.255.

For information, the Ethernet Controller doesn't have an EEPROM and
I'm programming MAC Address by hand. Should I program another feature
on the Controller?

Thanks

Marcelo Fornazin

voidcoder
Tue Feb 14 12:26:35 CST 2006

Yes, there is nothing bad that you set the MAC address by hand. Sure your
NIC on the PC has a different MAC :)

The packets you are seeing in reply to BOOTME are the part of
the simplified TFTP protocol, used by the EBOOT and PB.
If I remember it right, the first packet that you will receve
from the PC when doing "Attach Device" in PB is the
TFTP Write Request. You can easily verify, it should be
"NK.BIN" string somewhere within the first packet.
PB will keep sending this request until the device
will respond with the ACK packet.

What about all network connections on your PC?
How much do you have there? Just goto Network Places -> Properties
and tell me how much active (enabled) connections you have
there, including wireless, other NICs, etc.




"Fornazin" <fornazin@gmail.com> wrote in message
news:1139937788.726895.48740@g43g2000cwa.googlegroups.com...
> Hi,
>
> Now I can get the packets using Ethereal or by Platform Builder. It
> seems that the Controller is sending frames ok.
>
> I was analyzing SMCGetFrame routine. It seems that SMCGetFrame catches
> some packets, but I don't know what theses packets are and what is
> happening.
>
> I'm connecting the board and host PC by cross. The board gets DHCP ok
> from a DHCP server that I have on host PC. But Platform Builder
> doesn't transfer nk.bin file and the Board stays sending messages
> Sent BOOTME to 255.255.255.255.
>
> For information, the Ethernet Controller doesn't have an EEPROM and
> I'm programming MAC Address by hand. Should I program another feature
> on the Controller?
>
> Thanks
>
> Marcelo Fornazin
>

voidcoder
Tue Feb 14 13:11:21 CST 2006

Just have checked. PB uses "BOOT.BIN", not "NK.BIN".
So check for the "BOOT.BIN" string in the first packet.


"voidcoder" <voidcoder@yahoo.com> wrote in message
news:%23SkTvQZMGHA.420@tk2msftngp13.phx.gbl...
> Yes, there is nothing bad that you set the MAC address by hand. Sure your
> NIC on the PC has a different MAC :)
>
> The packets you are seeing in reply to BOOTME are the part of
> the simplified TFTP protocol, used by the EBOOT and PB.
> If I remember it right, the first packet that you will receve
> from the PC when doing "Attach Device" in PB is the
> TFTP Write Request. You can easily verify, it should be
> "NK.BIN" string somewhere within the first packet.
> PB will keep sending this request until the device
> will respond with the ACK packet.
>
> What about all network connections on your PC?
> How much do you have there? Just goto Network Places -> Properties
> and tell me how much active (enabled) connections you have
> there, including wireless, other NICs, etc.
>
>
>
>
> "Fornazin" <fornazin@gmail.com> wrote in message
> news:1139937788.726895.48740@g43g2000cwa.googlegroups.com...
>> Hi,
>>
>> Now I can get the packets using Ethereal or by Platform Builder. It
>> seems that the Controller is sending frames ok.
>>
>> I was analyzing SMCGetFrame routine. It seems that SMCGetFrame catches
>> some packets, but I don't know what theses packets are and what is
>> happening.
>>
>> I'm connecting the board and host PC by cross. The board gets DHCP ok
>> from a DHCP server that I have on host PC. But Platform Builder
>> doesn't transfer nk.bin file and the Board stays sending messages
>> Sent BOOTME to 255.255.255.255.
>>
>> For information, the Ethernet Controller doesn't have an EEPROM and
>> I'm programming MAC Address by hand. Should I program another feature
>> on the Controller?
>>
>> Thanks
>>
>> Marcelo Fornazin
>>
>
>

Fornazin
Tue Feb 14 13:12:59 CST 2006

I'll try to Dump de packets received.

Sorry, I forgot to answer about the network connection. I have just one
network connection on PC and it is downloading images to other
platforms ok.

Thanks

Marcelo Fornazin

voidcoder
Tue Feb 14 13:41:40 CST 2006

Well. I'm asking because PB sometimes behaves not very good
when you have several active network connections in the same time.



"Fornazin" <fornazin@gmail.com> wrote in message
news:1139944379.435912.34410@g47g2000cwa.googlegroups.com...
> I'll try to Dump de packets received.
>
> Sorry, I forgot to answer about the network connection. I have just one
> network connection on PC and it is downloading images to other
> platforms ok.
>
> Thanks
>
> Marcelo Fornazin
>

Fornazin
Wed Feb 15 07:54:10 CST 2006

Hi,

I catch the packets on network. I have tried to follow: I got the
packets using Ethereal and Dumping from SMCGetFrame routine.

In Ethereal I can see the board sending BOOTME Messages and the Host PC
sending packets with boot.bin.octet.

But, in the Dump I did on SMCGetFrame routine, I only can see the
packet came from broadcast messages. I can't see the packet sent to
the Ethernet controller.

I seems like the controller is not catching the packet sent to it.

Thanks

Marcelo Fornazin

Voidcoder
Wed Feb 15 17:09:11 CST 2006

Oh, that may shed some light. Please post your chip
initialization code as well.


"Fornazin" <fornazin@gmail.com> wrote in message news:1140011650.445838.201080@z14g2000cwz.googlegroups.com...
> Hi,
>
> I catch the packets on network. I have tried to follow: I got the
> packets using Ethereal and Dumping from SMCGetFrame routine.
>
> In Ethereal I can see the board sending BOOTME Messages and the Host PC
> sending packets with boot.bin.octet.
>
> But, in the Dump I did on SMCGetFrame routine, I only can see the
> packet came from broadcast messages. I can't see the packet sent to
> the Ethernet controller.
>
> I seems like the controller is not catching the packet sent to it.
>
> Thanks
>
> Marcelo Fornazin
>

Fornazin
Wed Feb 15 10:56:46 CST 2006

Hi,

Here is the code for Chip Initialization. I'm using the code from
Mainstone II BSP. I changed some features to get it working. The main
changes is the header redefinition and the code to load EEPROM.

BOOL SMCInit( BYTE *pAddress, DWORD offset, USHORT mac[3])
{
BOOL rc = FALSE;

OALMSGS(OAL_ETHER&&OAL_FUNC, (
L"+SMCInit(0x%08x, 0x%08x, 0x%08x)\r\n", pAddress, offset, mac
));

// Save address
g_pSMC = (SMC_REGS*)pAddress;

// Chip settle time.
OALStall(750);

// Verify that network chip can be detected
if ((INPORT16(&g_pSMC->BANKSEL) & 0xFF00) != 0x3300)
{

OALMSGS(OAL_ERROR, (
L"ERROR: SMCInit: Network Chip not found at 0x%08x\r\n",
pAddress
));

EdbgOutputDebugString("ERROR: SMCInit: Network Chip not found at
0x%x\r\n", pAddress);

goto cleanUp;
}

// Select bank 3 and read the chip ID and revision.
OUTPORT16(&g_pSMC->BANKSEL, 3);

g_chipRevision = INPORT16(&g_pSMC->REV);

OALMSGS(TRUE, (
L"SMCxxx: Chip Id %d Revision %d\r\n",
GET_CHIP_ID(g_chipRevision), GET_REV_ID(g_chipRevision)
));


// Select bank 1
OUTPORT16(&g_pSMC->BANKSEL, 1);


// Wait until reset & EEPROM load is done
// Fornazin - We don't have a EEPROM, so we don't need this code
//OUTPORT16(&g_pSMC->CTR, CTR_RELOAD);
//while ((INPORT16(&g_pSMC->CTR) & (CTR_RELOAD|CTR_STORE)) != 0);


// Fornazin - Programming MAC by hand
mac[0] = 0x0080;
mac[1] = 0x263E;
mac[2] = 0x5D0A;

OUTPORT16(&g_pSMC->IAR0,mac[0]);
OUTPORT16(&g_pSMC->IAR1,mac[1]);
OUTPORT16(&g_pSMC->IAR2,mac[2]);

// Initialize the control register
switch (GET_CHIP_ID(g_chipRevision)) {
case CHIP_ID_SMC111:
OUTPORT16(&g_pSMC->CTR, CTR_TEEN);
// The SMC111's internal PHY is disabled at boot time - enable
it.
PhyWrite(0, 0, CONTROL_MII_DIS);
// Enable auto-negotiation of link speed.
OUTPORT16(&g_pSMC->BANKSEL, 0);
OUTPORT16(&g_pSMC->MCRPCR, 0x0800);
break;
default:
// Set SQUELCH & NO WAIT bits
OUTPORT16(&g_pSMC->BANKSEL, 1);
SETPORT16(&g_pSMC->CR, CR_SETSQLCH|CR_NOWAIT);
OUTPORT16(&g_pSMC->CTR, CTR_BIT8|CTR_TEEN);
// Memory configuration register value.
OUTPORT16(&g_pSMC->BANKSEL, 0);
OUTPORT16(&g_pSMC->MCRPCR, 0x0006);
}

// Initialize transmit control register
OUTPORT16(&g_pSMC->BANKSEL, 0);
OUTPORT16(&g_pSMC->TCR, TCR_SWFDUP|TCR_PADEN|TCR_TXEN);

// Initialize interrupt mask register (all ints disabled to start)
OUTPORT16(&g_pSMC->BANKSEL, 2);
OUTPORT16(&g_pSMC->INTR, 0);

// Initialize the Receive Control Register
OUTPORT16(&g_pSMC->BANKSEL, 0);
OUTPORT16(&g_pSMC->RCR, RCR_RXEN|RCR_STRIP_CRC);

// We are done
rc = TRUE;

cleanUp:
OALMSGS(OAL_ETHER&&OAL_FUNC, (
L"-SMCInit(mac = %02x:%02x:%02x:%02x:%02x:%02x, rc = %d)\r\n",
mac[0]&0xFF, mac[0]>>8, mac[1]&0xFF, mac[1]>>8, mac[2]&0xFF,
mac[2]>>8,
rc
));

return rc;
}

voidcoder
Wed Feb 15 12:32:34 CST 2006

Hm, looks ok. Are you sure MAC is programmed correctly?
It seems something is wrong with the MAC address, this may
explain why you receive broadcasts, and not directly addressed
frames. You can turn on promiscuous mode (don't remember,
it should be a special bit somewhere in registers) to receive
all frames and than verify packet header.

What MAC is shown in the device packets by the Etherall when
you send BOOTMEs?

Also please try to read it back once programmed:


OUTPORT16(&g_pSMC->IAR0,mac[0]);
OUTPORT16(&g_pSMC->IAR1,mac[1]);
OUTPORT16(&g_pSMC->IAR2,mac[2]);

mac[0] = INPORT16(&g_pLAN91C->IAR0);
mac[1] = INPORT16(&g_pLAN91C->IAR1);
mac[2] = INPORT16(&g_pLAN91C->IAR2);

OALMSGS(OAL_ETHER&&OAL_FUNC, (
L"MAC = %02x:%02x:%02x:%02x:%02x:%02x\r\n",
mac[0]&0xFF, mac[0]>>8, mac[1]&0xFF, mac[1]>>8, mac[2]&0xFF,
mac[2]>>8
));

Does it show the same MAC?

"Fornazin" <fornazin@gmail.com> wrote in message
news:1140022606.909724.299310@z14g2000cwz.googlegroups.com...
> Hi,
>
> Here is the code for Chip Initialization. I'm using the code from
> Mainstone II BSP. I changed some features to get it working. The main
> changes is the header redefinition and the code to load EEPROM.
>
> BOOL SMCInit( BYTE *pAddress, DWORD offset, USHORT mac[3])
> {
> BOOL rc = FALSE;
>
> OALMSGS(OAL_ETHER&&OAL_FUNC, (
> L"+SMCInit(0x%08x, 0x%08x, 0x%08x)\r\n", pAddress, offset, mac
> ));
>
> // Save address
> g_pSMC = (SMC_REGS*)pAddress;
>
> // Chip settle time.
> OALStall(750);
>
> // Verify that network chip can be detected
> if ((INPORT16(&g_pSMC->BANKSEL) & 0xFF00) != 0x3300)
> {
>
> OALMSGS(OAL_ERROR, (
> L"ERROR: SMCInit: Network Chip not found at 0x%08x\r\n",
> pAddress
> ));
>
> EdbgOutputDebugString("ERROR: SMCInit: Network Chip not found at
> 0x%x\r\n", pAddress);
>
> goto cleanUp;
> }
>
> // Select bank 3 and read the chip ID and revision.
> OUTPORT16(&g_pSMC->BANKSEL, 3);
>
> g_chipRevision = INPORT16(&g_pSMC->REV);
>
> OALMSGS(TRUE, (
> L"SMCxxx: Chip Id %d Revision %d\r\n",
> GET_CHIP_ID(g_chipRevision), GET_REV_ID(g_chipRevision)
> ));
>
>
> // Select bank 1
> OUTPORT16(&g_pSMC->BANKSEL, 1);
>
>
> // Wait until reset & EEPROM load is done
> // Fornazin - We don't have a EEPROM, so we don't need this code
> //OUTPORT16(&g_pSMC->CTR, CTR_RELOAD);
> //while ((INPORT16(&g_pSMC->CTR) & (CTR_RELOAD|CTR_STORE)) != 0);
>
>
> // Fornazin - Programming MAC by hand
> mac[0] = 0x0080;
> mac[1] = 0x263E;
> mac[2] = 0x5D0A;
>
> OUTPORT16(&g_pSMC->IAR0,mac[0]);
> OUTPORT16(&g_pSMC->IAR1,mac[1]);
> OUTPORT16(&g_pSMC->IAR2,mac[2]);
>
> // Initialize the control register
> switch (GET_CHIP_ID(g_chipRevision)) {
> case CHIP_ID_SMC111:
> OUTPORT16(&g_pSMC->CTR, CTR_TEEN);
> // The SMC111's internal PHY is disabled at boot time - enable
> it.
> PhyWrite(0, 0, CONTROL_MII_DIS);
> // Enable auto-negotiation of link speed.
> OUTPORT16(&g_pSMC->BANKSEL, 0);
> OUTPORT16(&g_pSMC->MCRPCR, 0x0800);
> break;
> default:
> // Set SQUELCH & NO WAIT bits
> OUTPORT16(&g_pSMC->BANKSEL, 1);
> SETPORT16(&g_pSMC->CR, CR_SETSQLCH|CR_NOWAIT);
> OUTPORT16(&g_pSMC->CTR, CTR_BIT8|CTR_TEEN);
> // Memory configuration register value.
> OUTPORT16(&g_pSMC->BANKSEL, 0);
> OUTPORT16(&g_pSMC->MCRPCR, 0x0006);
> }
>
> // Initialize transmit control register
> OUTPORT16(&g_pSMC->BANKSEL, 0);
> OUTPORT16(&g_pSMC->TCR, TCR_SWFDUP|TCR_PADEN|TCR_TXEN);
>
> // Initialize interrupt mask register (all ints disabled to start)
> OUTPORT16(&g_pSMC->BANKSEL, 2);
> OUTPORT16(&g_pSMC->INTR, 0);
>
> // Initialize the Receive Control Register
> OUTPORT16(&g_pSMC->BANKSEL, 0);
> OUTPORT16(&g_pSMC->RCR, RCR_RXEN|RCR_STRIP_CRC);
>
> // We are done
> rc = TRUE;
>
> cleanUp:
> OALMSGS(OAL_ETHER&&OAL_FUNC, (
> L"-SMCInit(mac = %02x:%02x:%02x:%02x:%02x:%02x, rc = %d)\r\n",
> mac[0]&0xFF, mac[0]>>8, mac[1]&0xFF, mac[1]>>8, mac[2]&0xFF,
> mac[2]>>8,
> rc
> ));
>
> return rc;
> }
>

Fornazin
Fri Feb 17 05:59:20 CST 2006

Hi,

I got the MAC Address as you said and the first 2 bytes was different.
Then I tried to rewrite the MAC Address like the code below:

OUTPORT16(&g_pSMC->IAR0,mac[0]);
OUTPORT16(&g_pSMC->IAR1,mac[1]);
OUTPORT16(&g_pSMC->IAR2,mac[2]);
OUTPORT16(&g_pSMC->IAR0,mac[0]);

Now the MAC Address is ok. BootLoader can get the NK.bin and starts
boot process.

But Windows CE is stopping after the routine InitializeJIT. I think it
could be an issue on interrupt handling.

I had the same problem on other board. The Ethernet Controler on the
other board has Interrupt pin mapped to GPIO0 instead of FPGA. To solve
this problem on the other board I changed the Interruption Handling
Routines (OEMInterruptXXX()). But for this board I don't know what
could be as this board has the same layout of Lubbock, i.e. the
interrupt pin from Ethernet Controller is mapped to FPGA that is Mapped
to GPIO0, like Lubbock.

Thanks
Marcelo Fornazin

S
Mon Mar 20 15:03:31 CST 2006

Hello Marcelo Fornazin

I have just today encountered the same symptoms as you describe in your post
of 02/07/2006.

I am developing a platform with PXA270 running WinCE5.0, derived in some
ways from Mainstone II. One of things that is directly used from Mainstone
II is the LAN9C111 and driver code for this Ethernet controller.

Two of the features of both the Mainstone II wiring to the LAN91C111 as well
as my platform are (a) 32-bit wide data bus, and (b) the CPU bus address bit
ADDR<1> is wired to the A<1> pin of the LAN91C111.

The problem in my circumstance is that the code for the OUTPORT16 function,
which resolves to WRITE_PORT_USHORT in Mainstone file "io.c" appears to be
incorrect.

The problem code line in WRITE_PORT_USHORT is:

*(volatile UINT32 *)nAlignedAddr = (READ_PORT_USHORT(pAddr) | (Data << 16)

If the address to be written is word-aligned (that is, address bits 1 and 0
are both zero), this code works OK. However, if the address is half-word
aligned (address bit 1 = '1'), this statement causes the value that was in
the addressed (upper) halfword (before the call to WRITE_PORT_USHORT) to
overwrite the lower halfword bevause the PXA270 executes the LDRH instruction
to access the upper halfword using pAddr, rather than the lower halfword.

One effect of this problem is that writing the mac addresses as both you and
I have done...

mac[0] = 0x0080;
mac[1] = 0x263E;
mac[2] = 0x5D0A;

... leaves the MAC addresss in the LAN91C111 as

mac[0] = 0x0000;
mac[1] = 0x263E;
mac[2] = 0x5D0A;

We get the value of mac[0] as stored into the LAN91C111 to be 0x0000,
because after reset of the LAN91C111 all the MAC address values are zeroed.

I think the problem code line should be as follows....

*(volatile UINT32 *)nAlignedAddr = (READ_PORT_USHORT(nAlignedAddr) | (Data
<< 16)

At this moment I have not proven that this problem is not caused by some
other glitch in my platform prototype. I know the Mainstone II development
board worked to download nk.bin, and that suggests that something has changed
between the Mainstone II development board and my version of the code or
wiring. Of course, if the least significant two bytes of the Mainstone MAC
address were "00", thenthe problem would not appear, but I no longer have a
Mainstone to examine.

Did you develop a fix for your platform other than to recode
WRITE_PORT_USHORT?

Best regards

Sanford Jones

"Fornazin" wrote:

> Hi,
>
> I got the MAC Address as you said and the first 2 bytes was different.
> Then I tried to rewrite the MAC Address like the code below:
>
> OUTPORT16(&g_pSMC->IAR0,mac[0]);
> OUTPORT16(&g_pSMC->IAR1,mac[1]);
> OUTPORT16(&g_pSMC->IAR2,mac[2]);
> OUTPORT16(&g_pSMC->IAR0,mac[0]);
>
> Now the MAC Address is ok. BootLoader can get the NK.bin and starts
> boot process.
>
> But Windows CE is stopping after the routine InitializeJIT. I think it
> could be an issue on interrupt handling.
>
> I had the same problem on other board. The Ethernet Controler on the
> other board has Interrupt pin mapped to GPIO0 instead of FPGA. To solve
> this problem on the other board I changed the Interruption Handling
> Routines (OEMInterruptXXX()). But for this board I don't know what
> could be as this board has the same layout of Lubbock, i.e. the
> interrupt pin from Ethernet Controller is mapped to FPGA that is Mapped
> to GPIO0, like Lubbock.
>
> Thanks
> Marcelo Fornazin
>
>

Fornazin
Wed Mar 22 13:30:48 CST 2006

Hello Sanford Jones,

The main changes I did on the code were related to EEPROM. My board
doesn't have an EEPROM and I should write de MAC Address by hand.
I'm supposing you are writing MAC Address by hand because yours doesn't
have too.

The first change I did was on the code to read EEPROM data on SMCInit
routine. I change this code:

OUTPORT16(&g_pSMC->CTR, CTR_RELOAD);
while ((INPORT16(&g_pSMC->CTR) & (CTR_RELOAD|CTR_STORE)) != 0);

to

OUTPORT16(&g_pSMC->CTR, CTR_RELOAD);

dwStartTime = OEMEthGetSecs();

while (((INPORT16(&g_pSMC->CTR) & (CTR_RELOAD|CTR_STORE)) != 0)
&& (OEMEthGetSecs() - dwStartTime < 2));

OALStall(1000);

I did this to set a timeout on EEPROM reload.

After the EEPROM code, I rewrote MAC address. Note that I wrote mac[0]
two times to the register. I don't know why, but it only worked in
this way. I also put a delay between MAC Address write and read.

OUTPORT16(&g_pSMC->IAR0,mac[0]);
OUTPORT16(&g_pSMC->IAR1,mac[1]);
OUTPORT16(&g_pSMC->IAR2,mac[2]);
OUTPORT16(&g_pSMC->IAR0,mac[0]);


These are the Major changes I did on LAN91C111 driver code. I also
rewrote the routines to read and write to the LAN registers.

__inline UINT16 READ_PORT_USHORT(UINT16 *pAddr)
{
UINT32 nAlignedAddr = ((UINT32)pAddr & ~0x3);
if ((UINT32)pAddr & 0x2)
return((UINT16) ((*(volatile unsigned long *)nAlignedAddr) >>
16));
else
return(*(volatile unsigned short *)nAlignedAddr);
}

#define WRITE_PORT_USHORT(pAddr, Data) \
{ \
UINT32 nAlignedAddr = ((UINT32)pAddr & ~0x3); \
if ((UINT32)pAddr & 0x2) \
*(volatile UINT32 *)nAlignedAddr = (READ_PORT_USHORT(pAddr) |
(Data << 16)); \
else \
*(volatile UINT16 *)pAddr = Data; \
}

Do this help you?

Best Regards

Marcelo Fornazin

SJones
Wed Mar 22 14:36:30 CST 2006

Hello,

If you wish to fix the code bug in the same manner I did, then change the
statement

*(volatile UINT32 *)nAlignedAddr = (READ_PORT_USHORT(pAddr)

... to this...

*(volatile UINT32 *)nAlignedAddr = (READ_PORT_USHORT(nAlignedAddr)

After making this change, you should not have to write mac[0] a second time.

It has been working for me for a day now, and I have not seen any problems
since making this change.

After googling the Web for hours, I see that many others have suffered
similar problems due to this code bug, but have have not recognized it, using
workarounds instead of either fixing it or just avoiding IO calls to the
WRITE_PORT_USHORT function in io.c.

Another fix would be to disconnect and ground the address bit 1 (A1) line
at the LAN91C111. However, that would not prevent the problem for any other
devices that might be accessed by calls to OUTPUT16 when the linker resolves
OUTPORT16 into WRITE_PORT_USHORT in module io.c.

The code in io.c for WRITE_REGISTER_USHORT may work too instead of
WRITE_PORT_USHORT, but I have not tried that substitution.

Best regards

Sanford Jones


"Fornazin" wrote:

> Hello Sanford Jones,
>
> The main changes I did on the code were related to EEPROM. My board
> doesn't have an EEPROM and I should write de MAC Address by hand.
> I'm supposing you are writing MAC Address by hand because yours doesn't
> have too.
>
> The first change I did was on the code to read EEPROM data on SMCInit
> routine. I change this code:
>
> OUTPORT16(&g_pSMC->CTR, CTR_RELOAD);
> while ((INPORT16(&g_pSMC->CTR) & (CTR_RELOAD|CTR_STORE)) != 0);
>
> to
>
> OUTPORT16(&g_pSMC->CTR, CTR_RELOAD);
>
> dwStartTime = OEMEthGetSecs();
>
> while (((INPORT16(&g_pSMC->CTR) & (CTR_RELOAD|CTR_STORE)) != 0)
> && (OEMEthGetSecs() - dwStartTime < 2));
>
> OALStall(1000);
>
> I did this to set a timeout on EEPROM reload.
>
> After the EEPROM code, I rewrote MAC address. Note that I wrote mac[0]
> two times to the register. I don't know why, but it only worked in
> this way. I also put a delay between MAC Address write and read.
>
> OUTPORT16(&g_pSMC->IAR0,mac[0]);
> OUTPORT16(&g_pSMC->IAR1,mac[1]);
> OUTPORT16(&g_pSMC->IAR2,mac[2]);
> OUTPORT16(&g_pSMC->IAR0,mac[0]);
>
>
> These are the Major changes I did on LAN91C111 driver code. I also
> rewrote the routines to read and write to the LAN registers.
>
> __inline UINT16 READ_PORT_USHORT(UINT16 *pAddr)
> {
> UINT32 nAlignedAddr = ((UINT32)pAddr & ~0x3);
> if ((UINT32)pAddr & 0x2)
> return((UINT16) ((*(volatile unsigned long *)nAlignedAddr) >>
> 16));
> else
> return(*(volatile unsigned short *)nAlignedAddr);
> }
>
> #define WRITE_PORT_USHORT(pAddr, Data) \
> { \
> UINT32 nAlignedAddr = ((UINT32)pAddr & ~0x3); \
> if ((UINT32)pAddr & 0x2) \
> *(volatile UINT32 *)nAlignedAddr = (READ_PORT_USHORT(pAddr) |
> (Data << 16)); \
> else \
> *(volatile UINT16 *)pAddr = Data; \
> }
>
> Do this help you?
>
> Best Regards
>
> Marcelo Fornazin
>
>