Hi Graeme,
On Fri, Mar 2, 2012 at 3:05 AM, Graeme Russ graeme.russ@gmail.com wrote:
This is a very rough (i.e. it is not even close to finished and maybe won't even appply as it sits on top of some other dev patches I have) but it should give you an idea of what the INIT_FUNC implementation will look like.
Ultimately, tools/mkinitseq.c will process the dependencies and generate a C file containing the three init sequence arrays which have been deleted from arch/x86/lib/board.c
Makefile | 24 +++- arch/blackfin/cpu/initcode.c | 1 + arch/blackfin/cpu/serial.c | 1 + arch/mips/cpu/mips32/au1x00/au1x00_serial.c | 1 + arch/mips/cpu/mips32/incaip/asc_serial.c | 1 + arch/mips/cpu/xburst/jz_serial.c | 1 + arch/powerpc/cpu/mpc512x/serial.c | 1 + arch/powerpc/cpu/mpc5xx/serial.c | 1 + arch/sparc/cpu/leon2/serial.c | 1 + arch/sparc/cpu/leon3/serial.c | 1 + arch/x86/cpu/cpu.c | 4 +- arch/x86/cpu/interrupts.c | 1 + arch/x86/cpu/sc520/sc520.c | 1 + arch/x86/cpu/sc520/sc520_sdram.c | 2 + arch/x86/cpu/sc520/sc520_timer.c | 1 + arch/x86/cpu/u-boot.lds | 1 + arch/x86/lib/board.c | 134 +------------- arch/x86/lib/init_helpers.c | 14 ++ arch/x86/lib/init_wrappers.c | 11 + arch/x86/lib/relocate.c | 3 + board/amirix/ap1000/serial.c | 1 + board/bmw/serial.c | 1 + board/eNET/eNET.c | 3 + common/console.c | 2 + common/env_dataflash.c | 1 + common/env_eeprom.c | 1 + common/env_flash.c | 1 + common/env_mgdisk.c | 1 + common/env_mmc.c | 1 + common/env_nand.c | 1 + common/env_nowhere.c | 1 + common/env_nvram.c | 1 + common/env_onenand.c | 1 + common/env_sf.c | 1 + common/serial.c | 1 + common/stdio.c | 1 + config.mk | 2 + doc/README.INIT_FUNC | 31 +++ include/initcall.h | 19 ++ tools/Makefile | 6 + tools/mkinitseq.c | 278 +++++++++++++++++++++++++++ u-boot-init.lds | 25 +++ 42 files changed, 449 insertions(+), 136 deletions(-) create mode 100644 doc/README.INIT_FUNC create mode 100644 include/initcall.h create mode 100644 tools/mkinitseq.c create mode 100644 u-boot-init.lds
I read through this and it looks pretty nice. No point in commenting on the code at this stage I suspect.
But I wonder if this could fit on top of the generic board init series? Then we could move to initcalls for all boards rather than just x86, and in fact for U-Boot as a whole.
Plus a few questions. What tool do we need to display the result init sequence at build time? Can we make U-Boot print out the initcalls as it runs them (perhaps with pre-console buffer)?
Hoping you can pull this off!
Regards, Simon