Message-ID: <4900cf8f-9ec8-48d6-8187-126e111cd048@nvidia.com>
Date: Thu, 18 Dec 2025 11:12:11 +0000
From: Jon Hunter <jonathanh@...dia.com>
To: Aaron Kling <webgeek1234@...il.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Rob Herring <robh@...nel.org>,
 Conor Dooley <conor+dt@...nel.org>, Thierry Reding
 <thierry.reding@...il.com>, linux-kernel@...r.kernel.org,
 devicetree@...r.kernel.org, linux-tegra@...r.kernel.org
Subject: Re: [PATCH v4 3/5] memory: tegra186-emc: Support non-bpmp icc scaling


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

Powered by blists - more mailing lists