(长帖)U启故障关注MBR/BIOS是不够的，更深的病根在固件缺陷。附umsdinfo工具。
一、U启的初始处理
量产/未量产的U盘、外置USB移动硬盘、外置USB-FDD/CD/DVD/ZIP
驱动器等都属于UMSD(Usb Mass Storage Device，USB海量存储设备)。
部分手机、MP3、MP4具备Usb Mass Storage属性，也视同UMSD。
U启初始阶段的大致处理过程是：枚举、获取描述符信息结束后，BIOS
发固定的SCSI/UFI指令，UMSD固件接收执行，并向BIOS反馈结果，提供
原始数据。比如，报告自己是DISK还是CD/DVD，报告自己的LBA、原始
CHS值(注:这个CHS是固件提供的CHS，与使用fbinst/U+...软件格式化无关)。
但是，如果UMSD固件存在缺陷，不完全支持那些本应支持的指令，则会有多种
可能的错误：
1、严重错误，真死机或挂起等待唤醒；
2、超时响应，假死机或被BIOS忽略；
3、命令执行成功，但提供的原始数据不正确。比如：H/S为空、H/S为0、C>1024。
则BIOS会补BUG--结合其他指令结果，尝试修改--甚至强行硬编码，重新伪造生成
新的CHS，使之看上去更合法。INT 13 F8/F48内部处理实际上就是这样。
......
很不幸，现实中，UMSD固件存在缺陷，不是个别现象，而是普遍现象。这其实
也不十分奇怪。UMSD固件的开发者，很大程度上只考虑了普通存储用途(实现
基本的SCSI指令要求即可)，压根就没认真考虑BOOT用途! 其固件开发当然
也就没有遵守USB启动标准--《UMS Spec for bootability》要求，去实现
对BOOT至关重要的UFI指令。
[ 本帖最后由 wuwuzz 于 2011-3-26 08:35 编辑 ] umsdinfo工具下载
每个USB存储设备，umsdinfo.exe将产生2个TXT文件：
一、info<设备名>.txt文件：
保存UMSD固件执行SCSI/UFI命令输出结果，目前共执行4条命令(4个检查点)：
Inquiry查询、Read Capacity读容量、Mode Sense(10)模式感知、Mode Sense(6)。
前三条命令是USB BOOT规范要求必须实现的。
最后一个M6是我增加的。原因是：现实中由于UMSD固件缺陷，M10执行出错的可能性
非常大，需要尝试M6作为补充。
二、err<设备名>.txt文件：
记录SCSI/UFI命令执行成功与否。
执行成功：状态标记good，出错信息为空。
执行失败：状态标记非good，如check condition，会有不同的出错信息，比如：
非法请求。这表示UMSD固件不支持该命令。
根据USB BOOT规范要求，前三条命令除了good，不能有其他出错信息。
[ 本帖最后由 wuwuzz 于 2011-3-26 08:38 编辑 ] 三、关于umsdinfo
既然UMSD固件缺陷造成种种问题，能不能把相关信息取出，让大家
实际看看呢?当然可以。原理很简单：按U启标准要求，把那些对
BOOT至关重要的命令包发给UMSD，然后把UMSD固件的执行结果
放在TXT文件里。
这些命令包是固定的。发包可以在BIOS下、利用INT13 F50发包服务进行
(buldr增加pss模块重新编译可达此目的)；也可以在高版本的Windows
/Linux下手动进行。甚至还可以不自己发包，而利用USB协议分析软件
查看、捕获OS的自动发包结果。
在http://bbs.wuyou.net/forum.php?mod=viewthread&tid=186560&extra=page%3D1&page=9
这个帖子里，我和不点发生分歧，他提出开发、拿出实际的软件才能服人，
我当时很生气。事后想想，不点的意见也不能说全无道理。我举例用的USB协议分析
软件，虽然结果正确，但杀鸡用牛刀，无关信息多，而且也容易冲突、蓝屏死机
(因为USB协议分析软件要修改Windows底层驱动)，还是不适合一般用户使用。
通过反复查找测试，直到最近，我才算是找到比较好的解决办法：
Linux提供了专用于发送SCSI命令包的sg软件，而且sg有windows命令行版本。
我们可以搞个shell前端界面，核心捆绑sg。这样既适合一般用户使用，又
降低了开发难度。最后的成品就是umsdinfo.exe这个小工具(XP/2K环境)。
umsdinfo.exe是个绿色软件，执行后会自动查找本机的UMSD，用户只要选择一下，
umsdinfo.exe就会发包产生结果，其标准输出、标准错误都放在TXT文件里，方便
用户上传、分析。需要说明的是:由于umsdinfo.exe捆绑了sg，可能会被杀毒软件
误报，忽略即可。
下面是umsdinfo.exe的运行示意图：
[ 本帖最后由 wuwuzz 于 2011-3-26 08:46 编辑 ] 二、我为什么不对MBR/PBR/fbinst/U+/HP格式化...的讨论投入很大
精力，为什么不赞成不点的BIOS阴谋论
(一)第1个问题，要看是什么情况
从一中的说明可知，有些UMSD固件缺陷造成的错误太严重，U启还没到
读MBR/PBR阶段就焦头烂额了，甚至早就Game Over了。在这种情况下，
考察UMSD的MBR/PBR...这些内容，有点马后炮，意义不大。
另外，在Phoenix BIOS的世界里，BIOS主要是从驱动器设备获取参数，而不是
从介质(含有MBR/PBR)上来获取参数。所以，在这种环境中，就不要把过多的
精力投到倒腾介质格式上了......
(注：AMI BIOS则不同，它要用MBR的内容作为生成参数的考虑因素之一，在这种
环境中，MBR/PBR...这些内容有讨论下去的价值。)
(二)第2个问题
这在一中已经涉及到了。BIOS的“异常”表现，与其努力弥补UMSD固件缺陷
有关，而不是阴谋、设陷阱，这在CHS问题上尤其突出。从已知的AMI、Phoenix
BIOS源代码来看，BIOS的努力还远不止CHS这些。例如：
AMI BIOS定义了名为“INCMPT_FLAGS”的不兼容UMSD标志位结构，
对多种有固件缺陷UMSD，专门进行特别处理；Phoenix BIOS会对一些UMSD
固件造成的超时问题，多加指令试图唤醒或确认其准备好，再进行下一步
处理......
从实践上看，BIOS阴谋论也容易让人陷入思维定势，不利于问题的解决。
例如：这两个讨论USB移动硬盘启动的帖子。
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=187168
http://bbs.wuyou.net/forum.php?mod=viewthread&tid=187940
事实上，这两帖子，重点考虑2点就可以了：
1、USB供电问题；2、UMSD固件缺陷。还没到担心EB、fbinst的地步。
需要指出一点，BIOS的补BUG努力，十分具有讽刺意味，让人哭笑不得。
很多同学不是一直在高呼，要遵守统一的U启标准吗? 孰不知，BIOS真要严格
按U启标准来，我们的UMSD会更难通过检查、死得更难看!
而有固件缺陷的UMSD，经过BIOS的擦屁股，BOOT成功了，高兴么?
不高兴。因为这意味着BIOS做了妥协让步，违反了已经制订发行的U启标准。
[ 本帖最后由 wuwuzz 于 2011-3-26 08:36 编辑 ] 有争议才会有进步，有空学习下。 有深度的内容。必须潜心阅读楼主帖子。 看完了楼主的论述，有一定的道理，下载来实践一下，谢谢！ (buldr增加pss模块重新编译可达此目的)
能提供buldr这个文件么？还有怎么使用？ 嘿嘿，很有意义的讨论，虽说插不上嘴，但帮顶还是可以滴。
不顶不行！ 原帖由 3370123 于 2011-3-22 21:24 发表 http://bbs.wuyou.net/images/common/back.gif
(buldr增加pss模块重新编译可达此目的)
能提供buldr这个文件么？还有怎么使用？
这个有难度，需要搭建编译环境，自己修改pss.c源代码，添加想发的指令，
编译生成pss.mod，然后再链接生成包含pss模块的buldr。
pss模块的开发，bean没有最后完成。我也是自己进行修改，断断续续测试。
而且，有的BIOS不提供pss服务，使用范围受限制。
有关信息，可参考这里
http://www.burgloader.com/bbs/index.php?topic=86.0
[ 本帖最后由 wuwuzz 于 2011-3-23 12:15 编辑 ]
回复 #10 wuwuzz 的帖子
说到 burg的编译环境我有点疑问，我下载的msys，环境搭好了，编译fbinst没问题，编译burg就是不成功。只出现 burg-emu.bat，libiconv-2.dll，libintl-8.dll，SDL.dll四个文件，不知道哪里没弄好。 看不明白。
但有一点可以肯定：不少人很反感楼主把这些东西说出来，以至觉得很不爽。 根本插不上半句，支持一下 楼主的研究很有见地，很佩服你！
U盘的固件在启动中起着非常重要的作用，甚至关键作用，但是我们改变不了固件的开发商。
我关心的是怎样去挑选U盘，用你这个umsdinfo.exe可以吗？
我等菜鸟看不懂生成的报告，能说明一下吗？期待回复。 恩，不知道什么固件兼容性好点，以后买移动硬盘盒和U盘做个参考。
现在移动硬盘盒买的多的是JMicron的。 原帖由 Plantsoot 于 2011-3-22 21:36 发表 http://bbs.wuyou.net/images/common/back.gif
说到 burg的编译环境我有点疑问，我下载的msys，环境搭好了，编译fbinst没问题，编译burg就是不成功。
只出现 burg-emu.bat，libiconv-2.dll，libintl-8.dll，SDL.dll四个文件，不知道哪里没弄好。
很抱歉，这方面我也不熟悉，可能无法提供有价值的信息。我用的是bean给的下载链接，变量设置/问题解答
也是看其帖子。
buldr的编译生成，我的实际操作是这样：修改编译自己有兴趣的模块(比如pss.c)为目标文件.mod，
然后按照bean的说明，把众多模块cat合并，生成新的buldr。 有争议不要紧，只要不是争吵，关键是争议之后大家积极的想办法考虑解决问题~~
很佩服楼主和不点等论坛网友的严谨作风，也正是因为这所以才有了不同的异议，才有了更多的提升进步。 原帖由 lmle 于 2011-3-22 22:09 发表
我关心的是怎样去挑选U盘，用你这个umsdinfo.exe可以吗？
我等菜鸟看不懂生成的报告， ...
原帖由 freesoft00 于 2011-3-22 22:39 发表
恩，不知道什么固件兼容性好点，以后买移动硬盘盒和U盘做个参考。
现在移动硬盘盒买的多的是JMicron的。
就如同想分析MBR就需知道其字节含义一样，分析USB同样需要一些背景基础知识。
三言两语说不清楚。
目前的umsdinfo.exe还只是个简单的概括信息(SCSI/UFI命令结果)搜集器，不具备
数据分析能力(自动提取字段信息、转换成易懂的报告)。这主要是因为我的编程能力
有限，手上也没有合适的开发工具。
所以，暂时还只能依靠使用者掌握的USB知识，手动分析。如果你掌握了USB的相关知识，
umsdinfo.exe采集的信息可以作为选购UMSD的参考。如果你觉得有理解困难，可以把
info.txt、err.txt内容发上来，大家共同讨论。
----------------------------------------------------------------------
我在帖中说了，UMSD固件问题是“普遍”现象。也就是说，从我掌握的信息看，
就没有完美的主控存在，只不过有的主控固件问题重、有的主控固件问题稍轻罢了。
作为一个临时办法，BOOT盘我是这样做的：选用SK6211BA主控的U盘，量产DISK，
第1驱容量放到980M以下(这是因为其固件能成功执行USB BOOT规范要求的M系指令，
提供了CHS。但其CHS算出来是980M，不管你的SK主控U盘实际容量是4G、8G还是16G，
都是这个固件CHS)
另外，我觉得也不要过于担心，因为还有BIOS的补BUG机制存在。如果BIOS足够强大，
可以减轻UMSD固件问题的影响，增大BOOT成功机率。
[ 本帖最后由 wuwuzz 于 2011-3-23 12:25 编辑 ] wuwuzz，我很想了解umsdinfo.exe所得信息的各字段含义，但这方面的介绍似乎不多。我搜索了你以前的一些帖子，知道了设备类型、扇区大小，其它就一无所知了。期望你能用umsdinfo.exe的信息，来个图文并茂的介绍。
附件是我一个U盘的信息（宇瞻8G盘，群联主控，量产成一个光盘、一个移动磁盘，厂商改成了LMLE，呵呵）
今天上午在时空看过这个话题了，很期待革命性的工具，这个会有吗？
昨天扫盲了一下UEFI知识, 可能这个就是BIOS终结者，以后不存在u盘启动问题了，或者说启动不是个大问题了 UEFI马上代替BIOS了，希望启动不成问题了 这是很值得学习的文章 原帖由 快雪时晴 于 2011-3-23 13:07 发表 http://bbs.wuyou.net/images/common/back.gif
今天上午在时空看过这个话题了，很期待革命性的工具，这个会有吗？
昨天扫盲了一下UEFI知识, 可能这个就是BIOS终结者，以后不存在u盘启动问题了，或者说启动不是个大问题了
原帖由 shan 于 2011-3-23 13:14 发表 http://bbs.wuyou.net/images/common/back.gif
UEFI马上代替BIOS了，希望启动不成问题了
本帖谈论的内容，主要还是USB方面的，BIOS完蛋后依然要用，除非USB也被淘汰了。
So，在可预见的时间内不会过时。 原帖由 lmle 于 2011-3-23 13:05 发表 http://bbs.wuyou.net/images/common/back.gif
我很想了解umsdinfo.exe所得信息的各字段含义，但这方面的介绍似乎不多。我搜索了你以前的一些帖子，知道了设备类型、扇区大小，其它就一无所知了。期望你能用umsdinfo.exe的信息，来个图文并茂的介绍。 ...
每个USB存储设备，umsdinfo.exe将产生2个TXT文件：
一、info<设备名>.txt文件：
保存UMSD固件执行SCSI/UFI命令输出结果，目前共执行4条命令(4个检查点)：
Inquiry查询、Read Capacity读容量、Mode Sense(10)模式感知、Mode Sense(6)。
前三条命令是USB BOOT规范要求必须实现的。
最后一个M6是我增加的。原因是：现实中由于UMSD固件缺陷，M10执行出错的可能性
非常大，需要尝试M6作为补充。
二、err<设备名>.txt文件：
记录SCSI/UFI命令执行成功与否。
执行成功：状态标记good，出错信息为空。
执行失败：状态标记非good，如check condition，会有不同的出错信息，比如：
非法请求。这表示UMSD固件不支持该命令。
根据USB BOOT规范要求，前三条命令状态标记必须为good。
命令输出结果的字节解释，这个有点汗，工作量较大。是要结合几本书才能说清的
(知识点比较多、散)。依我的水平，不可能比规范表达得还严谨、详细。所以，
手里时时拿着SCSI/UFI规范条文、对照学习理解4条指令输出结果字节含义是
必需的。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------
从上传的TXT文件看，反映出的信息是：
1、USB-CD:570M；USB-DISK:7.3G
2、该版本群联主控固件支持M系指令，但其提供的DISK CHS原始数据(16头/32扇/29204柱面)
不完全符合要求。因为：C>1024，超过了BIOS INT13 F8的允许范围。所以，BIOS内部还是
会做补BUG处理---通过缩小C、放大HS的办法。 USB设备的兼容性弄得我很头痛。顶！ wuwuzz兄出来讲学了，好消息啊，帖子仔细拜读，之前和你讨论个U盘启动的问题，你给予的纠正，确实令帖子的内容更加合理！大家希望多来学习，等楼数多了后，打算给你的帖子添加到导航和置顶！ 非常希望楼主可以把USB的相关知识跟楼主提供的程序得到的信息具体来讲解一下。得到的信息分别是什么意思。
下面是上传的两个U盘的信息，楼主有空给具体解释一下，谢谢了。
[ 本帖最后由 sgw888 于 2011-3-24 10:08 编辑 ] 我的两个U盘的测试结果慧荣smi325x主控 以及 联盛ut165主控
唯一能看懂的是 err<设备名>.txt文件里四条命令状态标记都是good 看来有必要搞个新版本了，增加简单分析功能，生成一个易懂的参考报告。
我再研究一下。 原帖由 wuwuzz 于 2011-3-24 13:59 发表 http://bbs.wuyou.net/images/common/back.gif
看来有必要搞个新版本了，增加简单分析功能，生成一个易懂的参考报告。
我再研究一下。
期待新版本的面世。