public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
* [U-Boot-Users] relocate_code
@ 2003-01-03 16:22 YanMin Qiao
  2003-01-04  2:22 ` Murray Jensen
  0 siblings, 1 reply; 10+ messages in thread
From: YanMin Qiao @ 2003-01-03 16:22 UTC (permalink / raw)
  To: u-boot

<u-boot>/cpu/mpc8xx/start.S

....
....
    .globl    relocate_code
relocate_code:
    mr    r1,  r3        /* Set new stack pointer        */
    mr    r9,  r4        /* Save copy of Global Data pointer    */
    mr    r10, r5        /* Save copy of Destination Address    */
....
    cmplw    cr1,r3,r4
    addi    r0,r5,3
    srwi.    r0,r0,2
    beq    cr1,4f        /* In place copy is not necessary    */
    beq    7f        /* Protect against 0 count        */
    mtctr    r0
    bge    cr1,2f
    ^^^^^^^^^^ why we need to differeciate the two situation, 
addr>CFG_MONITOR_BASE
                         and addr<=CFG_MONITOR_BASE

    la    r8,-4(r4)
    la    r7,-4(r3)
1:    lwzu    r0,4(r8)
    stwu    r0,4(r7)
    bdnz    1b
    b    4f

2:    slwi    r0,r0,2        <<----------------- i think above code will 
be enough for the two        
    add    r8,r4,r0                                      situation
    add    r7,r3,r0
3:    lwzu    r0,-4(r8)
    stwu    r0,-4(r7)
    bdnz    3b
....
....


thnx
best regards

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot-Users] relocate_code
  2003-01-03 16:22 [U-Boot-Users] relocate_code YanMin Qiao
@ 2003-01-04  2:22 ` Murray Jensen
  2003-01-04  2:45   ` YanMin Qiao
  0 siblings, 1 reply; 10+ messages in thread
From: Murray Jensen @ 2003-01-04  2:22 UTC (permalink / raw)
  To: u-boot

On Sat, 04 Jan 2003 00:22:21 +0800, YanMin Qiao <sepherosa@sohu.com> writes:
...
>    cmplw    cr1,r3,r4
...
>    bge    cr1,2f
...
>1:    lwzu    r0,4(r8)
>    stwu    r0,4(r7)
>    bdnz    1b
>    b    4f
>
>2:    slwi    r0,r0,2        <<----------------- i think above code will 
>be enough for the two        
>    add    r8,r4,r0                                      situation
>    add    r7,r3,r0
>3:    lwzu    r0,-4(r8)
>    stwu    r0,-4(r7)
>    bdnz    3b

One is copying forwards, the other is copying backwards - you can see the
lwzu/stwu pair of instructions either add +4 or -4 to the registers
containing the source and destination addresses (the "u" means to update the
index register with the resulting memory address).

Be careful with the first "bge" above - it isn't testing the result of the
previous instruction, it is testing the result of the "cmplw" done quite a
few instructions beforehand and stored in "cr1" i.e. it will branch if "r3"
(the destination address) is >= "r4" (the source address) i.e. if it is
possible that the copy will overwrite the source.

The Powerpc CPU has four(?) condition code sets where results of operations
can be stored. While I don't understand the details, I presume it has
something to do with the instruction pipeline and avoiding unnecessary
flushes - esp. when you consider that the programmer can indicate whether a
branch is likely or not with a bit in the instruction - I presume (again)
that this determines whether the processor does pre-fetching or something
like that. Details of all this stuff is in the Powerpc Programmer's
Environment Manual (I think).

If you look through the latest linux kernel source you often see things like

	if (unlikely(<condition>)) {

or

	if (likely(<condition>)) {

On powerpc (I'm guessing) these macros will set an attribute for the compiler
which will result in this bit being set or cleared in the branch instruction
of the resulting assembly code - I guess it does something similar for later
Pentium processors (and nothing at all if the processor doesn't have these
sort of features). 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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot-Users] relocate_code
  2003-01-04  2:22 ` Murray Jensen
