[U-Boot] [PATCH] relocation: Do not relocate NULL pointers.

[Joakim Tjernlund]

Peter Tyser <ptyser at xes-inc.com> wrote on 28/09/2009 16:29:15:
>
> > > > >
> > > > > > Anyhow, I have also been thinking/working on making U-boot
> > > > > > fully PIC and reached a important conclusion. The GOT holds absolute
> > > > > > ptr values and there is not much one can do about it sans modifying gcc.
> > > > > > So before u-boot is relocated to RAM one must manually add any offset to
> > > > > > all global/static data and string literals. The majority of strings
> > > > > > are passed directly to printf and friends so the offset can be added inside
> > > > > > printf. The remaining few data accesses needs to be dealt with
> directly, example:
> > > > > > -       for (init_fnc_ptr = init_sequence; *init_fnc_ptr; ++init_fnc_ptr) {
> > > > > > +       for (init_fnc_ptr = got_off(init_sequence); *init_fnc_ptr; +
> > > +init_fnc_ptr) {
> > > > > >
> > > > > > Only code called before relocation to RAM needs this, mostly the _f
> () functions.
> > > > > > Would this be an acceptable change?
> > > > >
> > > > > Could you describe the advantages of generating a fully PIC U-Boot
> > > > > image?  I understand you could execute the image from different places
> > > > > in flash, but on the boards I've worked with this isn't a huge concern.
> > > > > For example, its possible to have a preliminary flash mapping that
> > > > > U-Boot executes from, then after relocation to RAM that flash mapping
> > > > > can be modified.  So where U-Boot initially executes from isn't all that
> > > > > important for me.  Is there some killer feature that a fully PIC U-Boot
> > > > > provides to make adding the got_off() workarounds you mention
> > > > > worthwhile?
> > > >
> > > > For me, it is mainly to be to have two u-boot partitions and
> > > > be able to select one to boot from. This makes it safer to
> > > > update u-boot in the field.
> > >
> > > X-ES requires this same functionality of dual booting.  We generally
> > > have a jumper on each card that swaps 2 chip select 0 and 1 so that
> > > either can be booted from (assuming CS 0 is always used to load U-Boot).
> > > The same U-Boot image can be programmed to both flashes.  After U-Boot
> > > relocates to RAM, we remap the flashes (in
> > > board/xes/xpedite5370/xpedite5370.c: flash_cs_fixup()) to provide a
> > > common flash layout regardless of which flash we booted from.  Would it
> > > be possible to do something similar in your hardware setup so that the
> > > same U-Boot image could be loaded from either flash partition without
> > > the got_off() fixups you mention above?
> >
> > Nope, we don't have that extra HW support and won't have in the future
> > either. This type of extra HW logic should not be needed and even if you
> > do have it, how do you flip a jumper remotely? Can be done I am sure, but
> > all this extra HW logic should not be needed at all.
>
> How do you provide true redundancy without some means of changing a chip
> select, hardware strapping pin, etc?  Without hardware support you only
> have 1 code entry point, correct?  If that fails, the board is toast,
> regardless if you have redundant U-Boot images.  The "jumper" I was
> refering to could be a physical jumper, a non-volatile gpio device,
> FPGA, IPMI controller, etc.

I have a small flash block at the reset vector(which is never updated). This
block should choose which boot to branch to. This small boot block only looks
at the two boot images without any HW initialization. The exact method how
to choose boot isn't ready yet, but I figure one could embed a simple crc sum
in u-boot which will validate the boot images.

       Jocke