I really don't understand what this discussion is all about.
Please look at the code yourself. It is not that complicated to understand. See "cpu/ppc4xx/start.S":
Sorry if I am upsetting the members of the list, I was just trying to develop some understanding of what the code in trap_init does. I KNOW that there must be code to copy the IVT, and I studied the section that you pointed out in trap_init, I simply am weak at PPC assembly and mistundestood some of the instructions - I suppose I should have posted it to the PPC-assembly users list if there is one.
Guess what this 1: ... "bne 1b" loop is doing?
I figured that out all by myself...
The code is really simple, and I don't know why you are missing it when reading the sources or when running under a debugger. And the function name "trap_init()" is IMHO well chosen and descriptive enough, too. And there is even a comment which explains what it does.
The code is simple to you - not to me - however now that I have gone through this learning process - it looks simple to me.
The only thing I can see that could go wrong here is that the computation of the end address (r9 = _start & 0x3FFF) might fail if you pass bogus values for _start to that code. Please note that the code assumes that it has been started from the reset entry point, i. e. _start is at a well known address, and "_start & 0x3FFF" is equivalent to 0x100 ;-) But then, this should be trivial to check, and I assume you already checked it under a debugger, didn't you?
Yes - of course I checked it under the debugger
Thanks for the response. I think my problem may be the base uboot address. The address is 0x3fcf000. The mask is 3fff. If my uboot started on a nice 16 bit address then the result would be 0(3fc0000 & 3fff) but I was getting 0xf000(3fcf000 & 3fff). So I think that the fix is to move uboot down to 0x3fc0000 or 0x3fc8000.
Jerry Walden
-----Original Message----- From: wd@denx.de [mailto:wd@denx.de] Sent: Wednesday, April 16, 2003 3:17 PM To: jwalden@digitalatlantic.com Cc: u-boot-users@lists.sourceforge.net Subject: Re: [U-Boot-Users] IVT on 405GP
Jerry,
in message EGEGIJHKDKJGAJMGIDPNMEPACKAA.jwalden@digitalatlantic.com you wrote:
Just reading some uboot install stuff and it appear to say what I am doing is ok but it does not seem to do everything. It say that it copies itself to upper memory then it should copy 8k of vector stuff to zero. So it looks like somehow I am missing the vector copy code, or it is not working.
Again it appears as though "trap init" initializes some vectors in the
IVT,
however it does not copy the code prologue and exception code. Can you see in the code where the contents of the first 8k of memory is copied?
I really don't understand what this discussion is all about.
Please look at the code yourself. It is not that complicated to understand. See "cpu/ppc4xx/start.S":
... 1366 /* 1367 * Copy exception vector code to low memory 1368 * 1369 * r3: dest_addr 1370 * r7: source address, r8: end address, r9: target address 1371 */ 1372 .globl trap_init 1373 trap_init: 1374 lwz r7, GOT(_start) 1375 lwz r8, GOT(_end_of_vectors) 1376 1377 rlwinm r9, r7, 0, 18, 31 /* _start & 0x3FFF */ 1378 1379 cmplw 0, r7, r8 1380 bgelr /* return if r7>=r8 - just in case */ 1381 1382 mflr r4 /* save link register */ 1383 1: 1384 lwz r0, 0(r7) 1385 stw r0, 0(r9) 1386 addi r7, r7, 4 1387 addi r9, r9, 4 1388 cmplw 0, r7, r8 1389 bne 1b ...
Guess what this 1: ... "bne 1b" loop is doing?
The code is really simple, and I don't know why you are missing it when reading the sources or when running under a debugger. And the function name "trap_init()" is IMHO well chosen and descriptive enough, too. And there is even a comment which explains what it does.
The only thing I can see that could go wrong here is that the computation of the end address (r9 = _start & 0x3FFF) might fail if you pass bogus values for _start to that code. Please note that the code assumes that it has been started from the reset entry point, i. e. _start is at a well known address, and "_start & 0x3FFF" is equivalent to 0x100 ;-) But then, this should be trivial to check, and I assume you already checked it under a debugger, didn't you?
Wolfgang Denk
-- Software Engineering: Embedded and Realtime Systems, Embedded Linux Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Email: wd@denx.de If it has syntax, it isn't user friendly.