@ 2003-01-04  2:45   ` YanMin Qiao
  2003-01-04  8:08     ` Wolfgang Denk
  2003-01-04 12:50     ` Murray Jensen
  0 siblings, 2 replies; 10+ messages in thread
From: YanMin Qiao @ 2003-01-04  2:45 UTC (permalink / raw)
  To: u-boot

Murray Jensen wrote:

>On Sat, 04 Jan 2003 00:22:21 +0800, YanMin Qiao <sepherosa@sohu.com> writes:
>...
>  
>
>>   cmplw    cr1,r3,r4
>>    
>>
>...
>  
>
>>   bge    cr1,2f
>>    
>>
>...
>  
>
>>1:    lwzu    r0,4(r8)
>>   stwu    r0,4(r7)
>>   bdnz    1b
>>   b    4f
>>
>>2:    slwi    r0,r0,2        <<----------------- i think above code will 
>>be enough for the two        
>>   add    r8,r4,r0                                      situation
>>   add    r7,r3,r0
>>3:    lwzu    r0,-4(r8)
>>   stwu    r0,-4(r7)
>>   bdnz    3b
>>    
>>
>
>One is copying forwards, the other is copying backwards - you can see the
>lwzu/stwu pair of instructions either add +4 or -4 to the registers
>containing the source and destination addresses (the "u" means to update the
>index register with the resulting memory address).
>
    First thanks for your answer, howerever, my question is
    Why we copy _forward_ when  _memory address_ <CFG_MONITOR_BASE, but 
when _memory address_>=CFG_MONITOR_BASE we will have to _copy backword_? 
 Is it because some overlapping problem when copy?

>
>Be careful with the first "bge" above - it isn't testing the result of the
>previous instruction, it is testing the result of the "cmplw" done quite a
>few instructions beforehand and stored in "cr1" i.e. it will branch if "r3"
>(the destination address) is >= "r4" (the source address) i.e. if it is
>possible that the copy will overwrite the source.
>
    thanks, I know

>
>The Powerpc CPU has four(?) condition code sets where results of operations
>can be stored. While I don't understand the details, I presume it has
>something to do with the instruction pipeline and avoiding unnecessary
>flushes - esp. when you consider that the programmer can indicate whether a
>branch is likely or not with a bit in the instruction - I presume (again)
>that this determines whether the processor does pre-fetching or something
>like that. Details of all this stuff is in the Powerpc Programmer's
>Environment Manual (I think).
>
>If you look through the latest linux kernel source you often see things like
>
>	if (unlikely(<condition>)) {
>
>or
>
>	if (likely(<condition>)) {
>
>On powerpc (I'm guessing) these macros will set an attribute for the compiler
>which will result in this bit being set or cleared in the branch instruction
>of the resulting assembly code - I guess it does something similar for later
>Pentium processors (and nothing at all if the processor doesn't have these
>sort of features). 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.
>
>
>  
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot-Users] relocate_code
  2003-01-04  2:45   ` YanMin Qiao
@ 2003-01-04  8:08     ` Wolfgang Denk
  2003-01-04 12:50     ` Murray Jensen
  1 sibling, 0 replies; 10+ messages in thread
From: Wolfgang Denk @ 2003-01-04  8:08 UTC (permalink / raw)
  To: u-boot

In message <3E164AC7.1050505@sohu.com> you wrote:
>
>     Why we copy _forward_ when  _memory address_ <CFG_MONITOR_BASE, but 
> when _memory address_>=CFG_MONITOR_BASE we will have to _copy backword_? 
>  Is it because some overlapping problem when copy?

Right (although not very likely here).

> >(the destination address) is >= "r4" (the source address) i.e. if it is
> >possible that the copy will overwrite the source.
> >
>     thanks, I know

Ummmm... Why do you ask when you already know?

