基于双核Cortex-A7 SoC的工业网关产品设计与量产

一个基于SSD20X Cortex-A7 双核的软硬件设计, 适用于网关类型产品, 双网卡. 用于作为原来的IMX6ULL版本的补充,一个是商业级,一个是工业级。

最开始使用的是buildroot来构建Rootfs,但是鉴于可定制性,以及功能全面性, 以及我们的Flash将会使用256MB或者512MB,容量足够,因此换成了Yocto

考虑到Rootfs需要升级, 而且有些应用场景是没有外网的离线环境, 因此除了app的升级外, 还加入了整个Rootfs离线升级的功能.以备在需要的时候可以对整个系统升级.

这个专门用于升级的Rootfs放到了单独的一个分区, 占用的size很小(<5MB).

系统启动的时候可以根据key以及文件情况,自动判断并进入到Rootfs upgrade模式中,类似于Android系统中的fastboot.

为了保证内核在有Bug的情况下可以离线升级, 对kernel也做了升级功能.同样的, 需要有对应的key才能进行升级,而且升级文件也进行了加密处理.以防传输过程中的被盗用/反编译等风险.

因为是双网卡,默认两个网卡都会用同一个Mac地址,这个会导致在同一个网络内Mac地址重复的问题. 为了解决这个问题,后面想到的是将芯片的UUID作为Mac地址使用, 这样可以保证唯一而且不重复. 这边修改了Uboot与Kernel代码, 从而让uboot里面也使用UUID作为Mac地址.

BSP中有一些ko模块,例如ALSA这边就是没有源码的,这种BSP的做法让人很不舒服, 与Linux内核的常规开源做法格格不入, 而且也不便于调试. 这个可能因为一些IP需要做保护,不暴露寄存器的原因导致的.

在整体上,硬件上对于EMC/EMI均进行了考研与相关设计,以及器件的处理, 如基本的TVS/PTC等防护.

走线layout部分对等长,差分,阻抗匹配均按照要求进行了处理, 所有功能均正常.

但是在第一版的时候出现了在多次快速上下电的时候可能会无法正常启动的情况, 分析来看是放电不完全导致, 最终采用了专门的芯片来处理,保证电压到了足够的量且再延时一段时间后再释放Reset Pin. 这样处理后,没有再出现此问题.

同样的模块设计, 发现某些UART组确无法正常工作, 调查后发现某些组的GPIO没有内部上拉,这个设计相当的坑,因为默认基本上所有GPIO都有的,如果不是特别注意,根本发现不了. 我们在第一版出现这个问题后, 调查了很久,一直找不到不正常工作的原因. 后面用示波器/逻辑分析仪逐步分析才发现是这个原因. 在第二版的时候直接添加了上拉电阻.

这个问题是在Uboot中特别容易出现, 最开始我们设计了从U盘升级,从而加快开发,但是有的时候USB Host会无法probe成功, 这个看起来更像是Uboot中USB Host没有处理好的缘故. 而且不同的板子还不相同. 最后额外支持了从TF卡升级,从而保证总有一种方式可以升级成功.

这几年因为一些芯片和模块经常出现短缺无货的状态, 因此在软件层与硬件层都做了多种模块可以兼容的设计,从而尽可能的应对硬件模块的短缺无货. 测试下来几种引脚兼容的模块均工作良好, 在软件层上,根据不同的USB的vid和pid进行对应的module install,也工作良好.

因为不同的系列需要的4G模块并不相同, 例如有的需要4G+GPS功能,有的只需要支持物联网卡的4G Cat.1, 因此硬件设计上使用了miniPCI-E, 从而兼容不同的4G模块. 对于4G模块,还需要考虑不同的模块供电电压稍有不同, 有的是3.8V最低,最高4.2V,有的则可以到更低,但是他们对电流尤其是电源响应要求均较高, 尤其是在恶劣环境下射频工作的时候, 这边需要特别注意, 否则容易出现较大电压跌落而出现工作异常.

选用了公版的透明外壳, 效果还可以:

Shell

在某些环境下, 金属屏蔽外壳是必须的,因此还设计了一款金属外壳:

Iron Shell

对于量产,没有自动化测试,以及方便快捷的烧写是不行的, 会导致生产效率太低. 因此在Uboot中添加了从U盘或者TF卡加载密钥和升级文件功能,对于生产烧写非常方便。

设计了一块PCB, 配合树莓派,同时写了一个带webserver的自动化测试程序用来做自动化测试与烧录. 使用了Python来写, 效果不错, 而且配合IPV6或者转发服务器也方便远程访问与查看.

下面这个新设计的配合树莓派以及其他模块一起使用用来做成品测试和自动化烧录等功能的板子:

Testing ext board

测试运行效果如下,连接了树莓派,在树莓派中使用python + web的方式来访问和控制:

Using Testing board

除了上面的方式外,还支持使用U盘升级整个系统, 包括Rootfs + BSP. 而Rootfs与app也完成了CI自动化编译生成升级包等操作, 尽可能的减少人工操作, CI完成后还会发送IM消息,这样协作者就可以及时收到更新消息.

CI notification

最开始使用了Github, 但是免费的Action时长较短, 国外的还有Gitlab,同样免费用户runner的CPU时长较短. 国内的有阿里云的AOne, 以及腾讯收购了的Coding,整体还不错, 对比而言,阿里提供的免费的时长最长.但是对Rust等编译的支持很差, 尤其是action的cache支持.这点上还是Github做的最好.

国内的CI还有一个问题,那就是npm的package有些在github上面, 要访问需要一些特殊的处理, 这个经常导致CI编译不过,但是使用Github就没有这些问题了.

在多个行业均有投入应用,稳定性没有问题:

Production in shield