无忧启动论坛

 找回密码
 注册
搜索
系统gho:最纯净好用系统下载站投放广告、加入VIP会员,请联系 微信:wuyouceo
楼主: 2011yaya2007777
打印 上一主题 下一主题

[原创] GRUB4DOS for UEFI

    [复制链接]
151#
发表于 2020-11-2 10:18:16 | 只看该作者
回复

使用道具 举报

152#
发表于 2020-11-2 10:28:30 | 只看该作者
本帖最后由 chenall 于 2020-11-2 10:33 编辑

我来迟了。

这个的工作量可不一般,太强悍了!
EFI核心的内容我不太了解帮不上忙^_^,只能在其它方面支持了。

关于代码的问题,我个人是建议直接开一个新的分支上传。

开新分支基本上的操作就是如 #61 的方法。

1. 首先备份当前代码数据(或直接生成补丁)
2. 然后清理当前代码让代码保留在github上的最后一个版本。
3. 开新分支git checkout -b efi
4. 恢复EFI版本代码(或恢复补丁)。
5. 添加所有修改的文件。 git add .
6. 提交本次改动。git commit -m "add efi support ...."
7. 上传新的分支。 git push -u origin efi

你的帐号应该是有上传的权限的。

评分

参与人数 1无忧币 +10 收起 理由
xyzxp + 10 很给力!

查看全部评分

回复

使用道具 举报

153#
发表于 2020-11-2 10:52:29 | 只看该作者
谢谢楼主分享
回复

使用道具 举报

154#
 楼主| 发表于 2020-11-2 11:04:00 | 只看该作者
如果UEFI下面能够实现map --mem xxx.vhd或者map xxx.vdf并启动,那UEFI-RAMOS就非常有意思

bios 版本就可以实现上述功能。测试了一下,uefi 版本同样可以实现。
vdf静态:map xxx.vdf (hd)
vdf动态:map --mem xxx.vhd (hd)
vdf差分:好像bios版本也不支持。

点评

我试过了直接map vdf,不带mem的这种,启动到BCD这里,如果采用NTFS单分区就会报0xc0000225错误。 如果采用激活的FAT32+NTFS双分区,则会报0xc000000f错误。 晚点我把菜单贴上来。 根据前面的微软知  详情 回复 发表于 2020-12-18 07:34
UEFI下面,map xxx.vdf (hd0)这个的确可以实现,主要问题是实现之后,windows无法从这个(hd0)上面继续启动,windows不认识这个磁盘,无法继续启动,卡在BCD那里出错了,错误代码忘记了,原因不明。  详情 回复 发表于 2020-11-2 13:32
回复

使用道具 举报

155#
发表于 2020-11-2 11:23:49 | 只看该作者
这个帖子顿时让无忧老潜水员们高潮了
回复

使用道具 举报

156#
发表于 2020-11-2 11:35:31 | 只看该作者
liuzhaoyzz 发表于 2020-11-2 08:36
efi是UEFI下面的可启动程序,用这个作为扩展名显然不合适!

我只是从可读性来说,不一定是efi结尾,也可以“”efi-“开头地文件,比如 efi-menu.lst efi-grub.cfg
回复

使用道具 举报

157#
发表于 2020-11-2 12:21:31 | 只看该作者
太好了,感谢YAYA
回复

使用道具 举报

158#
发表于 2020-11-2 13:32:49 | 只看该作者
本帖最后由 liuzhaoyzz 于 2020-11-2 13:35 编辑
2011yaya2007777 发表于 2020-11-2 11:04
bios 版本就可以实现上述功能。测试了一下,uefi 版本同样可以实现。
vdf静态:map xxx.vdf (hd)
vdf动 ...

        UEFI下面,map xxx.vdf (hd0)这个的确可以实现,主要问题是实现之后,windows无法从这个(hd0)上面继续启动,windows不认识这个磁盘,无法继续启动,卡在BCD那里出错了,错误代码忘记了,原因不明。

点评

试了一下,通过UEFI环境变量传递内存盘地址是可行的。 如图,我写了个小程序,在windows下获取grub2创建的内存盘地址。直接查看内存,是可以看到内存盘数据的。 问题是,我不会写windows驱动。 [attachimg]467781  详情 回复 发表于 2020-11-2 19:18
回复

使用道具 举报

159#
 楼主| 发表于 2020-11-2 13:48:32 来自手机 | 只看该作者
