完善资料让更多小伙伴认识你，还能领取20积分哦， 立即完善>
3天内不再提示
|
这个通用boot基于我们的应用有点问题 比如： flash空间有限，加入组件过多非常可能导致空间不够。是否可以增加设置，比如只划分3个区，bootloader一个区，其余两个区都是download区，交替使用，bootloader根据判断标准，比如版本+其他来决定从哪个区启动。 这样空间利用率更高，因为factory版本实际在很多场合其实没机会去手动操作来恢复。特别是工业场合，就是一个鸡肋。 这样的升级逻辑可能存在问题，如果download下去的是一个有问题的版本，但是版本号的确比app区的高，那boot不管这些，还是把download区覆盖app，然后启动失败之后，只能恢复出厂设置，但咱们这是IOT产品啊，现场哪里有人啊。 所谓ota一定要保障即时有一个版本出问题，还是能启动另一个版本，而不是只能人工操作的模式。OTA肯定要保障完全安全的升级，即使失败还能自动回退先前的版本。有兄弟可能会质疑软件发布测试验证流程之类，这块，只能说，道理都对。 是否能提供通用bootloader的代码，我们在此基础上做自定义的修改呢？ 
0
|
|
相关推荐
5个回答
|
|
|
download下去的是一个有问题的版本
这个应该在开发和测试阶段发现并避免，正式发布时，也分批分时间升级，避免全军覆没。 靠程序自己判断是很不靠谱的作法， 都不能启动，版本是怎么通过审核并发出去的？ 如果能启动，如何判定这份不正常？或部分正常？ 恢复出厂设置 有工厂分区，在FLASH足够的前提下，可以从这个分区来恢复。 但看第1条，“flash空间有限”，只能取舍了。 |
|
|
|
|
|
您这个说法没有任何问题，但是实际是不是也需要考虑这样的情况，或者说，bootloader是否可以做的更灵活些，可以选择模式，比如download区和app区是对等的，即两个区都可以download，根据版本不同，选择不同区域来下载，启动的时候，如您所说增加判断来选择从哪个区启动。这样更安全不是吗？
|
|
|
|
|
|
工厂模式需要按键操作，我们的应用场景不太容易做到这一步，真成搬砖，对于我们的产品，只能是努力争取客户谅解，直接替换了。而且客户的评价会出问题。
|
|
|
|
|
|
anyway，您说的道理没问题，但是否可以考虑下我的建议呢？或者是否能有部分开放的源码，可以做二次开发？当然，我们也可以自己写自己的bootloader，这不是人力有限，希望快速解决问题嘛
|
|
|
|
|
|
这是常用的AB区模式，也可以的。
相对的： 新固件将不能被压缩存储，需要1:1 没有地址映射功能的话，需要链接2份固件，并每次升级检查当前在升级A区还是B区。 您可以用论坛大神写的qboot代码改一份。 |
|
|
|
|
你正在撰写答案
如果你是对答案或其他答案精选点评或询问，请使用“评论”功能。
802 浏览 0 评论
5053 浏览 0 评论
如何使用python调起UDE STK5.2进行下载自动化下载呢？
2650 浏览 0 评论
开启全新AI时代 智能嵌入式系统快速发展——“第六届国产嵌入式操作系统技术与产业发展论坛”圆满结束
2990 浏览 0 评论
获奖公布！2024 RT-Thread全球巡回线下培训火热来袭！报名提问有奖！
32051 浏览 11 评论
73196 浏览 21 评论
/6 
关注我们的微信
下载发烧友APP
电子发烧友观察
版权所有 © 湖南华秋数字科技有限公司
电子发烧友 （电路图） 湘公网安备 43011202000918 号 电信与信息服务业务经营许可证：合字B2-20210191
工商网监
湘ICP备2023018690号
1014
评论
淘帖
366
