[U-Boot-Users] IVT on 405GP

[Jerry Walden]

>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 at denx.de [mailto:wd at denx.de]
Sent: Wednesday, April 16, 2003 3:17 PM
To: jwalden at digitalatlantic.com
Cc: u-boot-users at lists.sourceforge.net
Subject: Re: [U-Boot-Users] IVT on 405GP


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.