From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Babic Date: Mon, 22 Jan 2018 17:20:55 +0100 Subject: [U-Boot] [PATCH V5 31/31] imx: add i.MX8MQ EVK support In-Reply-To: References: <20180110052048.4425-1-peng.fan@nxp.com> <20180110052048.4425-32-peng.fan@nxp.com> <41e2e905-173d-afe6-f3e0-047f82bf5d08@denx.de> Message-ID: <549892c8-39ed-bb2c-f3a5-0faadc6aad02@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Fabio, On 22/01/2018 16:23, Fabio Estevam wrote: > Hi Stefano, > > On Mon, Jan 22, 2018 at 12:00 PM, Stefano Babic 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 =====================================================================