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

wuwuzz

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。