<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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot