[U-Boot-Users] relocate_code

[U-Boot-Users] relocate_code

[YanMin Qiao]

<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

[U-Boot-Users] relocate_code

[Murray Jensen]

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.

[U-Boot-Users] relocate_code

[YanMin Qiao]

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.
>
>
>  
>

[U-Boot-Users] relocate_code

[Wolfgang Denk]

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.

[U-Boot-Users] relocate_code

[Murray Jensen]

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.

[U-Boot-Users] relocate_code

[YanMin Qiao]

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.
>
>
>  
>

[U-Boot-Users] PPC405GP - uboot - can't get past stackloop

[Wolfgang Denk]

In message <EGEGIJHKDKJGAJMGIDPNCEBDCEAA.jwalden@digitalatlantic.com> you wrote:
> >Be careful! The initial memory is NOT in  RAM!!!  It  used  the  data
> >cache  or OCM - don't know the design of your board. If in doubt, use
> >the data cache.

Actually you must  be  using  the  data  cache  for  initial  data  -
otherwise you would not enter "stackloop" at all.

> So if I read correctly, the OCM for the 405GP is not a function of how the
> board is "wired", but how I set it up programmatically.  However it seems
> that you are indicating that it depends on the design of my board.  Can
> you please help provide clarification.

Sorry for not being clear - for me the design  of  a  board  inclused
hardware  and software issues - for example the memory map, which may
be dictated by hardware (address decoders  etc.),  but  often  is  at
least partially adjustable by software.

Did you verify that your stack space (in data cache) can be read  and
written?

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
An Elephant is a mouse with an Operating System.              - Knuth

[U-Boot-Users] relocate code

[Jerry Walden]

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

[U-Boot-Users] relocate code

[Wolfgang Denk]

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

[U-Boot-Users] Relocate code

[raju rediff]

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

[U-Boot-Users] Relocate code

[Holger L. Bille]

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