On 2020-09-14 10:15, Matthias Brugger wrote:
On 10/09/2020 23:12, Stefan Agner wrote:
On 2020-09-07 16:36, Peter Robinson wrote:
Any thoughts on this issue?
Any reason why you're using 2020.01 and not at least 2020.07, or at least seeing if it's reproducible on 2020.10-rc3? The RPi4 support has changed quite a bit since then I suspect.
Hi Peter,
It's a stable release and we support a couple of devices with the same U-Boot version. I'd rather prefer to stay with 2020.01 for RPi4 as well.
We are on 2020.07 on development branch, and it does work fine there. So I thought it can't be that hard, just bisect and backport whatever fixes it... Unfortunately, it seems that there is no particular commit which fixes it (the bisect ended up in a random unrelated commit, and it seems that the issue appears/disappears depending on alignment/size...).
I also did applied pretty much every RPi4 related commit made after 2020.01 up until master back to 2020.01, no success either.
Which version of the Raspberry Pi firmware did you use? Unfortunately changes in the FW breaks stuff on U-Boot from time to time.
The 4GB I left untouched so far, it came with the following setup:
pi@raspberrypi:~$ sudo rpi-eeprom-update BCM2711 detected Dedicated VL805 EEPROM detected *** UPDATE AVAILABLE *** BOOTLOADER: update available CURRENT: Mon 15 Jul 12:59:55 UTC 2019 (1563195595) LATEST: Thu 16 Apr 17:11:26 UTC 2020 (1587057086) FW DIR: /lib/firmware/raspberrypi/bootloader/critical VL805: update available CURRENT: 00013701 LATEST: 000137ad
The 2GB I did some firmware updates already, currently I ran it with the following settings:
pi@raspberrypi:~$ sudo rpi-eeprom-update BCM2711 detected Dedicated VL805 EEPROM detected BOOTLOADER: up-to-date CURRENT: Thu 16 Apr 17:11:26 UTC 2020 (1587057086) LATEST: Thu 16 Apr 17:11:26 UTC 2020 (1587057086) FW DIR: /lib/firmware/raspberrypi/bootloader/critical VL805: up-to-date CURRENT: 000138a1 LATEST: 000137ad
I was able to reproduce the issue with U-Boot 2020.07, but I still have two non-upstream patches ontop (I really can't see how they can affect relocation, but they seem to cause a state which makes the issue appear). I try to find a configuration which shows it without non-upstream code.
-- Stefan
Regards, Mathias
I fear that the problem in fact is still in master, but only appears if certain things align a certain way... That is why I thought I bring it up, to see if anybody else has noticed something along this lines. We do have a rather trimmed down configuration, which might make the problem appear more (fit in a D cache...).
I probably will just disable cached around relocation for 2020.01 and see if it resurfaces on development branch.
-- Stefan
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