那增加--mem加载到内存,windows认识吗?

点评

也不认识啊。  详情 回复 发表于 2020-11-2 14:35
回复

使用道具 举报

160#
发表于 2020-11-2 14:35:50 | 只看该作者
2011yaya2007777 发表于 2020-11-2 13:48
那增加--mem加载到内存,windows认识吗?

也不认识啊。
回复

使用道具 举报

161#
发表于 2020-11-2 17:44:46 | 只看该作者
GRUB4DOS——难得的好东西,要是能适应UEFI启动,那就太棒了,若不能适应UEFI启动
回复

使用道具 举报

162#
发表于 2020-11-2 19:06:52 来自手机 | 只看该作者
yaya威武!
回复

使用道具 举报

163#
发表于 2020-11-2 19:08:17 | 只看该作者
Hello masters, while there was no problem in testing Grub4dos_UEFI with Qemu, I am also testing a real UEFI pc I get the following error please can a tell me the solution?

It appears in the upper left corner of the screen.

Hotkey for grub4dos by chenall, Oct 29 2020
Hotkey Installed!
回复

使用道具 举报

164#
发表于 2020-11-2 19:18:35 | 只看该作者
liuzhaoyzz 发表于 2020-11-2 13:32
UEFI下面,map xxx.vdf (hd0)这个的确可以实现,主要问题是实现之后,windows无法从这个(hd0)上 ...

试了一下,通过UEFI环境变量传递内存盘地址是可行的。
如图,我写了个小程序,在windows下获取grub2创建的内存盘地址。直接查看内存,是可以看到内存盘数据的。
问题是,我不会写windows驱动。

点评

我对底层的东西完全不懂,对于UEFI-RAMOS领域,需要的是懂得操作系统启动流程的大神们继续研究才行,现在的思路和原理似乎有两个: 1、grub4dos_UEFI或者grub2的map --mem xxx.vdf (hd0)加载vdf到内存,配  详情 回复 发表于 2020-11-3 09:20
以前稍微搞过这种东西…… 其实不仅是驱动的问题,重要的是如何让系统在第一轮驱动加载之前,让【bootmgfw.efi】正确的把【winload.efi】,【SYSTEM】读进内存。这是最麻烦的。 bootmgr时代,bootmgr是直接呼叫I  详情 回复 发表于 2020-11-2 21:28
回复

使用道具 举报

165#
发表于 2020-11-2 19:39:56 | 只看该作者
支持原创
回复

使用道具 举报

166#
发表于 2020-11-2 19:41:06 | 只看该作者
希望加入 exit命令
比如:shell 下引到这个 g4e 后,能用 exit 退回 shell  
(这个也是常用的)
回复

使用道具 举报

167#
 楼主| 发表于 2020-11-2 19:59:09 来自手机 | 只看该作者
可以在内存某个地址写入"$INT13SFGRUB4DOS" 字符串,以及映射表。不知道那些程序的内存搜索范围,还有没有判断的关键字。

点评

firadisk和svbus都不搜索内存,直接从中断向量表读。 这个位置在uefi下可能是不让写的。  详情 回复 发表于 2020-11-2 20:20
回复

使用道具 举报

168#
发表于 2020-11-2 20:20:47 | 只看该作者
2011yaya2007777 发表于 2020-11-2 19:59
可以在内存某个地址写入"$INT13SFGRUB4DOS" 字符串,以及映射表。不知道那些程序的内存搜索范围,还有没有 ...

firadisk和svbus都不搜索内存,直接从中断向量表读。
  1. intVector = ((INTERRUPT_VECTOR*)(VOID*)(virtAddr))[0x13];
复制代码

这个位置在uefi下可能是不让写的。
回复

使用道具 举报

169#
 楼主| 发表于 2020-11-2 20:44:46 来自手机 | 只看该作者
有可能不让写,关键是uefi环境没有int13接口呀。在0x4c处写一个指针?我已知有一个电脑把0-0x8000占用了。

点评

如果 uefi 让写,那应该是可行的。 我看 vgashim 和 grub2 的 fakebios 在 uefi 下模拟 int10h 就是在 0x40 的地方写了个指针。  详情 回复 发表于 2020-11-2 22:12
回复

使用道具 举报

