Hi there
Since both start M core(APP) and A core still no good, and refer to the attatched document,
I want to start Linux form M7_0 bootloader all lone (not include M7 APP).
I did following steps, but there was not any info output from the UART0,
Could you tell me where the problem is?
Prepare images for Cortex-A53 cores
- 1:download binaries_auto_linux_bsp33.0_s32g2_pfe.tgz and extract it
- 2:dd if=binaries_auto_linux_bsp33.0_s32g2_pfe/s32g274ardb2/fsl-image-auto-s32g274ardb2.sdcard of=/dev/sdc bs=1M status=progress && sync
- (by this, SD mode startup OK)
- 3:checkout release/bsp33.0-2020.04 and build it
- 4:checkout arm-trusted-firmware (release/bsp33.0-2.5) and buid it (`FIP_ALIGN := 64` and unset LDFLAS because I had a "aarch64-fsl-linux-ld.bfd: unrecognized option '-Wl,-O1'" error)
- 5:Build the ATF and got a fip.32 the address info as blow:
- IVT Location: SD/eMMC
- Load address: 0x342fc580
- Entry point: 0x34302000
- 6:renew fip.32
dd if=fip.s32 of=/dev/sdb skip=512 seek=512 iflag=skip_bytes oflag=seek_bytes conv=fsync,notrunc
Prepare bootloader for Cortex-A7_0 core
- 1:load Integration_Reference_Examples bootloder to EB
- 2:disable RM Eep MemDal CryptoDal Crypto plugin and releated options
- (In my Env the SDHC and HSE is still abnormal)
- 3:Bootloader(…)->Bootloader->General Software breakpoint enable uncheck
- 4:boot option like blow:
- 5:generate project and build bootloader.bin
- 6:Generate S32G Boot Image Using S32DS IVT_TOOL
- 7:Deploy the bootloader(with IVT) and fip.32 to QSPI(NOR Flash) with s32ft.exe
- bootlader 0x0000_0000
- fip.32 0x0010_0000
After above operations, set RDB2 to QSPI boot mode.
- You are referring to an attachment, but we could not find it, is the attachment the images provided above?
Sorry for this, I will attach the file .
- we retake our point, the fip file you are using is the same you used for your SD boot? if so, this is wrong. You should use a fip file configured to work from QSPI.
I am sorry I still don't think so, pls let me explain the reason
1:refer to the GoldVIP binaries and GoldVIP document, we found the following files that you provided.
And I dd the fsl-image-goldvip-s32g274ardb2.sdcard to SD card and burnt the boot-loader and fip.32-sdcard to QSPI Flash, the Linux can start normally in QSPI mode.
Alao I hexdumped the fip.32-sdcard and you can the IVT image is on the 0x1000,
that is the position of IVT in SD mode.
2: I downloaded the u-boot and make s32g274ardb2_qspi_defconfig and create IVT image with arm-trusted-firmware, but still NG(burnt it to NOR Flash but no any message outputed on UART0)
I also confirmed that this FIP file is available(no burnt linux image to QSPI)
NOTICE: BL2: v2.5(release):bsp33.0-2.5-dirty
NOTICE: BL2: Built : 08:08:26, Jan 13 2023
NOTICE: BL2: Booting BL31
U-Boot 2020.04 (Jan 13 2023 - 16:06:18 +0800)
CPU: NXP S32G274A rev. 2.0
Model: NXP S32G274A-RDB2
DRAM: 3.5 GiB
MMC: FSL_SDHC: 0
Loading Environment from SPI Flash... SF: Detected mx25uw51245g with page size 256 Bytes, erase size 64 KiB, total 64 MiB
*** Warning - bad CRC, using default environment
Using external clock for PCIe0, CRNS
Configuring PCIe0 as RootComplex(x2)
Using external clock for PCIe1, CRNS
Frequency 125Mhz configured for PCIe1
Configuring PCIe1 as SGMII(x2) [XPCS0 2.5G, XPCS1 OFF]
Setting PCI Device and Vendor IDs to 0x4002:0x1957
PCIe0: Failed to get link up
Pcie0: LINK_DBG_1: 0x00000000, LINK_DBG_2: 0x00000800 (expected 0x000000d1)
DEBUG_R0: 0x00189900, DEBUG_R1: 0x08200000
PCI: Failed autoconfig bar 20
PCI: Failed autoconfig bar 24
PCIe1: Not configuring PCIe, PHY not configured
In: serial@401c8000
Out: serial@401c8000
Err: serial@401c8000
Board revision: RDB2/GLDBOX Revision D
Net: EQOS phy: rgmii @ 1
Warning: eth_eqos (eth0) using random MAC address - 12:e8:6d:ee:63:42
eth0: eth_eqos PFE: emac0: sgmii emac1: none emac2: rgmii
## No elf image at address 0xffdc92f8
PFEng firmware file '<NULL>@0x03000000:<NULL>' loading failed: -22
Hit any key to stop autoboot: 0
## No elf image at address 0xffdc9048
PFEng firmware file '<NULL>@0x03000000:<NULL>' loading failed: -22
PFE: emac0: sgmii emac1: none emac2: rgmii
pfeng_cfg_mode_enable: Invalid PFE device
Booting from flash...
device 0 offset 0x1f0000, size 0xe00000
SF: 14680064 bytes @ 0x1f0000 Read: OK
device 0 offset 0xff0000, size 0x100000
SF: 1048576 bytes @ 0xff0000 Read: OK
device 0 offset 0x10f0000, size 0x2000000
SF: 33554432 bytes @ 0x10f0000 Read: OK
Bad Linux ARM64 Image magic!
=>
=>
So, Although It hard to say what the model is, I think the blow flow can work normally
- QSPI mode
- BOOTROM -> M-core bootloader(with IVT in NOR Flash) -> M-core APP
|-------A-core FIP(SD-Card mode and in NOR Flash) -> A-Core U-Boot(in SD-Card)->A-Core Linux(in SD-Card)
Back to the question of the title
I used the UART sample of RTD, and configured the bootloader like blow:
And I burnt both bootload, ATF(SD-Card and QSPI ), UART sample with windows GUI tool
the UART0 can be output normally like blow but UART0 still NG
I also give the IVT compilation log. Can you give me some suggestions?
SD Mode
QSPI Mode
Hi,
Thanks for the attachment.
We do apologize for our insistence, but we want to retake the following point:
"- we retake our point, the fip file you are using is the same you used for your SD boot? if so, this is wrong. You should use a fip file configured to work from QSPI."
Below should be a capture of what is provided inside the NXP BSP 33.0 binaries folder, under the RDB2 sub-folder.
In which 2 fip files are provided, one for SD and one for QSPI.
For what you have been telling us, you are using the same fip file you used (and worked) on the SD interface. This should not work on the QSPI interface.
Have you tried (at this point in time) to boot up linux (without M7 into the equation) from NOR Flash?
From the first point you mentioned "...and fip.32-sdcard to QSPI Flash, the Linux can start normally in QSPI mode." and also "...I hexdumped the fip.32-sdcard and you can the IVT image is on the 0x1000." we understand you tried this option, but it is not explicitly mentioned.
In QSPI mode, S32G looks for the IVT on 0x0, not 0x1000 [Table 137, Page 1146, S32G2 Reference Manual, Rev. 6, 11/2022], which the IVT for the fip file you are using is located, but you still got it working in QSPI mode.
We suspect you got your platform to boot up from the SD (not QSPI), which is expected from the steps you mentioned (and files you used).
Still, as we said before, we could not be understanding correctly your application nor configuration/set-up.
Please, let us know.
Hi
Daniel
Sorry for the Chinese New Year leave.
- have you tried running the application without modifications?
Yes, I did, but still NG,But there was one difference:
- to disable BREAKPOINT, I unchecked Bootloader(…)->Bootloader->General ->Software breakpoint enable, No code modification.
For confirmation, I Re-compiled the images and provide those files and IVT configuration
In addition,here are two questions, please let me to confirm
- In AN13750, about deployment, should we have to copy two files, and is the deployed file a fip.bin file instead of a fip.s32 file?
- I tried to debug the bootloader.elf file that I attached, it stopped at HSE firmware initialization, is there a problem here?(I think it should be because of the debugger， because I unchecked the [secure boot] at Bootloader(…)->EcuC(…)->Bootloader(…)-> Bootloader->General and the debug is OK,but start A53 still NG)
Maybe I still missed something, but there is still no special progress so far. Please help me.
Thank you very much.
Hi Daniel
Thank you for your kind help,
Since I reconfigure the IVT image like blow, it seems that both A53 and M7_0 were startup OK
and between Linux Kernel and Cortex-M7 cores the IPC communication was OK too.
- we would like to confirm if you can boot-up Linux from NOR Flash using the A53 core. This can be done directly from S32DS and by following Section 4 from AN13750.
About this, I still think that the content in Section 4 describes starting Linux from SD card instead of NOR Flash.
BTW,
we will soon use S32G to develop AUTOSAR AP and domain controllers, and I inquired about NXP's customer service in China. They mentioned that the support of S32G is in Europe (the Netherlands?), because there is a time difference between China and the Netherlands. Besides this forum, is there any more easy way (near-real-time) to ask you questions?
In addition,
I saw some Chinese menual in the forum. I don't know whether these menaul were made by NXP employees in China or Chinese employees in Europe?
Therefore, even in Europe, is it possible for Chinese (or Ethnic Chinese) to support China's S32G business in the future.
首先
但是从NorFlash中起M核（SW4-7 OFF）失败了，串口这段完全没有任何信息print出来
这个你是说M和这边串口没有消息打印的对吧，
你还是需要在理解一下AN13750的case，这个case的最终结果并不是所A核和M核要有东西打印，
其核心是测试IPCF来测试IPC通信是否正常（如下图）
所以在这个case中，如果要确认M核是否起来，可以参考PDF的22页的内容，
通过Linux端的驱动发行IPC消息给M核，然后M核把同样的消息返回给Linux，
具体内容如下：
$echo 1 > /sys/kernel/ipc-shm-sample-instance0/ping
$echo 1 > /sys/kernel/ipc-shm-sample-instance1/ping
$echo 1 > /sys/kernel/ipc-shm-sample-instance2/ping
$dmesg | grep ipc-shm-sample_multi-instance
[ 462.703716] ipc-shm-sample_multi-instance: starting demo on instance 0...
[ 462.703739] ipc-shm-sample_multi-instance: INST0 ch 0 >> 19 bytes: SENDING MESSAGES: 1
[ 462.703753] ipc-shm-sample_multi-instance: INST0 ch 1 >> 32 bytes: #0 HELLO WORLD! from KERNEL
[ 462.703797] ipc-shm-sample_multi-instance: ch 0 << 19 bytes: REPLIED MESSAGES: 1
[ 462.703818] ipc-shm-sample_multi-instance: ch 1 << 32 bytes: #0 HELLO WORLD! from CORE 4
[ 462.703850] ipc-shm-sample_multi-instance: exit demo for instance 0
[ 470.935633] ipc-shm-sample_multi-instance: starting demo on instance 1...
[ 470.935653] ipc-shm-sample_multi-instance: INST1 ch 0 >> 19 bytes: SENDING MESSAGES: 1
[ 470.935667] ipc-shm-sample_multi-instance: INST1 ch 1 >> 32 bytes: #0 HELLO WORLD! from KERNEL
[ 470.935712] ipc-shm-sample_multi-instance: ch 0 << 19 bytes: REPLIED MESSAGES: 1
[ 470.935732] ipc-shm-sample_multi-instance: ch 1 << 32 bytes: #0 HELLO WORLD! from CORE 5
[ 470.935763] ipc-shm-sample_multi-instance: exit demo for instance 1
