[20190106]慧荣主控”免量产“自由划分多个驱动器（最多7个）

wuwuzz

求道者 发表于 2023-2-2 11:40
都发我吧，我到时候再找找还有没有其他源码，然后做个bt种子放网上，我自己的服务器也永久存一份，其他地 ...

这个怎么发给你？  


因为我只对USB启动有兴趣，所以原始BIOS包N多文件夹、N多文件，我只摘出USB相关文件看，其他的不关心，
扔一边去。包括上次的insyde bios，你要是不提，时间一长，原始包又不知扔哪里去了。这些摘出的文件打包
传到哪？

求道者

2011yaya2007777 发表于 2023-2-2 14:31
vbe图形模式，他的编号混乱，有的个主板一致，有的不相同。所以不知道0x17F属于多少水平像素*多少垂直像 ...

发现了，换张卡图形模式就不对了，但另外一台机子似乎能跑到1080P。

2011yaya2007777

怎么计算图形模式？
0x17F属于什么图形模式？

vbe图形模式，他的编号混乱，有的个主板一致，有的不相同。所以不知道0x17F属于多少水平像素*多少垂直像素。

wuwuzz

求道者 发表于 2023-2-2 12:35
对了，K470在U盘LUN0为removeable，LUN1为fixed的时候会怎么处理？

RMB位的取值没有对Phoenix Bios设定HDD/ZIP产生决定影响。而是我前面说的
容量规则在起决定性作用。

设为Remove的仍然是USB-HDD，设为Fixed
仍然可以是USB-ZIP。

wuwuzz

求道者 发表于 2023-2-2 12:43
smi 3.0的盘已经做了cd+fixed。
2.0的盘做了removeable+fixed（必要时隐藏fixed）

这样做无法保证1LUN盘始终存在吧，
有些BIOS对multi_LUN支持不够好。

求道者

2011yaya2007777 发表于 2023-2-2 11:52
我下载过，也没有仔细看。电脑换了好几个，也找不到了。
我觉得现在仔细研究这些 ，没有太大的必要。

怎么计算图形模式？
0x17F属于什么图形模式？

求道者

wuwuzz 发表于 2023-2-2 12:41
看这2楼的需求，目前市场上易得的方案是：
准备2个写保护3267盘。
一个做R+F+Cd的3LUN盘，

smi 3.0的盘已经做了cd+fixed。
2.0的盘做了removeable+fixed（必要时隐藏fixed）

wuwuzz

求道者 发表于 2023-2-2 12:27
我确实不打算放弃UD和fixed，所以准备了第二个u盘做removeable。
fixed在win7下可以显示所有分区。

看这2楼的需求，目前市场上易得的方案是：
准备2个写保护3267盘。
一个做R+F+Cd的3LUN盘，
一个保留1LUN。如果老BIOS机器比较多，
后面这个换成USB2.0的盘3257。

求道者

wuwuzz 发表于 2023-2-2 12:22
为什么非要fixed模式，是有特殊需求么？ 比如UD无法放弃？

对了，K470在U盘LUN0为removeable，LUN1为fixed的时候会怎么处理？

求道者

wuwuzz 发表于 2023-2-2 12:22
为什么非要fixed模式，是有特殊需求么？ 比如UD无法放弃？

我确实不打算放弃UD和fixed，所以准备了第二个u盘做removeable。
fixed在win7下可以显示所有分区。

求道者

2011yaya2007777 发表于 2023-2-2 12:18
就这种主板而言，放弃吧，折腾的成本太高。U盘又不贵，多备几个不同启动方式的。

这是内存冲突了。抽 ...

如果要一个u盘通杀的话，u盘固件需要支持LUN的盘片切换，fixed/removeable/CDROM的盘片的挂载切换。
要保证总是能启动的话，最好只呈现单lun。
而除了硬件开关切换之外，就只能在电脑上量产软件改，有时候没有电脑就寄了。
所以要有硬件开关。最好加个档位，显示所有lun。
然后是写保护开关。
这么复杂的硬件和固件根本就还没出生。

wuwuzz

求道者 发表于 2023-2-2 11:51
到这地步fixed模式就没救了吧？改造成本高到还不如removeable模式，操作起来就是备一个额外的小点的u盘 ...

为什么非要fixed模式，是有特殊需求么？ 比如UD无法放弃？

2011yaya2007777

到这地步fixed模式就没救了吧？

就这种主板而言，放弃吧，折腾的成本太高。U盘又不贵，多备几个不同启动方式的。

