Re: [PATCH v4 3/5] memory: tegra186-emc: Support non-bpmp icc scaling
From: Jon Hunter
Date: Thu Dec 18 2025 - 06:12:27 EST
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