Best regards,

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
The only perfect science is hind-sight.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot-Users] relocate_code
  2003-01-04  2:45   ` YanMin Qiao
  2003-01-04  8:08     ` Wolfgang Denk
@ 2003-01-04 12:50     ` Murray Jensen
  2003-01-04 13:28       ` YanMin Qiao
  1 sibling, 1 reply; 10+ messages in thread
From: Murray Jensen @ 2003-01-04 12:50 UTC (permalink / raw)
  To: u-boot

On Sat, 04 Jan 2003 10:45:27 +0800, YanMin Qiao <sepherosa@sohu.com> writes:
>    First thanks for your answer, howerever, my question is
>    Why we copy _forward_ when  _memory address_ <CFG_MONITOR_BASE, but 
>when _memory address_>=CFG_MONITOR_BASE we will have to _copy backword_? 
> Is it because some overlapping problem when copy?

Yes. It is generic memory copying code - if it is at all possible that the
copy might overwrite the destination then it goes backwards, instead of
forwards. It shouldn't make a lot of difference either way (I guess I can
imagine a scenario where it stuffs up some fancy pre-fetching in the CPU,
which might make it go half or a third of the speed, but its not likely).

>>Be careful with the first "bge" above - it isn't testing the result of the
>>previous instruction, it is testing the result of the "cmplw" done quite a
>>few instructions beforehand and stored in "cr1" i.e. it will branch if "r3"
>>(the destination address) is >= "r4" (the source address) i.e. if it is
>>possible that the copy will overwrite the source.
>>
>    thanks, I know

OK, I was just trying to be thorough. 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.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot-Users] relocate_code
  2003-01-04 12:50     ` Murray Jensen
@ 2003-01-04 13:28       ` YanMin Qiao
  0 siblings, 0 replies; 10+ messages in thread
From: YanMin Qiao @ 2003-01-04 13:28 UTC (permalink / raw)
  To: u-boot

Thank you for your detail answer :) , I see them now.

Best regards


Murray Jensen wrote:

>On Sat, 04 Jan 2003 10:45:27 +0800, YanMin Qiao <sepherosa@sohu.com> writes:
>  
>
>>   First thanks for your answer, howerever, my question is
>>   Why we copy _forward_ when  _memory address_ <CFG_MONITOR_BASE, but 
>>when _memory address_>=CFG_MONITOR_BASE we will have to _copy backword_? 
>>Is it because some overlapping problem when copy?
>>    
>>
>
>Yes. It is generic memory copying code - if it is at all possible that the
>copy might overwrite the destination then it goes backwards, instead of
>forwards. It shouldn't make a lot of difference either way (I guess I can
>imagine a scenario where it stuffs up some fancy pre-fetching in the CPU,
>which might make it go half or a third of the speed, but its not likely).
>
>  
>
>>>Be careful with the first "bge" above - it isn't testing the result of the
>>>previous instruction, it is testing the result of the "cmplw" done quite a
>>>few instructions beforehand and stored in "cr1" i.e. it will branch if "r3"
>>>(the destination address) is >= "r4" (the source address) i.e. if it is
>>>possible that the copy will overwrite the source.
>>>
>>>      
>>>
>>   thanks, I know
>>    
>>
>
>OK, I was just trying to be thorough. 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.
>
>
>  
>

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot-Users] relocate code
  2003-01-06 15:18 [U-Boot-Users] PPC405GP - uboot - can't get past stackloop Wolfgang Denk
@ 2003-01-20 20:12 ` Jerry Walden
  2003-01-20 21:23   ` Wolfgang Denk
  0 siblings, 1 reply; 10+ messages in thread
From: Jerry Walden @ 2003-01-20 20:12 UTC (permalink / raw)
  To: u-boot


Greetings:

