通过查阅：
得知jh7110（vf2）支持直接由bootrom加载sd/emmc引导启动流程，但是被标为不推荐，请问是否有与此相关的解释说明？
听说是因为兼容性有问题。
我尝试使用了上游uboot+opensbi，从distro_boot的env cmd迁移了bootstd，现在整个env干净了很多，现在vf2启动流程和pc很像了，由板上flash承载完整的平台固件（uboot spl+opensbi+uboot），去自动发现并引导外围存储上的OS。也可以不用搞那几个硬编码的uuid之类的了。如果不是追求启动速度的话，感觉现在这个架构确实更flexable也robust
1 Like
但是现在的问题是， flash 存储的启动阶段，还无法提供和 PC 一样而且非常重要的：显示和键盘数入功能。
现在这个架构也并不是主动发现外围存储的系统，而是刷写到 flash 版本是先去从 nvme 找系统，寻找失败再去找 tf 上的系统。而 tf 卡里面的 QSPI 是先去找 TF 卡上的系统。
这并不是一个“智能”的过程，仅仅是一个“试错列表”。
所以一个简单的例子，如果你的 nvme 系统出现了错误无法启动，你拿个 tf 卡作为救援盘，那么你的这个 tf 卡就必须自己携带了 uboot/spi 并且切换硬件开关到 SD 启动，而不能很轻易的让 flash 版的 uboot/spi 来启动 tf 卡的数据。不这么做，VF2 依然会继续启动出现错误的 nvme 内的系统。
而在 PC 上，启动的时候用 BIOS/UEFI 提供的系统启动菜单，就可以很轻松的选择任何支持的设备来启动系统，并不需要先给 U 盘写入一个硬件对应的 BIOS/UEFI 。
确实，作为平台固件没有提供显示和键鼠输入的话，就会和PC有显著UX差距。不过这属于用例相关的特性了，作为一个SBC来说，uboot没有图形支持也合理，edk2不清楚是什么情况。我认为避开在sd/emmc上部署平台固件是有意义的，硬要说的话现在最大的问题是那个测试固件recovery没法开源，也缺一个开源实现，作为SBC来讲会有问题。
没有图形支持合理，但是也不支持文字显示就显然差意思了。
其实针对嵌入式应用，这不是问题。
但是如果真的想挑战 PC ，至少启动要有一个备份机制吧，必然需要一个直接就能实现的系统启动前操作的能力。
其实我觉得，能启动一个类似 GRUB 的二级引导程序是最佳的办法。这个 GRUB 类的程序，可以一并写在 flash 里面。作为型号专用的程序，也容易自己携带必备的驱动程序实现一定的显示和输入功能。
1 Like
听说兼容问题不是软件问题，是硬件问题。tf 口这里接口的设计上是可以调整电压和频率的。但是 VF2 的主板电路画设的有问题，导致不能切换电压。电压和频率是挂钩的，进而不能切换频率。很多 tf 卡也无法工作，可能是和这里的电压频率问题有关系。
显示要求是在 HDMI 和 DSI 口上都能直接输出对应的操作界面。同时任意 USB 口上也要能自动识别键盘并且实现输入。
我反正记得 VF2 现在不可以实现上述 uboot 环境的操作要求。
这些问题一定程度上可以通过软件来解决，比如这个patch就是修改了sdcard/emmc pin的drive strength：
但是rom写好了就不能改了，所以我觉得推荐使用qspi大概率是因为后期往U-boot SPL里面加了这种patch
HDMI 显示个图片和实现 console 还是有点距离的，还需要一套渲染字符界面的程序。其实这套东西在 PC 上，是靠显卡的 BIOS 提供这个功能。UEFI 才真正靠驱动实现显示功能（但其实也是一个通用驱动实现，本身还是依赖于显卡的设计）。
USB 模式，原则上说，什么模式应该是插上设备的时候根据设备信息来切换。当然， VF2 上面那 4 个 TYPE-A 口，本身就应该只有 Host 功能，唯一需要自动识别的只有那个 type-c 口需要。这 4 个口主要问题是牵扯到那个 PCI-E 转 USB3 的芯片驱动问题。
至于你说不在乎这些，其实准确来说 VF2 这个产品的定位，本身就不是把这个当作重点的。
大家都不在乎。
VF2 本身设计上还是针对嵌入式通用主板的应用方向，最终其实还是能否实现应用的正确而可靠的运行，同时提供一个低成本快速兼容的软硬件环境。
实现 PC BIOS/UEFI 功能，未来针对桌面化的 RVA22、RVA23 规范，这些功能就必然会成为基本需求。
按说 CPU 里面的 ROM 并不提供这些功能。CPU 内固化的程序更简单，riscv 必须有 spi 提供系统底层访问支持。
CPU 应该只使用兼容模式通过简单的操作来设置 TF 卡才符合设计原则。
我试了下，似乎内核的integeration tree里没有fbdev支持，kmscon能用但是这个用户态console只有到系统启动之后才会生效。jh7110有fbdev相关支持嘛？(还没有也不打算尝试闭源gpu驱动)
edit:
已解决，找到了CONFIG_DRM_FBDEV_EMULATION
说的不是一个东西……
riscv 需要 spi 程序，这部分不在 rom 里面。CPU 的 rom 只提供读取特定存储器的读取并且启动特殊位置的程序。而且个存储器有特殊要求，这就是为什么 QSPI 是 1bit Nor flash 。
包括 PC ，为什么要有 BIOS/UEFI ，其实也是因为这部分需要被 CPU 内部的 ROM 直接启动。
比如 x86 ，最经典的设计就是 BIOS 在 FFFF:0000 位置，其实是计算机开机时 CPU 会直接开始执行这里的程序，而这之前，CPU 并不做任何工作。
所以开机瞬间 BIOS 就会被被执行，但是实际上 BIOS 并没有被读取到内存里面，而计算机设计上又是程序必须载入内存才能被运行。所以实际上 BIOS 是直接在硬件存储器上运行，是靠专门设计的电路来做替代。
现在虽然 CPU 已经技术进步了很多，但是其实这个设计也没有变化多少。
CPU 内的 ROM 不会提供太多的功能，他只是尽可能的低成本实现对某些设计必须实现的目的存储设备提供启动访问。
这部分 ROM 的功能其实不光是存储设备的访问限制，有的时候还包括内存限制，这部分程序，原则上是没有内存支持的，这个运行阶段必须先把缓存模拟成内存来替代使用。
这么大的硬件限制，不可能让你轻松的实现你所认为的这些功能的。
比如这个 UART 启动模式，其实就是 QSPI 启动，只是不继续启动 Linux 而是进入自己的命令行。
uboot 有不代表就一定能用。这里面还有驱动的事情。
至于 UEFI ，其实 UEFI 现在只是一个类似于协议的东西。
实现了 UEFI 和实现了 UEFI 的全功能操作界面，是两码事。
这东西其实说白了，就类似写一个操作系统。
你只要能写出两个程序交替输出 a 或者 b ，有一个资源分配器提供调度，就可以叫做操作系统了。大概几千行的代码就能解决。
但是今天的 Linux ，是一个非常复杂的组织体系来支撑开发的。
FBDEV 貌似还是 CPU 运行的，运行效率还是慢。
建议还是等开源的 DRM 驱动。
我真的不建议在 console 下面实现 unicode 字符支持。
看来，你没弄明拜一直说的 ROM 是什么。
以嵌入式标准，QSPI 那个 16M 的 nor flash 就是 ROM。
而 CPU 内部还有一个固化的 ROM 。
也就是说 VF2 其实至少存在 2 个 ROM。
你现在不过是用 QSPI 的 ROM 和 CPU 内部的 ROM 混淆而已。
拿着 QSPI 的功能，去说 CPU ROM 功能如此之强。
实现 SD 卡启动，根本不需要 QSPI 内的代码，这是 CPU ROM 的功能。
而你说的 DTIM 作为内存对应的启动部分。我忘了叫什么，这是第一级的启动程序。用处就是读取二级 spi 程序。
所以包括 UART 传输启动程序，其实也是这个 1 级启动程序从串行口上读取二级程序并且运行的功能。
其实官方提供的 uart 恢复 bootloader 的界面，已经显示出来了恢复的是 second boot。
而前面讨论的所有 spi/uboot 实现的功能内容，全都是这个二级程序的事情。
你一直把 2rdboot 的程序功能，当作 CPU 内 ROM 的 core boot 程序功能做混淆。