On Fri, 2016-02-26 at 08:25 +0100, Sascha Hauer wrote: > BTW I noticed the xload defconfig does not build anymore with this patch > applied because the image gets too big. I searched for the reason at got > a step closer. The SDRAM sequencer code is compiled into the image > multiple times, one time for each board. The intention was that the > linker throws away the unused copies via -ffunction-section and > --gc-sections. Unfortunately this does not work because the functions in > the different copies all end up with the same name. So for example we > have mem_precharge_and_activate() three times in the image. Only one > version is used, but the others can't be thrown away because they are in > the same section. There are two possible optimization here. As you say, if the two copies where in different sections, then all but one could be GCed by the linker, as only one will be in the call tree starting from the entry function for the board specific pbl being linked. But it's also the case that text of all the copies of mem_precharge_and_activate() is exactly the same. And so they could also be merged as identical, i.e. via ICF. I have an xloader that supports four socfpga board variants by exploiting the fact that most of the "board specific" sequencer, scan chain, pinmux, etc. data is in fact identical among all the board variants. I can't use GC for this, as all the board data is referenced in the single xload image which supports all the boards. _______________________________________________ barebox mailing list barebox@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/barebox
