[U-Boot-Users] PPC ROM relocation and GCC GOT

[U-Boot-Users] PPC ROM relocation and GCC GOT

[Bradley A. Bosch]

Greetings,

The firmware update strategy we are planning for a product I am
working on will work best if we can pre-build U-Boot images which can
be run from either of two locations in ROM.  A very small piece of
code at the reset vector would choose the correct version to run.

It seems that the method GCC (eldk 2.0) uses for global variable
reference does not lend itself to such relocation.  The effect of the
current GCC generated code is to reference the variables at the
original linked address.  This is in spite of the fact that the GOT
itself is properly located by relative addressing techniques.  The GOT
can't be updated at runtime because, of course, it is in ROM.

Aside from our particular application, such "install time" relocation
(including to ROM) would seem a useful capability to have in a boot
loader.  I've only been working with the PPC a few months, so please
enlighten me I am completely wrong, but I don't see any way to cause
GCC to generate code for full code relative or even simple global
register+offset access to global constants.

I guess I could set up the BAT registers earlier and relocate the ROM
image back to it's linked location.  Is there any reason that wouldn't
work, at least for the MPC8241?

If GCC were just a bit more flexible, this might be easier.  Has
anyone else solved (or even tried to solve) this problem?

BTW, the U-Boot documentation and code which imply that r30 is used by
GCC to point to the GOT seem misleading.  R30 is indeed used for
access thru the GOT within each function, but r30 appears to be set up
independently at the beginning of each function.  In particular, I
don't see the point in updating r30 in the following code from
/cpu/mpc824x/start.S since it doesn't return to a C function anyway.

        /*
         * Fix GOT pointer:
         *
         * New GOT-PTR = (old GOT-PTR - CFG_MONITOR_BASE) + Destination Address
         *
         * Offset:
         */
        sub     r15, r10, r4

        /* First our own GOT */
        add     r14, r14, r15
        /* the the one used by the C code */
        add     r30, r30, r15

Have I missed something obvious?  Thanks for any insight anyone can
provide.

--Brad Bosch

[U-Boot-Users] PPC ROM relocation and GCC GOT

[Thomas Lange]

I solved this problem the easy way by simply
making two images, compiled to run from different
locations.
Check our board, gth, to see how it was done.

To choose one of the two images, we use miniboot,
http://opensource.se/projects/miniboot/index.html

/Thomas

Bradley A. Bosch wrote:
> Greetings,
> 
> The firmware update strategy we are planning for a product I am
> working on will work best if we can pre-build U-Boot images which can
> be run from either of two locations in ROM.  A very small piece of
> code at the reset vector would choose the correct version to run.
> 
> It seems that the method GCC (eldk 2.0) uses for global variable
> reference does not lend itself to such relocation.  The effect of the
> current GCC generated code is to reference the variables at the
> original linked address.  This is in spite of the fact that the GOT
> itself is properly located by relative addressing techniques.  The GOT
> can't be updated at runtime because, of course, it is in ROM.
> 
> Aside from our particular application, such "install time" relocation
> (including to ROM) would seem a useful capability to have in a boot
> loader.  I've only been working with the PPC a few months, so please
> enlighten me I am completely wrong, but I don't see any way to cause
> GCC to generate code for full code relative or even simple global
> register+offset access to global constants.
> 
> I guess I could set up the BAT registers earlier and relocate the ROM
> image back to it's linked location.  Is there any reason that wouldn't
> work, at least for the MPC8241?
> 
> If GCC were just a bit more flexible, this might be easier.  Has
> anyone else solved (or even tried to solve) this problem?
> 
> BTW, the U-Boot documentation and code which imply that r30 is used by
> GCC to point to the GOT seem misleading.  R30 is indeed used for
> access thru the GOT within each function, but r30 appears to be set up
> independently at the beginning of each function.  In particular, I
> don't see the point in updating r30 in the following code from
> /cpu/mpc824x/start.S since it doesn't return to a C function anyway.
> 
>         /*
>          * Fix GOT pointer:
>          *
>          * New GOT-PTR = (old GOT-PTR - CFG_MONITOR_BASE) + Destination Address
>          *
>          * Offset:
>          */
>         sub     r15, r10, r4
> 
>         /* First our own GOT */
>         add     r14, r14, r15
>         /* the the one used by the C code */
>         add     r30, r30, r15
> 
> Have I missed something obvious?  Thanks for any insight anyone can
> provide.
> 
> --Brad Bosch
> 
> 
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users
>