ldppc -X -N -e _rominit -Ttext 0x0010000 ..help - VxWorks

This is a discussion on ldppc -X -N -e _rominit -Ttext 0x0010000 ..help - VxWorks ; vxworks+ppc when "make bootrom", see: .... ldppc -X -N -e _rominit -Ttext 0x00010000 ... i think _rominit is the first code when boot,and the address is 0x00010000,but with powerppc ,the boot address is 0xfff00000, it work corectly. why? there is ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: ldppc -X -N -e _rominit -Ttext 0x0010000 ..help

  1. ldppc -X -N -e _rominit -Ttext 0x0010000 ..help

    vxworks+ppc
    when "make bootrom", see:
    ....
    ldppc -X -N -e _rominit -Ttext 0x00010000 ...

    i think _rominit is the first code when boot,and the address is
    0x00010000,but with powerppc ,the boot address is 0xfff00000,
    it work corectly. why?

    there is another way to make rom:

    bin2hex bootrom -l 0xfff00000 -u 0xfff7ffff bootrom.hex
    makerom bootrom.hex -d 0x00010000 bootrom

    how makerom works? why the address is 0x00010000?


  2. Re: ldppc -X -N -e _rominit -Ttext 0x0010000 ..help

    On 31 Oct 2005, zhengbuaa@163.com wrote:
    > vxworks+ppc
    > when "make bootrom", see:
    > ...
    > ldppc -X -N -e _rominit -Ttext 0x00010000 ...
    >
    > i think _rominit is the first code when boot,and the address is
    > 0x00010000,but with powerppc ,the boot address is 0xfff00000,
    > it work corectly. why?
    >
    > there is another way to make rom:
    >
    > bin2hex bootrom -l 0xfff00000 -u 0xfff7ffff bootrom.hex
    > makerom bootrom.hex -d 0x00010000 bootrom
    >
    > how makerom works? why the address is 0x00010000?


    The assembler code at romInit is "position independent". This code
    does run at 0xfff00000. However, when the MMU is enabled, there is a
    double mapping [at least in some BSPs]. The romInit is living at both
    0xfff00000 and 0x10000. You can also use "address aliasing" and other
    tricks to cause it to live at multiple locations.

    There is part of the code in romInit where it does something like
    this,

    ...
    ; flush cache, etc.
    b label
    nop
    label:
    ; continue as usual...

    When the code is at "b label", it is running from 0xfffXXXXX. After
    it does the jump, it is now at 0x10000. The code at both locations is
    identical, so it is a very strange jump/branch.

    Sorry if the opcodes aren't right. I don't have PPC references on
    hand. I think the PPC uses "b label". It might be "jmp label", etc.
    But the principal is the same in all cases.

    I have no idea what "makerom" does. You haven't told us very much.
    Are you using Solaris or Windows NT?

    In some cases, the code is burnt to the address and there is a small
    loader that decompresses to another address. This small loader
    decompresses a full vxWorks image to anther location. In this setup,
    the code can actually run from three different addresses.

    WRS provides some documentation explaining this. Do you have a file
    called target.nr or something like that in the BSP directory. It will
    often describe the addressing setups.

    The BSP developers guide and maybe the vxWorks User manual have
    information on this.

    There is no need to thank me. Just help other people once you have
    learned things.

    hth,
    Bill Pringlemeir.

    --
    Do not meddle in the affairs of dragons, for you are crunchy and taste
    good with ketchup.

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

  3. Re: ldppc -X -N -e _rominit -Ttext 0x0010000 ..help

    I see. The assembler code at romInit is "position independent". but In
    my bootrom , the MMU is disable.

    romInit.o bootInit.o version.o is uncompressed, bootConfig.o version.o
    sysALib.o sysLib.o is compressed.

    _romInit is 0x00010000, _ursInit is 0xfffXXXXX, _rominit is the first
    code when boot,because it is "position independent", it is no problem .
    but in romInit.s, there is some "jump codes", such as "bl warm ...bl
    start.. "
    Can it work corectly? it run in rom!
    _usrInit can be coped to 0xfffXXXXX,so it can work corectly.

    ....
    ldppc-X -N -e _romInit -Ttext 00010000 \
    -o bootrom romInit.o bootInit.o version.o \
    D:\Tornado\target/lib/libPPCgnuvx.a bootrom.Z.o ...

    bootrom.Z.o is the result of "bootConfig.o version.o sysALib.o
    sysLib.o" link,and delfate. so after this step, _usrInit is still
    0xfffXXXXX? and _romInit is -0x00010000.

    i also use "bin2hex" to convert the bootrom to hex format. the format
    of ldppc linke is elf?
    bin2hex can set lowaddress 0xfffXXXXX and upaddress 0xfffXXXXX in rom .
    this can change _romInit and _usrInit?

    My host is windows ,"makerom" is also a tools to convert file format,i
    think.
    but i don't know i can change _romInit _usrInit?
    such as "makerom bootrom.hex -d 0x00010000 bootrom "?

    All above question, I think i dont know "How the linker work" clearly
    ..


  4. Re: ldppc -X -N -e _rominit -Ttext 0x0010000 ..help

    On 1 Nov 2005, zhengbuaa@163.com wrote:
    > I see. The assembler code at romInit is "position independent". but
    > In my bootrom , the MMU is disable.
    >
    > romInit.o bootInit.o version.o is uncompressed, bootConfig.o
    > version.o sysALib.o sysLib.o is compressed.
    >
    > _romInit is 0x00010000, _ursInit is 0xfffXXXXX, _rominit is the
    > first code when boot,because it is "position independent", it is no
    > problem . but in romInit.s, there is some "jump codes", such as "bl
    > warm ...bl start.. " Can it work corectly? it run in rom! _usrInit
    > can be coped to 0xfffXXXXX,so it can work corectly.


    I think on the PPC, the bl (and b and blr, etc) are position
    independant. The position jump that changes the address in romInit.s
    must be like this,

    li LO(_here), r0
    lis HIGH(_here), r0
    mov r0,pc
    nop
    _here:

    .... or something like that. You should get the PPC opcode definitions
    from FreeScale or IBM. I think FreeScale will give it for free.

    > ... ldppc-X -N -e _romInit -Ttext 00010000 \ -o bootrom romInit.o
    > bootInit.o version.o \ D:\Tornado\target/lib/libPPCgnuvx.a
    > bootrom.Z.o ...


    ....

    > All above question, I think i dont know "How the linker work"
    > clearly .


    The -Ttext specifies the load and execute address. The load address
    is only useful if you have an OS or loader. This is called VMA and
    LMA (or some such) in the linker documentation. The load address is
    very important for the "initdata" section. Ie, RAM variables that are
    initialized.

    Did you have an actual problem booting or are you just trying to
    understand things? If you image is not booting, I would suggest
    cutting down the size of the user code. If you have too much code,
    the memory mapping for the decompress may not work out.

    Where is RAM located? It is usually at zero. Typically, the romInit
    runs from ROM and switches the MMU on to set up the mapping that
    vxWorks/BSP is expecting. Code is copied from the ROM to higher RAM.
    The decompressor decompresses to 0x10000. If you have a compressed
    images, I am surprised that _romInit is at 0x10000. It should be 6MB
    or something (RAM_HIGH_ADRS).

    The usrInit should not be at 0xfffXXXXX, unless you are running a ROM
    image. Are you sure this is correct. How did you arrive at that
    conclusion?

    The ROM_*_ADRS and RAM_*_ADRS in config.h and from the Makefile *MUST*
    match. Ie, the code and the linker addresses must match.

    hth,
    Bill Pringlemeir.

    --
    All my best thoughts were stolen by the ancients. - Ralph Waldo
    Emerson

    vxWorks FAQ, "http://www.xs4all.nl/~borkhuis/vxworks/vxworks.html"

  5. Re: ldppc -X -N -e _rominit -Ttext 0x0010000 ..help

    Thank your very much

    I see.
    I have an old BSP of MPC which has been used corectly,I just try to
    understand somethings.
    I know RAM_LOW_ADRS RAM_HIGH_ADRS,and the basic process of boot.

    i think i have known the "position independant." in rominit.s and
    romStart clearly.


    ...._ursInit is 0xfffXXXXX.... is wrong and sorry

    I think i have not know linker and loader clearly.

    If my system has a loader ,for example an os has worked corectly,the
    address of _Ttext or .text .data .bss
    will be used by loader to load code and data in right address. All of
    these address infomation are put in the ead of the exectue file? and
    will be used in "position dependant" code? eg. the "abs address" is
    used in code
    and data will to be found in ".data".

    but bootrom and bsp is the boot code, no loader and os ,the hardware
    has no loader also.So the file format must be bin?

    some tools such as "elf2hex" can changed the addres of .text .data
    ..bss?

    thanks and regards


+ Reply to Thread