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 <[email protected]> > > > > > > > > > > > > > > > > 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 < > > > > > > > > [email protected] > > > > > > > > > > > > > > > > --- > > > > > > > > > > > > > > > > > > > > > > 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@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@5a090000 Out: serial@5a090000 Err: serial@5a090000 Model: Toradex Colibri iMX8 QuadXPlus 2GB Wi-Fi / BT IT V1.0B, Serial# 06410651 Net: eth0: ethernet@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 _______________________________________________ U-Boot mailing list [email protected] https://lists.denx.de/listinfo/u-boot
