[U-Boot] [PATCH] mx6: invalidate D-cache only when booting from USB

[Stefano Babic <sbabic@denx.de>]

Hi Vincent,

On 26/05/2015 17:16, Vincent wrote:
> Stefano wrote:
>> Please help me to find the use case. I searched in all i.MX6 boards in
>> mainline, but none of them is setting CONFIG_SKIP_LOWLEVEL_INIT. Can you
>> tell me on which board there is this issue ?
> 
> Hi Stefano,
> 
> Thank you for taking the time to look at this proposed patch.
> 
> You are right, this is a "non standard" use case. What I am trying to do
> is to boot u-boot with u-boot on i.MX6Q Sabre SD :)

ok - so there is a chain of u-boot, and the last one loads and starts
the kernel.

> 
> Here are more details on what I would like to do:
> 
> 1. Boot "old" u-boot from SD card.
> 2. "old" u-boot loads "new" u-boot from network with 'dhcp' command.
> 3. "old" u-boot boots "new" u-boot with 'go' command.

ok, understood what you are doing.

> This is not so easy to achieve, it seems. I learned that in this
> peculiar use case it is necessary to set CONFIG_SKIP_LOWLEVEL_INIT when
> building the "new" u-boot, as hinted by the README.

This use case can happen and I had in the past, but I confess with other
SOCs. It can be requested if U-Boot in field is outdated and a new
U-Boot is required, but updating U-Boot is dangerous, and a chain of
multiple (two) U-Boot is chosen.

Anyway, to reach the goal, you have to check the initialization
routines. CONFIG_SKIP_LOWLEVEL_INIT should ensure that the DDR
controller is not initialized twice. On imx, I guess you will have a
u-boot.imx on the board, while the "new" u-boot is in "bin" format. In
fact, you do not nned the DCD table that is parsed and applied only by
the SOC's Boot ROM.

> 
> Also I found out that the call to invalidate_dcache_all() would prevent
> the boot for the aforementioned use case. "protecting" the call (as done
> in Freescale u-boot) "repairs" my use case, and I verified that it does
> not alter the boot through USB.

Before booting the kernel, U-Boot calls "cleanup_before_linux()" to let
the SOC in a well knon state. Cache are disable at this point, and this
let the kernel doing evething with the hardware.
However, when you load U-Boot as different image, this cleanup is not
called at all. Maybe it works in your case if cleanup is called even by
loading your second u-boot and not only by starting Linux.

> 
> (boot from USB detection code)
>> This looks like a hack. I understand this can work in your case, but can
>> we set as general case ? You check power for PHY0, but what about if a
>> board is using PHY1 ?
>> Anyway, is it not possible to get the boot storage from the SRC ?
> 
> You are right, the detection code is not perfect. This is the one I
> borrowed from Freescale u-boot, though, so it is reasonably tested "in
> the field".

This cannot be generalized - maybe it does not work on all boards, even
if in your case it does the job.

> 
> About the phy0/phy1 distinction, I think we can boot only from OTG PHY0
> so no worry.
> 
> About the SRC; I am not sure you can get the desired information from
> there, as booting from USB is a ROM "fallback".
> 
> (adding a condition to cache invalidation)
>> I cannot understand well this. The correct implementation seems correct
>> to me. And if you have issues booting with USB, why are you changing the
>> behavior in all other cases *except* booting from USB, where you rely on
>> the current implementation invalidating the cache ?
> 
> In my case, it is NOT booting with USB rather, it is booting from
> another u-boot. I discovered that invalidating the caches in this case
> breaks the boot.

It should not be. And the second U-Boot should not be started with
enabled cache, as it is done now.

> 
> The current implementation invalidates the cache in all cases for i.MX6,
> as it believes it is always booting from the ROM.
> 
> As the comments hint that invalidating the caches is necessary only when
> booting from USB (from ROM), I tried to restrict a bit more the
> invalidation to this "boot from USB" case. The detection is not perfect,
> but it is enough to repair my use case, at least.
> 

Best regards,
Stefano Babic



-- 
=====================================================================
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================