[U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support

[Fabio Estevam <festevam@gmail.com>]

Hi Stefano,

On Mon, Jan 22, 2018 at 12:00 PM, Stefano Babic <sbabic@denx.de> wrote:

>> --- /dev/null
>> +++ b/board/freescale/mx8mq_evk/README
>> @@ -0,0 +1,47 @@
>> +U-Boot for the NXP i.MX8MQ EVK board
>> +
>> +Quick Start
>> +====================
>> +- Build the ARM Trusted firmware binary
>> +- Build U-Boot
>> +- Get ddr fimware and tools
>> +- Generate flash.bin using imx-mkimage
>> +- Boot
>> +
>> +Get and Build the ARM Trusted firmware
>> +====================
>> +Get ATF from: https://source.codeaurora.org/external/imx/imx-atf
>
> This is currently not enough - master is empty, which branch should be
> selected ?

Yes, the README from this patch does not allow us to create a bootable image.

Diego sent a patch today that puts more details so that we can really
boot the mx8mevk board.

> Is this maintainable ?
>
> I am asking why this is coming from here and not from an official
> source, like :
>
>         https://github.com/ARM-software/arm-trusted-firmware

Agreed.

> I am just asking which is the plan here. This is a fork of U-Boot's
> mkimage tool. I did not see attempts to push changes to imximage mainline.
>
> Any thoughts ? This means that it is not possible inside U-Boot to
> produce a U-Boot image, but we need an external tool that was *based* on
> U-Boot code....

Agreed. In long term imx-mkimage should go away and we should just use
the official mkimage tool.

> I have not understood the usage of firmware-imx-7.2.bin. You ask to load
> it, but it is not used in further commands.

Diego's patch clarifies this point as well.

> I guess we will not have any improvement here, at least for first
> version. I cannot say this is optimal, because it becomes difficult to
> add further MX8M targets.
>
> Just an example: dramtmgX contain timings, and they are computed from
> the RAM chip (tRAS, and so on).
>
> The best way (and I hope, this will go on sometimes..) should be to add
> a table for the chosen RAM chip and registers are then computed.
>
> It will be even ok if there is a tool(I guess, you or the DDR-team is
> using such as tool) to derive registers value from chip datasheet.
>
> Fabio, what do you think about this ?

Yes, the current method expects too much DDR code for each board and
does not seem to scale well.

> Im open to suggestions how to go on. The big isssues with the patchset
> is IMHO the cryptical part with the LPDDR settings. We could start to
> merge most of patches - they were already reviewed and they are freee of
> comments.
>
> Fabio, do you have a best approach ?

Yes, I agree. Please start merging the patches of the series that were
reviewed and are in good shape.

Then Peng can rework this current patch that adds the mx8mqevk board support.

Thanks