[U-Boot] [PATCH v2 5/5] board: toradex: add colibri imx8qxp 2gb wb it v1.0b module support

Fri Apr 26 09:38:01 UTC 2019

On Fri, 2019-04-26 at 09:03 +0000, Peng Fan wrote:
> > Subject: Re: [PATCH v2 5/5] board: toradex: add colibri imx8qxp 2gb
> > wb it
> > v1.0b module support
> > 
> > Hi Peng and Stefano
> > 
> > On Fri, 2019-04-26 at 10:38 +0200, Stefano Babic wrote:
> > > Hi Peng,
> > > 
> > > On 26/04/19 04:10, Peng Fan wrote:
> > > > Hi Stefano,
> > > > 
> > > > > Subject: Re: [PATCH v2 5/5] board: toradex: add colibri
> > > > > imx8qxp
> > > > > 2gb wb it v1.0b module support
> > > > > 
> > > > > Hi Marcel,
> > > > > 
> > > > > On 25/04/19 14:35, Marcel Ziswiler wrote:
> > > > > > Hi Stefano
> > > > > > 
> > > > > > On Thu, 2019-04-25 at 12:48 +0200, Stefano Babic wrote:
> > > > > > > Hi Marcel,
> > > > > > > 
> > > > > > > On 09/04/19 17:25, Marcel Ziswiler wrote:
> > > > > > > > From: Marcel Ziswiler <marcel.ziswiler at toradex.com>
> > > > > > > > 
> > > > > > > > This commit adds initial support for the Toradex
> > > > > > > > Colibri
> > > > > > > > iMX8QXP 2GB WB IT V1.0B module. Unlike the V1.0A early
> > > > > > > > access samples exclusively booting from SD card, they
> > > > > > > > are
> > > > > > > > now strapped to boot from eFuses which are factory
> > > > > > > > fused to
> > > > > > > > properly boot from their on-module eMMC. U- Boot
> > > > > > > > supports
> > > > > > > > either booting from the on-module eMMC or
> > > > > may
> > > > > > > > be used for recovery purpose using the universal update
> > > > > > > > utility
> > > > > > > > (uuu) aka mfgtools 3.0.
> > > > > > > > 
> > > > > > > > Functionality wise the following is known to be
> > > > > > > > working:
> > > > > > > > - eMMC and MMC/SD card
> > > > > > > > - Ethernet
> > > > > > > > - GPIOs
> > > > > > > > - I2C
> > > > > > > > 
> > > > > > > > Unfortunately, there is no USB functionality for the
> > > > > > > > i.MX
> > > > > > > > 8QXP as of yet.
> > > > > > > > 
> > > > > > > > Signed-off-by: Marcel Ziswiler <
> > > > > > > > marcel.ziswiler at toradex.com
> > > > > > > > 
> > > > > > > > ---
> > > > > > > > 
> > > > > > > 
> > > > > > > I merged the series and build locally (fine), but Travis
> > > > > > > complains and stops with error:
> > > > > > > 
> > > > > > > +cc1: fatal error: opening output file spl/u-boot-
> > > > > > > spl.cfgout:
> > > > > > > No such
> > > > > > > file or directory
> > > > > > > +compilation terminated.
> > > > > > > 
> > > > > > > Can you take a look at it ?
> > > > > > 
> > > > > > Sure, looks like Peng's commit caceb739ea07 ("imx: build
> > > > > > flash.bin for
> > > > > > i.MX8") takes SPL for granted while my patchset currently
> > > > > > avoids
> > > > > > it.
> > > > > 
> > > > > It looks so, yes.
> > > > > 
> > > > > > BTW: I still don't believe SPL makes much sense on i.MX 8X
> > > > > > given
> > > > > > all the other proprietary parts involved in booting.
> > > > > 
> > > > > SPL makes more sense if it is possible to detect at runtime
> > > > > the HW
> > > > > and change the configuration - for i.MX6, this means RAMS
> > > > > detection, which boot device is booting, and so on.
> > > > > 
> > > > > On i.MX8 there is a lot of proprietary parts - we lose the
> > > > > flexibility of SPL, and most features are lost (or must be
> > > > > provided by proprietary code).
> > > > > I agree that
> > > > > on this platform SPL makes less sense, and i.MX8 should be
> > > > > built
> > > > > independently if CONFIG_SPL is set (this is also for
> > > > > i.MX6 / MX5, there are boards without SPL and using the DCD
> > > > > image
> > > > > to set up the RAM controller).
> > > > 
> > > > The reason we move to use SPL on i.MX8 is that we would like to
> > > > avoid bind ATF/OP-TEE/U-Boot into a flat image with hacked
> > > > offset in
> > > > an image.
> > > > 
> > > 
> > > It seemed I have missed some point. Thanks for clarification.
> > > This
> > > makes sense.
> > 
> > OK, I was also not aware of this.
> > 
> > However, currently I am just happy the current tooling kinda works.
> > Which is we can ship stuff to customers and they may use uuu to
> > recover
> > bricked modules. So far nobody is talking about OP-TEE and such
> > advanced
> > use cases yet.
> > 
> > On the other hand enabling SPL currently does not seem to work at
> > all on our
> > hardware. Neither booting from eMMC nor recovering using uuu.
> > That is really the main reason I decided against it at least for
> > now.
> 
> In vendor tree, we use SPL to load i.MX8 container image.
> To UUU, 1st need to enable usb gadget functions in SPL, then enable
> container
> for the 2nd image. So with uuu, it not work with upstream U-Boot now.