G4D的图形模式的bug能修吗？

这是内存冲突了。抽时间看看。
g4d内存使用比较乱，大部分是固定的。随机分配内存的函数有，估计是不太完善，使用不多。

wuwuzz

2011yaya2007777 发表于 2023-2-2 11:46
你说的可能比较规范。不论是协议也好，命令也罢，USB传输用到了SCSI指令，比如读扇区，读容量，查询等等 ...

喔，是这样：我不是想讲规范的事，而是因为“启动”，需要特别注意几个点：

一、UFI这个协议值是Phoenix BIOS决定软驱设备类型判定的关键，所以把它单踢出来强调。

二、命令确实可以混用，因为UFI命令集本来就是SCSI命令集的简化修改版。(继承)

三、U盘固件声称自己遵循SCSI命令集，实际上也是扯淡，SCSI太复杂无法完整实现。所以平时按简化的UFI来学习掌握没问题。

四、问题出在这：同一条命令，USB启动规范做了重新定义，而U盘固件开发者又按SCSI那一套定义来，对启动极为不利。

求道者

2011yaya2007777 发表于 2023-2-2 11:52
我下载过，也没有仔细看。电脑换了好几个，也找不到了。
我觉得现在仔细研究这些 ，没有太大的必要。

G4D的图形模式的bug能修吗？
QEMU估计也能复现。

2011yaya2007777

很久很久以前，我就建议过YAYA下载保留AMI BIOS那套，不知后来他做了没有。

我下载过，也没有仔细看。电脑换了好几个，也找不到了。
我觉得现在仔细研究这些 ，没有太大的必要。

求道者

2011yaya2007777 发表于 2023-2-2 10:54
依wuwuzz提供的Phoenix BIOS 源码分析，的几个特殊点：
1. USB驱动器，遵循UFI或SFF8070i协议 ...

到这地步fixed模式就没救了吧？改造成本高到还不如removeable模式，操作起来就是备一个额外的小点的u盘用来做removeable模式吧，确实不算难。
如果能在pbr里嵌入usb2.0驱动，然后重载u盘，大概能够访问UD，但这实施成本太高了。
阴间BIOS确实有这种古怪的限制。

2011yaya2007777

常用U盘不遵循UFI协议，而是遵循SCSI协议。

你说的可能比较规范。不论是协议也好，命令也罢，USB传输用到了SCSI指令，比如读扇区，读容量，查询等等，这些在我魔改的实模式USB2.0代码中，都有应用。记得与UFI是否有关，可能时间长了忘记。

我是实用主义，不求甚解。看过USB的协议，看过一些实例。能把他们驱动起来，正常使用便可。

求道者

wuwuzz 发表于 2023-2-2 11:36
我手上有phoenix bios的这套、然后就是AMI BIOS(BIOS技术剖析这本书光盘附带的)那套。

后来泄露出的AM ...

都发我吧，我到时候再找找还有没有其他源码，然后做个bt种子放网上，我自己的服务器也永久存一份，其他地方存这个迟早被删除。
然后网上下不到了。

求道者

2011yaya2007777 发表于 2023-2-2 10:54
依wuwuzz提供的Phoenix BIOS 源码分析，的几个特殊点：
1. USB驱动器，遵循UFI或SFF8070i协议 ...

我找到了一个比较容易复现的G4D图形bug。
普通进入图形菜单。
哪怕是只设置一张图片，在1600x900 32位色深模式下，字体也会不显示。
命令行模式下可以显示字体。
图形模式 0x17F

wuwuzz

求道者 发表于 2023-2-2 11:30
wuwuzz亲把其他牌子的BIOS源码都发给yaya吧，指不定能找到点什么鬼东西，如果还有其他源码，发给我，我放 ...

我手上有phoenix bios的这套、然后就是AMI BIOS(BIOS技术剖析这本书光盘附带的)那套。

后来泄露出的AMI UEFI/BIOS源码，基本就是上面那套汇编代码，用C重写了一遍。


很久很久以前，我就建议过YAYA下载保留AMI BIOS那套，不知后来他做了没有。

求道者

wuwuzz 发表于 2023-2-2 06:56
我的看法:

不用搞得这么繁复吧，K470 Phoenix BIOS USB-HDD菜单下，SMI盘不用怎么调，就可以正常启 ...

wuwuzz亲把其他牌子的BIOS源码都发给yaya吧，指不定能找到点什么鬼东西，如果还有其他源码，发给我，我放到我的nas上做个bt种子，万一有人要用这些源码也能找到，就是可惜15年泄漏的I2O源码找不到了。

