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

[Peter Tyser]

<snip>

> > > >
> > > > > 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.

Best,
Peter