What is Position Independent Code w.r.t romInit.s
Ganesh Okade
I have some questions.
a) Can you explain what is position independent code?
b) How is it different from ordinary code?
c) Why should romInit.s be written as position independent code?
d) I find two different symbols w.r.t romInit.s a) romInit b)
_romInit. Are these two different? By any chance does romInit refer to
the copy of romInit() in RAM and _romInit to copy in ROM?
e) In romInit.s we finally jump to the 'C' entry point given by
'C' entry point = romStart - romInit + ROM_TEXT_ADRS
I am confused about this math! My questions:
i) In my understanding the addresses referred by 'romInit' and
'ROM_TEXT_ADRS' are the same (since ROM_TEXT_ADRS is the ROM entry
point which is romInit!). So the expression reduces to
'C' entry point = romStart - romInit + romInit
= romStart
So why not simply branch to 'romStart' without doing all the
maths!
ii) The 'C' entry point to we want to jump is anyway
'romStart()' whose address is known to us by the symbol 'romStart'.
Why is it that we do not jump straight to 'romStart' rather then
recalculating the entry point (which eventually reduces to 'romStart'
itself!)
I know I am missing out on something. But I want to know what!
Thanks in advance.
David Bryan
Position independent code is code that can operate "anywhere" in memory, all
of the calls and jumps use relative addressing so that the code can execute
anywhere in memory.
To call romInit.s Position Independent Code is really incorrect ( though
that's what WIND calls it). romInit.s is actually written to execute at a
specific position: ROM_TEXT_ADRS - just as you pointed out.
Here is what is different about it... romInit, romStart, usrInit, and the
rest of the VxWorks binary image are compiled into a single binary image
placed in contiguous memory in RAM not ROM. The location of this image is
determined by the type of image you are building (bootRom, VxWorks,
VxWorks_romCompressed, etc) and several MACROs (usually RAM_HIGH_ADRS and/or
RAM_LOW_ADRS)
If you look at the symbol map for the VxWorks image you've built (use the
nmXYZ binary tool, where XYZ refers to your arch id 68k, ppc, etc) you will
notice that the symbol for romInit is actually placed in RAM at or near
either RAM_HIGH_ADRS or RAM_LOW_ADRS.
So the compiler/linker have placed romInit in RAM, but you want to execute
them in ROM. So the math works out like this:
romInit compiler assigned address = 0x100000 ( just using a random address
here)
romStart compiler assigned address = 0x1002a0
Actual execution location of romInit is at ROM_TEXT_ADRS = 0xfff00000
When the board boots up, there is nothing in RAM. Through some means the
CPU begins executing code at or before ROM_TEXT_ADRS. When the romInit
routine (compiled to be located in RAM, but actually place in ROM) needs to
call romStart, it must call romStart in ROM not at the compiler assigned
address in RAM.
so the address for romStart must be calculated:
rom location of RomStart(ROM) = RomStart(RAM) - romInit(RAM) + ROM_TEXT_ADR
= 0x1002a0 - 0x100000 + 0xfff00000
= Offset between romInit and romStart +
Address of romInit in ROM
= 0x2a0 + 0xfff00000
= 0xfff002a0
Hopefully this answers your questions.
This might also help you understand why the Makefiles and config.h must be
agree in their definition of
ROM_TEXT_ADRS
RAM_HIGH_ADRS
RAM_LOW_ADRS
ROM_SIZE
The compiler uses those assignments to place the code in specific places in
memory. The config.h file uses these defines to locate code and data in
memory during execution.
Dave
----------------------------------------------
T h e P T R G r o u p, I n c.
----------------------------------------------
->->->-> ->->->->-> ->->->->
-> -> ->
->->->-> -> ->->->->
-> -> -> ->
-> -> -> ->
----------------------------------------------
Embedded, Real-Time Solutions, and Training
www.ThePTRGroup.com
----------------------------------------------
_______________________________________________
VxWorks Users Group mailing list
VxWe...@lbl.gov
http://www-csg.lbl.gov/vxworks/
John
> Position independent code is code that can operate "anywhere" in memory, all
> of the calls and jumps use relative addressing so that the code can execute
> anywhere in memory.
>
> To call romInit.s Position Independent Code is really incorrect ( though
> that's what WIND calls it). romInit.s is actually written to execute at a
> specific position: ROM_TEXT_ADRS - just as you pointed out.
No, the code at the start of romInit.s is (usually) hand coded to
remain entirely position independentm hence it is perfectly legitimate
to call it position independent code. It could run at any address, and
during development & testing often will be run from another address
(in RAM).
HTH,
John...
=====
Contribute to the VxWorks Cookbook at: http://books.bluedonkey.org/
Ganesh Okade
I must greatly appreciate your having taken time off to explain
the whole stuff to me so elegantly. The whole thing is crystal clear
to me now.
Best Regards,
Ganesh Okade
Sunlux Technologies Ltd.
Bangalore, India
www.sunlux-india.com
David Bryan
I don't want to get into semantics, but I would consider position
independent code to be code that AFTER it is fully linked, can be loaded and
executed anywhere in memory. A good example of this is the interrupt entry
and exit code stubs that are pre-pended and appended to user interrupt
/exception handlers.
This is not the case with romInit.s. This file (and romStart.c) are written
to be relocatable via compilation. After the code is fully linked -
regardless of where it was placed by the compiler, it will execute in memory
relative to ROM_TEXT_ADRS, but only at that address. True, by modifying
ROM_TEXT_ADRS in config.h and the Makefile, I can relocate romInit to
execute at some other place in memory. But this does not meet my definition
of position independent code, it simply means the code is relocatable (via
compilation).
Again, this might just be an opinion (and everyone has one of those :) ) and
it certainly gets into semantics. But I wanted to clarify my explanation.
Thanks
Dave
Hello,
HTH,
John...
Martin Roth
There is something very important that should be mentioned.
For 8xx and 82xx (PPC architecture) Rominit.s includes two main entry
points:
1)Entry for cold reset
2)Entry for warm reset
On cold reset the booting (flash) memory is mapped starting from address 0x0
and the first operation is performed at address 0x100.
On warm reset (done by software) the same flash memory is mapped to address
ROM_TEXT_ADRS .
Rominit.s includes a common piece of code which runs at address 0x100 (on
cold reset) and at address ROM_TEXT_ADRS +0x100+8 (on warm restart).
So in this sense the code should be position independent, because it is
running in two different address spaces.
Martin Roth
Motorola Israel
"David Bryan" <Da...@ThePTRGroup.com> wrote in message
news:mailman.93.106614...@csg.lbl.gov...