Frequency monitor floods uart due low freqency on SPI2

I have a connected device that requires frequency of 300kHz to SPI2. It is working correctly, but when after I load kernel module, I get flood of messages from FMON on the debug port/uart.

verify_rate_range: FMON_SPI2: rate 300000 below min 750000 fmon_update_config: FMON_SPI2: detected fault 0x80

When I was doing test using loopback connection we didn’t have this issue. I have change parent clock to osc for SPI2 to be able to reach required frequency. I edited device tree to always set this property:

	spi@c260000 {
		//SPI3 300000
		status = "okay";
		assigned-clock-parents = <&bpmp TEGRA234_CLK_OSC>;
		spi-max-frequency = <300000>;
        ///….
}

How to suppress frequency monitor message about verify rate range. I didn’t find any kernel code handling this property. Is it possible to change minimal frequency value for SPI2? Or I have to switch to other SPI, but this will require redesigning the board.

Is this associated with a device special file in “/dev”? If so, then what is the exact output of “ls -l” on that device? I am thinking this might already be in use for serial console. It sounds like serial console messages (a UART which is available has group dialout).

FMON properties are defined at the bootloader level and are probably related to BPMP, because disabling logs at the kernel level or modifying them does not affect these properties. I haven’t found any information about fmon_update_config in either the kernel sources or the NVIDIA modules.

Hi m.krawczuk

Are you using the devkit or custom board for AGX Orin?
What’s jetpack version in use?

Can your SPI device work with the frequency above 750kHz?

Please note that SPI2 is from SPE and its level is 1.8V.
You can also check if there’s the similar issue on SPI1 and SPI3.

I tested this with custom board and devkit and results are same. Device is working fine with changed clock parent, but only issue is message flood from FMON_SPI2. We will replace device with something which will handle faster SPI, but for first batch of devices we want fix this issue reported by testers.

Those messages are output by bpmp-fw.

Have you considered using SPI1 or SPI3 instead?

We consider to switch to different SPI, but bmap-fw also has same values for other SPI:

Please share the result of the following command on your board.

$ cat /etc/nv_tegra_release

And also, the bpmp-dtb used in your case.

We are using Jetpack 6.2.1:

# R36 (release), REVISION: 4.4, GCID: 41062509, BOARD: generic, EABI: aarch64, DATE: Mon Jun 16 16:07:13 UTC 2025
# KERNEL_VARIANT: oot
TARGET_USERSPACE_LIB_DIR=nvidia
TARGET_USERSPACE_LIB_DIR_PATH=usr/lib/aarch64-linux-gnu/nvidia

tegra234-bpmp-3701-0008-3737-0000.zip (13.1 KB)

It seems the following lines have been configured so that it won’t trigger reset/error.

                fmon@spi2 {
                        clk-id = <0x88>;
                        fault-actions-disabled;
                };

If you don’t want to get those log printed, you can simply configure the log level for BPMP as following.

        serial {
                port = <0x03>;
+              log-level = <1>;
                has_input;

                combined-uart {
                        enabled;
                };
        };

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.