[U-Boot] Commit 294b91a5817147d4b7f47be2ac69bac2a1f26491 broke mpc85xx

[Simon Glass]

Hi York,


On 30 September 2014 22:06, York Sun <yorksun at freescale.com> wrote:
> Simon,
>
> I didn't notice until today the commit
> 294b91a5817147d4b7f47be2ac69bac2a1f26491 broke at least T4240QDS. I have
> narrowed down to these two lines in common/board_r.c
>
> initr_barrier,
>         initr_malloc,
>
> If I move these two lines below this part
>
>
> #if defined(CONFIG_SYS_INIT_RAM_LOCK) && defined(CONFIG_E500)
>         initr_unlock_ram_in_cache,
> #endif
>
>
> U-boot boots OK on T4240QDS (I can see the prompt). But if I move them
> anywhere above this initr_unlock_ram_in_cache, it hangs the core when
> initializing PCI. It may break other mpc85xx platforms but I didn't have
> time to check more today. I haven't figured out why you have to move these
> two lines up. Please take a close look.

I could adjust this so that the ordering changes only when driver model is used.

This would be a case of putting '#ifdef CONFIG_DM' around the first
section, then repeating it later with '#ifndef CONFIG_DM'. You can see
that I did this for stdio out of an abundance of caution.

However, in the interests of supporting driver model on these
platforms I wonder if it might be possible to move the cache logic
earlier. I suspect that the unlock/invalidate should happen before
post-relocation RAM is used.

Please take a look and let me know if that might be possible.
Otherwise we'll have to go with the fallback.

BTW I don't have any of these boards. If there is one that is readily
and cheaply available, or if you have an old one you can send me, I'd
be happy to test on this and take a closer look at driver model
support.

Regards,
Simon