讨论：bios识别U盘以及过程，具体是什么？

zleafz

首先，问题是有些U盘格式化成HDD能启动，有些又是ZIP，还有FDD等等。这里就有个疑问了，
BIOS凭什么知道U盘当前是什么格式的呢？

然后，既然BIOS能区别U盘格式，那么可以这样说是不是：不管你U盘是什么格式，能不能启动，
BIOS在启动时候都会去检查U盘的参数。说到这里，好像又回到开始那个问题了，BIOS究竟靠检查U盘上扇区上的什么信息来判断U盘格式？还是不靠判断扇区，而是另外什么的？严重困惑中！

敬请大家各抒己见，高人点评

h8jyuq

原帖由 zleafz 于 2008-7-2 04:32 PM 发表
BIOS究竟靠检查U盘上扇区上的什么信息来判断U盘格式？

BIOS不靠检查U盘的扇区去判断U盘格式。BIOS和U盘主控直接通讯，然后根据主控返回的信息确定U盘的格式。

zleafz

原帖由 h8jyuq 于 2008-7-2 06:52 PM 发表


BIOS不靠检查U盘的扇区去判断U盘格式。BIOS和U盘主控直接通讯，然后根据主控返回的信息确定U盘的格式。

那U盘的各种格式意义有何在呢？这位朋友的意思是不是主控里面包含了U盘的格式？

netwinxp

以下纯属个人理解，细节部分请上网下载Universal Serial Bus Mass Storage Class UFI Command Specification标准文档(PDF格式)。
BIOS通过USB总线(2.0的是通过EHCI USB)向USB存储设备发送UFI指令来和它进行交流的。
其中MODE SENSE Command(5AH)就是你所说的媒体介质、模式检测功能，在返回的数据包中包含了一个Media Type and Write Protect块里面有介质描述符的字节(该字节在格式化的UFI命令包中可以指定)，BIOS就是根据这个来确认U盘的类型和是否有写保护等。
系统对USB存储设备访问是采用一种叫LBA的地址(目前采用的是LBA28)，并没有所谓的CHS，windows、linux等访问USB存储设备的时候并不使用BIOS的INT 13H，而是通过USB总线直接发UFI命令包，采用的地址也是LBA，所以就不太存在兼容性问题。
然而U盘启动引导程序确是依靠BIOS的INT 13H来访问。
BIOS的INT 13H对U盘的支持(不一定支持)，就是把INT 13H中的C、H、S参数转化成LBA地址，然而不同的BIOS设定的每道扇区数、每头柱面数并不一定相同。假设我们有个U盘在自己机子的BIOS被认成16H、512C、64S，分区格式化后，分区的开始位置为0H、1CH、1S，分区引导程序所在的LBA是0000064H，另一台机子的BIOS认成16H、1024C、32S，那么我们刚才做的那个启动盘，分区起始扇区的LBA就变成0000032H，很显然位置错了，当然启动不起来了。
BIOS对每道扇区数、每头柱面数的不同设置就是导致U盘启动不通用的根本原因。
也许你会说那么我们引导程序干脆直接使用扩展INT 13H发送LBA包，GRUB就是这种思路，可是有的BIOS并不支持U盘的扩展INT 13H功能，并且在检测的时候还会返回支持的假象-_-!!
其实386时代的硬盘也遇到这个问题，然而当时CMOS里面提供了硬盘类型参数的手动设置，再加上硬盘不是移动存储设备，所以问题就没那么明显了。
至于HDD、FDD、ZIP只是媒体介质描述的不同，并不能彻底解决CHS问题。

[ 本帖最后由 netwinxp 于 2008-7-2 11:26 PM 编辑 ]

zleafz

原帖由 netwinxp 于 2008-7-2 07:22 PM 发表
以下纯属个人理解，细节部分请上网下载Universal Serial Bus Mass Storage Class UFI Command Specification标准文档(PDF格式)。
BIOS通过USB总线(2.0的是通过EHCI USB)向USB存储设备发送UFI指令来和它进行交流 ...

谢谢你的解答，好像有点懂了。看来这个U盘启动的兼容性确实不好解决呢。我开始以为用MBR的方式可能兼容性最高，看来错了，还得看 BIOS究竟认那种文件系统的磁盘了。不知道LARGE模式还是LBA模式兼容性更好

[ 本帖最后由 zleafz 于 2008-7-2 07:44 PM 编辑 ]

netwinxp

从ATA-1开始LBA已经成为标准，当然是LBA好了。

[ 本帖最后由 netwinxp 于 2008-7-2 07:49 PM 编辑 ]

h8jyuq

原帖由 netwinxp 于 2008-7-2 07:22 PM 发表
windows、linux等访问USB存储设备的时候并不使用BIOS的INT 13H，而是通过USB总线直接发UFI命令包，采用的地址也是LBA，所以就不太存在兼容性问题。
然而U盘启动引导程序确是依靠BIOS的INT 13H来访问。

我不明白，为什么WIN下就能通过USB总线直接发UFI包，而DOS下就不行呢？莫非是WIN是跑在386实模式下，而DOS7是跑在16位模式下？我记得有个DOS软件包叫做DOS4GW.exe，是可以让DOS从16位模式进入32位的386实模式，以前的DOS游戏就是靠这一点来突破16位模式的640K内存限制，从而能访问到XMS的4G内存。
以前我在DOS下写C程序时，刚接触了短短一段时间的DOS4GW，然后WIN95时代就来临了，令我无可奈何地跟入WIN编程大潮中。现在回想起来，我们可不可以在DOS下先加载了DOS4GW.exe后再访问USB设备？从而绕过INT 13H。

