全志在线开发者论坛

mengxp

https://open.allwinnertech.com/#/faq/0/show?faqId=2086&menuID=17
这个FAQ中没有提到具体修改了哪个函数哪个语句，请问可以详细说明一下吗？

mengxp

@zhangwei 在 T113-S3 Longan SDK 调试AP6212问题求助中说：

wiphy_register

遇到一模一样的问题，应该还没到加载博通固件的环节，在调用wiphy_register就崩溃了

mengxp

@mengxp 看了下r328上使用的v3代码，关键字alloc，我发现有

ss_rng_start buf 内存泄露 (kmalloc without kfree)

目前就发现这一个

mengxp

写了个afalg测试 TRNG 接口，发现有内存泄露，肉眼可见的内存泄露。应该是发生在内核层面的。

我的芯片是 R328-S3，Tina 3.5 SDK
测试代码如下，原厂大神来看看吧。

运行前free一下，然后等跑了几千轮几万轮后再free一下，少了很多MB内存。
用top看一下，发现测试程序没有占用多少内存，所以基本可以石锤是内核层面内存泄露。

我这边也慢慢分析下 sunxi-ss 模块哪里有泄露。

#include <errno.h>
#include <stdint.h>
#include <sys/uio.h>
#include <sys/syscall.h>
#include <sys/socket.h>
#include <linux/if_alg.h>
#include <stddef.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>

#ifndef SOL_ALG
#define SOL_ALG 279
#endif

int os_get_random(unsigned char *buf, size_t len)
{
    int trng_tfmfd = 0;
    int trng_opfd = 0;
    int retval = -1;

    do {
        struct sockaddr_alg sa = {
          .salg_family = AF_ALG,
          .salg_type = "rng",
          .salg_name = "trng"
        };
        int ret;

        trng_tfmfd = socket(AF_ALG, SOCK_SEQPACKET, 0);
        if (trng_tfmfd < 0)
        {
            printf("socket failed\n");
            break;
        }

        ret = bind(trng_tfmfd, (struct sockaddr *)&sa, sizeof(sa));
        if (ret)
        {
            printf("bind failed\n");
            break;
        }

        trng_opfd = accept(trng_tfmfd, NULL, 0);
        if (trng_opfd < 0)
        {
            printf("accept failed\n");
            break;
        }

        retval = 0;
        while (len > 0)
        {
            ret = read(trng_opfd, buf, len);
            if (ret < 0)
            {
                retval = -1;
                break;
            }
            buf += ret;
            len -= ret;
        }

    } while (0);

    if (trng_opfd > 0)
        close(trng_opfd);

    if (trng_tfmfd > 0)
        close(trng_tfmfd);

    return retval;
}

#if 1
unsigned char trng_buf[65536];

void Test_TRNG(void)
{
    int i = 0;

    while(1)
    {
        os_get_random(trng_buf, 512);

        if(!(i++ % 1000))
            printf("random %d\n", i);
    }
}

int main(void)
{
    Test_TRNG();
    return 0;
}
#endif

mengxp

@jacky502 你做板子是完全不考虑差分走线的阻抗、信号完整性、串扰。
虽然说USB2.0要求不高，但是为了确定是不是完整性问题。我建议你做如下步骤

在芯片USB引脚就近切断走线，使用等长的飞线连接USB座子(不是板子上的USB座，是额外的)
然后插优盘测试。
如果你要用板子上的USB座测试，那么USB座的信号线也要切断。也就是放弃你画的走线。

总之这种情况大概率是信号完整性问题。

你的板子是双层板，在设计时建议：
1.如果阻抗值无法满足，起码要满足阻抗连续，双层板的做法就是保证信号线的背面有连续的地平面，且沿信号线打地孔。如果不知道怎么做，建议拆个华为的光猫看一下你就懂了。华为的低成本光猫都是双层板，他是如何做DRAM走线、2.5G光差分信号、1G网口信号、USB信号，都是值得学习的。
2.少过孔，做等长。虽然你这个走线过孔其实不多，但问题也恰恰最有可能出在孔上，你要知道现在的快板厂，过孔质量其实很渣，这也是为什么有些板厂提出四线低阻这个东西，虽然是噱头吧，但是也是有道理的，起码他可以保证自己的过孔有实力。
3.避免串扰，高速信号远离其他信号线。
4.供电串扰问题，加磁珠，退耦电容。

mengxp

@yteraa 加密还是得用 SSK

mengxp

分析到了。上下电时序可能有异常，破坏了efuse中rotpk的某些比特。

正确的rotpk
74e61bc6f59b1382a29019xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

芯片中的rotpk
74e61bc6fd9b1382a39019xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

果然efuse供电引脚需要改成按需上电。

mengxp

@whycan 哇，那就离谱，看来全志的I2S接口很拉胯啊

mengxp

@musich
我今天用IDA撸完了，已经掌握了相关寄存器和SRAM中的几个调试数据。
启动失败进FEL读一下就可以了。
不得不说全志的SBROM开发人员还是有两把刷子。

mengxp

@ubuntu 在 R11的I2S没有MCLK引脚，如果要驱动声卡，应该怎么处理呢？可以用一个24.576MHz有源晶振代替吗？中说：

，播放音乐鸦雀无声。

等晕哥试试？

mengxp

我小批量试产了一些R328做的小产品，发现在烧录securebit之后有概率无法启动，不知道是什么原因。有的时候还遇到过正常使用用着用着就无法启动了。

我想分析启动失败的原因，由于是SecureBoot，我逆向了SBROM的相关代码，发现启动时会写入寄存器 30000D0，好像是阶段指示器，请问这个寄存器写入的数据，可否公开一下？我不想逆了，BROM_CONFIG是未公开的，代码好复杂。

mengxp

@huangkun 什么车机方便说下嘛，想搞研究

mengxp

@ubuntu 应该可以，那个时钟不是同步数据用的，就好比你wifi芯片外挂24M晶振或者37.4M晶振。你看下你对接芯片的datasheet 和设计指南。

mengxp

我焯我焯。我参考了 https://support.xilinx.com/s/article/65240 上面说的，他说的上下电时序会影响 efuse 完整性！！！看来得改设计。。LDO是省不了了。

mengxp

求原厂大佬们回复

mengxp

正在试产一些样机，全志R328芯片。
烧录了 secure bit 之后，有小概率无法引导，引导失败，现象就是进入到了 FEL。（此时还没有烧录 ROTPK）

排除主板问题，焊接问题。因为FEL烧录镜像是没问题的，整个主板和CPU是能够正常工作的。只是无法引导，此时 normal image 和 secure image 都不能引导。感觉就是芯片莫名其妙报废掉了。

大概5块板子有1块就出现一次这种问题。换芯片重新烧录可以解决这个问题。感觉不是板子的问题。

如果 boot 失败了，会有什么日志或者寄存器状态可以帮助调试吗？

是否有可能是上电时序造成的？我现在EFUSE供电是和PLL LDO 1.8V绑定在一起的。有关系吗？我看设计指南上说EFUSE应该最晚上电。

mengxp

@xiaowenge 在 T113跟D1s应该怎么选？中说：

T113

可能有些涉及到硬件加速之类的开源项目会使用arm neon加速，riscv出的比较晚可能不受支持，具体你使用哪些开源库可以查询下。

mengxp

@yangzhenjiang SD卡引导。或者，重做个板子吧。。。

mengxp

@yangzhenjiang 有usb烧录就没必要用jtag了吧。

mengxp

问题解决了。

我今天看到了 v833 的 Tina_Linux_Secure_Development_Guide.pdf 文档，里面有 TA 使用 SSK 加密的案例，查看了tina相关的代码，有一个sign.py，看了下，确认了加密引擎确实是使用原始SSK加密的，没有做什么黑盒变换。

那特么为什么我自己写的bootloader在调用CE使用ssk加密的结果异常呢？

想来optee肯定有相关的接口，找了下也就是
#define TEESMC_SSK_ENCRYPT 0
#define TEESMC_SSK_DECRYPT 3

由于optee是闭源的，只能拿IDA逆了一下看他是怎么做的。
发现了一个奇怪的事情，既然CE是使用SSK作为key，那代码里为什么要申请一个 256 字节的keyBuf呢？

然后我试着在我的bootloader里面，给 task desc 的 key 指向了一个 256 字节的缓冲，果然OK了！！！

mengxp

@xiaowenge 是我想保护kernel不被读出并反编译，同时受保护的ssk密钥也无法读出，防硬件抄板拷贝。我现在只是不明白，ssk密钥在被硬件ce引擎作为aes密钥加解密时，是不是经过了某种处理？

mengxp

没有人回复下吗，求原厂大神解释一下啊。。。我现在想用SSK作为密钥加密kernel镜像，那么我量产时如何不依赖硬件，在主机上生成kernel镜像啊。

mengxp

@yuzukitsuru 是，但是还得是读卡器操作啊，不能usb刷机

mengxp

编译dump固件然后用 phoenixsuit 刷一下，能dump到pc
参考小文哥
https://blog.csdn.net/weixin_43094346/article/details/83854695
dump的固件不是完整的，不能用于刷机。仅供参考。

拆eMMC上编程器可以读出所有数据，但也不能用于刷机。

mengxp

螃蟹wifi 做AP就算了，稳定性很差。你要是苹果的手机可以试试。我这有测试代码。
https://blog.csdn.net/MengXP/article/details/122736176?spm=1001.2014.3001.5501

mengxp

X32KOUT，那个信号很弱，只能给soc，不可以在飞出来很远给wifi。
可以用有源晶振。

mengxp

@yuzukitsuru 是啊死贵。只能找一些冷门的型号外加那种山寨版用用，便宜一些。但是人家贵是真的有道理，他芯片和驱动架构做的确实好。。。

mengxp

@mangogeek 博通稳的一逼，拿我那个代码测一下立见高下。

mengxp

@bedrock 做STA当个普通网卡是没问题，AP就别想了，不稳定。

mengxp

补充测试代码
https://blog.csdn.net/MengXP/article/details/122736176?spm=1001.2014.3001.5501

mengxp

螃蟹官方驱动有问题，在AP模式和iphone通讯有概率卡死系统，我找了一个模组厂家的fae，联系了原厂，但好像他们也不愿意修，很拉稀。后来我换正基wifi模块了，山寨版的ap6330也不贵，再也不会用什么螃蟹的垃圾。详细的bug和测试我发在网上了。https://blog.csdn.net/MengXP/article/details/122736176

mengxp

R328如何使用寄存器判断是R328-S2 或 R328-S3？我看fes中好像是判断了SID 3006200位置也就是 CHIPID 寄存器的第一个字节的低8位？我手上的R328-S3这个字节是A3，但是R328-S2这个字节是00？

请问如何通过CHIPID或者其他手段来判断当前芯片是R328S2 R328S3吗？我是裸机编程的。

mengxp

有人研究过使用crypto engine 使用SSK做 AES 加密吗？
我测试写入SSK "1234567890ABCDEF"，然后用这个SSK作为KEY加密一个消息
再使用输入key "1234567890ABCDEF"，加密同样一个消息
两个结果不一样？why？

其中输入key的测试是没有问题的，使用标准 test vector测试过，结果没有问题

难道 CE 在使用SSK加密前对key做了某种黑盒变换吗？

mengxp

已初步确定是螃蟹的AP模式逻辑问题，并非死锁。

测试环境
1.rtl8723ds (AP) <-----> iphone (STA)

触发条件
1.作为AP模式
2.正在发送数据
3.对方STA进入SLEEP模式，有概率触发该bug。

问题描述
1.hal\rtl8723d\sdio\rtl8723ds_xmit.c 中 xmit_xmitframes 函数
#ifdef CONFIG_AP_MODE
if (MLME_IS_AP(padapter) || MLME_IS_MESH(padapter)) {
if ((pxmitframe->attrib.psta->state & WIFI_SLEEP_STATE) &&
(pxmitframe->attrib.triggered == 0)) {
RTW_INFO("%s: one not triggered pkt in queue when this STA sleep, break and goto next sta\n", func);
break;
}
}
#endif

这段代码意图其实是符合 80211 中的传统省电模式 (Legacy Power Save)

传统省电模式 (Legacy Power Save)
假设某个时间STA进入sleep，它通过发送数据帧或null-date帧来告诉AP我进入省电了
AP收到这个帧后就不发数据帧给处于省电模式下的STA了。
STA会在下一个 DITM period wake up，并收到AP的beacon
在beacon 中DTIM 信息元素会告诉 STA，你sleep的时候有发你的数据，我替你存下了，快来取

但实际工作的时候不知道为什么驱动会反复的触发发送信号量，然后反复的进入这个流程，导致 RTWHALXT 线程占满CPU。
而且影响到了正常的收发逻辑。

暂时解决方案
注释掉上述 break; 语句，逻辑变更为，即使 STA 进入休眠仍然发送，STA收不到就收不到，该帧就算丢弃了。
实验发现也并没有造成多大的通讯延迟影响。

后续解决方案
联系模块fae尝试解决。但我不认为模块fae方面有能力解决这个问题。(我是普通用户不是VIP)

mengxp

目前在r328平台上使用rtl8723ds高并发流量时内核死锁
具体表现是 top 监控到 RTWHALXT 内核线程占用 CPU 50% (r328其中一个核心)
随后系统死掉，shell会弹出提示
[ 274.772512] INFO: rcu_sched self-detected stall on CPU
[ 274.778301] 1-...: (1 GPs behind) idle=6cb/140000000000001/0 softirq=2804/2805 fqs=7499
[ 274.787477] (t=15000 jiffies g=1214 c=1213 q=179)
[ 295.912599] INFO: rcu_sched detected expedited stalls on CPUs/tasks: { 1-... } 15329 jiffies s: 1 root: 0x2/.
[ 295.923762] blocking rcu_node structures:
只弹出这些，没有列出更多内容。
shell不再响应，系统呈现内核死锁状态。

尝试过使用不同版本的rtl8723ds驱动
1.R328 SDK中的 v5.6.5_31752.20181221_COEX20181130-2e2e
2.R329 SDK中的 v5.10.1-26-ga10bc0b8b.20200617_COEX20200103-3535
3.rtl8723DS_WiFi_linux_v5.13.5-29-g0dbf6713f.20210604_COEX20210106-3b3b.tar.gz https://whycan.com/t_7504.html 这里下载到的

使用这些驱动都存在上述问题。由于是死锁问题，我尝试关闭一个CPU核心
echo 0 > /sys/devices/system/cpu/cpu1/online

这样关闭核心后再测试就不再死锁了。但是这不是个长久之计啊，
请问有人遇到过这个问题吗？该如何解决？？

补充上述的top图

mengxp

使用afalg小块性能非常拉胯，可能是受限于内核通信或硬件中断之类的吧。

engine "afalg" set.
You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 62569 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 57975 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 55735 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 43987 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 16572 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 9685 aes-128-cbc's in 3.00s
OpenSSL 1.1.1m  14 Dec 2021
built on: Fri Dec 31 05:37:09 2021 UTC
options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) 
compiler: arm-linux-gnueabihf-gcc -fPIC -pthread -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc        333.70k     1236.80k     4756.05k    15014.23k    45252.61k    52893.01k

不开afalg加速性能如下

You have chosen to measure elapsed time instead of user CPU time.
Doing aes-128-cbc for 3s on 16 size blocks: 4299138 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 64 size blocks: 1332727 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 256 size blocks: 357553 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 1024 size blocks: 91071 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 8192 size blocks: 11447 aes-128-cbc's in 3.00s
Doing aes-128-cbc for 3s on 16384 size blocks: 5724 aes-128-cbc's in 3.00s
OpenSSL 1.1.1m  14 Dec 2021
built on: Fri Dec 31 05:37:09 2021 UTC
options:bn(64,32) rc4(char) des(long) aes(partial) idea(int) blowfish(ptr) 
compiler: arm-linux-gnueabihf-gcc -fPIC -pthread -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG
The 'numbers' are in 1000s of bytes per second processed.
type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
aes-128-cbc      22928.74k    28431.51k    30511.19k    31085.57k    31257.94k    31260.67k

平台: R328-S3

mengxp

@weifooo

哦我还有个问题就是 F1C200s 支持secureboot/trustzone吗？

我看sdk的createkey脚本里有
PLATFORM_LIST="r18 c200s r30 r311 r328s2 r328s3 mr112"
看起来createkey支持 200s 平台的，但是执行时找不到dragon toc config失败了。。。

是不是这个芯片IC设计上支持trustzone，但实际后续开发sdk的时候取消了这个支持？

mengxp

@weifooo 哦哦感谢大神的回复，我明白了！

mengxp

我用uboot读了下brom发现确实是SBROM，那我想可能知道了上述问题答案…

1.芯片此时确实是 S-BROM 引导的，打断uboot引导，md.b 0x0 0x10000 可以读到 S-BROM 代码(包含 TOC0.GLH)
2.此时进入 FEL 模式，是运行在 non-secure mode，sunxi-fel 读到的是 N-BROM 映射。
3.FEL 运行在non-secure mode，应该是无法触碰 secure peripheral，所以即使在secureboot模式下进入 fel 也是安全的。

上述第三点我不太确认，想请求确认下

mengxp

@xiaowenge 向小文哥求助！！

mengxp

我使用R328平台刷写安全固件遇到了一些问题，大家能帮忙看看吗？

1.我用pack -s生成了 secure_v0.img 结尾的安全固件，然后用 PhoenixSuit 烧录成功了。
2.我配置dragonkey全局配置安全key，列表中的sn和mac删掉了，只添加rotpk配置，然后用dragonsn烧录了rotpk。

然后我想验证板子是否已经工作在secureboot模式
1.我查看了板子引导日志，发现是SBOOT is starting，证明是SBOOT在引导
2.下面的UBOOT 日志有 secure enable bit: 1 字样，证明 efuse 中开启了secure enable bit。
3.我想验证rotpk是否已经烧录成功，但是不知道怎么做，我看uboot2014的key_burn中有个 efuse_read 命令可以读，但是uboot2018上并没有，我把这个命令代码复制到uboot2018的key_burn.c上然后重新编译uboot，pack -s，烧录，打断uboot引导，执行 efuse_read rotpk 命令，发现已经读出了我烧录的rotpk。
4.那么根据全志wifi中的描述，一旦secure enable bit=1，且rotpk烧录了有效值，芯片就应该使用 S-BROM 引导而不是 N-BROM 引导。但是我用 sunxi-fel read 0x0 0x10000 brom.bin 保存的brom发现仍然是 N-BROM，里面有 eGON字样，没有 TOC 字样。
5.另外我用 sunxi-fel 仍然可以下载未签名的代码到cpu上执行。这里测试我使用的是未签名的 fes1.fex

上述验证步骤12345中的相关数据我已经打包上传到这里了
secureboot问题.zip

那么我的问题是
1.芯片此时为什么没有使用S-BROM引导，是还需要做哪个步骤吗？
2.如果已经是S-BROM引导，是我dump BROM的那个方法错误吗？
3.如果已经是S-BROM引导，sunxi-fel 仍然能执行未授权代码，是正常的吗？

向大家请教，谢谢了！

mengxp

sbrom校验toc0失败，进入fel模式后，可以使用sunxi-fel工具写sram并执行代码，这算是绕过secureboot了吧？这怎么能行，请问如何解决？

mengxp 发布的帖子