Strange, for me this works just fine with mainline just not with SPL
being enabled e.g. as per board/toradex/colibri-imx8qxp/README:

[user at host uuu]$ sudo ./uuu u-boot/u-boot-dtb.imx
uuu (Universal Update Utility) for nxp imx chips -- libuuu_1.2.66-0-
ga1a8e69

Success 1    Failure 0

1:33   2/ 2   [Done                        ] SDPS: done

U-Boot 2019.04-rc4-00169-g42dd45e2d9-dirty (Apr 26 2019 - 11:30:58
+0200)

CPU:   NXP i.MX8QXP RevB A35 at 1200 MHz

DRAM:  2 GiB
MMC:   FSL_SDHC: 0, FSL_SDHC: 1
Loading Environment from MMC... *** Warning - bad CRC, using default
environment

In:    serial at 5a090000
Out:   serial at 5a090000
Err:   serial at 5a090000
Model: Toradex Colibri iMX8 QuadXPlus 2GB Wi-Fi / BT IT V1.0B, Serial#
06410651
Net:   eth0: ethernet at 5b040000
Hit any key to stop autoboot:  0 
=> 

> > > > So the bootflow now is
> > > > SPL->ATF->OPTEE->ATF->U-Boot
> > > > 
> > > > Without SPL, when generating flash.bin, we have to hack ATF to
> > > > copy
> > > > OP-TEE image from flash.bin to the runtime location.
> > > 
> > > Nevertheless, I understand that it is not strictly required to
> > > enable
> > > OPTEE to boot the kernel, and in some applications a secure zone
> > > is
> > > not required. The thing is not that SPL is used here, but to
> > > constrain
> > > all other users like Marcel to do the same. With i.MX6, even if I
> > > strongly suggested to do this to allow run time detection, I let
> > > boards without SPL and with just u-boot.imx (with built-in DCD)
> > > to
> > > flow into mainline - the board maintainer rules as he knows
> > > better
> > > where the device is used.
> > 
> > Thanks!
> > 
> > > So I will prefer that the build assume to have SPL just if SPL is
> > > configured and not in any case, letting boards without SPL (like
> > > this
> > > colibri-mx8
> > 
> > Colibri iMX8X that is while on the Apalis family we have the Apalis
> > iMX8 (e.g. with the i.MX 8QuadMax or i.MX 8QuadPlus) and the new
> > Apalis
> > iMX8X with ECC RAM still in the works. Welcome to the i.MX 8 series
> > with the
> > i.MX 8 and i.MX 8X families and careful with NXP's brilliant naming
> > scheme
> > (;-p).
> > 
> > > ) to build.
> > 
> > Don't worry. I believe I found a fix for the issue at hand and will
> > send a patch
> > shortly.
> 
> ok.
> 
> Regards,
> Peng.
> 
> > > > > > Plus currently SPL
> > > > > > actually breaks the USB serial downloader aka recovery mode
> > > > > > using the universal update utility (uuu) aka mfgtools 3.0.
> > > > 
> > > > The usb related function for i.MX8 is not ready now.
> > > 
> > > That is ok - it s WIP, it will be merged when ready. I agree with
> > > you,
> > > this is *not* a reason to avoid SPL.
> > 
> > Agreed. However, it is kinda painful requiring different U-Boot
> > configuration
> > flavours for regular boot vs. recovery. That said we used to
> > previously do this
> > on Apalis/Colibri iMX6 as well so it is definitely no show stopper.
> > 
> > > > we are almost run out
> > > > of ocram with SPL DM, thinking to use OF_PLATDATA now, then
> > > > move to
> > > > usb functions.
> > > 
> > > Understood.
> > 
> > Yeah, I also played with OF_PLATDATA once before however was not
> > entirely
> > happy with the result as of yet. I guess WIP patches welcome (;-p).
> > 
> > > Best regards,
> > > Stefano
> > 
> > Cheers
> > 
> > Marcel