From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 9063F3BE645 for ; Wed, 26 Aug 2026 09:57:37 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787738259; cv=none; b=m7Y3m5a4Us/LKK0ASMtVcdOSDZQFshoRf4BniJn2o8PeWb2ea9FC5//lvUWkGsPsOlAnuCpYYMI/B0jWQHiM8bBPNeWCdIxJ0RnWTzCyTrQjPoPi+BoB3s5iTyOx7TNFMDO3O1FsAs2E7uASoUz7NcY71RrKVjUJlpQQhdwciA8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1787738259; c=relaxed/simple; bh=HCKLdImOdMKQJJMilraP0Wk/2XAp3iAJOfJcTrNeEdc=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=Q/KWnqpTZ1M5X61/sHEsMKcqPoJNaujqC6rWsBk2Lnh+Y6wrFViBsN3J79AM8aokXF14Y5vlHfctWmMlflPCKLWtorgYTI7xo0ZlM3qRPg4jHVuTRry8hpLHKy6MJwVUJ87HSDsobWvnJZYI3fSKgP6gmW54r5AmvbSHcMxrjoc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.com; spf=pass smtp.mailfrom=gmail.com; arc=none smtp.client-ip=209.85.128.46 Authentication-Results: smtp.subspace.kernel.org; dmarc=fail (p=none dis=none) header.from=linux.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-49a97714f5dso704005e9.0 for ; Wed, 26 Aug 2026 02:57:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1787738256; x=1788343056; h=content-transfer-encoding:content-type:in-reply-to:from :content-language:references:cc:to:subject:user-agent:mime-version :date:message-id:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to:content-type; bh=rqs/JjM/rhFjmn0l/Jy51z8ISXKwBj5TSNnqoIe2ZtQ=; b=YX9dhgA5mXsFgG8UOSvmV33qC7WlQ9VmPSA7Di2FPEwuBo7HuIvxuW/hpi5R6lkx3V qMA0pJNf54sfi5nKkS1AvFGfe0ut+sh4AkThWFVfkkO213eqdNhNRgE2lR48auRZbSjJ uM9ZqdrU3tBML9x+6v16oP6eUrlPsJnsWy0my0PU0vh5x8rVvOd6d6wgRZT6m6TmlH2J qQVhkZMXQHfMNST9+R4vdzQNR5X8LkL8B8s29NTpu0cpqo/iEuni/gi8hQW31RDc+VsZ BQqPv2EvkJE1dXWytGC27LaaIKiOy1UTI8RYE/Tnp498r991KQofaPXrJRGK8XT1WYRF ivbg== X-Forwarded-Encrypted: i=1; AHgh+Rq8aeQg7QLJ2Q9PXiAhPEfLIATa73C8Arz055w09g2eWB2Apap+5WyfFWcbiqWmYBK7oRrD3myzJ4OIQ5I=@vger.kernel.org X-Gm-Message-State: AFuF++mqtVgHUPmu8Khzynd3femrGVK2Hf2SokeD46aRrd7ejES5G3mY AtSqpHVt/kldCj8ZFRjmfjVTTbHbGmovRmWgFVTtqPXB7Lk6fV4raPzt X-Gm-Gg: AR+sD11elTjdGnn87zl/rCNjxJzy8RuzcENNuVA2/gRN0gixSzSRtbbHjzYhz1xcwHa PTxxlPAFtmRUq2hTkZW9DXG3tSNoBvcAbVrptwfs7JofTww/WhbhIKQHvUnmRiQamEnfg/6SDfb hzPXcbOAf3LQ+udMqKOWVEK8UHz3FC3BEq/rMU1Xf4QBN5DoLTkvq1YGe4sYRlDSimi3w8KE+Nw JO/4f/73tQkuawxQ6t+BcdRFml+EK1jMOTpm/7FMJyp6useG9ZnKSGO+vsaqi+Iq7K5N5NgYSMi N8l/6UqVSVIAuXv2VSjSR/vreIKboHtD23RQunUUjrwlWehkO9OYXKUgzTGJ9f422wQ4QY3NNzd XtapTnzRELzE9oRhLPsl5GinKF+3nIEZ8+lOosi408+j5vSkb0Gd4lDkNNu6l93SNP/xVFWimG2 4JUwYVqdMKENYalHCcRR2rq98l7c3Sx6AxjU1jOX6Jy5WO+3IfYmazHvKFvOfsRrfFdXkhQ21dA kbn6JZb6JfSFs7e4bUMJw== X-Received: by 2002:a05:600c:620b:b0:499:516b:83d5 with SMTP id 5b1f17b1804b1-499dc7240a3mr44654155e9.11.1787738255490; Wed, 26 Aug 2026 02:57:35 -0700 (PDT) Received: from [192.168.1.135] ([83.106.158.114]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-499dcae3216sm20357655e9.15.2026.08.26.02.57.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 26 Aug 2026 02:57:34 -0700 (PDT) Message-ID: <2800152c-25e0-401f-950c-15942c4f9a04@linux.com> Date: Wed, 26 Aug 2026 10:57:33 +0100 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC] clk: meson: t7: Intermittent boot instability and memory corruption on VIM4 To: Neil Armstrong , Jerome Brunet , Michael Turquette , Stephen Boyd , Kevin Hilman , Jian Hu Cc: Brian Masney , Martin Blumenstingl , linux-amlogic@lists.infradead.org, linux-clk@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <3930906f-783b-4d72-9260-ba25cc8081cb@linux.com> <048697c8-8331-42aa-accf-d114774ac5fd@linaro.org> Content-Language: en-US From: Lucas Tanure In-Reply-To: <048697c8-8331-42aa-accf-d114774ac5fd@linaro.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 26/08/2026 10:02, Neil Armstrong wrote: > On 8/23/26 17:40, Lucas Tanure wrote: >> 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 > > Those could be used by low power stuff aswell, not only RTC > >> [    0.381377] clk: Unprepared unused clock: a73_div16 >> [    0.381972] clk: Unprepared unused clock: cpu_div16 > > Those should probably be left enabled if they're used by the DVFS code > >> [    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. > > It's hard to say, this is dependent on each family, Amlogic should be > able to help here. Yes, Amlogic, please help.> > You list some clocks, but I don't understand you say that it's stable > only if you have clk_ignore_unused, so how did you get this clock list ? I got this list when I add logs to the clock framework and run without clk_ignore_unused. > > Neil > >> >> Thanks, >> Lucas Tanure >