请yaya看看，g4d usb驱动未能将U盘盘号0x00映射到0x81

wuwuzz

2024.11.27更新解决：
usb --init之后，如果U盘盘号仍然是0x00，那么，可接续使用map (0) (0x80)，即可达到想要效果。

=====================================原来的问题：

1、很久以前yaya说过"加载g4d的usb驱动，驱动会将盘符A映射到C"，这个功能很有用，正好能解决神舟
A470/K470笔记本BIOS的bug[即:BIOS始终把U盘当移动盘(软盘)处理，跳过MBR，导致UD、Ventoy失败]，
之前测试SMI U盘时0x00能成功映射到0x81。直到今天，无意中换其他SMI U盘、Alcor6989 U盘测试，
usb --init之后，U盘盘号均未能像以前一样,被映射为0x8?，而是保持为0x00，见下图。测试机：
神舟A470/K470笔记本，G4D为最新0.4.6a 2024-02-26。



2、目前的临时措施，是对U盘做手术，量产分割为2个Lun，usb --init之后，会出现0x00、0x81两个磁盘
设备，然后再调整root为0x81所在设备(hd1,0)，有些笨拙。


======================================================================

问：不知yaya能否对此做改进，消除0x00，强制设定盘号为0x8?

不点

我插言几句，不知是否有用。

usb --init 是执行 yaya 自己的代码。无论生成的是软盘 00h，还是硬盘 80h、81h，都不必害怕、担忧。

因为此时虚拟盘的 BIOS int13 代码是 yaya 自己写的，肯定会遵守 CHS、LBA 调用规范。无论 usb --init 生成的虚拟盘是软盘还是硬盘，都没问题。

wuwuzz

不点 发表于 2024-11-25 21:35
我插言几句，不知是否有用。

usb --init 是执行 yaya 自己的代码。无论生成的是软盘 00h，还是硬盘 80h ...

不行额，您没看清题目啊。