netwinxp

DOS也可以向USB存储设备发送UFI包，和硬盘不同的是硬盘只需向1F?/17?口发送就可以了，U盘则需要通过USB总线才能发送，也就说要先驱动USB总线，而windows有USB总线的驱动，DOS则要全依靠自己:)
U盘启动的时候还没有DOS，仅靠引导程序要完成你所需要的功能难度是颇高的。
另WATCOM C(就是DOS4GW的开发工具)、DJGPP提供保护模式或者bigmode编程，其实如果用汇编语言，使用USER32模式的段就可以直接访问4G内存，并不需要别的开发工具提供接口。

[ 本帖最后由 netwinxp 于 2008-7-2 08:43 PM 编辑 ]

d09os3

原帖由 netwinxp 于 2008-7-2 08:42 PM 发表
使用USER32模式的段就可以直接访问4G内存...

老大，USER32模式的段去访问4G内存的话，它需要地经常切换页面。这远远比不起32位指针直接寻址那么爽滴。

还是怀念watcom c++的年代啊.......家里的角落里好象还有一本10年前花巨资购买的watcom C++书本....

netwinxp

DOS下一般来说在数据段用USER32模式就好了
你试试在数据段用
.586
DATA SEGMENT USER32

直接用32位寄存器做指针看看:)
当然，如果你要代码段也USER32模式，那还是得用.586P的保护模式。

CF6896

谢谢楼上的，真是长见识啊。

zleafz

你们的回答很精彩，谢谢。我很喜欢折腾这些，真后悔没有系统学过编程，毕竟不是这个专业。
我发这篇帖子之前本来有个构想，能不能用个很好的MBR软件，来解决兼容性问题，现在看来可能是不行的。。。

netwinxp

随着U盘超过8G，以后的BIOS肯定要支持INT 13H扩展来访问U盘，在MBR使用INT 13H扩展的DAP包来访问就会解决这个问题。当然你的想法也是有可能实现的，但你的整个程序只能放在0~16绝对扇区(这段空间对于绝大多数的BIOS INT13H来说是可以正确访问的)。

[ 本帖最后由 netwinxp 于 2008-7-2 11:23 PM 编辑 ]

wuwuzz

首先感谢netwinxp的指导，给了我研究方向。以前我接受贴中看法，现在则有些疑问：


1、在POST阶段，USB驱动还没加载，UFI命令就可以用了?

2、UFI命令集介质描述符只有寥寥几种720k/1.2M/1.44M之类的软盘，与我们设想的
USB-HDD/CD/ZIP还是有差距~而且，随后的Flex Disk Page描述的CHS参数优先级要
高于介质描述符；


3、我怀疑，USB是PNP设备，BIOS识别应与下面这个Expansion Header for PNP有关：

wuwuzz

5年了，物是人非，感慨万千。近日，zbkh发出了内容类似LZ的求助帖，
我回来订正、完善本帖，留给后来者。

2008年以后，我研究了众多资料(包括流出的BIOS USB源代码)，基本解决了
遗留问题，在认识上、实践上都取得了重要进展，可以做总结和收官了。
================================================================

一、2#的h8jyuq说法是正确的。

二、4#的netwinxp老师贡献最大。其大部分观点都是正确的，需要订正和说明的
有以下几点：

(一)关于Mode Sense命令media type的认识是错误的。media type确定的是：
USB-FDD中，如何区分360K、720K、1.2M、1.44M..等不同容量的软盘，而不是
USB-FDD/ZIP/HDD如何判定、区分。

(二)那么，BIOS如何区分U盘为USB-FDD/ZIP/HDD，或者说判定依据是什么呢?

1、不同的BIOS有不同的算法，没有统一的模式。

一般情况下，BIOS不依赖某一个参数来区分，而是参考多个参数进行计算，
根据综合计算出来的结果进行判定。

特殊情况下，BIOS汇编源码提供编译选项，如果开启了编译选项，则生成的
可执行BIOS代码就有可能依赖某一个参数判定FDD/HDD。

2、最重要的参数，就是“总扇区数(容量)”。这是不同BIOS(AMI和Phoenix)都
采信的相同依据。总扇区数(容量)的取得，由BIOS发命令，U盘固件执行命令并
反馈给BIOS。

3、辅助依据，不同的BIOS各不相同，例如：
Phoenix BIOS会发出ZIP驱动器专用命令，把命令返回码0或1，当作1个二进制位
参与计算。AMI BIOS则没有类似的做法。

(三)关于UFI指令集

UFI指令集最初是针对USB-FDD发布的，现实中，U盘固件指令集取值一般都是
SCSI，很少是UFI。

但是，由于UFI是SCSI的变形子集，而且，SCSI指令集太庞杂，根本不可能得到
真正完整实现，所以，U盘的实际情况是：声称是用SCSI指令集，实际上用UFI
指令集是可以的。至于USB启动，掌握UFI就够用了，需要了解更多的背景知识时，
再参考SCSI。


三、14#是4年前我自己的疑问，给出解答，留给后来者：

(一)在POST阶段，BIOS有自己的内置USB驱动，UFI命令可以使用。
(二)PNP扩展头，BIOS在构造可选启动设备菜单时要用到，与上述
USB FDD/ZIP/HDD判定不是一回事。