From: Lucas Tanure <tanure@linux.com>
To: Neil Armstrong <neil.armstrong@linaro.org>,
Jerome Brunet <jbrunet@baylibre.com>,
Michael Turquette <mturquette@baylibre.com>,
Stephen Boyd <sboyd@kernel.org>,
Kevin Hilman <khilman@baylibre.com>,
Jian Hu <jian.hu@amlogic.com>
Cc: Brian Masney <bmasney@redhat.com>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>,
linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: [RFC] clk: meson: t7: Intermittent boot instability and memory corruption on VIM4
Date: Sun, 23 Aug 2026 16:40:42 +0100 [thread overview]
Message-ID: <3930906f-783b-4d72-9260-ba25cc8081cb@linux.com> (raw)
Hi,
While testing mainline Linux on the Khadas VIM4 (Amlogic A311D2 / T7), I
am hitting intermittent system instability, storage loss, and memory
corruption during boot, unless I append clk_ignore_unused to the kernel
command line.
Because the failure is intermittent, I am running 100-reboot test
campaigns to bisect the remaining clocks and isolate which clocks are
critical and cannot be safely disabled.
As testing takes significant time over serial console, I wanted to check
if Amlogic or the maintainers could shed light on this:
Are there specific T7 clocks or hardware domains that must remain
critical/protected even without an explicit in-kernel consumer?
Current clocks being disabled that don't kill the board on a test run:
[ 0.380313] clk: Disabling unused clocks
[ 0.380413] clk: Disabled unused clock: rtc_dualdiv
[ 0.380718] clk: Disabled unused clock: rtc_duandiv_in
[ 0.381377] clk: Unprepared unused clock: a73_div16
[ 0.381972] clk: Unprepared unused clock: cpu_div16
[ 0.382605] clk: Unprepared unused clock: f50m
[ 0.383174] clk: Unprepared unused clock: fixed_pll_dco
[ 0.383786] clk: Unprepared unused clock: hdmi_pll_osc
[ 0.384416] clk: Unprepared unused clock: sys1_pll_osc
[ 0.385056] clk: Unprepared unused clock: earc_osc
[ 0.385652] clk: Unprepared unused clock: pcie_refclk_osc
[ 0.386323] clk: Unprepared unused clock: eth_pll_osc
[ 0.386961] clk: Unprepared unused clock: pcie_osc
[ 0.387548] clk: Unprepared unused clock: mclk_pll_osc
[ 0.388187] clk: Unprepared unused clock: usb_pll1_osc
[ 0.388826] clk: Unprepared unused clock: usb_pll0_osc
[ 0.389465] clk: Unprepared unused clock: tcon_pll_osc
[ 0.390105] clk: Unprepared unused clock: top_pll_osc
[ 0.390738] clk: Unprepared unused clock: aud_pll_osc
[ 0.391361] clk: Unprepared unused clock: ddr_pll_osc
I am not forcing any clock to be disabled; I am forcing all clocks to
stay on and letting them be disabled if unused one by one.
Any guidance or hints on required platform clocks would be greatly
appreciated.
Thanks,
Lucas Tanure
_______________________________________________
linux-amlogic mailing list
linux-amlogic@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-amlogic
next reply other threads:[~2026-08-23 15:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-23 15:40 Lucas Tanure [this message]
2026-08-24 15:29 ` Brian Masney
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3930906f-783b-4d72-9260-ba25cc8081cb@linux.com \
--to=tanure@linux.com \
--cc=bmasney@redhat.com \
--cc=jbrunet@baylibre.com \
--cc=jian.hu@amlogic.com \
--cc=khilman@baylibre.com \
--cc=linux-amlogic@lists.infradead.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-clk@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=mturquette@baylibre.com \
--cc=neil.armstrong@linaro.org \
--cc=sboyd@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®