本文说明在STR Resume后，如何解决M 核与A核的GPIO状态冲突的问题，并简单剖 析了Linux GPIO驱动。 目录 1 背景说明与参考资料 .................................................. 2 1.1 背景说明 ................................................................. 2 1.2 参考资料 ................................................................. 2 2 S32G linux GPIO驱动说明 ......................................... 3 2.1 SIUL2 GPO功能说明 .............................................. 3 2.2 Linux GPIO驱动DTS .............................................. 4 2.3 Linux GPIO驱动初始化 ........................................... 6 3 Rework办法 ............................................................... 7 3.1 SIUL2 GPO驱动PM函数 ........................................ 7 3.2 Rework方法 ............................................................ 9 4 测试办法 .................................................................. 10

Chinese version   S32G的partition off流程要求核稳定的进 入到WFI状态，本文说明如何修改Linux内核， 在A53 Linux关机或kernel panic时，如何让所 有A53 Core进入WFI。 目录 1 背景说明与参考资料 .................................................. 2 1.1 背景说明 ................................................................. 2 1.2 参考资料 ................................................................. 5 1.3 测试工具 ................................................................. 6 2 Panic ......................................................................... 7 2.1 Panic代码流程分析 ................................................. 7 2.2 BSP30修改说明(Non-ATF) ................................... 10 2.3 BSP36修改说明(ATF) .......................................... 15 3 Poweoff ................................................................... 17 3.1 Poweroff代码流程分析 ......................................... 17 3.2 BSP30修改说明(Non-ATF) ................................... 19 3.3 BSP36修改说明(ATF) .......................................... 20 4 Reboot情况说明 ....................................................... 20 5 STR情况说明 ........................................................... 21

由于NXP之前使用的git服务器codeaurora已经永久性关闭，本文说明针对S32G如何迁移到github服务器的方法。 目录 1    服务器迁移情况说明... 2 2    参考文档和工具... 4 3    Yocto迁移说明... 4 3.1  从头开始新建Yocto工程说明... 4 3.2  对已有Yocto工程的迁移说明... 6 3.3  Migrate.sh的帮助... 7 4    独立编译迁移说明... 10 4.1  PFE独立编译... 11 4.2  IPCF独立编译... 13

This doc explain how to modify the bootloader to boot linux&mcal, to solve the conflict between bootloader, mcal and linux   本文说明在S32G2 RDB2板上如何定制开发Bootloader，本文示例主要实现功能是： Bootloader启动一个M核，MCAL驱动测试程序，本文分别测试了MCU，DIO，UART的MCAL驱动示例代码。 Bootloader同时启动A53 Linux 目录 1    需要的软件，工具，文档与说明... 3 1.1  软件与工具... 3 1.2  参考文档... 3 1.3  开发说明... 3 2    测试软件安装编译说明... 4 2.1  安装RTD_MCAL驱动... 4 2.2  编译MCAL驱动测试程序(以MCU为例) 5 2.3  优化重排M7 demo镜像及与MPU设置的配合... 5 2.4  去掉CLOCK INIT. 7 2.5  去掉MCU相关INIT. 8 2.6  DIO MCAL程序去掉PORT INIT. 9 2.7  UART MCAL程序去掉PORT INIT. 10 2.8  UART MCAL程序修改CLOCK TREE.. 10 2.9  解决中断冲突... 11 2.10 准备A53 Linux镜像... 12 3    Bootloader工程说明... 13 3.1  关掉XRDC支持... 13 3.2  关掉eMMC/SD支持(可选) 14 3.3  关掉secure boot(可选) 14 3.4  增加MCAL驱动所需要的PORT的初始化... 15 3.5  解决Bootloader,MCAL与Linux的clock冲突... 17 3.6  配置A53 Boot sources: 34 3.7  配置M7 Boot sources: 35 3.8  关闭调试软断点：... 36 3.9  编译Bootloader工程... 37 3.10 制造Bootloader的带IVT的镜像... 38 3.11 烧写镜像... 41 4    测试... 42 4.1  硬件连接... 42 4.2  MCU MCAL+Linux测试过程... 42 4.3  DIO MCAL+Linux测试过程... 43 4.4  UART MCAL+Linux测试过程... 43 5    Bootloader源代码说明... 43 6    Bootloader定制说明... 45 6.1  QSPI NOR驱动说明... 45 6.2  eMMC/SDcard启动支持... 46 6.3  DDR初始化... 46 6.4  Secure Boot支持... 46 7    调试说明... 46 7.1  Bootloader的调试... 46 7.2  MCAL驱动的调试... 46   add one more doc to explain how to modify atf to boot on G3.

