From: Jon Hunter <jonathanh@nvidia.com>
To: Aaron Kling <webgeek1234@gmail.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>,
Rob Herring <robh@kernel.org>, Conor Dooley <conor+dt@kernel.org>,
Thierry Reding <thierry.reding@gmail.com>,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
linux-tegra@vger.kernel.org
Subject: Re: [PATCH v4 3/5] memory: tegra186-emc: Support non-bpmp icc scaling
Date: Thu, 18 Dec 2025 11:12:11 +0000 [thread overview]
Message-ID: <4900cf8f-9ec8-48d6-8187-126e111cd048@nvidia.com> (raw)
In-Reply-To: <CALHNRZ_zhZ3a7h8nSWkpGv6+unKn6DkSA9tKQ6cmb5TXjGcC9w@mail.gmail.com>
On 17/12/2025 22:44, Aaron Kling wrote:
...
>> Thanks I added all these on top of next-20251216 (as that is the latest
>> I have tested) and Tegra194 fails to boot. We always include all the
>> modules in the rootfs that is being tested. You can see the boot log
>> here [0]. We are using an NFS rootfs for testing and I see a message
>> related to the NFS server not responding. I am guessing something is
>> running too slow again because the only thing I changed was adding your
>> patches. The test harness reports it is timing out ...
>>
>> FAILED: Linux Boot Test 1
>> Test Owner(s): N/A
>> Execution Time 219.31 sec
>> Test TIMEOUT reached. Test did not report results in 120 secs
>> Percent passed so far: 0.0
>
> Okay, so. Modules are in the rootfs, none get copied to the initramfs?
> And the rootfs is on nfs? And for this failure, nfs never gets
> mounted. So... for this case, no modules get loaded, implying that
> whatever is happening is happening with the built-in drivers. Which
> means this case isn't pcie related. Are there any modifications to the
> defconfig? It appears that there must be, to have dwc-eth-dwmac
> available. I will see if I can trigger anything when using ethernet.
If you look at the boot log you will see ...
[ 7.839012] Root device found: nfs
[ 7.908307] Ethernet interface: eth0
[ 7.929765] IP Address: 192.168.99.2
[ 8.173978] Rootfs mounted over nfs
[ 8.306291] Switching from initrd to actual rootfs
So it does mount the rootfs and so the modules would be loaded. I
believe that PCIe is definitely loaded because that is what I observed
before. And yes there are a few modifications to the defconfig that we
make on top (that have been added over the years for various reasons) ...
CONFIG_ARM64_PMEM=y
CONFIG_BROADCOM_PHY=y
CONFIG_DWMAC_DWC_QOS_ETH=y
CONFIG_EEPROM_AT24=m
CONFIG_EXTRA_FIRMWARE="nvidia/tegra210/xusb.bin nvidia/tegra186/xusb.bin
nvidia/tegra194/xusb.bin rtl_nic/rtl8153a-3.fw rtl_nic/rtl8168h-2.fw"
CONFIG_EXTRA_FIRMWARE_DIR="${KERNEL_FW_DIR}"
CONFIG_MARVELL_PHY=y
CONFIG_R8169=y
CONFIG_RANDOMIZE_BASE=n
CONFIG_SERIAL_TEGRA_TCU=y
CONFIG_SERIAL_TEGRA_TCU_CONSOLE=y
CONFIG_STAGING=y
CONFIG_STAGING_MEDIA=y
CONFIG_STMMAC_ETH=y
CONFIG_STMMAC_PLATFORM=y
CONFIG_USB_RTL8152=y
CONFIG_VIDEO_TEGRA=m
CONFIG_VIDEO_TEGRA_TPG=y
CONFIG_DWMAC_TEGRA=y
Looking at the boot log I see ...
[ 3.854658] cpu cpu0: cpufreq_init: failed to get clk: -2
[ 3.854927] cpu cpu0: cpufreq_init: failed to get clk: -2
[ 3.855218] cpu cpu2: cpufreq_init: failed to get clk: -2
[ 3.858438] cpu cpu2: cpufreq_init: failed to get clk: -2
[ 3.863987] cpu cpu4: cpufreq_init: failed to get clk: -2
[ 3.869741] cpu cpu4: cpufreq_init: failed to get clk: -2
[ 3.875006] cpu cpu6: cpufreq_init: failed to get clk: -2
[ 3.880725] cpu cpu6: cpufreq_init: failed to get clk: -2
[ 3.886018] cpufreq-dt cpufreq-dt: failed register driver: -19
So actually, I am now wondering if this is the problem?
Jon
--
nvpublic
next prev parent reply other threads:[~2025-12-18 11:12 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-27 18:55 [PATCH v4 0/5] memory: tegra: Support EMC dfs on Tegra186/Tegra194 Aaron Kling via B4 Relay
2025-10-27 18:55 ` [PATCH v4 1/5] dt-bindings: memory: tegra186-mc: Add dummy client IDs for Tegra186 Aaron Kling via B4 Relay
2025-10-27 18:55 ` [PATCH v4 2/5] dt-bindings: memory: tegra194-mc: Add dummy client IDs for Tegra194 Aaron Kling via B4 Relay
2025-10-27 18:55 ` [PATCH v4 3/5] memory: tegra186-emc: Support non-bpmp icc scaling Aaron Kling via B4 Relay
2025-11-10 21:25 ` Jon Hunter
2025-11-10 21:55 ` Aaron Kling
2025-11-11 1:39 ` Aaron Kling
2025-11-11 11:13 ` Jon Hunter
2025-11-11 11:16 ` Krzysztof Kozlowski
2025-11-11 12:05 ` Jon Hunter
2025-11-11 14:35 ` Jon Hunter
2025-11-11 17:04 ` Aaron Kling
2025-11-11 21:29 ` Jon Hunter
2025-11-11 23:17 ` Aaron Kling
2025-11-12 6:18 ` Jon Hunter
2025-11-12 7:21 ` Aaron Kling
2025-11-12 7:31 ` Krzysztof Kozlowski
2025-11-21 11:21 ` Jon Hunter
2025-11-21 18:17 ` Aaron Kling
2025-12-10 4:08 ` Jon Hunter
2025-12-10 5:06 ` Aaron Kling
2025-12-10 15:03 ` Jon Hunter
2025-12-10 18:32 ` Aaron Kling
2025-12-10 21:24 ` Jon Hunter
2025-12-10 22:41 ` Aaron Kling
2025-12-11 7:46 ` Jon Hunter
2025-12-11 17:39 ` Aaron Kling
2025-12-17 18:39 ` Aaron Kling
2025-12-17 18:59 ` Jon Hunter
2025-12-17 20:29 ` Aaron Kling
2025-12-17 21:53 ` Jon Hunter
2025-12-17 22:44 ` Aaron Kling
2025-12-18 11:12 ` Jon Hunter [this message]
2025-12-18 19:25 ` Aaron Kling
2025-12-18 21:20 ` Aaron Kling
2025-12-19 11:05 ` Jon Hunter
2025-11-22 12:01 ` Krzysztof Kozlowski
2025-12-09 4:26 ` Aaron Kling
2025-12-09 5:53 ` Krzysztof Kozlowski
2025-12-10 4:08 ` Jon Hunter
2025-11-12 7:26 ` Krzysztof Kozlowski
2025-11-12 10:59 ` Jon Hunter
2025-11-12 11:42 ` Krzysztof Kozlowski
2025-11-12 12:29 ` Jon Hunter
2025-11-12 7:26 ` Krzysztof Kozlowski
2025-10-27 18:55 ` [PATCH v4 4/5] memory: tegra186: Support " Aaron Kling via B4 Relay
2025-10-27 18:55 ` [PATCH v4 5/5] memory: tegra194: " Aaron Kling via B4 Relay
2025-10-31 13:21 ` [PATCH v4 0/5] memory: tegra: Support EMC dfs on Tegra186/Tegra194 Krzysztof Kozlowski
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=4900cf8f-9ec8-48d6-8187-126e111cd048@nvidia.com \
--to=jonathanh@nvidia.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=krzk@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-tegra@vger.kernel.org \
--cc=robh@kernel.org \
--cc=thierry.reding@gmail.com \
--cc=webgeek1234@gmail.com \
/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