Hi All, Just thought I'd throw in a left-field idea...
Could we make the loading of U-Boot into a generic multi-stage framework with each stage bootstrapping the next stage? OK, I know this is how IPL, SPL etc work already, but I'm thinking something more formal and arch independent. I can think of three disctinct phases which are relatively commong across most arch's (especially NAND Flash arches) 1) An intial page (say 256 bytes for example) which loads a second stage into the CPU's cache 2) A second phase running in the CPU cache which initialises SDRAM and loads the remainder into main memory (performs relocations etc) 3) A final phase which is U-Boot proper, running at the final target address in SDRAM Now what I'm thinking is that if we formalise these loader stages, we could actually add a little more flexibility by, say, allowing the final U-Boot binary to reside on a file-system. And even break the final binary up into smaller 'run-once-and-discard' chunks. For example, a lot of the low level init is only ever done once, but it stays in SDRAM as a permanent piece of the U-Boot image - What if the second stage loader could instead load an low-level init blob and run it before loading the final U-Boot blob? This then opens the door for all sort of options - What if U-Boot commands were build into stand-alone binary blobs and only loaded when needed. Same with device drivers So a lot of what is now build-time configuration could be reduced to run-time configuration Just a few wild ideas... Regards, Graeme _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
