Hi Mike
On Tue, Aug 23, 2011 at 11:00 AM, Mike Frysinger vapier@gentoo.org wrote:
On Monday, August 22, 2011 16:10:23 Wolfgang Denk wrote:
Hardware initialization in inherently very much hardware depen- dent ;-) We have some boards where PCI must be initialized early because it is needed to access some other peripherals like memory. And we have other boards where PCI can only be initialized late because it depends on a lot of other functions that must be working first.
I explained this a number of times before: the current code was designed to allow even for completely board specific init sequences, by simply adding #define for the list of init functions to the board config file - see for example here:
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/33951/focus=36436
http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/72131/focus=72136
If you look at the current code - heavily larded with #ifdefs of all shapes and colors - I cannot see any good way to transform this into an initcall (and thus sequence number based) implementation. Do you have any specific ideas how to address this?
if the funcs get merged by the linker script, the board still has full control over the init order by writing their own linker script
Hmm, I hadn't thought of that as a solution. It would work, but i think it is very fragile. The way I have done the INIT_FUNC macro, each function gets assigned to an (otherwise unused) variable which is given it's own section in the link with each section being named with a .<step number> at the end. Now doing SORT_BY_NAME makes sure all the sections are in the right order and that all sections (and therefore variables, and therefore init functions) are included.
To re-order the function in the linker script would mean individually specifying each and every section in the boards linker script. If another function get added at the arch level, there is a great chance that this new linker section would not get included in any board specific linker script
Regards,
Graeme