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....@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.schre...@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 <feste...@gmail.com>
>> wrote:
>> >>
>> >> Hi Paul,
>> >>
>> >> On Wed, Aug 18, 2021 at 6:32 PM Paul Liu <paul....@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
>>
>
