i.MX RT1170 crossover MCUs are part of the Edge Verse™ platform and are setting speed records at 1 GHz. This ground-breaking family combines superior computing power and multiple media capabilities with ease-of-use and real-time functionality. For reducing the overall system cost, RT117x didn't have embeded flash, need external Flash as program storage and XIP place, NXP and third party like IAR, KEIL and Segger all provide mature tool to make Nor Flash‘s programing with their own flashloader, can fulfillment most customer’s application requirement, but still some users need to customize the flash programing algorithm due to programing speed optimization and difference of the nor Flash from different vendor and, such as SFDP support, QE bit's position, default sector size, DDR/OPI/QPI feature, default 3 Bytes/4 Bytes mode and also operating sequence, but the default Flashloader is based on the ROM API, it's hard to debug and customize as there is no source code. This reference demo will use source code Flash operation API instead of ROM API.
In addition, it also add two new useful feature, first one is current Flashloader framework can't support some nor flash which need pre-configuration, such as Cypress's S25HL01GT, its sector size is not unified, need to config additionally. This reference demo give some function interface to implement it with 3 bytes/4bytes command mode and DDR/SDR mode, it also improve the original framework by adding read-erase-write demonstration code, which can help user to verify their customized Flashloader without need to copy to IDE every time, improve the efficiency greatly. Second advantage is it can support download flow‘s log generation, by default there is no log info in overall download flow, hard to locate which step(get configure/init/erase/program/verify) the failure occur, this demo code add log function to record every detailed download step, by which users can optimize their download speed, it's helpful for mass production. Developers can also debug and customize depend on their own specific requirement and different nor Flash.
EEPROM selection guide for serial RCON boot.
On S32G reference manual, we only ask customer to make sure I2C address of EEPROM is 0xA0, no others requirement.
Actually, S32G only supports EEPROM with one 8-bit address byte. For high capacity EEPROM such as AT24C64D@8K bytes, which need two 8-bit word address bytes. Can’t be supported by S32G ROM.
AT24C01 has been validated on S32G EVK board, which need one word address byte
FAST BOOT FOR lx2160 IN adas
To speed up bringup of LX2 chip-based systems
•Pain Points to Address
The bringup time is much longer than 3s, which is very sensitive in ADAS systems or time-sensitive systems.
•Value Proposition / Key Features
The guide can help customers shorten uboot time from 5s to less than 1.5s, saving more than 70% bootup time.
Demo based on LX2160ARDB board.
Reference codes and patches.
Guide for Fast boot document.
Fast boot 广泛用于嵌入式设备，现以lx2160ardb板为例进行相关探索。 启动流程：
diff --git a/lx2160asi/flexspi_divisor_32.rcw b/lx2160asi/flexspi_divisor_32.rcw
index 422139c..0f8d5c9 100644
@@ -7,8 +7,10 @@
* Modify FlexSPICR1 register, to increase FlexSPI clock closer to 50MHz,
* with divisor value as 32.
* => 750 * 2 / 32 ==> 46.875MHz
+ *write 0x1e00900,0x00000013
+ * 0f -12 =125M
S32G just support serial download a M7 image to run by internal rom codes, our S32G DS IDE have a flash tools to use this feature to burn the image to external device. So current image burn method will divide into 2 step:
1: burn a uboot into the external device by S32G DS flash tools.
2: reboot the codes with uboot and run with network to burn the linux image into external device.
which need two working place on manufacture line, and customer wish to have a one time on-line tools, which means we need use serial port to boot uboot directly but S32G rom codes do not support it.
We have a reference tools of S32V but which IP difference is big between on S32V and S32G, So we can not reuse it and have to develop a new one.
The development working include:
调试解决串口接收乱码问题(Serial boot rom codes仍然在回送消息串口)
提供 解决A核启动串口halt思路(Serial boot rom codes仍然占用串口)
根据M7镜像和A核 Uboot 在SRAM中的内存分配要求，重排M7镜像位置，避免冲突
Pls check the attachment for the doc/codes/binary release which include:
|->M7: Linflexd_Uart_Ip_Example_S32G274A_M7: S32DS M7工程。
|->PC: s32gSerialBoot_Csharp: PC端的Visual Studio的C#的串口工具工程。
| |-> 115200_bootloader.bin: S32DS M7工程编译出来的bin文件，波特率为115200
| |-> 921600_bootloader.bin: S32DS M7工程编译出来的bin文件，波特率为921600
| |->load_uboot.bat: 运行工具的批处理文件，运行成功后打开串口可以看到Uboot执行，默认使用的波特率是115299
| |->u-boot.bin: BSP29默认编译出来的u-boot.bin.
NXP Part Number