[U-Boot-Users] Re: Interrupt management under PPC4xx platform
Just after posting the message "Interrupt management under PPC4xx platform", I noticed the thread "405Gpr timer interrupt" describing the same problem I encountered with the Ethernet interface (I work with the 405EP eval. board). I think it is due to the incorrect interrupt management, too. For this reason, and since this is my first experience with U-Boot, I posted the message "Interrupt management under PPC4xx platform" http://sourceforge.net/mailarchive/forum.php?thread_id=1968232&forum_id=.... I got a more stable situation by intializing the EVPR register like this: #if 1 /* OpenBIOS' way */ addis r4,r0,CFG_MONITOR_BASE@h /*! set exception vector prefix */ mtevpr r4 /*! to high ROM address */ #else /* U-Boot's way */ mtevpr r4 #endif
but unfortunately I still have the problem with the Ethernet interface. Did you figure out what is wrong?
llandre
Hi Llandre!
The EVPR is set to zero by U-Boot since the interrupts (exceptions) are enabled when U-Boot is running from SDRAM and _not_ from flash anymore (Wolfgang, please correct me, if I am wrong here). The exception vectors are located (relocated) at addresses 0x100, 0x200, etc. The offset (EVPR) is zero at this moment.
The interrupt management for PPC4xx in U-Boot is OK! We have several different boards with IBM PPC's (PPC405CR, PPC405GP, PPC405GPr) running without any problems here (timer and ethernet interrupts working).
Are you sure, that the interrupts are causing this "unstable" behaviour? I would suspect, that other exceptions are responsible for this errors?
Best regards, Stefan.
Just after posting the message "Interrupt management under PPC4xx platform", I noticed the thread "405Gpr timer interrupt" describing the same problem I encountered with the Ethernet interface (I work with the 405EP eval. board). I think it is due to the incorrect interrupt management, too. For this reason, and since this is my first experience with U-Boot, I posted the message "Interrupt management under PPC4xx platform" http://sourceforge.net/mailarchive/forum.php?thread_id=1968232&for um_id=12898. I got a more stable situation by intializing the EVPR register like this: #if 1 /* OpenBIOS' way */ addis r4,r0,CFG_MONITOR_BASE@h /*! set exception vector prefix */ mtevpr r4 /*! to high ROM address */ #else /* U-Boot's way */ mtevpr r4 #endif
but unfortunately I still have the problem with the Ethernet interface. Did you figure out what is wrong?
llandre
This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message EFEAIMDCOOOHIEPHDNFJCEEJFFAA.stefan.roese@esd-electronics.com you wrote:
The EVPR is set to zero by U-Boot since the interrupts (exceptions) are enabled when U-Boot is running from SDRAM and _not_ from flash anymore (Wolfgang, please correct me, if I am wrong here). The exception vectors are
This is correct.
The interrupt management for PPC4xx in U-Boot is OK! We have several different boards with IBM PPC's (PPC405CR, PPC405GP, PPC405GPr) running without any problems here (timer and ethernet interrupts working).
Same here.
Are you sure, that the interrupts are causing this "unstable" behaviour? I would suspect, that other exceptions are responsible for this errors?
Right, and as usual I would suspect SDRAM initialization first.
Thanks, Stefan!
Wolfgang Denk
In message EFEAIMDCOOOHIEPHDNFJCEEJFFAA.stefan.roese@esd-electronics.com you wrote:
The EVPR is set to zero by U-Boot since the interrupts (exceptions) are enabled when U-Boot is running from SDRAM and _not_ from flash anymore (Wolfgang, please correct me, if I am wrong here). The exception
vectors are
This is correct.
The interrupt management for PPC4xx in U-Boot is OK! We have several different boards with IBM PPC's (PPC405CR, PPC405GP, PPC405GPr) running without any problems here (timer and ethernet interrupts working).
Same here.
Are you sure, that the interrupts are causing this "unstable" behaviour? I would suspect, that other exceptions are responsible for this errors?
Right, and as usual I would suspect SDRAM initialization first.
Thanks, Stefan!
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
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. Nevertheless the problem with Ethernet still occurs:
### 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
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?
llandre
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
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.
Wolfgang?
Nevertheless the problem with Ethernet still occurs:
### 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
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?
I agree, SDRAM should be OK!
If you enable the "irq" command (CFG_CMD_IRQ), do you see any irq's incrementing at all?
This is what I see on a PPC405GP(r):
=> tftp 100000 /tftpboot/pImage ENET Speed is 100 Mbps - FULL duplex connection ARP broadcast 1 TFTP from server 10.0.18.190; our IP address is 10.0.18.160 Filename '/tftpboot/pImage'. Load address: 0x100000 Loading: ################################################################# ################################################################# ########## done Bytes transferred = 712344 (ade98 hex) => irqs
Interrupt-Information: Nr Routine Arg Count 09 01fc3f84 00000000 0 10 01fc3f84 00000000 0 11 01fc3f84 00000000 0 12 01fc3f84 00000000 1394 13 01fc3f84 00000000 0 14 01fc3f84 00000000 0 15 01fc3f84 00000000 0
Sorry, but I haven't digged into the PPC405EP this deep. It could be, that there is a difference in the implementation. Please check the above irq test at first...
Best regards, Stefan.
In message 5.1.1.6.0.20030414164127.01cb42e0@192.168.2.1 you wrote:
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? What's your TEXT_BASE? How much RAM do you have on your system? 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).
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".
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.
Best regards,
Wolfgang Denk
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
participants (3)
-
llandre -
Stefan Roese -
Wolfgang Denk