This article explains that on the S32G3 RDB3 board, when the PFE driver is enabled in Uboot, the PFE FW needs to be loaded. By default, in Uboot, the PFE FW is placed in the FAT partition of SD/eMMC and read through file system access. This article explains how to modify it to read from QSPI NOR.
The main application scenarios are: When burning the image, Uboot needs to burn the kernel image and rootfs through the network port. At this time, SD/eMMC has no partition, so the FW required by the PFE network port cannot be placed in the FAT partition.
The software version is BSP41 UBoot.
History Description Author
V1 Created this article John.Li
1 Background and related information
1.1 Problem background
The Linux image burning of S32G is usually as follows:
Use the burning tool (flash tools+uart or lauterbach program+jtag) to burn the bootloader into QSPI NOR.
Use the burning tool (flash tools+uart or lauterbach program+jtag) to burn the fip image into QSPI NOR;
Or: Use the burning tool (flash tools+uart or lauterbach program+jtag), or bootloader+CAN,
to burn ATF BL2 into QSPI NOR and burn Uboot into eMMC.
Uboot burns the kernel image and rootfs into eMMC through network devices (such as: tftp+NFS).
Assuming that the only network device supported by Uboot is PFE, it is necessary to develop a method to load PFE FW, because NXP's default Uboot for SD/eMMC startup only supports storing PFE FW in the FAT partition, and the above process cannot partition SD/eMMC.
So this article explains a way to solve this problem.
First, analyze all the ways to load FW for PFE drivers:
Serial No. Method Location Problem
1 The M core PFE MCAL Master driver compiles FW as an array into the \example_application\pfe_firmware \s32g_pfe_class.c program file.
2 The A core Uboot driver reads FW binary from the SD/eMMC FAT partition and puts it together with the kernel image and DTB: /boot# ls s32g_pfe_class.fw … No FAT partition during programming
3 The A core PFE master kernel module driver reads FW binary from the file system root file system /lib/firmware# ls s32g_pfe_class.fw s32g_pfe_util.fw The module driver starts slowly
4 The A core PFE master kernel driver reads FW binary from the kernel image and compiles it into the kernel. Refer to the following document [3] The kernel driver starts quickly
This article is mainly to solve the problem of item 2. The solution ideas can be:
No. Method Reference Problem
1 If there is a GMAC hardware connection, change to use GMAC as the network port for burning the image. Uboot has a GMAC driver, which can be used directly. 1: GMAC is usually used by the M core, and customers do not want to use GMAC in Linux. 2: Using GMAC requires changing another network interface, which is sometimes not allowed by the hardware.
2 Compile PFE FW into Uboot as an array. Refer to the method of MCAL driver. 1: There is a certain amount of development work. 2: Updating FW requires updating Uboot, or even the entire FIP.
3 Prepare a minimum linux system based on qspi and use the kernel driver directly to burn. NXP has released Uboot support based on QSPI Nor. 1: There is a certain amount of development work. 2: It cannot be reused with the image that is officially started, and it will occupy a certain amount of QSPI NOR space.
4 Store PFE FW in QSPI NOR, and change PFE FW loading from SD/eMMC FAT partition to loading from QSPI NOR. NXP has released Uboot support based on QSPI NOR, in which PFE FW is also stored in QSPI NOR. This method supports separate upgrade of PFE FW. 1: Uboot needs to support QSPI driver, which may conflict with MCAL QSPI driver (but generally speaking, M core is in suspended state during Linux burning process).
Compared with item 4, this method is more reasonable, so this article explains it.
pfeng pfeng-base: Uploading CLASS firmware pfeng pfeng-base: EMAC0 not used, skipped pfeng pfeng-base: EMAC1 block was initialized pfeng pfeng-base: EMAC2 block was initialized pfeng pfeng-base: Enabling the CLASS block
Shouldn't this be using the device tree from Linux?
When I update my dts file and rebuild my image, the fip.s32-sdcard file is not getting updated.
The last issue had to do with initializing the pfe0 clocks in the bootloader.
Now pfe0 is working, but I cannot run the kernel:
Load address: 0x83000000 Loading: ### 5.1 MiB/s done Bytes transferred = 43037 (a81d hex) ## Flattened Device Tree blob at 83000000 Booting using the fdt blob at 0x83000000 Using Device Tree in place at 0000000083000000, end 000000008300d81c
I've got it to the point where I "run nfsboot" and the device tree and kernel loads.
When the kernel starts, it fails to mount the rootfs. Probably because pfe0 is not back up yet.
Is there a way to fix this?
When the kernel boots, it fails here:
[ 115.678056] VFS: Unable to mount root fs via NFS. [ 115.682434] devtmpfs: mounted [ 115.686193] Freeing unused kernel memory: 2496K [ 115.690379] Run /sbin/init as init process [ 115.694512] Run /etc/init as init process [ 115.698438] Run /bin/init as init process [ 115.702435] Run /bin/sh as init process [ 115.706251] Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. [ 115.720324] SMP: stopping secondary CPUs [ 115.724235] Kernel Offset: disabled [ 115.727700] CPU features: 0x1,00000008,00020000,1000420b [ 115.732994] Memory Limit: none [ 115.736036] ---[ end Kernel panic - not syncing: No working init found. Try passing init= option to kernel. See Linux Documentation/admin-guide/init.rst for guidance. ]---