this doc and project explain how to integrate S32G M stby demo and Linux STR demo to one demo to achieve the fast boot, chinese version: 本文说明如何在S32G2 RDB2板上搭建 一个M7 MCAL Standby Fullboot GPIO resume Demo加A53 Suspend to RAM的Demo，主要的 应用场景是电动汽车的快速启动。 G3与更新版本BSP的支持情况与此类 似，不再另外说明，客户可以自行参考开发。 请注意本文为培训和辅助文档，本文不是 官方文档的替代，请一切以官方文档为准。     目录 1 参考资料说明与声明 .................................................. 2 2 STBY+STR的硬件注意点 .......................................... 3 3 修改M7 MCAL Standby Demo代码 ............................ 5 3.1 Clock相关修改 ........................................................ 5 3.2 MCU相关修改 ......................................................... 5 3.3 UART Clock相关修改 ............................................. 7 3.4 Port相关修改 .......................................................... 7 3.5 I2C相关修改 ........................................................... 7 3.6 实现M核进入STDY状态等待功能 ........................... 8 3.7 Main函数的修改 ..................................................... 8 4 修改Bootloader工程来支持同时Boot M/A核Demo ... 10 4.1 I2C Clock相关修改 ............................................... 10 4.2 Port相关修改 ........................................................ 11 4.3 其它修改 ............................................................... 12 5 修改A53 Linux代码 .................................................. 13 6 Demo 运行测试 ........................................................ 13 6.1 硬件连接 ............................................................... 13 6.2 镜像烧写 ............................................................... 13 6.3 Demo运行 ............................................................ 14 7 工程发布包............................................................... 15 8 未来开发建议 ........................................................... 17 8.1 M/A核同步机制 ..................................................... 17 8.2 功能安全与信息安全 ............................................. 17 9 遗留问题 .................................................................. 17 9.1 IPCF STR支持 ...................................................... 18 9.2 PFE Slave STR支持 ............................................. 18 注意以下说明与声明： 说明： 汽车网关有快速启动要求，而电动车因为驻车时有更大的电池提供待机电源，所以希望是使 用Linux 的suspend to ram 的功能来实现Linux 的快速启动，而在S32G 上则需要考虑将M 核的 Standby 功能 与A 核的STR 功能 结合起来，目前可用的资源包括：  从BSP32 起支持ATF，可以支持Linux 端的STR 功能，文档《S32G_Linux_STR_V1-*.pdf》 (John.Li)说明linux STR 的原理和与M7 Standby Demo 结合时所需要的修改。  NXP 的M7 内部standby demo，可以支持M 核端的standby 功能，支持full boot 和standby ram boot。文档《S32G_Standby_Demo_V4-*.pdf》(John.Li)有详细说明，本文使用MCAL full boot+GPIO resume Demo。  本Demo 与本文主要说明如何将这两个Demo 结合起来，形成一个整体的Demo。  由于需要Boot M 核加A 核，所以也需要Bootloader 工程的支持，文档 《S32G_Bootloader_V1-*.pdf》(John.Li)说明了如何创建一个MCAL sample 加Linux 的 Bootloader 工程。 声明： 请注意：  M7 standby demo 本来为NXP 内部Demo，不保证运行质量。而Linux 本身也是reference software。  Linux STR 本身会引入比较复杂的电源管理切换，也会引起系统级的不稳定性。  本文所说的方法也是实验性质，不保证运行质量。 所以客户应该谨慎决定其产品功能并自行保证其产品质量，本文及本Demo 仅为Demo 性质。   This article explains how to build a demo of M7 MCAL Standby Fullboot GPIO resume Demo plus A53 Suspend to RAM on the S32G2 RDB2 board. The main application scenario is the quick start of electric vehicles. The support situation of G3 and the newer version of BSP is similar to this, no further explanation is given, customers can refer to it for development by themselves.  Please note that this article is a training and auxiliary document. This article is not a substitute for the official document. Please refer to the official document. Contents 1    Reference materials and statement 2 2    STBY+STR hardware checkpoints. 3 3    Modified M7 MCAL Standby Demo codes. 5 3.1  Clock modification. 5 3.2  MCU related modification. 6 3.3  UART Clock related modificaiton. 7 3.4  Port related modification. 8 3.5  I2C related modification. 8 3.6  Enable the waiting function of M core entering STDY. 9 3.7  Main function modification. 9 4    Modify the Bootloader project to support simultaneous M/A core demo  11 4.1  I2C Clock related modification. 11 4.2  Port related modifcaiton. 11 4.3  Others modificaiton. 13 5    Modify A53 Linux codes. 14 6    Demo running and testing. 14 6.1  Hardware link. 14 6.2  Image burning. 14 6.3  Demo running. 15 7    Project release package. 16 8    Suggestion for the future development 17 8.1  M/A core sync mechanism.. 17 8.2  Function safety and Information security. 17 9    Remaining issues. 18 9.1  IPCF STR support 18 9.2  PFE Slave STR support 18   as need refer:   S32G_Linux STR This doc explain S32G Linux STR details and modify to integrate with M stdy demo https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Linux-STR/ta-p/1652680 S32G Standby Demo the project build a new Mcal standby demo and explain its details https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-M-kernel-Standby-demo-and-how-to-porting-to-Mcal/ta-p/1556313 S32G Boot customization doc how to run bootloader to run mcal&linux https://community.nxp.com/t5/NXP-Designs-Knowledge-Base/S32G-Bootloader-Customzition/ta-p/1519838

