From: Paul Liu <email@example.com>
To: Frieder Schrempf <firstname.lastname@example.org>
Cc: Fabio Estevam <email@example.com>, Marek Vasut <firstname.lastname@example.org>,
Fabio Estevam <email@example.com>, Stefano Babic <firstname.lastname@example.org>,
Kirill Kapranov <email@example.com>,
Uri Mashiach <firstname.lastname@example.org>,
Valentin Raevsky <email@example.com>,
U-Boot-Denx <firstname.lastname@example.org>, Harald Seiler <email@example.com>
Subject: Re: [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default
Date: Fri, 20 Aug 2021 10:06:25 +0800 [thread overview]
Message-ID: <CALG-KHwFBDFT-pCDMjQWB+3YqpA35eSQgB+vnVzYHmbDZtt5yA@mail.gmail.com> (raw)
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().
On Fri, 20 Aug 2021 at 04:51, Paul Liu <firstname.lastname@example.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.
> On Thu, 19 Aug 2021 at 15:14, Frieder Schrempf <
> email@example.com> wrote:
>> On 19.08.21 02:27, Fabio Estevam wrote:
>> > [Adding Marek]
>> > On Wed, Aug 18, 2021 at 6:39 PM Fabio Estevam <firstname.lastname@example.org>
>> >> Hi Paul,
>> >> On Wed, Aug 18, 2021 at 6:32 PM Paul Liu <email@example.com> 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
>> >> 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
>> 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() , which also makes sure
>> that the memory map is updated with the detected size in dram_init() .
prev parent reply other threads:[~2021-08-20 2:06 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-13 0:59 [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default Fabio Estevam
2021-08-13 0:59 ` [PATCH 2/2] imx8mm-cl-iot-gate: Add documentation Fabio Estevam
2021-08-13 10:07 ` Paul Liu
2021-08-13 9:59 ` [PATCH 1/2] imx8mm-cl-iot-gate: Do not build fip.bin by default Paul Liu
2021-08-13 12:15 ` Fabio Estevam
2021-08-15 19:26 ` Paul Liu
2021-08-16 21:09 ` Fabio Estevam
2021-08-16 21:29 ` Tom Rini
2021-08-16 22:41 ` Fabio Estevam
2021-08-17 0:50 ` Paul Liu
2021-08-17 18:32 ` Fabio Estevam
2021-08-18 0:08 ` Paul Liu
2021-08-18 12:24 ` Fabio Estevam
2021-08-18 21:32 ` Paul Liu
2021-08-18 21:39 ` Fabio Estevam
2021-08-19 0:27 ` Fabio Estevam
2021-08-19 7:14 ` Frieder Schrempf
2021-08-19 20:51 ` Paul Liu
2021-08-20 2:06 ` Paul Liu [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.