[U-Boot-Users] u-boot ISR question
Hello,
On a ppc_440gx platform I wrote a small u-boot stand alone app for debugging. I tried to hook the ISR at 0x700 and use a trap instruction.
I replaced the isr routine w/my own. In the process I discovered the isr at 0x700 does nothing except store the address of the service routine and return handler at addresses 0x788 and 0x78c.
I stubbed the entire routine and it still works as long as the above addresses are there.
How does u-boot execute a trap instruction without executing at least a branch instruction from the trap location 0x700?
How does it get to the global transfer_to_handler routine???
IVPR=0 and IVOR6=0x700 appear to be set correctly.
Thanks Don Russell
in service routine
MSR=0x9000, srr0=0x7088 ivpr=0x0, ivor6=0x700 pc= 0x403C , ad=0x1FF4E498 msr 0x00029000 lr 0x00004034 cr 0x24022222 trap 0x00000700
addr=0x700, 0x4C00012C =>isync istruction addr=0x704, 0x4C00012C addr=0x708, 0x4C00012C addr=0x70C, 0x4C00012C addr=0x710, 0x4C00012C addr=0x714, 0x4C00012C addr=0x718, 0x4C00012C addr=0x71C, 0x4C00012C addr=0x720, 0x4C00012C addr=0x724, 0x4C00012C addr=0x728, 0x4C00012C addr=0x72C, 0x4C00012C addr=0x730, 0x4C00012C addr=0x734, 0x4C00012C addr=0x738, 0x4C00012C addr=0x73C, 0x4C00012C addr=0x740, 0x4C00012C addr=0x744, 0x4C00012C addr=0x748, 0x4C00012C addr=0x74C, 0x4C00012C addr=0x750, 0x4C00012C addr=0x754, 0x4C00012C addr=0x758, 0x4C00012C addr=0x75C, 0x4C00012C addr=0x760, 0x4C00012C addr=0x764, 0x4C00012C addr=0x768, 0x4C00012C addr=0x76C, 0x4C00012C addr=0x770, 0x4C00012C addr=0x774, 0x4C00012C addr=0x778, 0x4C00012C addr=0x77C, 0x4C00012C addr=0x780, 0x4C00012C addr=0x784, 0x4C00012C addr=0x788, 0x6B1C => trapservice location addr=0x78C, 0x7E60 => return handler location
Hi Don,
On Wednesday 15 February 2006 16:28, Russell, Don wrote:
On a ppc_440gx platform I wrote a small u-boot stand alone app for debugging. I tried to hook the ISR at 0x700 and use a trap instruction.
Hmmm. Do you want to connect an ISR like for external interrupts? That would be at 0x500 for 4xx platforms.
I replaced the isr routine w/my own. In the process I discovered the isr at 0x700 does nothing except store the address of the service routine and return handler at addresses 0x788 and 0x78c.
I stubbed the entire routine and it still works as long as the above addresses are there.
How does u-boot execute a trap instruction without executing at least a branch instruction from the trap location 0x700?
How does it get to the global transfer_to_handler routine???
Could be that the 44x implementation is broken. If so a patch to fix this is most welcome. ;-)
<snip>
addr=0x700, 0x4C00012C =>isync istruction addr=0x704, 0x4C00012C addr=0x708, 0x4C00012C addr=0x70C, 0x4C00012C addr=0x710, 0x4C00012C addr=0x714, 0x4C00012C addr=0x718, 0x4C00012C addr=0x71C, 0x4C00012C addr=0x720, 0x4C00012C addr=0x724, 0x4C00012C addr=0x728, 0x4C00012C addr=0x72C, 0x4C00012C addr=0x730, 0x4C00012C addr=0x734, 0x4C00012C addr=0x738, 0x4C00012C addr=0x73C, 0x4C00012C addr=0x740, 0x4C00012C addr=0x744, 0x4C00012C addr=0x748, 0x4C00012C addr=0x74C, 0x4C00012C addr=0x750, 0x4C00012C addr=0x754, 0x4C00012C addr=0x758, 0x4C00012C addr=0x75C, 0x4C00012C addr=0x760, 0x4C00012C addr=0x764, 0x4C00012C addr=0x768, 0x4C00012C addr=0x76C, 0x4C00012C addr=0x770, 0x4C00012C addr=0x774, 0x4C00012C addr=0x778, 0x4C00012C addr=0x77C, 0x4C00012C addr=0x780, 0x4C00012C addr=0x784, 0x4C00012C addr=0x788, 0x6B1C => trapservice location addr=0x78C, 0x7E60 => return handler location
Here a log from our Ocotea:
=> md 700 00000700: 7e9043a6 7eb143a6 7e800026 3aa1ff00 ~.C.~.C.~..&:... 00000710: 929500a8 92d50068 92f5006c 7e9042a6 .......h...l~.B. 00000720: 92950060 7ed142a6 92d50064 7e8802a6 ...`~.B....d~... 00000730: 929500a0 7ec902a6 92d5009c 7e8102a6 ....~.......~... 00000740: 929500a4 7eda02a6 7efb02a6 90150010 ....~...~....... 00000750: 90350014 90550018 90350000 7ea1ab78 .5...U...5..~..x 00000760: 9075001c 90950020 90b50024 90d50028 .u..... ...$...( 00000770: 38610010 3a801000 52f40420 80ce8014 8a..:...R.. .... 00000780: 7cc803a6 4e800021 0ffc7a10 0ffc719c |...N..!..z...q. 00000790: 00000000 00000000 00000000 00000000 ................
This does not match your description. What version are you using?
Best regards, Stefan
participants (2)
-
Russell, Don -
Stefan Roese