S32G2 BootLoader

[Logan-Zhang]

如果采用官方OTA的方案，UDS刷写协议是在APP中实现的。但如果APP此时出现问题无法正常运行（即便采用ABswap功能，两个分区都可能存在这种情况），那就需要拆壳采用串行或debug方式来刷写。这种情况应该怎么避免？

我们目前想到的方案是在M核上做一个BootLoader，能够实现基于CAN或以太网的刷写。但不确定这种方案是否合理？是否有其他更合适的方案？

如果我们在M核上再做一个BootLoader的方案是合理的，那是基于官方的BootLoader来改？还是在此之上实现一个M核的APP软件来作为BootLoader？这样就形成了两级BootLoader。你们是否推荐直接基于官方BootLoader来去做修改？因为这个BootLoader的文件是很分散的，不便于代码的版本管理和维护。

期待你们的答复。

[chenyin_h]

您好, @Logan-Zhang 

很高兴FOTA的实现对您有所帮助，如您所见，FOTA release的时间大概是三年前，因此其代码基于比较早的RTD/BSP, 如果您安装文档中提到的早期版本的基础软件，并且按照文档来测试的话, 应该是没有问题的，因为这些demo 在发布之前都经过了相应的测试。

但是据我所知，这个demo并没有更新的版本，如果您想基于目前比较新的基础代码（RTD/BSP）来实现这个demo的功能的话， 您可能需要仔细研究相应的代码，然后做必要的移植和开发工作可能才能实现目标，这个工作量按照经验来讲可能还是比较大的，建议您可以根据情况具体考虑实现的方案。

BR

Chenyin

[chenyin_h]

您好，感谢您的回复

1. 目前有两个官方的DEMO和OTA有关

一个是您提到的这个FOTA（https://www.nxp.com/applications/automotive/software-defined-vehicle/firmware-over-the-air-fota:FOTA...

另一个来自于GoldVIP

看起来您目前参考的是FOTA的这个DEMO。

2. 就具体实现方法而言，大部分客户都会自己根据情况设计OTA的实现，实现方法很多都有差异，我们目前只是提供了两种参考实现（您看到的FOTA，以及GoldVIP中的实现），您除了参考了FOTA，不知道是否参考过更新一些的GoldVIP中的实现？从我个人经验而言，bootloader中实现和APP中实现都是可行的，而从我们在线技术支持的角度，我们主要支持具体的技术问题，但很难就方案的选择直接提出建议，非常抱歉给您带来的不便，一般而言我们都是提供以上参考的demo，具体的方案选择还是需要客户从安全，易用等角度斟酌。

就bootloader而言，除了您提到的Platform_Software_integrations_S32G2_2023_06（这个版本的软件已经不再更新），在GoldVIP的各个版本中（持续更新）也会提供参考的bootloader实现，这些实现客户都是可以修改的，而且很多客户实际上也是根据自己需求修改后使用的，这个没有问题的。

BR

Chenyin

[Logan-Zhang]

Hi, Chenyin

感谢您的支持！根据您的提示，我下载了GOLDVIP的示例，我之前提到的BootLoader，应该和GOLDVIP中的BootLoader是一致的。

对于您提到的FOTA的demo我也找到了，这个demo包含了DOIP、UDS、TCPIP、AB SWAP等功能，几乎满足了BootLoader的所有要求。我打算基于此来去做我们的BootLoader。但这个demo里面的“rtd_app_fota”这个软件编译不通过，产生了很多报错，很多文件找不到。对此您有什么建议吗？这个FOTA demo的安装包为“SW32G2_FOTA_App_V1_D2109”。

按照FOTA demo文档的说明，这个demo已经包含了必要的文件，应该是可以直接编译通过的。我打开S32DS配置更新代码后，很多文件版本不一致，同样编译不通过。但如果按照文档中提到的软件包版本重新安装，这些都是旧的软件，我担心会出现其他问题。您是否有其他文档资料可以提供？

[chenyin_h]

您好，Logan-Zhang

感谢您的咨询

1. 请问您提到的官方OTA的方案具体指的是哪个？FOTA或者GoldVIP？

2. 对于OTA的实现，不同的客户有不同的实现方式，您可以自己来设计，也可以参考以上两个我们官方的demo来具体实现。

BR

Chenyin

[Logan-Zhang]

您好，chenyin：

对于您的问题：

1、指的是OTA的一个文档，名称为《AN12978 S32G2 Support For Firmware Over The Air Updates》。这个文档提到了AP里面OTA的概念，但是这些都是在A核或M核的APP来实现的。

2、基于上面提到的在APP实现UDS刷写的功能。一旦客户APP都失效了，那就可能需要拆壳来刷写。但控制器一旦装车后是无法拆壳的，甚至控制器拆壳后都会报废。我们目前在S32K3平台上面有一个固化在flash的UDS BootLoader，如果APP失效，都可以通过这个BootLoader来重新刷写。所以我们也想在S32G2上面保留同样的一个BootLoader。但我们也不确定我们这种做法是否合理，因为我们还是基于单片机的思维来考虑这个问题，不确定这种想法是否适合S32G2。

如果我们这种想法是合理的，那我们是否可以直接基于官方的一个BootLoader demo（安装包名称为Platform_Software_integrations_S32G2_2023_06）来去改？这个demo安装完成后，代码很分散，不便于我们整体维护，也不便于修改代码，所以我们在想是不是这个demo本来就不允许我们修改？仅是来实现一个A核和M核APP的引导？   也有人提出了另一个建议，让我们基于这个官方BootLoader，再做一个APP专门用于刷写，那这个APP就可以看做customer BootLoader。然后这个customer BootLoader来负责引导M核和A核，或者仅用于刷写。

所以对于这两种方案，您有什么建议？或者基于S32G2的UDSBootLoader/DOIP BootLoader，通常是一个什么方案？

[Logan-Zhang]

官方BootLoader的安装包名称是Platform_Software_Integration_S32G2_2023_06