i.MX8M Mini Hangs at ATF when booting from USB

Adam Ford aford173 at gmail.com
Thu Feb 3 18:27:20 CET 2022


On Thu, Feb 3, 2022 at 11:23 AM Marek Vasut <marex at denx.de> wrote:
>
> On 2/3/22 17:46, Tom Rini wrote:
> > On Wed, Feb 02, 2022 at 12:48:06PM -0600, Adam Ford wrote:
> >> On Wed, Feb 2, 2022 at 12:42 PM Tom Rini <trini at konsulko.com> wrote:
> >>>
> >>> On Wed, Feb 02, 2022 at 02:45:44PM -0300, Fabio Estevam wrote:
> >>>> Hi Marcel,
> >>>>
> >>>> [Adding Tom and Marek]
> >>>>
> >>>> On Wed, Feb 2, 2022 at 2:40 PM Marcel Ziswiler
> >>>> <marcel.ziswiler at toradex.com> wrote:
> >>>>
> >>>>>> The blocker to getting non-dm-spl-usb support for IMX8M appears to be
> >>>>>> the base addresses and instead of adding more of them to imx-regs.h we
> >>>>>> need to get them from DT via of_platdata which nobody has had time to
> >>>>>> dig into yet.
> >>>>>
> >>>>> I was also a little hesitant due to not using DM in SPL might no longer be accepted upstream. What is the
> >>>>> stance on this?
> >>>>
> >>>> My understanding is that there is no requirement to use DM in SPL.
> >>>
> >>> DM isn't required in SPL, no.  Are we running in to some size limit
> >>> here?  I see SPL_DM being set in a number of imx8m* platforms is why I
> >>> ask.
> >>
> >> If we try to run SPL_DM_USB we run into serious space issues.  Some of
> >> us are trying to boot over USB, but the only real way to do it appears
> >> to be to not use DM_USB in SPL, but that requires adding some more
> >> manual registers.
> >>
> >> Ideally, we would use of_platdata, but if that's enabled, it requires
> >> a bunch of drivers to be updated, and until that's done, all kinds of
> >> stuff break.  I think Fabio tried to push a non-DM-USB method, but
> >> there was some resistance.
> >
> > OK.  Yes, I would prefer that ideal situation but given the current
> > backlog of imx changes, I understand the hesitation to add still more to
> > the to be merged queue.
>
> Stefano should be back soon.
>
> That said, the hang in MX8M USB likely happens because USB block depends
> on GPC driver to bring up its power domains, which does so by means of
> SMC calls into ATF, which at SPL time is unavailable, hence the hang.

I did some experiments on that, but the USB enumerates, downloads the
image, parses the image, but hangs on the jump.  From what I could
tell, the boot ROM appeared to enable enough of the USB to facilitate
the USB transfer.  If I did the same experiment without SPL_DM_USB,
the load was successful.  I am guessing the memory is too tight with
SPL_DM_USB, because I am not seeing a significant difference in
behavior other than code and memory footprint with and without DM_USB.

>
> So someone would have to rewrite the MX8M GPC driver to NOT do SMC
> calls, but rather control the GPC registers directly, like it is done in
> Linux.

This has been in my radar, since I think I understand it fairly well,
but I haven't had the time to tackle it.

adam


More information about the U-Boot mailing list