 |
|
| 呀，你这专研技术的劲头，值得点赞！ |
2011whp 发表于 2024-11-28 13:13 神舟A470/K470(机型EHA4) USB-HDD的问题，是求道者在本坛先提出来的。 我就是为了查看实情，专门花了几百块从臭鱼上买来测试用。 |
红毛樱木 发表于 2024-11-28 12:40 在。电池/电源不行了，冷启要按2次开关。 都是烂大街的机子，臭鱼上应该还能找到，机型EHA4，花几百块能买。 |
wuwuzz 发表于 2024-11-28 07:26 创新发展，果然永不停息！ 继 CPU 收费开启某功能，主板也启动了 “按功能收费” 的政策。 只有想不到，没有做不到。 接下来的 “新时代”，会是怎样一个时代呢？ 请大家给出预测。 |
|
吐槽一下phoenix BIOS USB启动按模块收费政策。 这里的收费区分有： 1、USB 1.X低速、USB2.0高速分别收费。 2、USB-HDD、USB-ZIP、USB-LS120、USB-FDD等启动按模块分别收费。 第1个，通过G4D虚拟盘，加载DOS USB2驱动，然后加速PE载入速度解决； 第2个，就造成今天本贴这个局面。 神舟K470/A470是裁剪USB-HDD模块功能，但保留USB-ZIP、USB-LS120、USB-FDD模块； 联想F31A相反，保留USB-HDD模块，裁剪USB-ZIP等模块。 |
红毛樱木 发表于 2024-11-27 23:06 那就是同一个大话题。只不过当时还没有发现有0x00、0x81区别，本贴算是补全了。 |
求道者 发表于 2024-11-27 20:54 那就超出本贴范围了，这里还是针对神舟A470/K470说的。 其他BIOS就得看具体是啥情况了。 |
红毛樱木 发表于 2024-11-27 20:38 哪个问题？是在本坛说的，还是无奈U盘群里？ 这里的问题是，UD被BIOS屏蔽了，要有一个恢复环节，然后才能用PBR跳回去。 |
wuwuzz 发表于 2024-11-27 20:41 这又不一定只出现在笔记本上…… |
求道者 发表于 2024-11-27 20:32 就是这个意思额，笔记本有自己的键鼠(保底手段)， 所以外接USB键鼠的问题不是刚需。 |
wuwuzz 发表于 2024-11-27 20:23 笔记本上触控板和键盘走的PS/2或者I2C总线吧。 这部分又没被usb --init搞掉驱动…… |
求道者 发表于 2024-11-27 20:15 没用过这种USB鼠标选G4D菜单项的情况。 有这种菜单配置的话，可以发上来我实验一下外接USB鼠标。 不过A470/K470有内置键盘/触摸鼠标，应该问题不大吧。 |
wuwuzz 发表于 2024-11-27 20:13 你在grub4dos里也要用键鼠才能选择菜单项目啊…… usb键鼠挂了的话，这部分就没法用…… |
求道者 发表于 2024-11-27 20:09 这是个什么环境下的工具呢？ Linux也跟Win一样额，握手时加载OS自己的驱动。 DOS的话，倒是要考虑一下。 |
wuwuzz 发表于 2024-11-27 20:06 你进了fbinst又不一定是用PE，可能用别的工具也不一定。 键鼠寄了，就只能想办法了…… |
求道者 发表于 2024-11-27 20:02 usb --init只是在引导阶段起作用吧，等进PE时，这个G4D USB驱动会被卸掉， windows重新加载自己的USB驱动，USB鼠标应该就正常了。 |
本帖最后由 求道者 于 2024-11-27 20:03 编辑 wuwuzz 发表于 2024-11-27 20:01 倒也是能自动化…… 不过usb --init之后usb键鼠就挂了…… |
本帖最后由 wuwuzz 于 2024-11-28 07:08 编辑 求道者 发表于 2024-11-27 19:55 是啊，PBR故意装了G4D，把BIOS引入陷阱。 然后G4D usb --init重置U盘，MBR恢复。再chainloader (hd1)+1跳回MBR，正常引导。 |
本帖最后由 求道者 于 2024-11-27 19:59 编辑 wuwuzz 发表于 2024-11-27 19:50 直接在PBR里安装g4d的PBR引导块是吧？ 然后usb --int，用链式引导引导fbinst？ |
本帖最后由 wuwuzz 于 2024-11-27 19:59 编辑 求道者 发表于 2024-11-27 18:42 进度就是问题解决了啊。 当初，神舟K470/A470 BIOS的问题是你最先提出来的，现在USB-HDD可以满血复活， fbinst(UD)、Ventoy等复杂格式盘，原有内容不用改动，在普通可见数据区再加个 G4D做中介，就可以在这种BIOS下正常启动使用了。 |
不点 发表于 2024-11-27 15:02 我同意您的分析。 原始fd0是BIOS内置USB驱动产生，而新的0x81则是由G4D USB驱动生成，两个驱动是否会 产生潜在的重叠、冲突(或者说BIOS USB驱动无法被完整卸载，还残留有fd0空壳)，不得 而知，从结果看，有这种可能性。如此看来，此时还是屏蔽fd0比较好。 |
wuwuzz 发表于 2024-11-27 13:32 两种 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？不同的人，可能得到不同的结论。 |
|
本帖最后由 不点 于 2024-11-27 10:47 编辑 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 |
Powered by Discuz! X3.3
© 2001-2017 Comsenz Inc.
组图打开中，请稍候......
收藏
支持
反对
