LPC2xxx Ethernet device driver

LPC2xxx Ethernet device driver

[uwe.kindler]

[-- Attachment #1: Type: text/plain, Size: 381 bytes --]

Hello,

the following patch adds a generic ethernet driver for the LPC2xxx on-chip EMAC peripheral. The driver was tested with the LPC2468 OEM Board from Embedded Artists. 

Regards,

Dipl. Inf. (FH)
Uwe Kindler
Software Engineering

--

cetoni GmbH
Am Wiesenring 6
D-07554 Korbussen

Tel.: +49 (0) 36602 338 28
Fax:  +49 (0) 36602 338 11
uwe.kindler@cetoni.de
http://www.cetoni.de

[-- Attachment #2: lpc2xxx_eth.tar.gz --]
[-- Type: application/octet-stream, Size: 13638 bytes --]

Re: LPC2xxx Ethernet device driver

[Andrew Lunn]

On Thu, Sep 11, 2008 at 10:29:16AM +0200, uwe.kindler@cetoni.de wrote:
> Hello,
> 

> the following patch adds a generic ethernet driver for the LPC2xxx
> on-chip EMAC peripheral. The driver was tested with the LPC2468 OEM
> Board from Embedded Artists.

Hi Uwe

I just read the README where you say tm_basic dies horrible.

What memory layout are you using?

I just build a ROM redboot and a RAM tm_basic using the defaults.
The resulting images clash in memory:

lunn@londo:~/eCos/redboot/install/bin$ arm-elf-objdump --headers redboot.elf 
 15 .data         00000700  a0000000  00015508  00020000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 16 .bss          0000aa24  a0000700  a0000700  00020700  2**5
                  ALLOC

lunn@londo:~/eCos/work$ arm-elf-objdump --headers install/tests/kernel/current/tests/tm_basic 
 15 .data         000002fc  a0000000  00011cb0  00020000  2**2
                  CONTENTS, ALLOC, LOAD, DATA
 16 .bss          00c7cf68  a00002fc  a00002fc  000202fc  2**5
                  ALLOC

In particular, lpc2xxx_priv_data in the redboot image is at 0xa0000264
which is in the middle of the lpc2xxx_sc for tm_basic. So an interrupt
from the ethernet is probably going to cause corruption.

Or do you are another RAM image layout when using ROM redboot?

   Andrew

Re: LPC2xxx Ethernet device driver

[Uwe Kindler]

Hello Andrew,

maybe you made a mistake when building tm_basic. Please make sure that 
RAM startup is selected.

Here is what I get from objdump:

arm-elf-objdump --headers redboot.elf
  15 .data         00000e08  a0000000  0002a458  00038000  2**2
                   CONTENTS, ALLOC, LOAD, CODE
  16 .bss          0000ad78  a0000e08  a0000e08  00038e08  2**5
                   ALLOC

arm-elf-objdump --headers tm_basic
  15 .data         00000330  a002bd98  a002bd98  00023d98  2**2
                   CONTENTS, ALLOC, LOAD, DATA
  16 .bss          00c7a65c  a002c0c8  a002c0c8  000240c8  2**5
                   ALLOC

So there is no memory clash here. This is a snipped from the RAM ldi file:

MEMORY
{
     sram   : ORIGIN = 0x40000000, LENGTH = 0x10000
     ram    : ORIGIN = 0xA0000000, LENGTH = 0x2000000
}

SECTIONS
{
     SECTIONS_BEGIN
     SECTION_fixed_vectors (sram, 0x40000400, LMA_EQ_VMA)
     SECTION_rom_vectors (ram, 0xA0010000, LMA_EQ_VMA)
     SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_rodata1 (ram, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_gcc_except_table (ram, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_data (ram, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
     SECTIONS_END
}

The first data in RAM (rom_vectors) starts at 0xA10000. That means the 
first 0x10000 bytes in RAM are reserved for Redboot.

I have the tm_basic test as an image in fis directory. I'm connected to 
Redboot via serial line. I load tm_basic with fis load tm_basic. After 
this operation there are no problems. The ethernet part from Redboot 
works fine (Ping and connection via TCP/IP is possible). If I execute 
the tm_basic test now while I'm still connected via serial line, the 
test runs properly. If I connect to Redboot via TCP/IP directly before I 
type the go command and then type the go command via TCP/IP then the 
test starts (I can see the first lines printed in my TCP/IP console) and 
then the test crashes.

If the test is started via TCP/IP then the test uses the TCP/IP 
connection channel to print all diag_printf messages. Only for testing 
purposes I inserted the following line into tm_basic cyg_start() 
function: CYGACC_CALL_IF_SET_CONSOLE_COMM(0). This forces all output to 
the first serial channel. So no single character is transmitted via 
TCP/IP after start of tm_basic. If I start tm_basic via TCP/IP then I 
see the first three lines in my serial console and then the test 
crashes. If I start this modiefied tm_basic via TCP/IP connection and 
the option -n then the test runs till completion without any problems - 
real strange :o(

Regards,

Dipl. Inf. (FH)
Uwe Kindler
Software Engineering

--

cetoni GmbH
Am Wiesenring 6
D-07554 Korbussen

Tel.: +49 (0) 36602 338 28
Fax:  +49 (0) 36602 338 11
uwe.kindler@cetoni.de
www.cetoni.de

Re: LPC2xxx Ethernet device driver

[Andrew Lunn]

On Thu, Sep 11, 2008 at 04:21:49PM +0200, Uwe Kindler wrote:
> Hello Andrew,
>
> maybe you made a mistake when building tm_basic. Please make sure that  
> RAM startup is selected.

Yep, i made an error :-(

I did think it was a bit unlikely it would be so simple...

Anyway, otherwise the driver looks good. I will commit it soon.

  Andrew

Re: LPC2xxx Ethernet device driver

[Andrew Lunn]

On Thu, Sep 11, 2008 at 10:29:16AM +0200, uwe.kindler@cetoni.de wrote:
> Hello,
> 
> the following patch adds a generic ethernet driver for the LPC2xxx on-chip EMAC peripheral. The driver was tested with the LPC2468 OEM Board from Embedded Artists. 

Hi Uwe

This and the following two patches which build on it have been
committed.

        Thanks
                Andrew