wuwuzz

2011yaya2007777 发表于 2023-2-2 10:54
依wuwuzz提供的Phoenix BIOS 源码分析，的几个特殊点：
1. USB驱动器，遵循UFI或SFF8070i协议 ...

我这里做一下订正：

软驱(盘)与可移动设备(removeable、盘号0x00、DOS下A:)是2个概念。


1.常用U盘不遵循UFI协议，而是遵循SCSI协议。通过BIOS内置算法的规则(关键标准之一就是U盘容量-总扇区数)，
可能会被设定为可移动设备。

2.当USB存储设备遵循UFI协议时，它将被Phoenix BIOS用作判断为软驱的条件之一，
即：BIOS菜单中的USB-FDC。这种遵循UFI协议的U盘，常见于有硬件仿真FDD电路的U盘。
软驱一定是可移动设备。新版AMI BIOS/UEFI源码也有这方面的设定。

3.SF8070I协议的情况比较复杂，暂时不详细讨论。遵循这种协议的USB设备不常见。
在phoenix BIOS下,这种设备也一定会被设定为可移动设备。

2011yaya2007777

依wuwuzz提供的Phoenix BIOS 源码分析，的几个特殊点：
1. USB驱动器，遵循UFI或SFF8070i协议时，判断为可移动！分配驱动器号 <0x80。也就是判断为软盘。
通常U盘，也就是Flash（闪存）盘，或者叫USB海量存储器，遵循UFI协议。因此统统判断为软盘。
在这种情况下（分配盘符A:），可能会影响某些软件运行。

2. 判断为可移动时，也就是判断为软盘时，减少1磁头，隐藏第一分区之前的扇区，逻辑0扇区指向PBR。
这对于通常形态的启动模式（即读MBR，查找活动分区，然后把控制权交给PBR），没有影响。
然而对于UD形态的启动模式（即读MBR，在隐藏分区读文件，进入菜单。不交权，与PBR启动代码完全无关），实在是灾难。以为根本就没有把代码控制权交给他。

这可能是Phoenix BIOS的某一个版本，其他版本可能不一样。
K470 Phoenix BIOS 则完全一样。

2011yaya2007777

BIOS源码里有BUG？
然后就K470这样了吗？

我说的是隐藏扇区，eax没有保存，被这个读容量函数破坏了。以后也没有见读出的容量减每磁道扇区数。

这个因素没有大碍，最多是容量不准。

wuwuzz

求道者 发表于 2023-1-31 09:10
BIOS会做这么无聊的事情吗？
无聊到了一定的地步。
这么说在启动的这一阶段除了第一分区之外的扇区都被 ...

我的看法:

不用搞得这么繁复吧，K470 Phoenix BIOS USB-HDD菜单下，SMI盘不用怎么调，就可以正常启动G4D，这就足够了。

fb/ventoy那样多分区，在此环境中，反而复杂化，不能正常启动。需放弃它们的时候就果断放弃。

wuwuzz

2011yaya2007777 发表于 2023-2-1 16:47
你的理解很对。问题在于这个函数执行之前，传入的eax没有保存，被这个读容量函数破坏了。以后也没有见读出 ...

因为我不懂汇编，这里是瞎猜的：

ReadCapacity函数在开始的时候，进行了一系列栈操作(含AX寄存器)，并且：

    call    hddUFIFunnySegmentToDS
    mov    al, ds:[hddUFIHotParametersOK]

而对[hddUFIHotParametersOK]的解释，我找了一下，是：
- One if we can safely alter the media capacity and block size, else zero

是否这些代码已经事先保存了EAX里的“需减少的总扇区数值”，然后才开始
执行readcapacity命令包，破坏EAX里的值。

wuwuzz

求道者 发表于 2023-2-1 23:35
BIOS源码里有BUG？
然后就K470这样了吗？

不是这样吧？

即使BIOS源码有BUG，也是在说隐藏MBR后，总扇区数忘了减相应数量，
并不影响隐藏MBR这个操作。

fzp070

感谢分享！
很详细，图文并茂，很用心，辛苦了!

求道者

2011yaya2007777 发表于 2023-2-1 16:47
你的理解很对。问题在于这个函数执行之前，传入的eax没有保存，被这个读容量函数破坏了。以后也没有见读出 ...

BIOS源码里有BUG？
然后就K470这样了吗？