WS1710_1.0主板错刷T1底包成砖求助，USB线刷已经认不到设备

webkn

TTL启动显示信息如下：


GXM:BL1:dc8b51:76f1a5;FEAT:BDFC31BC:0OC:3;RCY:0;EMMC:0;READ:0;0.0;CHK:0;
TE: 330205

BL2 Built : 11:58:42, May 27 2017.
gxl gc3c9a84 - xiaobo.gu@droid05

set vdd cpu_a to 1120 mv
set vdd cpu_b to 1050 mv
set vddee to 1000 mv
Board ID = 4
CPU clk: 1200MHz
DQS-corr enabled
DDR scramble enabled
DDR3 chl: Rank0+1 @ 912MHz
Rank0: 1024MB-2T-13
Rank1: 1024MB-2T-13
DataBus test pass!
AddrBus test pass!
-s
Load fip header from eMMC, src: 0x0000c200, des: 0x01400000, size: 0x00004000
aml log : R2048 check pass!
New fip structure!
Load bl30 from eMMC, src: 0x00010200, des: 0x01700000, size: 0x0000d600
aml log : R2048 check pass!
Load bl31 from eMMC, src: 0x00020200, des: 0x01700000, size: 0x0002c600
aml log : R2048 check pass!
Load bl33 from eMMC, src: 0x00050200, des: 0x01700000, size: 0x00065400
aml log : R2048 check pass!
NOTICE:  BL3-1: v1.0(release):a625749
NOTICE:  BL3-1: Built : 11:25:15, Aug 25 2017
NOTICE:  BL31: BL33 decompress pass
mpu_config_enablek
[Image: gxl_v1.1.3243-377db0f 2017-09-07 11:28:58 qiufang.dai@droid07]
OPS=0x82
wdt: reset registers!
45 bd f8 25 da e1 13 21 77 3a b5 16 [0.985789 Inits done]
secure task start!
high task start!
low task start!
ERROR:   Error initializing runtime service opteed_fast


U-Boot 2015.01-dirty (Dec 22 2017 - 10:20:14)

DRAM:  2 GiB
Relocation Offset is: 76eb8000
register usb cfg[0][1] = 0000000077f5b690
[CANVAS]canvas init
vpu: error: vpu: check dts: FDT_ERR_BADMAGIC, load default parameters
vpu: clk_level = 7
vpu: set clk: 666667000Hz, readback: 666660000Hz(0x300)
vpu: vpu_clk_gate_init_off
vpp: vpp_init
boot_device_flag : 1
Nand PHY Ver:1.01.001.0006 (c) 2013 Amlogic Inc.
init bus_cycle=6, bus_timing=7, system=5.0ns
reset failed
get_chip_type and ret:fffffffe
get_chip_type and ret:fffffffe
chip detect failed and ret:fffffffe
nandphy_init failed and ret=0xfffffff1
MMC:   aml_priv->desc_buf = 0x0000000073eb86b0
aml_priv->desc_buf = 0x0000000073eba9d0
SDIO Port B: 0, SDIO Port C: 1
emmc/sd response timeout, cmd8, status=0x1ff2800
emmc/sd response timeout, cmd55, status=0x1ff2800
init_part() 293: PART_TYPE_AML
[mmc_init] mmc init success
dtb magic 00000000
启动至此卡住，SD卡刷、U盘刷均不能，USB线刷不能发现设备
后再QQ群”二少“的帮助下，对主板1.8V的供电，从1.8V稳压芯片4VK4输出脚断开停掉emmc，USB线刷成功发现设备，再复位输出脚即可线刷emmc，
但是依然只能刷入”S912-斐讯T1-U盘引导包.img（带SECURE_BOOT_SET）“底包，
如果尝试刷入玩客云PRO底包”S912-章鱼星球-U盘引导包.img“会加载DDR失败，
如果使用CustomizationTool，把img前者DDR_ENC.USB、UBOOT_ENC.USB 加入img后者，img后者可以刷入成功，但是下次无法识别emmc上的数据无法引导，

暂时结论，一旦刷入带SECURE_BOOT_SET的img，CPU的会被刷入证书，或者理解为加密，
此后不用带SECURE_BOOT_SET的img将无法改写bl（至少无法改写bl2、bl31、bl32、bl33），
即便是使用混如”DDR_ENC.USB、UBOOT_ENC.USB“的img改写了bl，改写后的信息也无法被CPU识别。

• 下文为引用自从零开始移植最新版本(2023.10)主线Uboot到Orange Pi 3(全志H6) - 知乎
• 1、armv8-a 一般最先运行bl1阶段固件，也即是boot rom，这个一般固化在cpu的 rom里面，这是上电之后执行的第一段代码，主要是加载bl2阶段代码到iram执行
• 2、bl2阶段代码放在存储媒介，比如emmc中，由bl1负责 运行起来，因为bl1代码并未初始化DDR，所以加载到片内SRAM中执行，在这个阶段完成外部DDR的初始化,并加载bl31到DDR运行
• 3、bl31一般称为EL3 Service，属于runtime，负责切换non secure和secure两个世界环境，运行一些服务，比如PSCI,SCMI等，同时负责把bl32和bl33代码加载运行起来
• 4、bl32属于trusted OS，如果不需要这个或者硬件不支持，可以去掉bl32，这个是可选的
• bl33一般是bootlaoder，负责引导后面的操作系统内核
  

webkn

刷上有签名验证的底包就失去自由了，boot、bootloader、recovery都不能随意刷了，都要有签名才能通过验证，
那怎么对img做签名呢？是不是把WS1710的img，做上签名，就可以刷入WS1710盒子了呢？？？？
网上说：一般有两种根密钥：一个是加密解密用的对称密钥 Secure Boot Key，一般是 AES 128 的，每台设备都是随机生成不一样的；
另一个是一个 Secure Boot Signing Key 公钥，一般用的 RSA 或 ECC，这个是每个 OEM 自己生成的，每台设备用的都一样，有些芯片会存公钥的 Hash 来减少 eFUSE 的空间使用。
之前错刷T1底包时写入了SECURE_BOOT_SET，且刷入一次后不可改写，那是不是刷入的理解为对称密钥Secure Boot Key，
那是不是把正常的DDR.USB 和UBOOT.USB 使用该密钥加密为DDR_ENC.USB和UBOOT_ENC.USB再打包呢？？？
请朋友指导以下啊！！！

webkn

所有支持 Secure Boot 的 CPU 都会有一块很小的一次性编程储存模块，我们称之为 FUSE 或者 eFUSE，因为它的工作原理跟现实中的保险丝类似：CPU 在出厂后，这块 eFUSE 空间内所有的比特都是 1，如果向一个比特烧写 0，就会彻底烧死这个比特，再也无法改变它的值，也就是再也回不去 1 了。

一般 eFUSE 的大小在 1KB 左右，OEM 从 CPU 厂家购买了芯片，组装了产品后，一般都要焼写 eFUSE 的内容，包括产品的运行模式：测试、开发、生产等。面向终端消费者的产品都会被焼写为生产模式。这个模式下 bootROM 会禁用很多权限，更大面积地限制用户的能力。

另外一个很重要的焼写内容就是根密钥了，一般有两种根密钥：一个是加密解密用的对称密钥 Secure Boot Key，一般是 AES 128 的，每台设备都是随机生成不一样的；另一个是一个 Secure Boot Signing Key 公钥，一般用的 RSA 或 ECC，这个是每个 OEM 自己生成的，每台设备用的都一样，有些芯片会存公钥的 Hash 来减少 eFUSE 的空间使用。

只有 Secure World（后面会介绍）才能访问 eFUSE 的寄存器。除了读写 eFUSE 的基础寄存器之外，还有一些控制寄存器可以禁止别的程序访问 eFUSE，来保护其中的密钥。因此 eFUSE 中的根密钥以及 bootROM 将作为 Secure Boot 的根信任。

有些 CPU 中还会有一个专门负责加密解密的模块，我们称为 Security Engine。这个模块也是只有在 Secure World 中才能访问。这个模块通常会有若干个密钥槽（Keyslots），可以通过寄存器将密钥加载到任意一个 Keyslot 当中，Keyslot 的加载操作将复盖之前加载过的密钥。通过寄存器操作 DMA 读写，可以使用 Keyslot 中的密钥对数据进行加密、解密、签名、HMAC、随机数生成等操作，但是没有办法从一个 Keyslot 中读取已经加载的密钥值。

FSBL 的作用是初始化 PCB 板上的其他硬件设备，给外部 RAM 映射内存空间，从 eMMC 的 GPT 分区上加载验证并执行接下来的启动程序。

CPU 通电后执行的第一行指令就是 bootROM 的入口，bootROM 将初始化各种 CPU 内部的模块，但最主要的是，它会读取 eFUSE 上的内容，首先它会判断当前的运行模式是不是生产模式，是的话会开启 Secure Boot 功能，然后把 Secure Boot Key 加载到一个 Security Engine 的 Keyslot 当中，有时候它还会通过 Key Derivation 从 Secure Boot Key 或别的 eFUSE 内容生成多几个不同用途的密钥，分别加载到不同的 Keyslots 中。然后它会从 eMMC 上加载 FSBL，FSBL 里面会有一个数字签名和公钥证书，bootROM 会验证这个签名的合法性，以及根证书的 Hash 是否和 eFUSE 中的 Signing Key 的 Hash 相同。如果验证通过，说明 FSBL 的的确确是 OEM 正式发布的，没有受到过篡改。于是 bootROM 就会跳转到 FSBL 执行接下来的启动程序。有些 CPU 在跳转之前会把 bootROM 的内存区间设为不可见，防止 FSBL 去读取 bootROM。有些 CPU 还会禁止 eFUSE 的读写，或者至少 Secure Boot Key 区域的读取权限，来防止 FSBL 泄漏根信任的解密密钥。还有要注意的是，FSBL 是被加载到了 iRAM 上执行的，而且 FSBL 仍然拥有 EL3 级别的权限。
FSBL 会进一步初始化 PCB 板上的别的硬件，比如外部的 RAM 芯片等等，使其不再受限于 iRAM 的内存空间。然后它会进一步加载 eMMC 上的内容到 RAM。我们接下来会着重讲讲跟 Secure Boot 密切相关的启动内容。

一般 FSBL 都非常靠近 eMMC 的第一个扇区，bootROM 一般不会管 eMMC 有没有用 GPT 分区，而是简单的从第一个扇区读取一些头信息然后直接找到 FSBL 的扇区进行加载的。所以一般我们要做 GPT 分区的话都会放在 FSBL 后面。FSBL 加载一个 GPT 分区也是要跳过 eMMC 前面的非 GPT 扇区再进行加载。

从 FSBL 开始我们就要引入 TrustZone 的技术概念了。TrustZone 是 ARM 家的 Trusted Execution Environment（TEE）实现。相对应的，Intel 家的叫做 Software Guard Extensions（SGX），AMD 家的叫做 Platform Security Processor（PSP）。虽然本文只关注 TrustZone，但其实原理上都大同小异。

TrustZone 将 CPU 的执行环境划分为了 Secure World 和 Normal World，Secure World 拥有更高的权限，可以访问 Normal World 的内存、eFUSE 寄存器、Security Engine 寄存器等等。但是 Normal World 中的最高权限却无法访问 Secure World 的内存。

但是 Normal World 可以通过 SMC 指令调用 Secure World EL3 中注册的命令，然后 EL3 程序再将 Normal World 的请求转发给 Secure World，从而达到两个世界之间的通讯。
原文见：  https://bbs.kanxue.com/thread-260399.htm