[U-Boot] Booting i.MX6UL via SPL?

[Stefano Babic]

Hi Martyn,

On 07/11/18 21:46, Martyn Welch wrote:
> Hi All,
> 
> I've been trying to boot a i.MX6UL based device I have here using SPL.
> It doesn't seem to want to work for me.
> 
> I see there's a number of i.MX6UL ports in U-Boot already, some use a
> custom DCD to configure the board, others seem to provide both options
> (DCD and SPL). Interestingly the Freescale i.MX 6UltraLite Evaluation
> Kit port (via mx6ul_14x14_evk_defconfig) appears to be using the SPL
> mechanism exclusively.
> 
> Can someone confirm that the above device boots using this config from
> SD card?
> 
> I seem to be able to boot from SD card using a custom DCD (which copies
> U-Boot into RAM), I'm also able to get the SPL to boot via USB (which
> copies the SPL to OCRAM). However when I try to boot the SPL from SD
> card it doesn't boot. If I boot the SPL via USB, insert an SD card and
> reset the device, it seems to boot from the SPL previously loaded from
> USB (as in it's still in the OCRAM) but carries on like it's booted
> from the SD card (looking on the SD card rather than USB for the main
> U-Boot image). The reason I think it's doing this is that if I rebuild
> U-Boot and flash a copy with an updated build time to the SD card, when
> I perform a reset I still see the old build time in the U-Boot banner.
> It looks to me like for some reason it's unable to copy the SPL to
> OCRAM, but carries on thinking it has.
> 
> Anyone got any pointers?
> 

I confirm that SPL works for a MX6UL, but I had this issue, too. It
could depend on the Hardware Revision of your processor.

There is a bug in revision 1.2 of the processor that makes the first
part of the OCRAM not available and SPL cannot be copied. This bug
affects just some production charges, and NXP solved this later without
changing the revision of the processor. That means there are some boards
where everything is fine, some other boards with just a newer processor
that do not boot. I do not know if this is your use case, but it makes
sense to give a try.

I had just moved CONFIG_SPL_TEXT_BASE to a later offset:

define CONFIG_SPL_TEXT_BASE            0x00909000

However, there is no chance to know at runtime if a board is affected by
this issue because the revision does not change, and I do not think it
is a good idea to force all MX6UL to restrict their OCRAM due to a buggy
and time constrained production by the manufacturer.

I hope this helps,
Stefano

-- 
=====================================================================
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
=====================================================================