[U-Boot-Users] why jump at absolute address in start.S

[U-Boot-Users] why jump at absolute address in start.S

[Laudney Ren]

I'm reading cpu/mpc8xx/start.S and found the following:

        /*
          * Calculate absolute address in FLASH and jump there
          */

         lis     r3, CFG_MONITOR_BASE at h
         ori     r3, r3, CFG_MONITOR_BASE at l
         addi    r3, r3, in_flash - _start + EXC_OFF_SYS_RESET
         mtlr    r3
         blr

Why do we need to calculate the absolutely address?
Why should we do it here, instead of everywhere?

Thanks.
Laudney

[U-Boot-Users] why jump at absolute address in start.S

[Murray Jensen]

On Fri, 03 Jan 2003 11:47:22 +0800, Laudney Ren <bren@sjtu.edu.cn> writes:
>I'm reading cpu/mpc8xx/start.S and found the following:
>
>        /*
>          * Calculate absolute address in FLASH and jump there
>          */
>
>         lis     r3, CFG_MONITOR_BASE at h
>         ori     r3, r3, CFG_MONITOR_BASE at l
>         addi    r3, r3, in_flash - _start + EXC_OFF_SYS_RESET
>         mtlr    r3
>         blr
>
>Why do we need to calculate the absolutely address?
>Why should we do it here, instead of everywhere?

U-Boot (aka ppcboot - since you are looking at cpu/mpc8xx) is compiled using
the "-mrelocatable" flag i.e. my understanding of this is that all text
references will be relative so that the code may be relocated at run time.

The bit of code above is special - at this point the CPU will be executing
at whatever address the reset configuration dictates (for 8xx I think the CPU
will read from the data bus at hard reset, which the board designer will have
wired up for you - I forget what the options are, but just assume the address
will be somewhere that you don't want it to be :-). In addition, the memory
controller will be set up so that the boot device (e.g. flash) appears
repeated throughout the entire physical address space (see the hard reset
state of OR0/BR0).

CFG_MONITOR_BASE is the physical address where you want the boot device to
reside. It will be used to program the memory controller registers which
select the boot device (OR0/BR0). As soon as the mask in OR0 is programmed
correctly, the boot device will disappear from the entire address space, and
be accessible only at the base address programmed in BR0.

This code jumps to the address that the boot device will appear at after you
program the memory controller registers, so that the boot device will not
disappear out from underneath you.

Because the code is relocatable you can jump to any address you like - as
long as the offset within the boot device is correct. "_start" is the address
where the CPU will "start" execution - i.e. the hard reset vector. "in_flash"
is where we want to continue execution after the jump (its the next instruction
after the "blr" above - therefore this really isn't a jump because you simply
execute the next instruction). EXC_OFF_SYS_RESET is added because we need the
address to be relative to the start of the boot device, not the hard reset
vector.

I think I got in over my head here - I started out trying to keep this answer
simple, but there is too much background you need to know to understand this
code. The 8xx (and 8260) are very configurable - there are other ways you
could do this, this is just the way ppcboot decided to do it. This code will
work regardless of the hardware reset configuration - so I quite like it.

I hope I've helped rather than hindered :-) In particular, I hope I've got
all the above correct - I'm sure someone will correct me if I'm wrong.
Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech.      Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen at csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/

To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.

The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.

[U-Boot-Users] why jump at absolute address in start.S

[Wolfgang Denk]

In message <2214.1041574514@msa.cmst.csiro.au>
Murray Jensen wrote:
>
> On Fri, 03 Jan 2003 11:47:22 +0800, Laudney Ren <bren@sjtu.edu.cn> writes:
> >I'm reading cpu/mpc8xx/start.S and found the following:
...
> >         lis     r3, CFG_MONITOR_BASE at h
> >         ori     r3, r3, CFG_MONITOR_BASE at l
> >         addi    r3, r3, in_flash - _start + EXC_OFF_SYS_RESET
> >         mtlr    r3
> >         blr
> >
> >Why do we need to calculate the absolutely address?
> >Why should we do it here, instead of everywhere?
> 
> U-Boot (aka ppcboot - since you are looking at cpu/mpc8xx) is compiled using
> the "-mrelocatable" flag i.e. my understanding of this is that all text
> references will be relative so that the code may be relocated at run time.

The "-mrelocatable" thingy has nothing to do with this  part  of  the
code.  Also,  "-mrelocatable"  does _not_ mean that you can just copy
the code to a new address and jump into it - it just means  that  the
compiler  will  generate  enough  information (especially the GOT) so
that you can relocate the code _manually_.

> The bit of code above is special - at this point the CPU will be executing
> at whatever address the reset configuration dictates (for 8xx I think the CPU
...
> This code jumps to the address that the boot device will appear at after you
> program the memory controller registers, so that the boot device will not
> disappear out from underneath you.

_This_ is the correct explanation.


Ummm...

> To the extent permitted by law, CSIRO does not represent, warrant and/or
> guarantee that the integrity of this communication has been maintained or
> that the communication is free of errors, virus, interception or interference.
> 
> The information contained in this e-mail may be confidential or privileged.
> Any unauthorised use or disclosure is prohibited. If you have received this
> e-mail in error, please delete it immediately and notify Murray Jensen on
> +61 3 9662 7763. Thank you.

Can you please shut off this crap when posting to public mailing lists?

Best regards, and a Happy New Year!

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
Never put off until tomorrow what you can put off indefinitely.

[U-Boot-Users] why jump at absolute address in start.S

[Murray Jensen]

On Fri, 03 Jan 2003 09:23:17 +0100, Wolfgang Denk <wd@denx.de> writes:
>> ... my understanding of this ...
...
>
>The "-mrelocatable" thingy has nothing to do with this  part  of  the
>code.  Also,  "-mrelocatable"  does _not_ mean that you can just copy
>the code to a new address and jump into it - it just means  that  the
>compiler  will  generate  enough  information (especially the GOT) so
>that you can relocate the code _manually_.

OK, my understanding was slightly flawed - thank you for pointing out
my error (and in such a friendly manner too). I thought the code needed
"-mrelocatable" for this "execute anywhere" trick, but of course since
it is assembly code there, you simply don't write non-relocatable code.

>> The bit of code above is special - at this point the CPU will be executing
>> at whatever address the reset configuration dictates (for 8xx I think the CP
>U
>...
>> This code jumps to the address that the boot device will appear at after you
>> program the memory controller registers, so that the boot device will not
>> disappear out from underneath you.
>
>_This_ is the correct explanation.

Nice to know I got something right. I wonder if it actually helped anyone
or if I just wasted my time.

>Ummm...
>
>> To the extent permitted by law, CSIRO does not represent, warrant and/or
>> guarantee that the integrity of this communication has been maintained or
>> that the communication is free of errors, virus, interception or interferenc
>e.
>> 
>> The information contained in this e-mail may be confidential or privileged.
>> Any unauthorised use or disclosure is prohibited. If you have received this
>> e-mail in error, please delete it immediately and notify Murray Jensen on
>> +61 3 9662 7763. Thank you.
>
>Can you please shut off this crap when posting to public mailing lists?

Believe me - I would like to. But I am using CSIRO computers and networks
to post and they have demanded that this disclaimer appear on all external
email - I have to respect their wishes. If I was using their stupid exchange
email system, it would simply append it for me without any choice. At least
with mh-mail I have the option - but I have to be responsible otherwise I
just give them ammunition to shut me down and force me to use their exchange
system (they don't realise that they can't actually stop me short of pulling
the network cable out, but I'm not going to tell them that).

I will of course not post to the list anymore, if you say so. Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech.      Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen at csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/

To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.

The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.

[U-Boot-Users] why jump at absolute address in start.S

[Laudney Ren]

Murray Jensen wrote:
 > On Fri, 03 Jan 2003 11:47:22 +0800, Laudney Ren <bren@sjtu.edu.cn> 
writes:
 >
 >>I'm reading cpu/mpc8xx/start.S and found the following:
 >>
 >>       /*
 >>         * Calculate absolute address in FLASH and jump there
 >>         */
 >>
 >>        lis     r3, CFG_MONITOR_BASE at h
 >>        ori     r3, r3, CFG_MONITOR_BASE at l
 >>        addi    r3, r3, in_flash - _start + EXC_OFF_SYS_RESET
 >>        mtlr    r3
 >>        blr
 >>
 >>Why do we need to calculate the absolutely address?
 >>Why should we do it here, instead of everywhere?
 >

 >
 > This code jumps to the address that the boot device will appear at 
after you
 > program the memory controller registers, so that the boot device will not
 > disappear out from underneath you.

Murray:

I was very very very moved when I found you wrote such a detailed
answer, providing so much background information, which would be
precious to this list.

Actually, I know all the necessary background information, nearly
everything about MPC8xx reset and so forth. Finally, one sentence in
your reply inspired me: "the boot device will not disappear out from
beneath you."

Right, absolutely. That's the VERY REASON!

When MPC8xx is reset, it starts to execute machine code at 0x100. At
this time, all the address space is filled with copies of flash ROM
images. For our board, which has 2M flash ROM, we'll get the same
results when we read range 0x0 to 0x1fffff or 0x200000 to 0x3fffff
and so on.

It's like a row of bricks which are the same. It makes no difference
that which one you are standing on. Until the moment, in section
_in_flash, we take away all the other bricks except one. If we haven't
stood on the finally chosen brick, we'll fall. That's exactly what
"disappear underneath" means.

So, thanks for your enthusiastic reply. We guys really appreciate your
help.

Happy New Year!

Laudney

[U-Boot-Users] why jump at absolute address in start.S

[Murray Jensen]

On Fri, 03 Jan 2003 21:19:36 +0800, Laudney Ren <bren@sjtu.edu.cn> writes:
>I was very very very moved when I found you wrote such a detailed
>answer, providing so much background information, which would be
>precious to this list.

OK, thanks very much - it appears I didn't waste my time after all.

Just one thing ...

>When MPC8xx is reset, it starts to execute machine code at 0x100.

In fact, it might execute at 0xfff00100 or 0x00000100 depending on the
way your board designer has configured the hard reset (I think this is
correct for 8xx - I'm mainly 8260 these days and I have to think back).

That's the nice thing about this trick - it doesn't matter if it's
executing high or low at hard reset - we will relocate to the final
address that the flash is located at and it's all configurable.

>It's like a row of bricks which are the same. It makes no difference
>that which one you are standing on. Until the moment, in section
>_in_flash, we take away all the other bricks except one. If we haven't
>stood on the finally chosen brick, we'll fall. That's exactly what
>"disappear underneath" means.

Nice analogy :-) Cheers!
								Murray...
--
Murray Jensen, CSIRO Manufacturing & Infra. Tech.      Phone: +61 3 9662 7763
Locked Bag No. 9, Preston, Vic, 3072, Australia.         Fax: +61 3 9662 7853
Internet: Murray.Jensen at csiro.au

Hymod project: http://www.msa.cmst.csiro.au/projects/Hymod/

To the extent permitted by law, CSIRO does not represent, warrant and/or
guarantee that the integrity of this communication has been maintained or
that the communication is free of errors, virus, interception or interference.

The information contained in this e-mail may be confidential or privileged.
Any unauthorised use or disclosure is prohibited. If you have received this
e-mail in error, please delete it immediately and notify Murray Jensen on
+61 3 9662 7763. Thank you.

[U-Boot-Users] why jump at absolute address in start.S

[Wolfgang Denk]

In message <3E1507CA.7000305@sjtu.edu.cn> you wrote:
> I'm reading cpu/mpc8xx/start.S and found the following:
> 
>         /*
>           * Calculate absolute address in FLASH and jump there
>           */
> 
>          lis     r3, CFG_MONITOR_BASE at h
>          ori     r3, r3, CFG_MONITOR_BASE at l
>          addi    r3, r3, in_flash - _start + EXC_OFF_SYS_RESET
>          mtlr    r3
>          blr
> 
> Why do we need to calculate the absolutely address?

We want to jump to the address  where  our  ciode  resides  in  flash
memory, so we must calculate the jump target.

> Why should we do it here, instead of everywhere?

Please read the chapter of  the  8xx  User's  Manual  about  how  the
processor starts from a reset.

Best regards, and a Happy New Year!

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
How much net work could a network work, if a network could net work?

[U-Boot-Users] why jump at absolute address in start.S

[Jerry Van Baren]

At 09:19 PM 1/3/2003 -0500, bren at sjtu.edu.cn wrote:
>Murray Jensen wrote:
>  > On Fri, 03 Jan 2003 11:47:22 +0800, Laudney Ren <bren@sjtu.edu.cn>
>writes:
>  >
>  >>I'm reading cpu/mpc8xx/start.S and found the following:
>  >>
>  >>       /*
>  >>         * Calculate absolute address in FLASH and jump there
>  >>         */
>  >>
>  >>        lis     r3, CFG_MONITOR_BASE at h
>  >>        ori     r3, r3, CFG_MONITOR_BASE at l
>  >>        addi    r3, r3, in_flash - _start + EXC_OFF_SYS_RESET
>  >>        mtlr    r3
>  >>        blr
>  >>
>  >>Why do we need to calculate the absolutely address?
>  >>Why should we do it here, instead of everywhere?
>  >

Another part of the puzzle for doing an absolute address jump is because 
the PowerPC relative jump is limited 24 bits (+/- 8Mbytes).  If you are 
jumping to a location beyond the 24 bit jump range, for instance if your 
vector is at 0x100 but your ultimate u-boot code will be based at 
0x80000000 (to pick an arbitrary example to illustrate the problem), a 
relative jump won't get you there.  Since u-boot doesn't know a priori 
where the addresses will be on a given piece of hardware, this is the safe 
and effective method of getting to the right place on every system.

Once you get to your final destination, relative addresses are fine since 
Wolfgang will never let u-boot code exceed 8Mbytes :-).

gvb



**********************************************************************
This e-mail and any files transmitted with it are confidential and may
be legally privileged or otherwise exempt from disclosure under
applicable law. This e-mail and its files are intended solely for
the individual or entity to whom they are addressed and their content
is the property of Smiths Aerospace.  If you are not the intended
recipient, please do not read, copy, use or disclose this communication.
If you have received this e-mail in error please notify the e-mail 
administrator at postmaster at si.com and then delete this e-mail, its
files and any copies.

This footnote also confirms that this e-mail message has been scanned
for the presence of known computer viruses.
***********************************************************************