This doc explain the S32G STR feature details and how to modify it to integrate with M kernel STBY demo, to achieve the fast boot. chinese version: 本文说明S32G A53核STR详细情况及定 制，定制部分说明如何与M7 standby demo结 合，来实现整个产品的快速启动。 请注意本文为培训和辅助文档，本文不是 官方文档的替代，请一切以官方文档为准。 目录 1 参考资料说明 ............................................................. 2 2 Demo创建运行过程 ................................................... 2 3 Linux STR流程 ........................................................... 2 4 ATF Suspend流程 ..................................................... 5 4.1 Suspend流程 .......................................................... 5 4.2 Full boot resume流程 ............................................. 7 5 定制修改 .................................................................... 9 5.1 ATF中实现主核切换为M7 ....................................... 9 5.2 ATF中去掉PMIC与I2C4 ....................................... 11 5.3 ATF中去掉wkpu驱动 ............................................ 17 5.4 Uboot中去掉PMIC与I2C4 ..................................... 18 5.5 Kernel中去掉I2C4 ................................................ 19 6 发布 ......................................................................... 20   This article explains the details and customization of S32G A53 core STR. The customization part explains how to combine with M7 standby demo to realize the quick start of the whole product. Please note that this article is a training and auxiliary document. This article is not a substitute for the official document. Please refer to the official document. Contents 1    Reference materials. 2 2    STR Demo. 2 3    Linux STR call flow.. 2 4    ATF Suspend call flow.. 5 4.1  Suspend flow.. 5 4.2  Full boot resume flow.. 7 5    Customization. 9 5.1  The STR main core is switched to M7 in ATF. 9 5.2  ATF remove PMIC and I2C4. 11 5.3  ATF remove wkpu driver 17 5.4  Uboot remove PMIC and I2C4. 18 5.5  Kernel remove I2C4. 19 6    Release. 20

Memtool is a useful debug tool which can read/write some i.MX register. It is default supported in Linux while not supported in Android. This article describse how to integrate memtool into i.MX8MM Android 12 platform, which is also similar in other i.MX new android platform.  

This doc explain how to build a PFE master project on M7 and how to integration. chinese version. 目录 1 需要的软件与工具 ...................................................... 2 2 Master Demo编译说明 ............................................... 2 2.1 安装RTD_MCAL驱动 ............................................. 2 2.2 安装PFE_MCAL驱动 .............................................. 3 2.3 编译PFE master工程 .............................................. 3 3 修改为支持RDB板的RGMII接口 ................................ 4 3.1 硬件连接 ................................................................. 4 3.2 软件修改 ................................................................. 5 4 Master Demo测试 ...................................................... 7 4.1 硬件连接 ................................................................. 7 4.2 PFE_EMAC1(RGMII)测试过程 ............................... 7 5 Master Demo代码说明 ............................................... 8 6 集成中注意点 ........................................................... 11 6.1 PFE_PreInit .......................................................... 11 6.2 S32G3中的GENCTRL1的配置 ............................. 12 6.3 RX CLOCK重新锁定 ............................................ 13 7 Demo Debug建议 .................................................... 14 7.1 PFE相关寄存器说明 ............................................. 14   Contents 1 Required software and tools ...................................... 2 2 Master Demo compiling ............................................. 2 2.1 Install RTD_MCAL driver........................................ 2 2.2 Install PFE_MCAL driver ........................................ 3 2.3 Compile PFE master project .................................. 3 3 Change the demo to support RDB3 board RGMII port4 3.1 Hardware design .................................................... 4 3.2 Software modification ............................................. 5 4 Master DemoTest ...................................................... 7 4.1 Hardware design .................................................... 7 4.2 PFE_EMAC1(RGMII) test steps ............................. 7 5 Master Demo code flow ............................................. 8 6 Notes in integration .................................................. 11 6.1 PFE_PreInit .......................................................... 11 6.2 The GENCTRL1 configruation of S32G3 ............. 12 6.3 RX CLOCK relock ................................................ 13 7 Demo Debug suggestion ......................................... 14 7.1 PFE related registers ........................................... 14

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.

