[U-Boot-Users] why jump at absolute address in start.S
I'm reading cpu/mpc8xx/start.S and found the following:
/* * Calculate absolute address in FLASH and jump there */
lis r3, CFG_MONITOR_BASE@h ori r3, r3, CFG_MONITOR_BASE@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
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@h ori r3, r3, CFG_MONITOR_BASE@l addi r3, r3, in_flash - _start + EXC_OFF_SYS_RESET mtlr r3 blrWhy 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@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.
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@h ori r3, r3, CFG_MONITOR_BASE@l addi r3, r3, in_flash - _start + EXC_OFF_SYS_RESET mtlr r3 blrWhy 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
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@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.
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@h ori r3, r3, CFG_MONITOR_BASE@l addi r3, r3, in_flash - _start + EXC_OFF_SYS_RESET mtlr r3 blrWhy 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
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@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.
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@h ori r3, r3, CFG_MONITOR_BASE@l addi r3, r3, in_flash - _start + EXC_OFF_SYS_RESET mtlr r3 blrWhy 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
participants (3)
-
Laudney Ren -
Murray Jensen -
Wolfgang Denk