Hi Frieder,
I think I might have found a reason. The problem might be that the board_get_usable_ram_top() doesn't subtract the memory used by optee. Optee on imx8m uses the end of the memory. It is passed by arguments. VERBOSE: Argument #1 = 0x7e000000 VERBOSE: Argument #2 = 0x2000000
So if I extract 0x80000000 by 0x2000000 then the board boots. That also explains why Fabio can boot his board because he doesn't use OPTEE.
What I'm doing is I implemented a board_phys_sdram_size(). However because all of my boards are 2G memory. And I did set PHYS_SDRAM_SIZE to 2G when upstreaming Compulab's support previously. That means with or without board_phys_sdram_size() the board just doesn't boot on the master branch because the gd->ram_size is the same, 2GB. But you are correct, we do need to have board_phys_sdram_size() implemented because on Compulab's page we know that they have multiple choices. The memory could be 1G/2G/4G. So this function is needed to tell how much memory we have. But the hang problem is just not related to this function. The problem I think is we need to deal with rom_pointer that contains the OPTEE address in board_get_usable_ram_top().
Yours, Paul
On Fri, 20 Aug 2021 at 04:51, Paul Liu paul.liu@linaro.org wrote:
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....