结合MPC5748G的Lifecycle机制，阐述如何使用Lifecycle机制来满足在开发阶段及最终消费阶段对各利益相关方的数据进行保护的需求，比如Tier1的IP(知识产权)、OEM的一些标定参数、车主的个人隐私等。并介绍Lifecycle在每个阶段所支持的主要安全特性及如何配置使用。

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.   AT24C64D.pdf         AT24C01 has been validated on S32G EVK board, which need one word address byte AT24C01.pdf   Thanks, Lambert

This document introduce how to do LPDDR4 DQ Swapping in S32G platform.

This article explains the details and customization of the S32G M7 core Standby demo. And how to porting to Autosar Mcal demo. Contents 1    Description of reference materials. 2 2    Demo creation and running process. 2 2.1  Demo checkpoints. 2 2.2  The difference between Standby and StandbyRAMboot 4 3    S32G Standby principle and Code Description. 5 3.1  Peripheral initialization function. 5 3.2  standbyramc_cpy(optional) 5 3.3  WKPU_set 8 3.4  standby_modechange. 13 4    VR5510 PMIC Standby principle and code description. 15 4.1  PMIC_initConfig. 15 4.2  PMIC_standbyEntry. 17 5    Customization modification. 18 5.1  Do not enable RTC wakeup feaure. 18 5.2  Eable CAN1_RX wakeup feature. 19 5.3  Only support full boot 21 5.4  Open the DDR related power 21 5.5  Modify debug serial port to UART1. 24 5.6  Modify the device drive clock. 26 5.7  close other non-main core. 30 6    Build a new MCAL demo. 34 6.1  Modify the UART driver 35 6.2  Implement the clock shutdown code. 36 6.3  Configure the power mode switching driver 37 6.4  Confgure the wakeup source. 42 6.5  Add PMIC driver 51 6.6  Main function call routine. 59 6.7  Test 61 6.8  Future development plan. 62 本文说明S32G M7核Standby demo 详细情况及定制,以及如何新建一个mcal demo 录 1    参考资料说明... 2 2    Demo创建运行过程... 2 2.1  创建运行... 2 2.2  Standby和StandbyRAMboot的区别... 4 3    S32G Standby原理与代码说明... 5 3.1  外设初始化函数... 5 3.2  standbyramc_cpy(可选) 5 3.3  WKPU_set 8 3.4  standby_modechange. 13 4    VR5510 PMIC Standby原理与代码说明... 14 4.1  PMIC_initConfig. 14 4.2  PMIC_standbyEntry. 16 5    定制修改... 17 5.1  关闭RTC唤醒功能... 17 5.2  打开CAN1_RX唤醒功能... 19 5.3  只支持full boot 20 5.4  打开DDR相关电源... 21 5.5  修改调试串口为UART1. 23 5.6  修改设备驱动时钟... 25 5.7  事先关掉所有其它的非主核... 29 6    修改为MCAL Demo. 33 6.1  修改UART驱动... 34 6.2  实现时钟关闭代码... 35 6.3  配置电源模式切换驱动... 36 6.4  配置唤醒源... 41 6.5  加入PMIC驱动... 50 6.6  主函数逻辑实现... 58 6.7  运行测试... 60 6.8  未来开发计划... 61   attachment include chinese/english doc, s32ds codes with 2 zip package(remove the .7z), mcal codes.  

The label printer requires some means of regulating the flow of data to and from the system to which they are attached. The suspension and resumption of data flow is necessary in a variety of circumstances. The attached PPT introduces a simple and effective flow control method running upon lwIP stack.  

         随着近年来人们对日常出行品质的提高，电动自行车（包括共享类）市场得到了飞速发展，其功能日趋复杂智能。作为电控部分的“三大件”，电驱，主控和仪表也在不断升级迭代，其中电驱发展经历了最早期的直流有刷电机驱动到直流无刷方波驱动再到如今的 FOC 正弦波驱动，主控从以前附属在电驱或者仪表里的边缘化概念到如今独立出来的中心化，仪表则从普通的段式 LED 显示到如今尺寸越来越大功能越来越丰富的彩屏显示，而相对应的负责沟通互联“三大件”的通信总线也从传统的单总线到 TTL UART 到 RS485 再到如今逐渐展露头脚的 CAN 总线。对于电动自行车这种大众型消费市场来说，这些电控部分的升级换代给MCU 带来新的机遇的同时也对其性能，外设资源和价格带来了极大挑战。基于此， 针对三大件之一的仪表市场，NXP 开发了一套基于高性价比 LPC5506 系列 MCU 的 E-Bike 迈速表中低端显示屏方案。 系统框图： 主要特性： 4.5v~85v宽范围电压输入，支持24v，36v和48v锂电池组电源直接接入； 主控LPC5506支持CAN通信，8080 16bit/8bit LCD接口，且封装为LQFP 10*10mm，利于仪表小型化； 支持3.5寸320*480 16bit及以下尺寸的TFT LCD显示屏，预留I2C接口的电阻屏触摸控制芯片； 支持开源免费的ZLG AWTK GUI和LittleVgl GUI框架； 板载光敏传感器，可用于根据环境光自动调节LCD背光亮度； 板载六轴Motion Sensor（MPU6050），可用于转把方向检测，防盗检测和自行车摔倒检测等； 板载GPS和BLE模块，可用于定位，精确授时校准，行车轨迹离线存储或者与手机蓝牙通信； 板载4MB SPI Flash，用于图片和字体资源，GPS坐标轨迹存储和其他重要信息存储； 预留了USB Type-C电源供电端口和调试串口，方便工程师调试。 软件环境：        当前版本的软件代码工程有三份，一份为基于ZLG AWTK GUI的完整E-Bike迈速表工程，可显示车速仪表盘，里程，档位和电池电压等行车参数，也可以进入简单的功能设置界面浏览当前系统信息，且支持通过指定的CAN帧格式更新当前GUI界面的参数信息。一份为基于NXP GUIGuider图形化工具设计开发的LVGL版本E-Bike迈速表工程，分为3个子界面显示车速和骑行状态等详细信息。第三份为移植到本参考设计上的LVGL官方Demo例程，里面包含了配置好的EZH驱动库和LittleVgl基本的设备输入输出框架，用户可以基于此例程灵活开发定制自己的LVGL based其他GUI应用。        目前基于ZLG AWTK和LVGL GUI的E-Bike迈速表显示屏方案在经过优化之后对主控MCU的资源的占用以及GUI整体刷新性能如下表1，由于两个工程所使用的GUI素材和布局不一样，所以不要对两者的资源占用和性能参数做对比。他们都可以满足大部分客户的应用需求（>15fps）。如果将显示屏的分辨率降低到320*240及以下小尺寸的情况下，整个系统的资源占用会相应的减小，刷新性能也会得到更大的提升。 表1 方案资源占用及GUI刷新性能（分辨率320*480 16bit） Demo Code Flash RAM Refresh Rate AWTK GUI Version 202KB 61KB 22fps LVGL GUI Version 206KB 78KB 17fps 写在最后：        本参考设计的初衷是针对E-Bike中低端仪表显示屏市场提供一个高性价比的选择，同时也可以作为一个对于显示，CAN通信和小封装有类似需求的平台性的参考方案推广，比如电摩，带显示屏的便携式医疗设备和工业IoT设备等，希望此方案能给市场带来更好的用户体验和高性价比的选择。 注：由于代码工程超过25M，不能上传到该Community，如有需要请联系NXP销售或FAE索取。

Background:  ➢ IP protection is important for most customers, Kinetis, LPC54 series and i.MX RT have necessary security features that help us to win customers and markets. ➢ LPC55 series is a new generation of IoT MCU which is used for consumer and industrial market. LPC55 non-S parts are adopted by most customers due to its low-cost and easy-to-use features, but its secure features are different with S parts and is significantly simplified. ➢ LPC55 is designed for secured IoT application, so it’s supposed to hide the SWD/ISP ports after development work is finished. If the SWD/ISP ports are secured, they couldn’t be used any more. While for LPC54 & Kinetis MCU, mass erase command can be used to recover the MCU after the MCU is secured. ➢ However, Customers need the feature to secure the debugging/ISP ports, but they also need to recover them in some cases: - Reprogramming to update firmware - Investigate and analyze failed parts returned from end market - Rescue the MCU if it’s locked and stuck ➢ According to customers’ requirements, NXP support team raised the proposal to implement a solution which can be used to secure and recover the SWD/ISP ports with an IAP backdoor method. Solution: By Operating PFR region, LPC55 could switch between secure and recovery mode.   lpc5506_debug_isp_test_20220714: demonstrate how to operate this region to lock Debug Port then how to recovery it. The user interaction could be raised by UART or button;         2.hmac_test_20220714: demonstrate one full security flow,      ➢ This is a complete solution to secure & recovery debugging/ISP ports on LPC55, and it uses host machine challenge mechanism to implement security features: ▪ Challenge Host machine against unknown host probe; ▪ Generates dynamic seeds, so that the final encrypt information will be dynamically changed; ▪ The image hash value is device related, that avoids same encrypt info for different image/product; ➢ Customer also could clip the solution to simplify application complexity: ▪ Use UUID for device information only, no seed is needed; ▪ Host machine can use fixed keys instead of image hash values to do info encryption; ▪ Host machine can use UUID lookup table to find out verification key; Every device is programmed with dedicated verification key during production.  Demonstration: The attached demos could run at LPC55S06 EVK, and could easily migrate to other LPC55 series.

Demo Owner: Eduardo Montanez   Watch how Kinetis K Series and Kinetis L Series MCUs beat out the competition.     Features Latest Kinetis K2 microcontrollers running a CoreMark benchmark from EEMBC 4 different Microcontrollers are put to the test. Running all the same iteration benchmark with same capacity for all of the products Featured NXP Products K22F KL02 Links Kinetis MCUs|ARM® Cortex®-M Cores|NXP Kinetis L Series MCUs: Energy-Efficiency Benchmark Demo Kinetis L Series MCUs Energy Efficiency Benchmark - YouTube  

IEEE 1588协议简单理解        IEEE 1588 是一个精密时间协议 (PTP)，用于同步计算机网络中的时钟。 在局域网中，它能将时钟精确度控制在亚微秒范围内，使其适于测量和控制系统。 IEEE 1588 标准为时钟分配定义了一个主从式架构，由一个或多个网段及一个或多个时钟组成。 ​       TSN 网络中时间同步协议使用 IEEE 802.1AS 协议，它基于 IEEE 1588 协议进行精简和修改，也称为 gPTP 协议。 ​       IEEE 1588 协议简称精确时钟协议 PTP（Precision Timing Protocol），它的全称是“网络测量和控制系统的精密时钟同步协议标准”（IEEE 1588 Precision Clock Synchronization Protocol）。其工作的基本原理，是通过主从节点之间进行同步数据帧的发送，记录数据帧的发送时间和接收时间信息进行，并且将该时间信息添加到该数据帧中。从节点获取这些时间信息，并计算从节点本地时钟与主时钟的时间偏差和网络节点之间的传输延时，对本地时钟进行纠正，使之与主节点时钟同步。一个 PTP 网络只能存在一个主时钟。 ​ PTP 协议主要分为两大部分来实现时钟同步功能： ​ 1、建立同步体系： ​       协议使用最佳主时钟算法（Best Master Clock Algorithm，BMCA），通过选取主时钟，建立主从拓扑关系，进而在整个 PTP 网络中建立起同步体系。 ​ 2、同步本地时钟： ​       协议使用本地时钟同步算法（Local Clock Synchronization Algorithm，LCS），通过 PTP 数据报文在网络主从节点之间的交换，计算各从节点本地时钟与主时钟间的时间偏差，调整本地时钟，使之与主时钟同步。 IEEE 1588v1 ​       整个 PTP 网络内的时钟可按照其上 PTP 通信端口的数目来划分成普通时钟（Ordinary Clock，OC）与边界时钟（Boundary Clock，BC）：普通时钟只存在一个，而边界时钟则存在多个。一般在确定性不高的网络节点处使用边界时钟，例如交换机或者路由器一般用作边界时钟，如下图所示。在每个端口上，PTP 通信都是独立进行的。 1、边界时钟： ​      边界时钟上只允许存在一个从端口，与上级节点的主端口通信，将其本地时钟与级主端口进行同步。其余端口为主端口，与下游节点的从端口进行通信。边界时钟可以连接不同的网络协议。 ​ 2、同步体系建立流程： ​   （1）初始状态，各个节点端口会在指定的时间内侦听网络中的 Sync 数据帧； 若接收到 Sync 数据帧，节点端口将根据最佳主时钟算法决定端口状态。若没有收到 Sync 数据帧，该节点状态变更为 Pre_Master，并将自己假定为主时钟节点。此时节点端口状态表现为主时钟，但是并不发送 Sync 帧。 ​   （2）端口状态在一定时间内保持 Pre_Master： 若在端口指定时间内接收到 Sync 数据帧，则该端口状态由最佳主时钟算法决定。 若判定端口为主时钟，则将周期性地发送 Sync 帧；若判定为从时钟，则接受 Sync 帧，并计算偏差，纠正本地时钟。 ​ 若在该时间段内端口没有收到 Sync 数据帧，则将状态变更为主时钟，并且开始定时发送 Sync 数据帧。 ​   （3）主时钟和从时钟的状态随着时钟性能与运行状态的变化而变化。下图展示了 BMCA 中状态转移。 3、时间同步建立流程： ​ 如下图PTP同步原理         如图所示，Master为网路中的同步时钟源，可以认为其与UTC或者GPS时无限接近。Slave为网络中需要被同步设备。假设从Master到Slave的路径符合对称路径，那么路径上的延时我们设Delay，然后设备Master和设备Slave之间待同步的时间差值为Offset，即Slave比Master在同一时刻慢Offset。         Slave设备根据算出的Offset即可以进行本地时钟校准。但是1588V1协议依赖于链路的对称性，即Master到Slave与Slave到Master时延一致，这在实际网络状况下很难满足，故需要额外的不对称算法进行链路延时差计算和补偿校准。   IEEE 1588v2 ​IEEE1588V2在IEEE1588V1版本上做了改进和扩展。主要包括： ​ 1.新增点到点路径延时测量的独立消息模式。 端口 A 与端口 B 间的路径延迟时间 Delay 为： ​        在 PTPv1 中，平均路径延迟测量时通过 Sync 帧与 Delay_Req 帧配合使用的，但是在 PTPv2 中却不需要 Sync 帧的参与，仅通过 PDelay_Req 数据帧系列来进行测量。这是一个独立的延迟测量过程，不依赖 Sync 帧和同步体系建立的参与，使得测量精度有所提高，并且可以经过多次测量求得平均值得到更为准确的路径延迟。另一方面，如果网络中的同步体系发生改变，这时不需要重新计算该节点间的路径延迟，直接使用之前已测得的延迟数据，大大增强了协议执行的效率，使得协议更为方便灵活。在PTPv2 中，利用 PDelay_req 数据帧系列已成为主要的测量路径延迟方法。 ​ 2、新增透明时钟模型 ​        在 PTPv1 中，网络中间节点均采用边界时钟模型。与网络中唯一的主时钟，即一个普通时钟连接的边界时钟，其上唯一的从端口接收主节点发送的同步数据帧，与主时钟实现同步，其余的主端口和与之相连的其他边界时钟发送同步数据帧，最后同步到网络边缘的普通时钟，这样便实现了整个网络的时间同步。这种方法虽然可行，但是由于这种方式是逐级同步，所以距离主时钟越远的节点，同步精度越低。 ​        当网络中的一些节点不需要进行时钟同步或者不具备同步功能时，便可采用透明时钟模型。透明时钟不像 BC/OC 模式那样，需要每个节点都与主时钟进行同步，它的端口只对协议数据帧进行转发，并将计算出的数据帧滞留时间添加在校正域中。这种方式将 PTP 数据帧的处理变得更为简单，降低了网络中 PTP 协议的实施难度，同时提高了各从节点的同步精度。 ​ 透明时钟有模型两种：端对端透明时钟，和点对点透明时钟。 ​     （1）端对端（E2E）透明时钟 ​ E2E 透明时钟对网络中普通数据帧不做任何处理，仅进行转达让其正常通过。但是对于 PTP 事件数据帧，则将他们从接收端口到发送端口间的驻留延迟时间累加到数据帧中的修正域，用以弥补 PTP 数据帧在经过其自身所带来的延迟误差。 ​     （2）点对点（P2P）透明时钟 ​ 点对点（P2P）透明时钟只转发特定的 PTP 报文，包括 Sync 帧、Follo_Up 帧和Announce 帧等。并且会采用 Pdelay_Req 数据帧系列计算每个端口与所连接的端口间的路径延迟时间，再与端口间延迟时间合并添加到时间修正域，来补偿数据帧从源端口到点对点透明时钟出端口的时间延迟。 ​ 3、增加单步时钟模型 ​        单步时钟模型解决了 Follow_Up 帧与 Sync 帧匹配问题。PTP 协议基本的同步过程采用双步模式，即主时钟节点发送 Sync 帧，和带有 Sync 帧发送时间的Follow_Up帧。这种方式虽然能提高 Sync 帧时间戳标记的精度，提高同步效果，但是在网络负载较大的情况下，数据帧很有可能发生丢失或者阻塞，造成两种数据帧的匹配出现差错。 ​        在 PTP 数据帧中设置一个标志，来使用单步模式，将 Sync 帧的发送时间与数据帧中的时间标签的差值作为传输延迟，并将其累加到修正域中。这样主时钟便通过单独的 Sync 帧而不需要 Follow_Up 进行时间的同步校准工作。 ​        单步模式可以减少网络流量，提高网络负载较大时同步的可靠性。单步模式需要额外的辅助硬件，来帮助计算时间修正值并将其累加到校正域中，这对网络的实时性有比较高的要求。 BMCA ​        BMCA，即最佳主时钟算法，它选择网络中性能最佳的时钟作为主时钟，并以 此建立网络拓扑，生成同步体系，进而实现时钟同步功能。 ​        最佳主时钟的选取是通过Announce帧在网络中各节点的传输，比较各个节点上的时钟属性（比如是否将时钟指定为主或者从时钟），用于标识精度的时钟等级，以及用于标识时钟源类型的时钟类型（比如铷钟、铯钟等），还有表示时钟偏移、方差等的时钟特性、时钟地址以及时钟端口号等特征来选择最佳主时钟，当其他时钟特征都一样是，协议会将端口号最小的节点时钟作为主时钟。IEEE 1588协议会以主时钟节点作为根节点形成树形拓扑结构，并且为避免生成回路，那些竞争失败的节点端口，协议将他们定义为被动或者禁用状态。

