hi Christian, On Mon Jan 30, 2012 at 09:10:46AM +0100, Christian Riesch wrote:
<snip> > >> Perhaps we should revert that change and instead remove > >> CONFIG_SKIP_LOWLEVEL_INIT from the da850 board config files. But since > >> we don't need the lowlevel_init function for DA850 SoCs we must either > >> add a dummy function or add some additional defines that allow > >> removing the CONFIG_SKIP_LOWLEVEL_INIT define without calling > >> lowlevel_init. Any suggestions how such defines should be called or > >> how the logic behind them should be so it doesn't cause breakage of > >> existing boards? > > > > or we should introduce a "CONFIG_SKIP_CPU_CRIT_INIT" define, which > > if defined, prevent the jump to cpu_init_crit ... so we have the same > > behaviour as before commit "ca4b55800ed74207c35271bf7335a092d4955416" > > > > Boards which have problems with cpu_crit_init, should define > > this new define ... but it would be better to find out, what > > is really going on here ... > > Yes, that would be good of course. > > Another idea: Actually the init code that we are discussing here is > executed twice. First in the SPL and then in the full-blown u-boot. > Sughosh, are you sure it is the execution of the code in SPL that causes > the trouble? I'm asking since we don't do any memory barrier related stuff > in the code that loads u-boot from flash in SPL. Of course, dcache is off > but icache is on. Yes, it is the spl that is executing the code. There is a spl specific string that gets displayed on the console, before spl goes on to load the u-boot image and jump to it, and i don't see that string on the console. -sughosh _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
