From mboxrd@z Thu Jan  1 00:00:00 1970
From: Stefan Agner <stefan@agner.ch>
Date: Thu, 03 Sep 2020 13:23:02 +0200
Subject: RPi4 U-Boot freeze
In-Reply-To: <f96631871ef577ada93b3abd6c1a1140@agner.ch>
References: <f96631871ef577ada93b3abd6c1a1140@agner.ch>
Message-ID: <5ccb22ec4dd32d9ce283b14894ea39a6@agner.ch>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

Any thoughts on this issue?

Just to be sure, I did some memory testing on the 2GB module, but no
issues found.

I still somehow suspected that something else might be wrong with my
hardware, so I bought a new RPi4 (this time with 4GB of RAM) but the
very same with that:

U-Boot 2020.01 (Aug 23 2020 - 22:02:31 +0000)

DRAM:  3.9 GiB
<freeze>

I still think there is something wrong with caching. From what I
understand caches are enabled by the RPi (4) firmware. Is it safe to run
32-bit ARM U-Boot with enabled caches?

--
Stefan

On 2020-08-23 19:06, Stefan Agner wrote:
> Hi,
> 
> I noticed a quite common freeze when running 32-bit U-Boot 2020.01
> (rpi_4_32b_defconfig) on a 2GB RPi4 model:
> 
> U-Boot 2020.01 (Aug 07 2020 - 13:00:23 +0000)
> 
> DRAM:  1.9 GiB
> <freeze, no more output>
> 
> This happens fairly often, I would say 4 out of 5 boot tries. However,
> if it boots, everything seems to run fine.
> 
> The issue seems to go away when using 2020.04 or any newer release,
> however, when trying to find the actual patch fixing the issue using git
> bisect I ended up with a MMC merge request which really seems unrelated
> (36bdcf7f3b). It seems that the problem is quite evasive and disappears
> if certain structure are aligned differently etc.
> 
> Enabling initcall debugging showed that U-Boot crashes right after
> relocation:
> 
> ...
> initcall: 00016f2c
> 
> RAM Configuration:
> Bank #0: 0 948 MiB
> Bank #1: 40000000 1 GiB
> Bank #2: 0 0 Bytes
> Bank #3: 0 0 Bytes
> 
> DRAM:  1.9 GiB
> initcall: 00016bb8
> New Stack Pointer is: 3af6d9e0
> initcall: 00016da4
> initcall: 00016ef0
> initcall: 00016ef8
> initcall: 00016d38
> Relocation Offset is: 3b375000
> Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0
> initcall: 00016ec8 [clear_bss]
> initcall: 0004465c [display_options?? only appears sometimes]
> <freeze>
> 
> I realized when using CONFIG_SYS_(I|D)CACHE_OFF=y the problem seems to
> disappear. But to be 100% certain that it is cache related, I used my
> original configuration (which is known to "reliably" freeze), and
> replaced 00016ec8 with 00008688 manually in the binary, essentially
> swapping out function pointers in "init_sequence_f" [00008688 is
> cleanup_before_linux, which flushes and disables I-cache/D-cache]. And
> indeed, that hacked up binary does boot reliably every time:
> 
> ...
> initcall: 00016f2c
> 
> RAM Configuration:
> Bank #0: 0 948 MiB
> Bank #1: 40000000 1 GiB
> Bank #2: 0 0 Bytes
> Bank #3: 0 0 Bytes
> 
> DRAM:  1.9 GiB
> initcall: 00016bb8
> New Stack Pointer is: 3af6d9e0
> initcall: 00016da4
> initcall: 00016ef0
> initcall: 00016ef8
> initcall: 00016d38
> Relocation Offset is: 3b375000
> Relocating to 3b37d000, new gd at 3af78ec0, sp at 3af6d9e0
> initcall: 00008688
> initcall: 3b38c10c
> initcall: 3b38c114
> initcall: 000172e0 (relocated to 3b38c2e0)
> initcall: 0001712c (relocated to 3b38c12c)
> ...
> 
> From what I understand on RPi4 caches are enabled when entering U-Boot.
> I was wondering if the relocation code really can handle that?
> 
> --
> Stefan