[U-Boot-Users] Re: Interrupt management under PPC4xx platform

llandre r&d at wawnet.biz
Tue Apr 15 09:07:10 CEST 2003


> >
> > I found a first problem in the trap_init function. Here is the situation
> > before the instruction
> > rlwinm r9, r7, 0, 18, 31:
> >
> > r7 = 0x7fce100
> > CFG_MONITOR_LEN = 200*1024
>
>If you look at the code,  you  will  see  that  r7  was  loaded  from
>GOT(_start),  so  it  contains the entry point address of your image.
>0x7fce100 seems a bit unlikely to me.
>
>Here a couple of questions:
>
>How did you #define CFG_MONITOR_BASE?

#define CFG_SRAM_BASE           0xFFF80000
#define CFG_FLASH_BASE          0xFFF00000
#define CFG_MONITOR_BASE        CFG_SRAM_BASE

>What's your TEXT_BASE?

TEXT_BASE = 0xFFF80000

>How much RAM do you have on your system?

128MByte: 0x0000:0000 - 0x07FF:FFFF

>Which output is printed from the debug code in "lib_ppc/board.c"
>(especially the "Now running in RAM - U-Boot at: xxx" line is of
>interest).

U-Boot 0.2.0 (Apr 14 2003 - 19:05:41)

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 arbiter enabled
            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 200k for U-Boot at: 07fce000
Reserving 132k for malloc() at: 07fad000
Reserving 112 Bytes for Board Info at: 07facf90
Reserving 44 Bytes for Global Data at: 07facf64
Stack Pointer at: 07facf48
New Stack Pointer is: 07facf48
Now running in RAM - U-Boot at: 07fce000
FLASH: 512 kB
[board.c, 767] Calling env_relocate ...
env_relocate[203] offset = 0x804e000
env_relocate[221] malloced ENV at 07fad008
In:    serial
Out:   serial
Err:   serial
KGDB:  kgdb ready
ready
U-Boot relocated to 07fce000
### 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
ARP broadcast 1


> > So r9, that contains the target address, is set to 0x2100 and consequently
> > the vectors are placed starting from there.
> > If  change CFG_MONITOR_LEN to 192*1024 they are copied to the right place
> > (0x100, anybody corrects me if I'm wrong) and the PIT interrupt is ok.
>
>As you can read from the comments, the "rlwinm" instruction  performs
>the equivalent of the C expression "_start & 0x3FFF".

If I did the math right, r7 is 0x7fce100 because I reserved 200kB for 
U-Boot. So:
EndOfSDRAM - 200kB + 0x100 = 0x08000000 - 0x32000 + 0x100 = 0x07fce100
and
0x07fce100 & 0x3FFF = 0x2100


> > With Ethereal I monitor the LAN traffic and I can see that the PC 
> correctly
> > answers to the ARP request. The SDRAM controller should be ok because I
> > imported the initialization code from OpenBIOS. I suspect there are some
> > slight differences in the Ethernet controller across the 405xx processors
> > (I use a 405EP). I think I should investigate the Ethernet code. Where do
> > you suggest me to start?
>
>Please don't jump around. Let's fix one problem at a time.

Yeah, you are right but Jerry's message ( RE: 405Gpr timer interrupt ) 
convinced me the two problems, interrupts and ethernet, are strictly 
linked. Sorry if I made unwanted confusion.


llandre





More information about the U-Boot mailing list