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

[Stefano Babic]

Hi Fabio,

On 22/01/2018 16:23, Fabio Estevam wrote:
> Hi Stefano,
> 
> On Mon, Jan 22, 2018 at 12:00 PM, Stefano Babic <sbabic at 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.


ok, thanks, I will merge most of them.

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

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