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

[Stefano Babic]

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.

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

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) to build.

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

> we are almost run out
> of ocram with SPL DM, thinking to use OF_PLATDATA now, then move
> to usb functions.

Understood.

Best regards,
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
=====================================================================