170#
发表于 2020-11-2 21:28:25 | 只看该作者
本帖最后由 sunsea 于 2020-11-2 21:40 编辑
wintoflash 发表于 2020-11-2 19:18
试了一下,通过UEFI环境变量传递内存盘地址是可行的。
如图,我写了个小程序,在windows下获取grub2创建 ...

以前稍微搞过这种东西……
其实不仅是驱动的问题,重要的是如何让系统在第一轮驱动加载之前,让【bootmgfw.efi】正确的把【bcd】,【winload.efi】,【SYSTEM】读进内存。这是最麻烦的。

bootmgr时代,bootmgr是直接呼叫INT13来读第一轮的这些东西,然后由ntoskrnl.exe加载磁盘驱动,才切换进用磁盘驱动度盘。

现在不知道bootmgfw.efi怎么操作。可能需要调试确定。这一步搞定后面就比较好办了。

怀疑bootmgfw.efi可能调用了UEFI BIOS的相关功能。需要有技术的同志帮忙确定。

点评

这是最不麻烦的。 GRUB2 UEFI 的 map, wimboot, ntboot,GRUB4DOS BIOS 和 UEFI 下的 map, Syslinux BIOS 下的 memdisk 都能做到这个。  详情 回复 发表于 2020-11-2 21:57
回复

使用道具 举报

171#
发表于 2020-11-2 21:57:15 | 只看该作者
sunsea 发表于 2020-11-2 21:28
以前稍微搞过这种东西……
其实不仅是驱动的问题,重要的是如何让系统在第一轮驱动加载之前,让【bootmg ...

其实不仅是驱动的问题,重要的是如何让系统在第一轮驱动加载之前,让【bootmgfw.efi】正确的把【bcd】,【winload.efi】,【SYSTEM】读进内存。这是最麻烦的。

bootmgr时代,bootmgr是直接呼叫INT13来读第一轮的这些东西

这是最不麻烦的。
GRUB2 UEFI 的 map, wimboot, ntboot,GRUB4DOS BIOS 和 UEFI 下的 map, Syslinux BIOS 下的 memdisk 都能做到这个。

点评

如果已经UEFI下做到了,那就非常好,我们只需要接着搞磁盘驱动那一层了——我觉得修改SVBus使其能够从UEFI环境变量或者其他什么可靠参数传递渠道读地址的方案。 确实大概我对这些技术进展落后了。 BIOS下grub4  详情 回复 发表于 2020-11-3 11:54
回复

使用道具 举报

172#
发表于 2020-11-2 22:12:24 | 只看该作者
本帖最后由 wintoflash 于 2020-11-2 22:13 编辑
2011yaya2007777 发表于 2020-11-2 20:44
有可能不让写,关键是uefi环境没有int13接口呀。在0x4c处写一个指针?我已知有一个电脑把0-0x8000占用了。

如果 uefi 让写,那应该是可行的。
我看 vgashim 和 grub2 的 fakebios 在 uefi 下模拟 int10h 就是在 0x40 的地方写了个指针。
但是如果 uefi 有 csm,写了估计会爆炸。
回复

使用道具 举报

173#
发表于 2020-11-2 22:56:49 | 只看该作者
“firadisk和svbus都不搜索内存,直接从中断向量表读”
能不能这样:改一下firadisk和svbus直接从中断向量表读的那段代码,改成不读那里,而读UEFI环境变量。重新编译firadisk和svbus。
回复

使用道具 举报

174#
发表于 2020-11-2 23:16:42 | 只看该作者
要在主板里关闭安全启动吗?
回复

使用道具 举报

175#
 楼主| 发表于 2020-11-3 05:30:11 来自手机 | 只看该作者
重新编译firadisk和svbus。如果能这样做是最好的了。搜索1Mb以下内存,寻找特定字符串,定位映射表。
回复

使用道具 举报

176#
 楼主| 发表于 2020-11-3 05:38:35 来自手机 | 只看该作者
如果不行的话,看看0x4c处是否可写。如果可写,又被占用,得判断是否为csm占用。如何判断?仿真某个dos命令判断返回值?
回复

使用道具 举报

177#
 楼主| 发表于 2020-11-3 05:40:05 来自手机 | 只看该作者
目前不支持安全启动,需要关闭安全启动。
回复

使用道具 举报

178#
发表于 2020-11-3 05:47:32 | 只看该作者
这个好,
我还是喜欢 GRUB4DOS.
回复

使用道具 举报

