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

Martyn Welch martyn.welch at collabora.co.uk
Thu Nov 8 10:37:06 UTC 2018


On Thu, 2018-11-08 at 11:25 +0100, Stefano Babic wrote:
> 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
> 

Thanks Stefano, this was exactly the issue that I was hitting!

Martyn

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



More information about the U-Boot mailing list