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/imx8m... [2] https://elixir.bootlin.com/u-boot/latest/source/arch/arm/mach-imx/imx8m/soc....