[U-Boot-Users] IVT on 405GP

[Wolfgang Denk]

Jerry,

in message <EGEGIJHKDKJGAJMGIDPNMEPACKAA.jwalden at 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 at denx.de
If it has syntax, it isn't user friendly.