Re: [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default

From: Paul Liu <paul.liu@linaro.org>
To: Frieder Schrempf <frieder.schrempf@kontron.de>
Cc: Fabio Estevam <festevam@gmail.com>, Marek Vasut <marex@denx.de>,
	Fabio Estevam <festevam@denx.de>, Stefano Babic <sbabic@denx.de>,
	Kirill Kapranov <kirill.kapranov@compulab.co.il>,
	 Uri Mashiach <uri.mashiach@compulab.co.il>,
	Valentin Raevsky <valentin@compulab.co.il>,
	 U-Boot-Denx <u-boot@lists.denx.de>, Harald Seiler <hws@denx.de>
Subject: Re: [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default
Date: Fri, 20 Aug 2021 04:51:22 +0800	[thread overview]
Message-ID: <CALG-KHzS8uXwZATP_2j1yhXsdr1wrwx-G=O583XyXbWeWvJ80Q@mail.gmail.com> (raw)
In-Reply-To: <88d0c3c4-5596-32e9-0434-cd0316227a3f@kontron.de>

Hi Frieder,

I'll confirm it. But I guess you are correct. I'll send a patch soon when I
implement this right.

Yours,
Paul

On Thu, 19 Aug 2021 at 15:14, Frieder Schrempf <frieder.schrempf@kontron.de>
wrote:

> On 19.08.21 02:27, Fabio Estevam wrote:
> > [Adding Marek]
> >
> > On Wed, Aug 18, 2021 at 6:39 PM Fabio Estevam <festevam@gmail.com>
> wrote:
> >>
> >> Hi Paul,
> >>
> >> On Wed, Aug 18, 2021 at 6:32 PM Paul Liu <paul.liu@linaro.org> wrote:
> >>>
> >>> Hi Fabio,
> >>>
> >>> I got several boards. With all different PN. But all of them are 2GB
> memory. And the recent master doesn't boot on one of my board. I haven't
> tried all of the combinations.
> >>
> >> With the U-Boot from Compulab, it reports 4GB. With mainline U-Boot it
> >> reports 2GB, so yes, there is an issue indeed.
> >>
> >> However, I don't see a hang.
> >>
> >>> After bisect, I found commit e27bddff breaks the boot. It just hang
> there.
> >>
> >> Adding Frieder as the author of the patch.
> >
> > Marek objected to this change, which is now:
> > e27bdd ff4b97 ("imx8m: Restrict usable memory to space below 4G
> boundary")
>
> Yes, Marek objected and it was still pulled in for some reason.
>
> >
> > As this causes a regression on Paul's i.MX8MM IoT Gateway board,
> > should this be reverted?
>
> Maybe, yes. I'll leave that decision to the maintainers.
>
> For the failure: The change in e27bddff4b97 assumes that gd->ram_size was
> set during initialization/detection of the DDR. Could it be that the
> Compulab board doesn't do this and gd->ram_size is 0 or differs from the
> actual DDR size? That would probably cause some kind of issue.
>
> Paul, maybe you could check if gd->ram_size is set properly. Other boards
> do this by implementing board_phys_sdram_size() [1], which also makes sure
> that the memory map is updated with the detected size in dram_init() [2].
>
> [1]
> https://elixir.bootlin.com/u-boot/latest/source/board/gateworks/venice/imx8mm_venice.c#L21
> [2]
> https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-imx/imx8m/soc.c#L218
>