Net disconnects when the kernel starts up

[youke]

Hi，nxp

I am using s32g274a and our own developed baseboard.
The software versions are: rtd_4.0, llce_1.0.8, pfe_1.3.0, linux_bsp_42(5.15.158).
We use the M0 core to initialize llce and pfe_master, added CAN2NET logic, read CAN data from CAN5, and forward it to pfe_mac2. In the U-Boot and kernel code, we have disabled the entire pfe functionality.
We identified an issue where, after u-boot jumps to the kernel (armv8_switch_to_el2), there is approximately 350ms during which pfe_mac2 does not output network data. Once the kernel boots to start_kernel, network data output resumes normally.
The period between armv8_switch_to_el2 and start_kernel involves some low-level assembly code. How can I avoid this 350ms period of uncontrollable network status and ensure that CAN2NET forwarding remains correct throughout the entire boot process?

Looking forward to your response.

[chenyin_h]

Hello, @youke 

Thanks for your reply.

I am not sure which timer you are working with, but it does not matter, the PFE stop functional for some time is abnormal. 

Since at least bootloader, M core application and BSP are involved, it is a little difficult for me to reproduce the issue for further debugging from my side, what I suggested for locating your issue is to check at least pin, clock part of PFE/llce in both TFA/uboot and kernel.

Since you are working with CAN2ETH, I suggest also checking the clocks related with LLCE-CAN.

BR

Chenyin

[chenyin_h]

Hello, @youke 

Thanks for your reply.

I feel sorry that, from BSP side, there are not such document existed, I apologize.

From my understanding, I do not think the dts loading is done by the assembly code you mentioned(instead, it is done within the start_kernel, since it is the main routine), as I had stated, 350ms is quite long, take default BSP for an example, after 350ms after booting the kernel, some of the drivers should have been initialized.

BR

Chenyin

[youke]

Hi，chenyin

Here's how I tested 350ms.
I printed mark 1 using uart before the u-boot jump, and printed mark 2 using uart at the beginning of start_kernel. I subtracted mark 1 from mark 2 sent via uart to get 350ms.
Is there anything wrong with my testing method? Do you have any other suggestions?

[chenyin_h]

Hello, @youke 

Thanks for the reply.

From my understanding, besides what you had mentioned, you may have to care about the pinmux in dts, also all related clock for driving the PFE.

BR

Chenyin

[youke]

Hi，chenyi

Is there a configuration manual for the pinmux and clk parts mentioned? Please provide it.
I have a question. A 350ms net data interruption occurs between u-boot and kernel. Does the jump assembly code in this part have the function of reading dts, parsing, and executing related configurations?

[chenyin_h]

Hello, @youke 

Thanks for the post.

350ms seems quite long,  may I know if all PFE related source is removed from the kernel side? 

BR

Chenyin

[youke]

Hi，chenyi

I think I turned them all off.
In dts, I configured status = “disabled” for all pfe nodes and removed the pfe ko and sw files from kernel_rootfs.

What else should I be aware of?