没有抬杠的意思，从我们项目实践来看，客观总结我们遇到的情况。

D1是RISC-V芯片。如果使用ARM系芯片，ARM的引导程序是有成熟的套路，大概可以归纳为：

0阶段启动→1阶段启动→维护模式→平台相关引导程序→系统内核

RISC-V其实对操作系统的运行环境是有统一规定的。这个环境被叫做SBI，完整的启动流程大致可以表示为：

维护模式→平台无关引导程序→系统内核

没错就这么简单。我本人也是SBI规范的起草者之一，相比于以前非常复杂的启动过程，RISC-V在软件上也有了统一的规定。这就给以前所谓的“移植”提供相当大的遍历，因为引导程序环境只要兼容这个接口，就能启动任何基于这个接口的操作系统。
有些人直接告诉我：Linux这么复杂，RT-Thread这么复杂，你这个程序肯定只能启动简单的系统，复杂的肯定启动不了。我就是SBI标准的贡献者之一，我可以负责任地讲：完全不是这回事。对RISC-V下引导程序的误会，主要就来源于很多朋友以为引导程序很复杂，对这方面不了解，其实是很简单的。

现在D1的情况是这样的：

0阶段启动→1阶段启动→维护模式→平台相关引导程序→平台无关引导程序→系统内核

太复杂了！希望下一代D2、D3这些芯片重新设计引导过程，如果是做成RISC-V系列的，尽量只用RISC-V的标准。引导程序的软件设计如果有问题，我恰好就是SBI标准的贡献者，自己也维护一些引导程序，可以提供帮助。

===

鉴于很多朋友对RISC-V的引导程序环境（从使用上）了解不多，我简单的做一个比喻。

以前各个手机公司都搞自己的充电接口，诺基亚有诺基亚的，小米有小米的。后来，Type-C接口和PD协议出现了，只要是Type-C手机，随便拿一条充电线就能充电，管他是诺基亚、小米还是华为的，管他是大厂还是三无山寨机，不说充电速度快不快，肯定是能充的。
每个厂商针对自己手机的性质有优化，用自己原装的充电器，他们自己的快充协议会识别，这样就能获得更快的速度。
反过来讲，管他是官方充电器还是第三方充电器，绝对可以给手机充电，不过安全性和速度就由充电器本身决定了，和手机没关系。

SBI规范相比于以前的UEFI之类，就好像Type-C相比于以前小米诺基亚自己的充电接口。只要引导程序支持SBI规范，管他是谁家的操作系统，管他简单还是复杂，性能好不好我不说，启动是绝对可以启动的。
但是，每家操作系统对自己的引导程序会有优化，如果使用原厂的引导程序，能获得更好的性能。如果使用第三方引导程序，可能可以获得第三方提供的更多功能，如调试服务器、无盘启动等等。
无论使用谁家的引导程序，绝对可以启动，但是性能和功能就由引导程序决定了。

引导程序可以选择各个厂家的，目前SBI很多公司都自发地去用opensbi。在某些领域下，opensbi的使用是受到限制的，而且opensbi的开源模式要求分支后合并，对产权代码不友好。
我的项目rustsbi完美解决这些非技术问题，模块化开发，不需要提交代码到主分支，鼓励厂家自己发布引导程序实现。
rustsbi已经支持多款友商芯片，奈何D1的引导过程太复杂，很多细节只有原厂知道，目前我们真不敢写。

给我们仓库点个星吧：
https://github.com/rustsbi/rustsbi

不是想让谁大发慈悲地写这样的项目，而是我认为硬件设计实在太复杂，的确给上面的软件开发造成很大的障碍，大家做这种事情都没动力了（可能就转而选择友商的硬件产品了，不过在这个论坛上肯定不会明说，否则砸场子谁都不乐意）。或者如果全志牵头开仓库，提供一些支持，由开源社区完成也是可以的。

在此我借个楼强烈要求各个厂家提高boot0的透明度，产权代码没事，不给产权代码就行了，又不需要编译，如果不公开最后人去逆向，那产权代码的事情就全都让人知道了
不公开boot0对引导程序作者是灭顶之灾，我个人认为只做uboot却没有boot0参考，这个和**开发者区别不大

RustSBI是RISC-V SBI标准规定的SBI实现，SBI标准是（目前）所有RISC-V操作系统必须遵守的裸机软件接口。RustSBI是实现良好的SBI接口框架，但网上原厂资料很少。因此，我整理了一个资料集合到GitHub仓库里。

下载地址：https://github.com/rustsbi/slides

仓库中，每篇文档都给予了标题、发布时间，以及一段对文档内容的摘要说明。所有的文档全部都是中文文档，相信会对各个领域的RustSBI以及相关的RISC-V引导程序固件开发者提供不少帮助。

目前包含的主要功能性技术文档有：

• 《安全孤岛RustSBI固件设计简明指南》
• 《RISC-V引导程序环境：应用与规范》
• 《非对称多核处理器的RustSBI实现》
• 《RustSBI的多核管理和复位模块》

还有另一些文档是项目早期开发时的一些灵感和思路，也包含在仓库中：

• 《RustSBI的设计与实现》
• 《Rust语言与RISC-V操作系统》
• 《Rust语言与嵌入式开发》

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。RustSBI通过独立的包支持D1芯片的各个主板，鉴于RustSBI的star数已经超过所有竞争对手的总和，未来RustSBI团队希望积极和厂商沟通，得到更多芯片的支持。

项目链接：https://github.com/rustsbi/rustsbi

发布页：https://github.com/rustsbi/rustsbi/releases/tag/v0.3.0

目前的引导程序会和操作系统放在同一个存储介质中。以U-Boot为例，分区后放入SD卡。这种设计的缺点是：存储介质和主板绑定较强。比如主板A有多大的屏幕，主板B没有，当计算条从主板A拔下来插入主板B，理论上就需要重新烧写对应的引导程序。现在的U-Boot通过魔改来绕过这个做法，但这样无法促进引导程序架构的发展。

一种新的做法是，以主板绑定的介质存储引导程序。这样面对计算条应用，只需要在计算条的介质中安装操作系统本身即可，通过底板的引导程序去启动它。比如，在两个主板上分别设计16MB左右的闪存，它存储一个RISC-V架构的引导程序，分别为计算条上的操作系统指示各个主板上的资源，这对硬件的替换和更新是有利的，因为如果计算条损坏或升级，直接替换新的即可，无需重新刷引导程序和系统，无论计算条的操作系统以SD卡或者eMMC芯片为存储方式。
这种做法为硬件的升级提供极大的便利，如果它成为未来RISC-V单板计算机的标准配置，我决定在Oreboot和RustSBI引导路线中使用这一点。

它的优点是：可以无缝升级和替换硬件，较大地提升用户体验。
缺点是：至少需要一个闪存芯片的物料成本。如果没有更换计算芯片的兼容需求，成本不如只在eMMC/SD卡中分区的老操作低。

主板上集成引导程序用的闪存芯片有以上的优势和劣势。事实上，这个设计在PC机的早期已经形成。

我们通常在移植操作系统和软件上花费较多的精力，而对引导程序这一操作系统的信任根却常吃“嗟来之食”，持续地缺乏引导程序方面的创新和带头能力。我常为国产软件在世界上的话语权而效力奔波，也成功地为RISC-V的国际标准提出过提案，希望看到RISC-V引导程序成为国产软件、开源软件从跟跑到领跑的突破点。要看到这一天到来，希望从业者们和开源社区在未来能有长期的共同努力。

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。RustSBI通过独立的包支持D1芯片的各个主板，鉴于RustSBI的star数已经超过所有竞争对手的总和，未来RustSBI团队希望积极和厂商沟通，得到更多芯片的支持。

项目链接：https://github.com/rustsbi/rustsbi

发布页：https://github.com/rustsbi/rustsbi/releases/tag/v0.3.0

RustSBI是RISC-V SBI标准规定的SBI实现，SBI标准是（目前）所有RISC-V操作系统必须遵守的裸机软件接口。RustSBI是实现良好的SBI接口框架，但网上原厂资料很少。因此，我整理了一个资料集合到GitHub仓库里。

下载地址：https://github.com/rustsbi/slides

仓库中，每篇文档都给予了标题、发布时间，以及一段对文档内容的摘要说明。所有的文档全部都是中文文档，相信会对各个领域的RustSBI以及相关的RISC-V引导程序固件开发者提供不少帮助。

目前包含的主要功能性技术文档有：

• 《安全孤岛RustSBI固件设计简明指南》
• 《RISC-V引导程序环境：应用与规范》
• 《非对称多核处理器的RustSBI实现》
• 《RustSBI的多核管理和复位模块》

还有另一些文档是项目早期开发时的一些灵感和思路，也包含在仓库中：

• 《RustSBI的设计与实现》
• 《Rust语言与RISC-V操作系统》
• 《Rust语言与嵌入式开发》

在此我借个楼强烈要求各个厂家提高boot0的透明度，产权代码没事，不给产权代码就行了，又不需要编译，如果不公开最后人去逆向，那产权代码的事情就全都让人知道了
不公开boot0对引导程序作者是灭顶之灾，我个人认为只做uboot却没有boot0参考，这个和**开发者区别不大

我花一下午逆向了一份boot0，简单来说需要一个魔法头，头前面有一条跳转指令它倒是不会检查。有很多文档里没有的寄存器。
放这里了： https://github.com/luojia65/test-d1-flash-bare/blob/d6a052678f5e396da0b69835d34615b4a22f75af/test-d1-flash-bt0/src/main.rs#L51
这个项目很多代码都还需要整理（it works but nobody knows why），不过main函数是没问题的

目前的引导程序会和操作系统放在同一个存储介质中。以U-Boot为例，分区后放入SD卡。这种设计的缺点是：存储介质和主板绑定较强。比如主板A有多大的屏幕，主板B没有，当计算条从主板A拔下来插入主板B，理论上就需要重新烧写对应的引导程序。现在的U-Boot通过魔改来绕过这个做法，但这样无法促进引导程序架构的发展。

一种新的做法是，以主板绑定的介质存储引导程序。这样面对计算条应用，只需要在计算条的介质中安装操作系统本身即可，通过底板的引导程序去启动它。比如，在两个主板上分别设计16MB左右的闪存，它存储一个RISC-V架构的引导程序，分别为计算条上的操作系统指示各个主板上的资源，这对硬件的替换和更新是有利的，因为如果计算条损坏或升级，直接替换新的即可，无需重新刷引导程序和系统，无论计算条的操作系统以SD卡或者eMMC芯片为存储方式。
这种做法为硬件的升级提供极大的便利，如果它成为未来RISC-V单板计算机的标准配置，我决定在Oreboot和RustSBI引导路线中使用这一点。

它的优点是：可以无缝升级和替换硬件，较大地提升用户体验。
缺点是：至少需要一个闪存芯片的物料成本。如果没有更换计算芯片的兼容需求，成本不如只在eMMC/SD卡中分区的老操作低。

主板上集成引导程序用的闪存芯片有以上的优势和劣势。事实上，这个设计在PC机的早期已经形成。

我们通常在移植操作系统和软件上花费较多的精力，而对引导程序这一操作系统的信任根却常吃“嗟来之食”，持续地缺乏引导程序方面的创新和带头能力。我常为国产软件在世界上的话语权而效力奔波，也成功地为RISC-V的国际标准提出过提案，希望看到RISC-V引导程序成为国产软件、开源软件从跟跑到领跑的突破点。要看到这一天到来，希望从业者们和开源社区在未来能有长期的共同努力。

@zhuzhizhan 不是这个意思。能烧录的部分很大，不能改的部分很小，这就对了。写死的那部分并不包含驱动，它只包含几条汇编指令，来跳转到相应的存储器，以便能改的软件启动。

这篇文章说得就很对：

@tripod9 就这个意思，各种引导程序都可以，只要只有一个引导程序就好，别整太多复杂的。（话说西数前几年的ppt真的是乱讲……很多问题）

还有朋友表示听不懂，我再举个例子。

把系统启动可以看作是往洞里面拧螺丝，只要洞的大小一样，螺丝肯定能拧进去。

有人和我抬杠：那航母的螺丝和玩具的螺丝能一样吗？我这里只说能不能拧进去，我并没有说性能如何。拧都是能拧进去的。

用SBI程序启动操作系统，无论操作系统多复杂，肯定能启动。但是性能如何我就不知道了。我们主要回答的问题是能不能启动，性能是另一回事。

没有抬杠的意思，从我们项目实践来看，客观总结我们遇到的情况。

D1是RISC-V芯片。如果使用ARM系芯片，ARM的引导程序是有成熟的套路，大概可以归纳为：

0阶段启动→1阶段启动→维护模式→平台相关引导程序→系统内核

RISC-V其实对操作系统的运行环境是有统一规定的。这个环境被叫做SBI，完整的启动流程大致可以表示为：

维护模式→平台无关引导程序→系统内核

没错就这么简单。我本人也是SBI规范的起草者之一，相比于以前非常复杂的启动过程，RISC-V在软件上也有了统一的规定。这就给以前所谓的“移植”提供相当大的遍历，因为引导程序环境只要兼容这个接口，就能启动任何基于这个接口的操作系统。
有些人直接告诉我：Linux这么复杂，RT-Thread这么复杂，你这个程序肯定只能启动简单的系统，复杂的肯定启动不了。我就是SBI标准的贡献者之一，我可以负责任地讲：完全不是这回事。对RISC-V下引导程序的误会，主要就来源于很多朋友以为引导程序很复杂，对这方面不了解，其实是很简单的。

现在D1的情况是这样的：

0阶段启动→1阶段启动→维护模式→平台相关引导程序→平台无关引导程序→系统内核

太复杂了！希望下一代D2、D3这些芯片重新设计引导过程，如果是做成RISC-V系列的，尽量只用RISC-V的标准。引导程序的软件设计如果有问题，我恰好就是SBI标准的贡献者，自己也维护一些引导程序，可以提供帮助。

===

鉴于很多朋友对RISC-V的引导程序环境（从使用上）了解不多，我简单的做一个比喻。

以前各个手机公司都搞自己的充电接口，诺基亚有诺基亚的，小米有小米的。后来，Type-C接口和PD协议出现了，只要是Type-C手机，随便拿一条充电线就能充电，管他是诺基亚、小米还是华为的，管他是大厂还是三无山寨机，不说充电速度快不快，肯定是能充的。
每个厂商针对自己手机的性质有优化，用自己原装的充电器，他们自己的快充协议会识别，这样就能获得更快的速度。
反过来讲，管他是官方充电器还是第三方充电器，绝对可以给手机充电，不过安全性和速度就由充电器本身决定了，和手机没关系。

SBI规范相比于以前的UEFI之类，就好像Type-C相比于以前小米诺基亚自己的充电接口。只要引导程序支持SBI规范，管他是谁家的操作系统，管他简单还是复杂，性能好不好我不说，启动是绝对可以启动的。
但是，每家操作系统对自己的引导程序会有优化，如果使用原厂的引导程序，能获得更好的性能。如果使用第三方引导程序，可能可以获得第三方提供的更多功能，如调试服务器、无盘启动等等。
无论使用谁家的引导程序，绝对可以启动，但是性能和功能就由引导程序决定了。

引导程序可以选择各个厂家的，目前SBI很多公司都自发地去用opensbi。在某些领域下，opensbi的使用是受到限制的，而且opensbi的开源模式要求分支后合并，对产权代码不友好。
我的项目rustsbi完美解决这些非技术问题，模块化开发，不需要提交代码到主分支，鼓励厂家自己发布引导程序实现。
rustsbi已经支持多款友商芯片，奈何D1的引导过程太复杂，很多细节只有原厂知道，目前我们真不敢写。

给我们仓库点个星吧：
https://github.com/rustsbi/rustsbi

不是想让谁大发慈悲地写这样的项目，而是我认为硬件设计实在太复杂，的确给上面的软件开发造成很大的障碍，大家做这种事情都没动力了（可能就转而选择友商的硬件产品了，不过在这个论坛上肯定不会明说，否则砸场子谁都不乐意）。或者如果全志牵头开仓库，提供一些支持，由开源社区完成也是可以的。