Hi Benoît, On Tue, 14 May 2013 19:17:46 +0200 (CEST), Benoît Thébaudeau <[email protected]> wrote:
> Hi Albert, > > On Tuesday, May 14, 2013 6:32:08 PM, Albert ARIBAUD wrote: > > Hi Benoît, > > > > On Tue, 14 May 2013 18:01:50 +0200 (CEST), Benoît Thébaudeau > > <[email protected]> wrote: > > > > > Hi Albert, > > > > > > .globl c_runtime_cpu_setup > > > > c_runtime_cpu_setup: > > > > > > > > - bx lr > > > > + /* > > > > + * Unlock (actually, disable) the cache now that board_init_f > > > > + * is done. We could do this earlier but we would need to add > > > > + * a new C runtime hook, whereas c_runtime_cpu_setup already > > > > + * exists. > > > > + * As this routine is just a call to cpu_init_crit, let us > > > > + * tail-optimize and do a simple branch here. > > > > + */ > > > > + b cpu_init_crit > > > > > > Shouldn't the "#ifdef CONFIG_CPU_PXA25X" from the original code be kept > > > here? > > > > Yes, it should indeed. Thanks for spotting this! > > Have you seen the end of my notes for relocate.S? After all, keeping for later > your patches moving to compiler-generated symbols seems to complicate things > and > to be more error-prone. (that's unrelated to the PXA25X stuff above, right?) I don't think deferring the compiler-generated symbols patches complicates things, as anyway, they would only apply after this patch (so as to apply only on a single instance of relocate_code) so there's no way they could simplify things occurring before them. OTOH, they do simplify the code of relocate_code. That's why I put them in a separate series dealing with optimizing relocate_code. I'll post this second series right away, and let people decide whether both series should be merged in a single one. > Best regards, > Benoît Amicalement, -- Albert. _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