神舟buggy BIOS下，0x00会导致MBR被跳过，UD、Ventoy等格式盘特色会被废掉，引导失败。
(http://bbs.wuyou.net/forum.php?mod=viewthread&tid=437567)。

只有以usb --init为中转，人为调整映射为0x8?，恢复固定盘属性，才能对付BIOS bug，
正常读MBR，挽救UD、Ventoy格式盘。

不点

wuwuzz 发表于 2024-11-26 02:57
不行额，您没看清题目啊。

神舟buggy BIOS下，0x00会导致MBR被跳过，UD、Ventoy等格式盘特色会被废掉 ...

我再试试，看看能否有帮助。

usb --init 的工作任务，（在用 int13 读 USB 盘数据时）不就是取代（接管）主板 BIOS 吗？否则，运行 usb --init 有啥用？

usb --init 运行后，无论创建的是什么盘（软盘 00h，硬盘 8?h），都能够正常使用了。不存在 MBR 被跳过的问题。因为 yaya 的 usb 驱动代码会从 USB 的首扇区开始建立虚拟盘( 00 或 8?h)。

假如 usb --init 之后，新创建的 00 或 8?h 盘不是从 USB 设备的首扇区开始访问 USB 设备，那么，这属于 yaya 代码的 bug。这样的话，您想通过 usb --init 来解决问题，就是不可能的了。这需要 yaya 先解决 bug，然后才能实现。

在 grub4dos 下，软盘和硬盘的处理方式是一样的。软盘可以带有 MBR 和分区表，这种情况，可以使用 (fd0,0)、(fd0,1)、(fd0,2)、(fd0,3)、(fd0,4) 等等来访问软盘上的那些分区（里面的文件）。同理，如果硬盘没有 MBR 和分区表，那么，硬盘上的“卷”直接就是 (hd0)【就像软盘那样】，而不是 (hd0,0)、(hd0,1)、(hd0,2) 之类的。

我猜，有可能是这个 00 软盘，把您给吓到了。其实您只要不害怕它就行了。

有鉴于您已经进入 grub4dos 环境，因此，您这里的问题，都是小 case，不是真正的大问题，不是“过不去的坎儿”。

不点

主板 BIOS 创建的盘（或者说是主板 BIOS 自带的盘），是“真实”盘。其他“第三方软件”（例如 grub4dos、memdisk 等）创建的盘，那都是虚拟盘。

如果不曾使用 map 命令创建虚拟盘，那么，grub4dos 只能使用 BIOS “原装的”、“自带的”盘。

如果使用 map 创建了某个盘号，或者使用 usb --init 创建了某个盘号，这都属于虚拟盘。在 grub4dos 下访问这些虚拟盘时，都需要调用 grub4dos 的“虚拟盘扇区读写”代码。这是 grub4dos 开发者自己写的代码，肯定是经过锤炼的，（主观上）不会让它像“恶意”主板那样因“破坏规范”而“毛病百出”【存在 bug 的话，是另外一个问题】。

举例来说，假定在 grub4dos 下有个 00 虚拟盘（软盘），就可以尝试这样来启动它：

chainloader     (0)+1
rootnoverify     (0)
boot

也可以先尝试把软盘 0 仿真为硬盘 80h，然后启动虚拟硬盘：

map       (0)        (0x80)
map       --hook
chainloader        (0x80)+1
rootnoverify          (0x80)
boot

硬盘盘号 0x81 通常不适合用作启动盘，因此，它也需要仿真为 0x80 才能启动：

map       (0x81)        (0x80)
map       --hook
chainloader        (0x80)+1
rootnoverify          (0x80)
boot

guong

来看看了

不点

只有以usb --init为中转，人为调整映射为0x8?，恢复固定盘属性，才能对付BIOS bug，
正常读MBR，挽救UD、Ventoy格式盘。

任何启动方案，都有其局限性。超越了限度，那就无解。“挽救”，属于 “变通”，属于“走旁道”。

有许多真正难以对付的情况，那就是，根本无法启动到 grub4dos 的环境下。

您遇到的这个情况，属于 “上好” 的情况，而不是 “很差” 的情况。无论如何，您能够（动用一些方法而）进入 grub4dos，这样就可以在 grub4dos 下开展工作，自由度是 “满满” 的。

那么，在 grub4dos 下，也可以进入 PE， 不是吗？也可以进入 Windows，不是吗？既然这样，【粗略地说】那就算是 “没问题” 了。当然，如果非要追求某种 “极致” 的体验，非要启动或运行 某某某 软件，那可能还需要继续努力 “解决问题”。

wuwuzz

不点 发表于 2024-11-26 07:28
我再试试，看看能否有帮助。

usb --init 的工作任务，（在用 int13 读 USB 盘数据时）不就是取代（接 ...

您还是没有理解，我的主题、目标不是这个。

1、首先复述一下神舟K470/A470 BIOS BUG影响。
这种BIOS所配USB-HDD模块不完整，它可以正常工作到设备类型判定(U盘被设定为HDD)，但紧接着的流程
就不对了：不作为固定盘处理，而实际是按移动盘处理。也就是说，BIOS菜单项虽然显示是USB-HDD，
但实际是空壳，没有固定盘属性。选中后，BIOS将按移动盘处理，没有把控制权移交给MBR代码，U盘将
从PBR上引导(其中:LBA0会映射到第1分区第1扇)。即使MBR会被读，但其引导流程不会像预先设计的那样，
被正确执行。

具体过程，yaya做过分析，如下：
经过BIOS自己的判断，认为U盘是可移动设备，因此分配盘符A，隐藏第一个分区之前的扇区，修改（确切地说是减少）总扇区数，
修改第一个分区（PBR）的参数表（BPB），具体是修改偏移0x1c处的4字节隐藏分区值。以求道者的UD为例，是将0x4000修改为0。
然后把控制权移交给PBR代码。此时，使用int13/ah=42读LBA(0)，由于隐藏了第一个分区之前的扇区，现在LBA(0)指向第一个分
区（PBR），因而不是返回MBR代码，而是返回PBR代码。BIOS根本就没有把控制权移交给MBR的代码，因此UD的引导代码没有起
作用，隐藏分区的启动菜单及文件也没有使用，UD启动失败。wuwuzz注：Ventoy磁盘布局也类似推导，Ventoy引导代码也将无法
获得控制权，因为流程被BIOS指向到第1(数据)分区PBR上了。

2、应对方法：利用usb --init恢复固定盘属性
G4D将被安装到PBR上(也就是位于UD、Ventoy盘的普通数据区)。这个G4D在U盘被设定为0x00时，可以
正常单独引导为A:>，但不是我们所需要的。我们装它的目的，是为了中转，将计就计把buggy BIOS
引到PBR上的G4D。G4D在这里设了陷阱(执行usb --init)。

usb --init的作用，是为了将盘号由0x00改为0x8?，这样就能把USB-HDD失去的固定盘属性给找补回来，
让USB-HDD满血复活。此时，USB-HDD上原有的Ventoy、UD的磁盘布局内容无需做任何改动，就可以利用
g4d的find重新定位、跳转到其MBR上，正常执行了，从而达到挽救Ventoy、UD资源的最终目的。

wuwuzz

不点 发表于 2024-11-26 09:45
任何启动方案，都有其局限性。超越了限度，那就无解。“挽救”，属于 “变通”，属于“走旁道”。

...

本帖描述的场景，PBR上的G4D可以单独引导成功到A:>，但不是我们需要的。
(我们的目的，不是G4D单独引导成功，也不是为了PE)。

我们的目的，是如何以最简单的操作，保护利用已有的大量UD、Ventoy资源，
让其在这种Buggy BIOS下引导成功，实现最初设计的引导流程。

这里的最简单操作，是指保留UD、Ventoy原有磁盘布局不动，不再费事重新
制作。
=================================================================
本方案也没有超越限度，而只是现有功能叠加、组合，从而实现对付
BIOS BUG的中间目标。

不点

wuwuzz 发表于 2024-11-26 09:54
您还是没有理解，我的主题、目标不是这个。

1、首先复述一下神舟K470/A470 BIOS BUG影响。

明白了。

关注的焦点不同。

我关注的是 “基本层面”，即，“能否成功启动” 的问题。属于 “温饱” 问题。

您关注的是 “提高层面”，即，属于 “高质量发展” 方面的问题。

真是抱歉，我并不关注 “高质量发展” 方面的问题。

好吧，不打扰了，我就不再参与讨论了。

wuwuzz

不点 发表于 2024-11-26 10:38
明白了。

关注的焦点不同。

您太谦虚客气了，我觉得您在5#的讨论发言，很有启发指导意义啊。

map(0) (0x80)方法，我还没来得及实际测试，如果能成功，就要比
usb --init方法，更加简单、可靠。这是很好的事啊！

所以，我还是希望您能留下来继续指导，虽然各人关注侧重点、实现方法
不太一样，但殊途同归，最终的本质是一致的：对付BIOS BUG。

2011yaya2007777

问：不知yaya能否对此做改进，消除0x00，强制设定盘号为0x8?

讨论得挺热闹。
好长时间不接触usb驱动了，带有注释的原始代码也不知道在哪个旧电脑硬盘上。

最初阶段，usb驱动是最先加载的，它可以将启动盘号设定为0x80。后来就是先加载g4d代码，如果有“usb --init”参数，再加载usb驱动，此时已经不可能改变启动盘号了。

我个人觉得，即便设定盘号为0x80，也解决不了你提出的问题。
你是不是想通过usb驱动，去读取逻辑0扇区？这视乎可以办到，但是目前没有这个功能，需要你编写汇编代码。
你是不是想通过usb驱动，跳转到逻辑0扇区，去执行UD、Ventoy盘的代码？如果增加了汇编代码，视乎可以跳转到逻辑0扇区。但是UD、Ventoy盘通过int13读磁盘，会出现错误的，前面你已经提到了。

我觉得你已经启动成功，获取了控制权，就算很好了，可以想干自己的任何事情了！
如果是纯粹技术探讨，非要启动UD、Ventoy，我觉得应当研究UD、Ventoy启动代码，怎么去跳转到UD、Ventoy。就如grub与grub2相互跳转一样。好像UD前面的代码是做了一些测试，然后就跳转到一个固定的扇区。可以使用批处理或者外部命令替代测试工作，然后跳转到这个固定的扇区。

不点

首先，legacy BIOS 已经被冷落了、靠边站了。逐渐地，要被 UEFI 取代。因此，在 BIOS 上投入精力，效益不高，不划算。这些 buggy 电脑，只能 “自救”，不能指望有太多的开发者去为它们 “服务”。就让它们自生自灭吧，反正也没有前途了，迟早要毁灭。

其次，以往的那些启动方案，凑合着可以应付这些 buggy 电脑。这些电脑也不需要 “高质量发展”，因为它们自己给自己的定位就是 “低质量” 的。这些电脑的生产者都不考虑这些问题，我们作为普通的 “爱好者”（局外人），如果还要为它们 “擦屁股” 的话，我觉得那是 “过网击球”（手臂伸得太长了）。

不点

wuwuzz 写的帖子很认真、很仔细，也很长。世风日下，现在很少有这样 “严肃认真” 的人了。就连那些大公司，都在想着如何通过 “诈骗” 来盈利，而不是通过提高产品的技术含量来盈利。从某种程度上来说，我和 wuwuzz 属于同一类型的人。但我已经在走下坡路了，自然规律是无法抗拒的。

wuwuzz

2011yaya2007777 发表于 2024-11-26 15:37
讨论得挺热闹。
好长时间不接触usb驱动了，带有注释的原始代码也不知道在哪个旧电脑硬盘上。

欢迎ya大前来指导！实验结果与您的说明有所不同。

这个buggy BIOS，因为裁剪，USB-HDD功能缺失，会把HDD当成FDD处理，只从PBR上引导
(PBR上装啥就引导啥，可以获得控制权)。而Ventoy、UD因为磁盘布局的特殊性，需要
从MBR上引导。所以，在此buggy BIOS下，要借助usb --init重置USB，只要盘号为0x8?，
USB-HDD就“自动”恢复正常，无需增加汇编代码，就可以跳转到MBR[用chainloader (hd1)+1]，
正常启动Ventoy、UD了。

另外，补充2个刚做的测试结果(用bootice做引导盘，在此buggy BIOS下)
1、个别U盘，如果MBR、PBR均为g4d，则usb --init之后，盘号为0x00; 同一U盘，如果MBR为
Ventoy、PBR为g4d,则usb --init之后，盘号为0x81。原因不明。

2、usb --init后，若盘号仍为0x00，执行不点大在5#讲的map (0) (0x80)；chainloader操作，
会达到想要效果。但如果不执行usb --init，直接map (fd0) (hd0)；chainloader则会出错，
达不到想要效果。

wuwuzz

不点 发表于 2024-11-26 17:30
首先，legacy BIOS 已经被冷落了、靠边站了。逐渐地，要被 UEFI 取代。因此，在 BIOS 上投入精力，效益不高 ...

1、其实自始至终，我有兴趣、想掌握的是USB。之所以"看上去"谈论BIOS/UEFI启动方面的内容多，
是因为它们正好是USB具体应用，其算法对掌握USB帮助很大，我并不关心BIOS/UEFI的未来，
对我而言，它们的价值只在于USB。

2、本贴主题，本来不该出现，是半路加塞杀出来的。那么最初想谈的内容是什么呢？和您有关
--就是前几天那个LBA/CHS话题。

当时我有点意犹未尽，回去就想用Pheonix BIOS机(知道源码算法)做实例，结果实际上机验证出了意外。
第1台Pheonix BIOS机(二手联想F31A)出来的CHS结果大乱，与我以前测试结果不同、也与已知算法不同。
怀疑它硬件老化，出了溢出错误。那只好拿手头第2台Pheonix BIOS机(也就是本贴神舟A470/K470)
来验证，CHS结果符合预期。但它也有意外，就是突然发现有些U盘usb --init之后不能确定盘号为0x8？，
导致我不能顺利使用wdtb.exe（一个西数出的DOS查HDD软件，用在此场景，就可以直观显示USB-HDD的
INT13、扩展INT13结果）。所以，只好翻旧账，先解决这个改盘号、复活HDD的问题。

wuwuzz

不点 发表于 2024-11-26 17:47
wuwuzz 写的帖子很认真、很仔细，也很长。世风日下，现在很少有这样 “严肃认真” 的人了。就连那些大公司 ...

前面您过奖了。后面确实如此，本质上是同一类较真的人，我也在走下坡路，年龄增长、身体素质下降，
我刚参加工作时接触的那些同事，近2年都已逐渐退休了，莫名地怀旧伤感。

2011yaya2007777

这么说使用不点大推荐的交换磁盘方法解决了问题，可喜可贺啊！

2011yaya2007777

使用  usb --init 后，交换磁盘才起作用，是因为此时读u盘不使用int13，而是使用内部命令。这样就绕过了有bug的BIOS。

wuwuzz

2011yaya2007777 发表于 2024-11-27 05:37
这么说使用不点大推荐的交换磁盘方法解决了问题，可喜可贺啊！

单独使用交换磁盘不行，需要叠加usb --init才可以。所以，是2位大佬的成果双剑璧合、
共同发挥作用才解决的。再次谢谢两位的关注！

不点

交换磁盘盘号，是 grub4dos 在 BIOS 下的一个 “奇技淫巧”。其实，这是最基本的操作了，就连原始的 gnu grub legacy 都具有 “交换盘号”的功能。因此，这属于“必须掌握”的知识，而且要熟练。

真正的“奇技淫巧”，是 (fd0,0)、(fd0,1) 等“软盘分区”的概念，以及 (hd0)/path/to/file 的用法。

前者是软盘 00 带有分区表的情况，此时 grub4dos 就可以访问软盘各个分区下的文件。比如 (fd0,0)/path/to/file。

后者是硬盘不含分区表的情况，就像软盘那样。正是由于 hd0 不含 MBR 扇区（分区表），因此就不能使用 (hd0,0)、(hd0,1) 之类的设备表达法。

wuwuzz 描述的情况，可能是这样的：BIOS 把软盘的第一扇区（扇区号 0）定位在 U 盘第一分区的第一扇区，MBR 磁道不可见。因此，ud 和 Ventoy 就“不存在”了。直接把 00 仿真为硬盘 80h 没有用，因为 MBR 磁道是“不存在”的（总不可能是负的扇区号吧？比如扇区号为 (-63)？）。

运行 usb --init 之后，新的虚拟软盘 00 的首扇区（扇区号 0）是从 U 盘的 MBR 开始的，也就是说，此时 MBR 磁道是可见的、存在的，而不是被屏蔽掉的；那么此时软盘 00 就含有分区表了。既然这样，就可以用 (fd0,0)、(fd0,1) 等来访问软盘上的分区“卷”了。 当然，如果用 map 把 fd0 映射为 hd0，在 map --hook 以后，就可以用 (hd0,0)、(hd0,1) 等等来访问虚拟硬盘上的分区“卷”了。

2011yaya2007777

你重启UD、Ventoy的方法领教了。我原来以为多复杂。高手啊。

wuwuzz

不点 发表于 2024-11-27 07:43
交换磁盘盘号，是 grub4dos 在 BIOS 下的一个 “奇技淫巧”。其实，这是最基本的操作了，就连原始的 gnu gr ...

不点大分析很正确。

最初BIOS因缺陷，屏蔽了MBR(导致ud、Ventoy无法按预设流程启动成功)，
usb --init执行时，重新枚举驱动U盘(此过程可以用硬件USB协议分析仪看到)，
等于是废除了BIOS“原有”桎梏，MBR重新可见，后续启动就可以按正常流程走了。

wuwuzz

2011yaya2007777 发表于 2024-11-27 07:48
你重启UD、Ventoy的方法领教了。我原来以为多复杂。高手啊。

您过谦了，关键还在您的usb --init啊！ 后续 chainloader就是常规操作了。

不点

wuwuzz 和 yaya，都拥有对 USB 硬件进行操作的知识。这非常宝贵。尤其是在 Linux 的情况下，由于 Linux 不使用 BIOS，那么就必须直接使用 USB 硬件协议。

如果仍然需要在 Legacy BIOS 下进入 grub4dos 进行操作，我觉得应该掌握 grub4dos 的一些常规手段，方便自己进行 hack 研究。可以研究一下置顶的 grub4dos 文档、教程。

比如 cat --hex 命令，这能够显示扇区数据：

cat --hex (fd0)+1 显示软盘的首扇区（扇区号为 0 的扇区）
cat --hex (fd0)1+1 显示软盘的第二扇区（扇区号为 1 的扇区）
cat --hex (fd0)2+1 显示软盘的第三扇区（扇区号为 2 的扇区）

再比如，在执行 usb --init 之前，看看 BIOS 提供的（原始的）真实软盘的扇区内容是啥：

cat     --hex     (fd0)+1

它显示的应该是 U 盘第一分区的首扇区（PBR）的内容，而不是 MBR 的内容。

而在执行 usb --init 之后，再来看看 usb 命令创建的虚拟软盘的扇区内容是啥：

cat     --hex     (fd0)+1

此时它显示的应该是 U 盘 MBR 扇区的内容，而不是第一分区的 PBR 的内容。此时，假定软盘的首扇区确实是 MBR（含有分区表），那么，就可以继续用下面这条命令来显示软盘第一分区 PBR 的内容：

cat     --hex     (fd0,0)+1


假定软盘上也存在第二主分区，同理，可以用如下命令来显示第二主分区的 PBR：


cat     --hex     (fd0,1)+1

wuwuzz

不点 发表于 2024-11-27 10:21
wuwuzz 和 yaya，都拥有对 USB 硬件进行操作的知识。这非常宝贵。尤其是在 Linux 的情况下，由于 Linux 不 ...

按照您的想法，准备了2套图片。每套图片，均顺序反映usb --init前后的情况。

第1套图片，与您在25#设想完全一致。环境：启动盘用bootice制作，MBR装的g4d、
PBR装msdos；usb --init之后，U盘盘号保持为0x00(如果DOS下想A变C，需要map)







第2套图片，与您在25#原理一样，只不过usb --init后盘号变为0x81。环境：
启动盘用ventoy制作，MBR由ventoy生成、PBR装的g4d；U盘盘号变为0x81后，MBR
重新激活可见。不需要map，原始fd0将不可访问。






以上，U盘为同一U盘，BIOS为神舟A470/K470 buggy bios。

不点

wuwuzz 发表于 2024-11-27 13:32
按照您的想法，准备了2套图片。每套图片，均顺序反映usb --init前后的情况。

第1套图片，与您在25#设 ...

两种 U 盘制作方法，在执行 usb --init 之前，没有表现出差别，BIOS 盘号都是 fd0，而且都是屏蔽掉 MBR，只有 PBR 可见。

但在 usb --init 执行后，出现了差异。

虚拟盘的盘号不同：00 和 81h

当 usb 虚拟盘盘号是 00 时，覆盖掉了 BIOS 原始的 00 软盘。由于虚拟盘 00 具有 MBR（分区表），所以虚拟盘的内容是硬盘格式，不是软盘格式。

当 usb 虚拟盘盘号是 81h 时，原始的 BIOS 软盘 00 未被覆盖，仍然存在。但却无法访问了（disk read error）。我贸然猜测，这有可能是因为 usb 驱动程序的代码执行以后，影响了 ROM BIOS 代码的执行，导致 ROM BIOS 无法正常访问 USB 设备。既然 00 无法访问了，那我觉得，此时还是屏蔽掉 00 比较好。即使不屏蔽掉 00，也不要去访问它了。

另外，我估计这种 BIOS 有很多。所以，这个 BIOS 究竟算不算 buggy BIOS？不同的人，可能得到不同的结论。

wuwuzz

不点 发表于 2024-11-27 15:02
两种 U 盘制作方法，在执行 usb --init 之前，没有表现出差别，BIOS 盘号都是 fd0，而且都是屏蔽掉 MBR， ...

我同意您的分析。

原始fd0是BIOS内置USB驱动产生，而新的0x81则是由G4D USB驱动生成，两个驱动是否会
产生潜在的重叠、冲突(或者说BIOS USB驱动无法被完整卸载，还残留有fd0空壳)，不得
而知，从结果看，有这种可能性。如此看来，此时还是屏蔽fd0比较好。

求道者

现在有啥进度？fbinst能复用吗？

wuwuzz

求道者 发表于 2024-11-27 18:42
现在有啥进度？fbinst能复用吗？

进度就是问题解决了啊。

当初，神舟K470/A470 BIOS的问题是你最先提出来的，现在USB-HDD可以满血复活，
fbinst(UD)、Ventoy等复杂格式盘，原有内容不用改动，在普通可见数据区再加个
G4D做中介，就可以在这种BIOS下正常启动使用了。