It looks like I have made enough progress in programming the various
registers of the PPC405GPr to get
"relocate_code".  My problem is now this - I continue after the "return" in
relocate_code (which I
realize is not meant to return).  So now I type cont, and check to see if
there is any action on the
UART, and there is none - so I tell the BDI to halt, and the pc is at 0x70C.

How can I trace down a problem, after "relocate_code" is complete?

Thanks

Jerry

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot-Users] relocate code
  2003-01-20 20:12 ` [U-Boot-Users] relocate code Jerry Walden
@ 2003-01-20 21:23   ` Wolfgang Denk
  0 siblings, 0 replies; 10+ messages in thread
From: Wolfgang Denk @ 2003-01-20 21:23 UTC (permalink / raw)
  To: u-boot

In message <EGEGIJHKDKJGAJMGIDPNGEEHCFAA.jwalden@digitalatlantic.com> you wrote:
> 
> How can I trace down a problem, after "relocate_code" is complete?

Fix your RAM init sequence.

Best regards,

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
"Flight Reservation systems decide whether or not you exist. If  your
information  isn't in their database, then you simply don't get to go
anywhere."                                            - Arthur Miller

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot-Users] Relocate code
@ 2004-10-04  6:26 raju rediff
  0 siblings, 0 replies; 10+ messages in thread
From: raju rediff @ 2004-10-04  6:26 UTC (permalink / raw)
  To: u-boot

An HTML attachment was scrubbed...
URL: http://lists.denx.de/pipermail/u-boot/attachments/20041004/db9af5c9/attachment.htm 
-------------- next part --------------
Hi,
  
Can any of you tell what exactly "relocate_code" function does when
a. u-boot code is fused into the prom
b. u-boot code is loaded into RAM using emulator

It will be grateful if you can tell taking sbc board as reference. 

With Best Regards,
Raju

^ permalink raw reply	[flat|nested] 10+ messages in thread

* [U-Boot-Users] Relocate code
@ 2004-10-04  6:52 Holger L. Bille
  0 siblings, 0 replies; 10+ messages in thread
From: Holger L. Bille @ 2004-10-04  6:52 UTC (permalink / raw)
  To: u-boot

Hi Raju

Sending HTML to this list is inconsiderate. Please don't!

> <A target="_blank" HREF="http://clients.rediff.com/signature/track_sig.asp"><IMG SRC="http://ads.rediff.com/RealMedia/ads/adstream_nx.cgi/www.rediffmail.com/inbox.htm@Bottom" BORDER=0 VSPACE=0 HSPACE=0></a>

Sending tracking HTLM is downright rude! Don't do that! Not to this list - don't do it at all!

Holger Bille


-----Original Message-----
From:	u-boot-users-admin at lists.sourceforge.net on behalf of raju rediff
Sent:	Mon 2004-10-04 8:26
To:	u-boot-users at lists.sourceforge.net
Cc:	
Subject:	[U-Boot-Users] Relocate code
Hi,
  
Can any of you tell what exactly "relocate_code" function does when
a. u-boot code is fused into the prom
b. u-boot code is loaded into RAM using emulator

It will be grateful if you can tell taking sbc board as reference. 

With Best Regards,
Raju

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2004-10-04  6:52 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-01-03 16:22 [U-Boot-Users] relocate_code YanMin Qiao
2003-01-04  2:22 ` Murray Jensen
2003-01-04  2:45   ` YanMin Qiao
2003-01-04  8:08     ` Wolfgang Denk
2003-01-04 12:50     ` Murray Jensen
2003-01-04 13:28       ` YanMin Qiao
  -- strict thread matches above, loose matches on Subject: below --
2003-01-06 15:18 [U-Boot-Users] PPC405GP - uboot - can't get past stackloop Wolfgang Denk
2003-01-20 20:12 ` [U-Boot-Users] relocate code Jerry Walden
2003-01-20 21:23   ` Wolfgang Denk
2004-10-04  6:26 [U-Boot-Users] Relocate code raju rediff
2004-10-04  6:52 Holger L. Bille

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox