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: sba...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot