Hi Stefano, On Mon, Jan 22, 2018 at 12:00 PM, Stefano Babic <sba...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