179#
发表于 2020-11-3 09:11:09 | 只看该作者
怎么写入启动项,写个简单教程吧

点评

跟其他UEFI启动项是一样的操作。我知道的两个工具一个是bootice里的 UEFI / 启动项管理,另一个是DiskGenius里的 工具 / 设置UEFI BIOS启动项。 但这两个工具只是提供了功能,能不能起作用还要取决于主板的UEFI固  详情 回复 发表于 2020-11-3 20:57
回复

使用道具 举报

180#
发表于 2020-11-3 09:20:44 | 只看该作者
本帖最后由 liuzhaoyzz 于 2020-11-3 15:04 编辑
wintoflash 发表于 2020-11-2 19:18
试了一下,通过UEFI环境变量传递内存盘地址是可行的。
如图,我写了个小程序,在windows下获取grub2创建 ...

        我对底层的东西完全不懂,对于UEFI-RAMOS领域,需要的是懂得操作系统启动流程的大神们继续研究才行,现在的思路和原理似乎有两个:
1、grub4dos_UEFI或者grub2
_UEFI的map --mem xxx.vdf (hd0)加载vdf到内存,配合UEFI下的内存盘驱动,让windows识别这个内存盘,并从这个内存盘上面启动。这个启动流程类似于grub4dos的map --mem+firadisk/winvblock/subus磁盘仿真启动。这个需要人写驱动,估计需要很深的驱动开发、操作系统底层开发功底才行,这类人才估计也很少,这条路走下去有一定的难度,而且驱动速度的优化和提升可能还有很长的路要走。
2、
grub4dos_UEFI或者grub2_UEFI的map xxx.vdf (hd0)加载vdf到虚拟磁盘C:盘,windows从这个虚拟磁盘C:盘接着启动,加载内存盘驱动,比如primo驱动,由primo驱动把xxx.vdf加载到内存盘比如R:盘,这个xxx.vdf里面互换了C:盘和R:盘的mounteddevice,windows可以从这个内存盘C:盘继续启动,这个primo驱动是现成的,速度很快。这条路的问题是第一步grub4dos_UEFI或者grub2_UEFI的map xxx.vdf (hd0)加载vdf到虚拟磁盘C:盘,windows不认识这个虚拟磁盘C:盘,在BCD那里卡住了,后面的启动流程无法继续,这个仍然需要有懂得操作系统启动流程、对于RAMOS启动原理理解的大神做进一步的研究。

这两条路的区别是,第1个方案内存盘是由grub4dos/grub2创建的,而第2个方案内存盘则是由primo驱动创建的,相比较来说,第2条路似乎更有前景,因为驱动已经有了,万事俱备只欠东风,东风就是让windows识别grub4dos_UEFI或者grub2_UEFI的map xxx.vdf (hd0)仿真出来的虚拟磁盘,正常引导BCD。

为什么BIOS下面,grub4dos的map xxx.vdf (hd0),搭配内置了primo驱动的xxx.vdf,windows的bootmgr就能够正常识别这个(hd0)并继续启动BCD,而UEFI下面bootmgfw.efi就不能正常识别这个(hd0)并继续启动BCD?这个谜底如果被破解,那就很有玩头了。

BIOS下面grub4dos加载vdf的启动菜单是这样子的:
default 0
timeout 0
title vdf/SX100624
find --set-root /vdf/SX100624/D-RAMOS-2020-0915-15521.vdf
map --read-only /vdf/SX100624/D-RAMOS-2020-0915-15521.vdf (hd0)
map (hd0) (hd1)
map --hook
chainloader (hd0,0)/bootmgr

比较下UEFI下面,似乎没有实现磁盘映射map (hd0) (hd1)的功能?
但是我试了,不要这一句map (hd0) (hd1),RAMOS也能够正常启动,不明白这一句作用倒底是什么。



点评

Page 1 4. 在 UEFI 環境,可以從 0x80 以外的磁碟啟動,因此不需要交換磁碟操作,如 map (hd0) (hd1)。  详情 回复 发表于 2023-5-17 17:26
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 注册

本版积分规则

小黑屋|手机版|Archiver|捐助支持|无忧启动 ( 闽ICP备05002490号-1 )

闽公网安备 35020302032614号

GMT+8, 2024-11-26 12:42

Powered by Discuz! X3.3

© 2001-2017 Comsenz Inc.

快速回复 返回顶部 返回列表