Hi,

I noticed some strange issues with our PMC440 (PPC440PEx based) board and also with the sequoia eval platform.

In a certain configuration these boards stuck during the Ethernet POST tests. When they got stuck, it is even not possible to attach with a BDI2000.

On the console you only see this:

U-Boot 1.3.1 (May 30 2008 - 17:01:42)

CPU:   AMCC PowerPC 440EPx Rev. A at 533.333 MHz (PLB=133, OPB=66, EBC=66 MHz)        Security/Kasumi support        Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)        Internal PCI arbiter enabled, PCI async ext clock used        32 kB I-Cache 32 kB D-Cache Board: Sequoia - AMCC PPC440EPx Evaluation Board, Rev. F, PCI=33 MHz I2C:   ready DTT:   1 is 38 C DRAM:  256 MB FLASH: 64 MB NAND:  32 MiB PCI:   Bus Dev VenId DevId Class Int         00  0c  168c  0013  0200  43 In:    serial Out:   serial Err:   serial USB:   Host(int phy) Device(ext phy) Net:   ppc_4xx_eth0, ppc_4xx_eth1

I first noticed this behavior on our PMC440 boards. These boards are similiar to the Sequoia platform (256MB DDR2 RAM, 2x Gigabit Ethernet, ...). Playing with some printfs I found out that the board got stuck in the Ethernet POST. When I disable U-Boot's LOG_BUFFER feature the problem dissapears. First I never noticed this bahavior on the sequoia platform and I thought about a PMC440 specific issue. Then I compiled U-Boot 1.3.1 for the sequoia platform (1.3.1 is used on PMC440 until now). Last week I got the same issue on the sequoia platform. Not that often as on the PMC440, but the same issue. Because it is easy to reproduce on PMC440 boards, I played a little bit with different configurations:

1) With LOG_BUFFER enabled: often, about every 2nd boot 2) Without LOG_BUFFER (POST messages come out in the console) -> issue never seens 3) Modified 4xx Ether POST with RX Buffers in OCM -> issue never seens 4) DCACHE turned on -> issue never seens

On the sequoia board I've only seens it after a reboot from Linux. But on PMC440 also after poweron. This must not have any meaning because I do more testing with our board than with the eval board :-)

printf debugging showed up that the boards get stuck in post/cpu/ppc4xx/ether.c in test_ctlr()/ether_post_send(). Some packets are send, recevied and checked correctly. Then suddenly at a random packet size ether_post_send() freezes the board.

Did anybody else see this behavior? Did we miss any EMAC errata?

Matthias