[<prev] [next>] [day] [month] [year] [list]
Message-ID: <CAFBinCB5+5aWb6jHLW_LGvgMyCUeJ+eBYhTXWXOX3tkpb0mZiQ@mail.gmail.com>
Date: Fri, 2 Jul 2021 21:55:06 +0200
From: Martin Blumenstingl <martin.blumenstingl@...glemail.com>
To: linux-amlogic@...ts.infradead.org,
linux-arm-kernel@...ts.infradead.org
Cc: linux-kernel@...r.kernel.org, rcu@...r.kernel.org,
netdev@...r.kernel.org,
Christian Hewitt <christianshewitt@...il.com>
Subject: ARM: meson8m2: new board suffering from "rcu_preempt detected stall"
/ "CPU#n stuck" with stmmac enabled
Hello,
I am currently trying to make mainline Linux run on a device called
WeTek Core [0]
It uses an Amlogic S812 SoC with 4x Cortex-A9 cores and 2GB DDR3.
Enabling the dwmac-meson8b / stmmac Ethernet IP however is giving me
some trouble.
Four out of five times the board hangs during boot when the Ethernet
controller is enabled.
I have attached three boot logs:
- with-twd.txt - the boot process with the TWD timer enabled
- no-twd.txt - the boot process with the TWD timer disabled (since the
first log contained some TWD related bits I wanted to confirm that TWD
is not causing this issue)
- with-twd-successful.txt - uses the very same uImage, dtb and kernel
cmdline as "with-twd.txt" but this time the kernel does not hang
Disabling the Ethernet controller makes it boot every time (I tried it
five times in a row with 100% success rate).
That said, I am not insisting on the fact that the stmmac or
dwmac-meson8b drivers must be at fault. All of my other Meson8b and
Meson8m2 boards (none of them are using the TrustZone firmware) don't
have any Ethernet problems.
I am hoping that someone in the Linux community can share some advice
on how I can debug this issue.
Some background info:
Initially I thought adding support to mainline Linux would be easy.
After failing to read from the eFuse I found out that this board is
running a TrustZone firmware which prevents Linux from reading/writing
some registers.
So far this TrustZone firmware is affecting three areas (for which I
have patches ready):
- booting the secondary cores requires an SMCCC firmware call
- reading/writing the eFuse requires an SMCCC firmware call
- reading the SoC version requires an SMCCC firmware call
- some memory reservations need to be obtained from an SMCCC firmware
call (and then reserved in Linux as well)
Best regards,
Martin
[0] https://kodi.wiki/view/Archive:WeTek_Core
View attachment "with-twd.txt" of type "text/plain" (64434 bytes)
View attachment "with-twd-successful.txt" of type "text/plain" (43127 bytes)
View attachment "no-twd.txt" of type "text/plain" (44420 bytes)
Powered by blists - more mailing lists