From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter Tyser Date: Mon, 28 Sep 2009 09:29:15 -0500 Subject: [U-Boot] [PATCH] relocation: Do not relocate NULL pointers. In-Reply-To: References: <1253706706-30364-1-git-send-email-Joakim.Tjernlund@transmode.se> <1253708271.3968.11.camel@ptyser-laptop> <1253710639.3968.19.camel@ptyser-laptop> <20090923182314.1B317832E864@gemini.denx.de> <1254112288.6589.15.camel@ptyser-laptop> <1254141946.10493.11.camel@ptyser-laptop> Message-ID: <1254148156.24140.2460.camel@localhost.localdomain> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de > > > > > > > > > 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