(本帖原名：“用UEFI启动starfive_debian202510”，一边重复再现实验，一边完成文章，实验是有成功的，但实验中发现更简单更好的方法，所以就歪了方向，有些内容就不是UEFI的，我懒得更改内容了)
原生debian13.5 和 starfive_debian202510(利用debian13.5库已同步更新到相同版本)的主要区别有:内核版本、HDMI、GPU、VPU、UEFI。
自从我把原生debian13.5点亮、有HDMI显示后，就开始安装GPU驱动，调试到一半，发现在debian13.5安装旧版本GPU驱动是个大工程，因跨年跨版本较多，软件包的依赖极其复杂，可能有些旧包在debian归档库里都找不到了。所以决定改向，把starfive_debian改成UEFI启动，更简单、更快能使用上，我已经实验成功。
实验记录我不会写成新手指南，有些细节我就不写了，欢迎留帖提问。这个实验记录可能也适合VF2L，因为是同一个系统镜像，只是我没实验过。
实验准备：
1、用U盘烧录1个原生debian13.5 for riscv的安装镜像，下载链接是debian官网。
2、用U盘烧录1个starfive_debian202510镜像（国内下载， 国际下载），这个U盘是被改造成用于UEFI，镜像用TF或其他存储应该也是可以的，但U盘上启动运行系统，我只在原生debian for VF2上碰到过，所以我选U盘(有代表性)，也方便截图自证。
3、可选。用TF卡烧录1个starfive_debian202510镜像，镜像下载同上。这个镜像是用于救援的，因为QSPI会被刷成debian官方提供的uboot，刷完后，如果需要用starfive-debian，可以不刷回starfive的QSPI，把启动开关拨到SD位置，跳过QSPI，强制使用TF卡引导，可以引导starfive-debian，或目前版本的archlinux-cwt25。
4、可选。从VF2连接到另一台电脑的串口通讯线。这个不是必须的，刷QSPI可以不用串口线；如果改造过程顺利，也可以不用另一台电脑加入调试；如果过程不顺利，也可以用原生debian安装盘从USB启动，或者用starfive-debian从TF强制启动，去修复改造中的U盘。当然，如果手边有串口线更好。
更新 U-Boot文档到SPI Flash memory
1、debian官网 wiki文章，更新uboot的。利用原生debian的技术去改造starfive-debian。只需要看下图这个区域，观看并下载完uboot文档后，点击文章中第一个链接去更新。
新页面选 StarFive VisionFive2
新页面文章里比较完整的提供了几种更新flash方法。我推荐用最简单的（不需要串口线），从准备3烧录的TF卡启动到debian os，在系统里更新，方法在文章尾部，如图。注意，如果不确定VF2原有flash是适配那个操作系统的，可以选用启动开关0:1，强制从SD启动。
2、更新完后关机，并把VF2启动开关拨到0:0位，也就是两个开关全部朝向cpu。
3、可选项。如果没有串口线，可以跳过后续，等待改造。如果有串口线，可以把准备1的原生debian13.5安装盘插到usb，然后开机启动试试，原生debian13.5是没有HDMI显示输出的，只能通过串口线从另一台电脑操作。原生debian安装操作，可以返回debian官网 wiki文章查看。
改造1
我最初的实验，就是奔着用UEFI启动starfive-debian, 在第一次改造用UEFI启动成功后，又做了几次复现实验，发现个意外的现象，经多次确认，debian官方的uboot，是可以直接启动starfive-debian202510的，使用非UEFI方式启动，只能是U盘上的202510, TF上不行；原生202510有个启动参数错误，造成不能从U盘启动进入桌面系统，HDMI能显示启动过程。所以改造1不是改成UEFI启动，是如何修复那个错误参数。如果有网友已经把前置准备都做好，可以自己试试这个现象，刷完debian官方uboot，把准备2的U盘202510插入USB, 开机启动就能看见错误信息。修复方法如下（单选）：
1、把待改造的U盘挿入另一台llinux电脑，挂载U盘上第三分区，编辑extlinux/extinux.conf 如下图一样，VF2上只插入单个启动U盘，可以确定是/dev/sda。改好存盘，把U盘插回VF2开机，等几秒就能看到绿灯闪烁，屏幕有加载信息。有串口线更好。
2、用准备3的救援TF卡启动到系统里，挂载待改U盘，如上修改启动参数，存盘重启。
3、用准备1的原生debian安装U盘启动，grub菜单界面选救援模式启动，待改U盘在系统启动前不挿入，在安装程序检查存储前挿入。在救援模式菜单选待改U盘的第4分区为救援环境，进入，挂载待改U盘第3分区，如同上面修改启动参数，存盘重启。（补充20260616）之前的文章里提到过，原生debian安装盘在VF2上是没有显示输出的，需要串口线辅助，这里再说一次。
4、（20260616补），如果有串口线又熟悉busybox，可以在启动错误停止时，利用串口线及 vi 编辑修复错误配置。
哈哈，就是这么简单。不想再弄UEFI的，可以跳到后面看改后须知。
我很郁闷，折腾UEFI费力。当然，折腾UEFI还是有用的，至少在TF、eMMC、NVME外，又多了USB系统运行存储，还能单盘多重系统。而且我猜测，starfive大概率不会再开发新的VF2/VF2L镜像，毕竟starfive是硬件商不是系统开发商，starfive应该不会对系统开发投入太多，starfive现在方向是推JH-8100（B100）；中国的系统开发商对VF2/VF2L又是出工不出力，以后的新系统就指望原生debian，debian又是主推UEFI的，把starfive-debian改UEFI就是向标准靠拢。这篇文章大体完成，随后真正的改UEFI，我会继续写完，毕竟实验都完成并成功，标题留着，我会把坑填上，而且还有延伸试验待做。
改造2
再次实验，发现准备3中那个原用于救援的TF卡(starfive-deian202510), 用debian原生uboot引导，也会出现与改造1中相同引导错误，参照改造1的方法修改就行了，区别就是把/dev/sda4替换成/dev/mmcblk1p4。
改造3
实验复现中，实验纪录文章编写中。。。。。。
改造后须知
1、在第一次启动后，修改debian库源之前，需要按starfive官方提供的方法，对升级进行第一级保护。
sudo nano /etc/apt/preferences.d/sf-debian.pref
Package: *
Pin: origin “debianrepo-t.starfivetech.com”
Pin-Priority: 1001
2、在长期使用中发现，有官方提供的一级保护是不够的。例如原生202510版本里可以安装支持VPU解码的mpv 0.35.1，在vf2上mpv比vlc更易用，upgrade后，不能保证mpv版本；再有，一级保护只能保证新版本不能覆盖旧版本，但它不能保证被自动卸载，所以需要二级保护hold，hold mesa*、mpv、vlc*、ffmpeg。
3、安装timeshift做第三级保护。
4、警告:因starfive-debian202510，到现在已经存在有8个月，vf2 GPU驱动需要的mesa22.3.6已经跨越多年，如果把starfive_debian直接升级到debian13.5，又为了保证GPU VPU运行正常，需要要放弃gdm3和gnome，upgrade会卸载它们，因为某些依赖不能满足（半年前是可以的）。labwc、sway、wayfire能正常运行，weston gnome kde不能。
5、202510的内核，有可能在升级后，需要重新配置sudo dpkg-reconfigure linux-image-6.12.5-starfive ，特别是在 ls /dev/dri 输出没显示renderD128的时候。重新配置时会修改extlinux.conf为错误，需注意。ps:/boot平时不挂载更好，需要升级内核/改变grub.cfg时才挂载。
6、linux-image-6.12.5-starfive的内核是有严重漏洞的，内网用户不需要担心，公网用户目前可以考虑升级第三方内核。第三方内核之前我在原生202510测试，是可以支持GPU VPU的。但在改造后的202510还没做测试。
新实验计划：
1、用UEFI启动nvme上的starfive-debian, 理论上大概率可行，待有空做实验验证，时间未定。
2、用UEFI启动上eMMC上的starfive-debian, 理论上大概率可行，待有空做实验验证，时间遥远，我无闲置eMMC,Rpi4B在用。
3、用UEFI启动U盘上的archlinux-cwt25, 理论不确定，万一又有惊喜呢,时间待定。（实验完成，用debian原生uboot可以启动U盘和TF卡上的archlinux-cwt25,完美启动，没有错误信息）
4、用UEFI启动NVME上的archlinux-cwt25, 理论不确定，万一又有惊喜呢,时间待定.
2026.6.15 16：00 完成第一次编写，留改造2、3两个坑。
2026.6.16 19：30 把改造2写了。然后archlinux-cwt25的实验也完成2个。现在有些不想写改造3了。