FAST BOOT FOR lx2160 IN adas •Objective 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. •Deliverables Demo based on LX2160ARDB board. Reference codes and patches. Guide for Fast boot document. Fast boot 广泛用于嵌入式设备，现以lx2160ardb板为例进行相关探索。 启动流程： 优化思路： 1.适当提高FSPI时钟速率 diff --git a/lx2160asi/flexspi_divisor_32.rcw b/lx2160asi/flexspi_divisor_32.rcw index 422139c..0f8d5c9 100644 --- a/lx2160asi/flexspi_divisor_32.rcw +++ b/lx2160asi/flexspi_divisor_32.rcw @@ -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 */ .pbi -write 0x1e00900,0x00000013 +write 0x1e00900,0x0f .end ​ 2.关键路径优化 固化spd参数 固化ddrc参数 BL33 裁剪 详细patch和测试结果参考附件。

This doc explain our Linux BSP driver and how to custom them. Contests as follows: include bsp30/32 目录 1 S32G Linux文档说明 ................................................. 2 2 创建S32G RDB2 Linux板级开发包编译环境 .............. 2 2.1 创建yocto编译环境: ................................................ 2 2.2 独立编译 ................................................................. 8 3 Device Tree ............................................................. 11 3.1 恩智浦的device Tree结构 ..................................... 11 3.2 device Tree的由来(no updates) ............................ 13 3.3 device Tree的基础与语法(no updates) ................. 15 3.4 device Tree的代码分析(no updates) .................... 37 4 恩智浦S32G BSP 包文件目录结构 .......................... 70 5 恩智浦Linux BSP的编译(no updates) ...................... 72 5.1 需要编译哪些文件 ................................................ 72 5.2 如何编译这些文件 ................................................ 73 5.3 如何链接为目标文件及链接顺序 ........................... 74 5.4 kernel Kconfig ...................................................... 76 6 恩智浦BSP的内核初始化过程(no updates) .............. 76 6.1 初始化的汇编代码 ................................................ 78 6.2 初始化的C代码 ..................................................... 82 6.3 init_machine ......................................................... 94 7 恩智浦BSP的内核定制 ............................................. 97 7.1 DDR修改 .............................................................. 98 7.2 IO管脚配置与Pinctrl驱动 .................................... 100 7.3 新板bringup ........................................................ 121 7.4 更改调试串口 ...................................................... 125 7.5 uSDHC设备定制(eMMC flash,SDcard, SDIOcard) 129 7.6 GPIO驱动 ........................................................... 137 7.7 GPIO_Key 驱动定制 .......................................... 145 7.8 GPIO_LED 驱动定制 ......................................... 150 7.9 芯片内thermal驱动 ............................................. 155 7.10 CAN接口驱动 ..................................................... 157 7.11 I2C及外设驱动 .................................................... 162 7.12 SPI与SPI Slave驱动 ........................................... 183 7.13 Watchdog test. ................................................... 190 7.14 汽车级以太网驱动定制 (未验证) (未完成) ........... 191