RustSBI是RISC-V下SBI标准的实现，旨在为裸机平台、虚拟化和模拟器软件提供良好的SBI接口支持。它有机结合了Rust嵌入式生态与RISC-V系统软件，加快开发速度的同时，保证Rust语言具备的良好安全性和运行性能。本次0.3.0版本主要包括增加了实例化的SBI接口支持及相关的构造器结构，可以在stable Rust编译，去除了对堆内存和全局变量的依赖，完善了相关文档，以及若干的小修复。0.3.0版本更新将为Rust编写的RISC-V虚拟化软件和RISC-V模拟器提供良好的支持，并进一步完善裸机RISC-V开发的实用性，可以启动Linux等在内的成熟操作系统和zCore等在内的科研操作系统。
随着RustSBI 0.3.0正式版的发布，RustSBI的生态链项目趋于成熟，正在酝酿的“RustSBI原型设计系统”也在活跃开发中。内核运行工具sbi-rt、常数与结构包sbi-spec和规范测试集sbi-testing都已完成定型、发布预览版，并进入实际项目的依赖选项中。“RustSBI原型设计系统”并非专注于原型设计，而是提供一种快速开发的解决方案，开发完成后，它将允许厂家在最短的时间内适配SBI接口到自己的RISC-V主板和平台，并且直接获得蓬莱TEE、@dram的软件模拟虚拟化以及Raven固件调试器等高级功能。与此同时，贡献者和用户群体也反馈了对RustSBI及其新版本的评价。
活跃的社区贡献者@YdrMaster认为，RustSBI软件是社区力量在RISC-V SBI生态中的表现。“RustSBI帮助我探索‘内核之下（M态）’和‘内核之前（bootloader）’；相比OpenSBI，它的实现更简洁、干净，构建方式更现代，能提供更好的开发体验和操作空间”，YdrMaster说，“它除了具备所有Rust的优势之外，还具有库 + 实现的抽象，不必将所有实现塞进一个仓库，对一个硬件也有针对不同需求的不同实现。如果需要一个新实现，可以只重做关心的部分，复用其它部分。另外，它的运行速度快，在连续的内核测试时十分明显。”
长期贡献Oreboot项目的Daniel Maslowski说，RustSBI简化了完整引导程序的开发工作。“RustSBI是Rust生态中的SBI实现，它有助于记住RISC-V中（的SBI服务）需要什么，并且已经定义了所有的常量和结构”，丹尼尔说，“Rust是它特长的一方面，（在引导程序开发中）我不需要额外的组件或者代码库。这样，对于相当多的SoC，我们可以为固件提供单个的初始化阶段，只要它能够放入SRAM中，就像我为JH7100（128K）做得一样。”
UltraOS团队的@LoanCold认为，RustSBI就它为RISC-V SBI生态所做的贡献来说，它可以继续蓬勃发展下去，给开发者更多的选择空间。“我所参与的UltraOS团队用Rust实现撰写的操作系统，使用了RustSBI项目。从项目来说，更好的开发者支持以及更强大的K210开发板支持，是我受益的最大部分”，LoanCold说，“我们团队也自身更改过RustSBI以实现更好的功能，这是开源或者进一步开源带来的好处，或者说RustSBI较为完备的注释带来的好处。它同时使得我们能够更好地支持K210平台的开发，这是OpenSBI所不能做到的。未来的RustSBI可以做到垂直整合，吸引稳定的使用者，完善平台支持和自动化测试，来保障系统级别的应用长期稳定运行。”
“今年相比过去的两年，RustSBI生态和用户在进一步扩大。除了科研和教学界，我们乐于见到更多产业界的公司贡献到RustSBI生态中”，洛佳说，“BL808的官方Rust支持库就是一个好的开始。大小核支持、虚拟化和模拟器支持以及安全特性，这些都是RustSBI擅长的部分。无论用户选择创新的全栈Rust实现还是兼顾U-Boot、UEFI或者EDK II等传统软件的实现，RustSBI都可以良好地支持和配合产业软件的发展。在我们应用于模拟器的性能测试中，RustSBI体现出非凡的性能，部分性能指标达到了竞争对手的20至30倍。我们希望将RustSBI卓越的特点分享给所有的引导程序软件，无论是C或者Rust都可以——生态的参与者能够一起合作，共同提高引导程序产业的安全和稳定性。”
本次更新的主要贡献者有@duskmoon314，@OrangeCMS，@YdrMaster和@luojia65。
项目链接：https://github.com/rustsbi/rustsbi
发布页：https://github.com/rustsbi/rustsbi/releases/tag/v0.3.0
arm只有商业供应商，不存在开源供应商；risc-v不仅有商业供应商，还有开源供应商。
开源供应商的好处是：芯片的硬件电路完全开源，软件设计有电路参考。无需签NDA保密协议，无需走人际关系，无需付费。你可以拿存在开源供应商这回事去砍价，现在结果是risc-v整个生态的授权费都不高。有社区的技术支持，社区软件（比如Linux）可以和社区合作，节省人力物力。
坏处是：开源供应商一般公开网表，落地到具体工艺的实现不是所有供应商都有。
商业供应商的好处是：通常有落地具体工艺的实现。如果给够钱，有足够的技术支持。如果给够钱，有配套软件。
坏处是：如果你是企业用户，要给够钱，要签NDA保密协议。由于买到电路之后禁止公开，无法获取社区支持。授权费通常不低。而且，通常只有合作的工艺厂能做这一款供应商的处理器核，否则还得自己布线。如果你是个人用户，你无法获得芯片的硬件电路，对有些硬件bug无从下手，只能走人际关系去问，导致社区支持会很不好（Linux也是社区合作的软件）。
@jasonhu
1. 这一点其实与内核开发者关联很大，如果是跟着清华的rCore课做内核的，内核的开发语言是Rust语言，这时候反而装一个C的编译器就成负担了，C的编译器老是要配置，Rust不用，对新语言的开发者来说O开头的竞争品非常不好。如果你是Rust内核的开发者，你会发现C语言的开发环境极其复杂，还要配置，很麻烦，而直接用RustSBI编译环境就会很简单，还不用你配置，用了就知道。
2. 这里是资料：github.com/rustsbi/slides 。还有很多资料散落在项目的wiki里。
O开头那个SBI资料多是因为西数公司的商业宣传，尤其是19年有篇错漏百出的ppt，强行说“RISC-V必须和OpenSBI配套使用”，还指出所谓RISC-V的引导必须有4-5个级别，我在做Oreboot的时候就只有一个级别。它4-5个级别就导致开机时间甚至要一分钟左右，但是为啥它还推这一套呢，是因为OpenSBI项目是他们公司掌控的，所有贡献者都是他们的人，打压个竞争对手岂不是分分钟的事情（这也是为啥我要做RustSBI）。他们商业宣传（广告啊这些）导致去网上一搜资料全是他们的，即使事实上我的资料数量更多、质量还更好。
另外，我的文档全部是中文，国人看着更舒服，一目十行，巨快，很容易消化吸收，有问题直接发帖，我直接用中文交流，毫无障碍，而西数毕竟还是美国人的东西，就很语焉不详，英文很难阅读，很多工程师还得等翻译，文章里有啥不懂的，人家天高皇帝远，也没地方问。
3. 这一点我至少公开批评过全志、勘智和先楫，凭什么白白给美国公司送代码，反而自己人的项目就嘲讽和打压
不过确实很多嵌入式老厂对Rust是完全不懂，至少没有改变的勇气。而且risc-v固件和arm、x86不同，不是所谓“能用就行”，它是在内核后台保持运行的，具体看我的ppt。一个良好编写的引导程序，可以提高操作系统运行的效率。有学术论文，SBI固件可以实现内核调试和安全孤岛（也就是secure enclave）功能，硬要说的话就是arm里的el3和这个很像，这些功能都是opensbi不能提供的。况且，opensbi只支持SBI 0.2规范，而早就有SBI 1.0版本了，很多新内核都没法在0.2上跑（linux除外，不要和我说“linux还没升级”）。
随着时间流逝，仍然固守opensbi的厂商将无法运行这些逐步发展的新内核。
今天我翻了翻github，我的rustsbi在github有451个星，而o开头的sbi只有437个星，到底哪个软件好开发者还是会用脚投票的。西数那边反正都是成年人了，谁的软件好大家心里都清楚，但是他们的目的要把o开头的推广成唯一标准，如果他们成功了，risc-v将成为一个只是看似开放的指令集，因为不可缺少的sbi环节被西数一个商业公司垄断。我的rustsbi就是为了打破垄断，让risc-v真正成为一个开放的指令集而存在的。
上面那层楼我没有说清楚，讲一讲（后续芯片代数开始）具体的实现方案。
总的思路是使用多级证书。多级证书就是经销商拥有一个证书，厂商也有一个证书。经销商的证书是芯片厂商签名过的，芯片厂商会在ROM代码里用私钥验证，保证经销商证书是不能造假的。然后有买家要买芯片的时候，它的引导程序必须被经销商证书签名，然后签名要放在引导程序的固件开头。那我怎么知道是哪个经销商签名的引导程序呢？把经销商的证书写进efuse代码里就可以了。经销商发给客户的芯片都是写好自己的经销商证书的，不能修改。芯片开机时，厂商的ROM代码会直接验证固件开头，保证引导程序是efuse里给定的证书签名的，而且efuse里的经销商证书也是厂商验证因此是真实的。如果客户要换引导程序或者升级引导程序怎么办呢？客户把新版引导程序发给经销商，经销商签名，然后客户把签名放在引导程序之前镜像的开头就可以了。
厂商私钥验证部分的ROM代码不能读，而且必须使用时长无关的指令去验证，防止各种侧信道偷ROM数据的做法。比如可以用RISC-V的K指令集。私钥验证的ROM代码可以和其它的ROM代码分开设计，私钥验证的ROM禁止读取，但其它部分的ROM代码开放性要尽量强，方便开源社区做引导程序来做芯片生态，其它部分的ROM代码仍然可以读。
为什么不用直接签名，而用多级证书呢？首先直接签名会把收到的芯片和某一个引导程序捆绑。如果芯片买家要更新引导程序版本（修bug等等）或换自己的引导程序（实现TEE、软调试内核或特殊需求等等），即使你仍然用同一个密钥给它签名，得到的签名是不同的，它这批买的芯片就废了。如果换一个密钥给它签名，直接签名的方法就得换一批efuse的值才能达到换密钥的目的，买家就只能等下一批新签名的货到了才能用，然后如果又发现老版本的引导程序才是对的，又要换老efuse的芯片，这就子子孙孙无穷尽了，所以直接签名在商业上不是容易完成的做法。
落实到具体应用上，如果经销商担心自己的证书私钥泄露（不一定是通过芯片泄露的，也有可能是内鬼或者别的网络安全问题），可能会在上面的模型之后再增加一个证书级别。每个批次的经销商货源会使用一个证书，这样每给客户交付一批新的货，给客户的引导程序重新签名一次就可以了。如果证书私钥泄露了，最多导致这一批货的芯片可以被破解，而不会影响前序后续批次的所有产品。当产品序列结束现役（比如5年、10年时间等等），经销商可以把货源的私钥公开，允许开发者去hack这个批次的产品，进一步扩展经销商的销路。
当厂家交付开发用芯片时，efuse代码还没写入证书，也就是不需要签名引导程序就能运行。这时候开发者可以写进自己的证书，然后通过一个特殊的外设验证ROM签名是否成功，来作为开发时参照使用。芯片里”不能更改证书“的efuse位还是允许的。量产的芯片如果规定必须经过经销商，经销商再写入”不能更改证书“位来禁止更改证书，达到验证货源的目的。
翻了一下JH7100 Data sheet，大核U74默认的JTAG口是GPIO0~4：
https://whycan.com/files/members/9377/jh7100_jtag.png
jtag当然是这几个脚，最关键的不是jtag在哪，而是里面的调试模块（debug module），jtag是debug transport，它只是一个途径，最终访问的是调试模块。
它的调试模块高度怀疑是加密的，如果属实，它会和原厂软件强捆绑，原厂不给软件就没有任何办法。
我问了一些原厂的工程师，基本都拿“jtag是这几个脚”糊弄我
我做了个专门的夹子。然后，JTAG能不能用是问题之一，我试了ft2232和jlink，莫名其妙的问题非常多。问题之二是RISC-V debug module。这个RISC-V确实有标准规定，但是有些厂家故意不符合标准，他们提供调试帮助还好，如果不提供，太噩梦了。
有人有这块板子成功调试的经验吗？
如果有人关心我在做什么的话：我这里参加项目的目标是做一个能完整启动linux的引导程序，详见：github.com/oreboot/oreboot 。首先，我要能从闪存启动，而这对闪存格式的了解是必须的，这又依赖于JTAG调试过程。
RISC-V的引导程序和别的架构很不同，是需要保持在操作系统后台运行的，权限比内核还高，所以安全性至关重要，会有自己编写的需求。而且RISC-V的引导程序可以用来调试内核，还能用来做TEE，就不是一个简单的（厂家只给的那一个）引导程序能代替的了。
为什么不用u-boot呢？它为了兼容别的架构，还要适配RISC-V的SBI标准（又加了一级引导），最终把引导链做得巨长，导致开机一次要至少一分钟，这就没法接受了。
如果有厂家在看这篇帖子：尽量增加rom程序的透明度！因为rom代码对引导程序开发至关重要，没有的话只能抓瞎。RISC-V下又不是厂家做一个就能包揽所有需求，厂家不能只做一个引导程序然后说：都用我的吧。其实相当于啥也没给
如果rom里有产权代码：去掉这些代码就行了，或者分割成两个项目。我们又不要求源码能编译，相反，能看懂就行。
还有：有朋友告诉我，RISC-V的调试模块没有arm公司严格规定，它甚至可以做成加密的。然而如果厂商这么做了，我认为这是在选择彻底和开源社区决裂，这就是另一个话题了。
链接： https://github.com/luojia65/test-d1-flash-bare
可以在任何平台上编译，无论linux，Windows或者mac。
这个项目是给oreboot引导程序准备的