[U-Boot-Users] Linux kernel crash in the early_init function

[llandre]

I have a problem with U-Boot on the 405EP eval. board. Everything works 
fine until the kernel takes control and the system hangs:
------------------------------------------------------------------------------------
U-Boot 0.2.0 (May  6 2003 - 12:04:15)

CPU:   IBM PowerPC 405EP Rev. A at 266.666 MHz (PLB=133, OPB=66, EBC=66 MHz)
            PCI async ext clock used (sync mode not supported), internal 
PCI arbd           16 kB I-Cache 16 kB D-Cache
Board: ### No HW ID - assuming WALNUT405
I2C:   ready
DRAM:  128 MB
Top of RAM usable for U-Boot at: 08000000
Reserving 192k for U-Boot at: 07fd0000
Reserving 132k for malloc() at: 07faf000
Reserving 112 Bytes for Board Info at: 07faef90
Reserving 44 Bytes for Global Data at: 07faef64
Stack Pointer at: 07faef48
New Stack Pointer is: 07faef48
Now running in RAM - U-Boot at: 07fd0000
FLASH: 512 kB
[board.c, 767] Calling env_relocate ...
env_relocate[203] offset = 0x8050000
env_relocate[221] malloced ENV at 07faf008
In:    serial
Out:   serial
Err:   serial
KGDB:  kgdb ready
ready
U-Boot relocated to 07fd0000
[board.c, 913] Calling interrupt_init ...
### main_loop entered: bootdelay=3

### main_loop: bootcmd="tftpboot 0x400000 vmlinux.PPCBoot"
Hit any key to stop autoboot:  0
ENET Speed is 10 Mbps - HALF duplex connection
TX_BUFF 0 @ 0x07fb0228
RX_BUFF 0 @ 0x07ff3fc0
RX_BUFF 1 @ 0x07ff45c0
RX_BUFF 2 @ 0x07ff4bc0
RX_BUFF 3 @ 0x07ff51c0
Install interrupt for vector 9 ==> 07fd49c0
Install interrupt for vector 10 ==> 07fd49c0
Install interrupt for vector 11 ==> 07fd49c0
Install interrupt for vector 12 ==> 07fd49c0
Install interrupt for vector 13 ==> 07fd49c0
Install interrupt for vector 14 ==> 07fd49c0
Install interrupt for vector 15 ==> 07fd49c0
ARP broadcast 1
Got good ARP - start TFTP
TFTP from server 192.168.10.6; our IP address is 192.168.10.203
Filename 'vmlinux.PPCBoot'.
Load address: 0x400000
Loading: #################################################################
          #########################################
done
Bytes transferred = 539758 (83c6e hex)
Automatic boot of image at addr 0x00400000 ...
## Booting image at 00400000 ...
    Image Name:   Linux-2.4.21-pre5
    Created:      2003-05-06  11:42:31 UTC
    Image Type:   PowerPC Linux Kernel Image (gzip compressed)
    Data Size:    539694 Bytes = 527 kB
    Load Address: 00000000
    Entry Point:  00000000
    Verifying Checksum ... OK
    Uncompressing Kernel Image ... OK
## Current stack ends at 0x07FAE5B8 => set upper limit to 0x00800000
## cmdline at 0x007FFC00 ... 0x007FFC16
bd address  = 0x07FAEF90
memstart    = 0x00000000
memsize     = 0x08000000
flashstart  = 0xFFF80000
flashsize   = 0x00080000
flashoffset = 0x00030000
sramstart   = 0x00000000
sramsize    = 0x00000000
bootflags   = 0x6BBA3A55
procfreq    = 266.666 MHz
plb_busfreq = 133.333 MHz
pci_busfreq = 33.333 MHz
ethaddr     = 00:50:C2:1E:AF:FE
IP addr     = 192.168.10.203
baudrate    = 115200 bps
No initrd
## Transferring control to Linux (at address 00000000) ...
------------------------------------------------------------------------------------

I found that the function memset_io, invoked by early_init, corrupts the 
memory region where the function identify_cpu is located.
This is the disassembled produced by objdump:

c0006774 <identify_cpu>:
c0006774:       3d 03 c0 12     addis   r8,r3,-16366
c0006778:       39 08 e1 40     addi    r8,r8,-7872
c000677c:       7c ff 42 a6     mfpvr   r7
c0006780:       80 a8 00 00     lwz     r5,0(r8)
c0006784:       7c a5 38 38     and     r5,r5,r7
c0006788:       80 c8 00 04     lwz     r6,4(r8)
c000678c:       7c 06 28 40     cmplw   r6,r5
c0006790:       41 82 00 0c     beq-    c000679c <identify_cpu+0x28>
c0006794:       39 08 00 20     addi    r8,r8,32
c0006798:       4b ff ff e8     b       c0006780 <identify_cpu+0xc>
c000679c:       3c c3 c0 14     addis   r6,r3,-16364
c00067a0:       38 c6 f0 bc     addi    r6,r6,-3908
c00067a4:       54 84 10 3a     rlwinm  r4,r4,2,0,29
c00067a8:       7d 03 40 50     subf    r8,r3,r8
c00067ac:       7d 04 31 2e     stwx    r8,r4,r6
c00067b0:       4e 80 00 20     blr


This is what I see in memory before executing the memset_io:

PPC405EP>go
- TARGET: target has entered debug mode
PPC405EP>md 0xc0006774 8
c0006774 : 0x3d03c012   1023655954  =...
c0006778 : 0x3908e140    956883264  9..@
c000677c : 0x7cff42a6   2097103526  |.B.
c0006780 : 0x80a80000  -2136473600  ....
c0006784 : 0x7ca53838   2091202616  |.88
c0006788 : 0x80c80004  -2134376444  ....
c000678c : 0x7c062840   2080778304  |.(@
c0006790 : 0x4182000c   1099038732  A...
PPC405EP>go
- TARGET: target has entered debug mode

This is what I see in memory after executing the memset_io:

PPC405EP>md 0xc0006774 8
c0006774 : 0xff03ffff  -  16515073  ....
c0006778 : 0xff08ffff  -  16187393  ....
c000677c : 0xff08ffff  -  16187393  ....
c0006780 : 0x80a80000  -2136473600  ....
c0006784 : 0x7ca53838   2091202616  |.88
c0006788 : 0x80c80004  -2134376444  ....
c000678c : 0x3c060840   1007028288  <..@
c0006790 : 0x7c062840   2080778304  |.(@
PPC405EP>


Anybody have already seen something like that?
Is it possible that this has to do with an erroneous cache initialization?

Many thanks in advance.


llandre