[原创]支持外置硬盘控制器驱动,可任意方式启动的PE[10-01-13稳定版]

chenall

压缩的到DOS下同样要解开再处理啊。使用的那个INIFILE不支持处理大于64K以上的文件。
如果要支持64K的只能想办法把这个替换掉。

zhaohj

今天无意中发现这个：http://chenall.liondrive.com/

inifile.com也是你发明的，相信你能解决！

chenall

原帖由 zhaohj 于 2009-11-18 22:20 发表
今天无意中发现这个：http://chenall.liondrive.com/

inifile.com也是你发明的，相信你能解决！

这里的INIFILE是从网上下的。
http://home.mnet-online.de/horst.muc/div.htm#inifile

zhaohj

今天早上实机测试了一下，#1347楼的问题还是存在，我每步测试一下如下：
而虚拟机测试是通过的。
我的机器3硬盘，开启AHCI，ich10

[ 本帖最后由 zhaohj 于 2009-11-19 08:31 编辑 ]

zhaohj

我再在另外一台机器上（marvell芯片）开启AHCI，接上3个硬盘，启动完好！
是不是我的其中一个硬盘分区有问题导致出现上述问题？
其中一个硬盘当时FIRADISK驱动加载后分区情况出现异常，在这个错误下分的扩展分区。肯定与这个有关。
可能把这个硬盘拔掉问题会解决。

chenall

和硬盘应该没有关系，你上面的图片，最后面
ls (hd0,0)
看一下。

zhaohj

原帖由 chenall 于 2009-11-19 12:27 发表
和硬盘应该没有关系，你上面的图片，最后面
ls (hd0,0)
看一下。

可能与我的机器内存是4G有关，在其他2G内存的机器上都没有问题。

chenall

原帖由 zhaohj 于 2009-11-19 12:48 发表


可能与我的机器内存是4G有关，在其他2G内存的机器上都没有问题。

有可能，目前GRUB4DOS支持4G内存的功能正在测试，我没有条件测试。没试过。

zhaohj

看来这个G4D版本的问题还比较严重，而现在又没有其他版本可代替（要用到HD新功能）。

得出一个结论：只要内存>=4G，用到UNMAP的都不能启动PE。0PE和MICROPE或CSPE都如此。
全内置PE可以启动，没用到UNMAP。
望C大到时空论坛反馈一下。

chenall

有没有更详细的信息？有可能的话自己去时空报告一下。

比如map --unmap前后的内存信息，map状态等。
还有map --unmap后
直接使用map --hook是否正常，使用map --rehook的信息等。

zhaohj

你可以讲讲需要怎样测试步骤。
map --unmap前后的内存信息需要哪些，怎样查看。
我明天测试一下，不知用虚拟机4G内存能不能重现，当然这样本机就需要6G内存了，32位系统可能没用。

chenall

你先试一下把EXT.ZIP里面的GRUB.EXE换成新版的。

zhaohj

原帖由 chenall 于 2009-11-20 09:02 发表
你先试一下把EXT.ZIP里面的GRUB.EXE换成新版的。

ope里的GRUB.EXE是2009.11.14，应该是最新的，OPE情况也是这样。

chenall

map --status
displaymem

然后map --rehook以后再次执行以上命令，把结果截图上来。

zhaohj

我下面图中已有注明，map --unmap前、后及rehook后

[ 本帖最后由 zhaohj 于 2009-11-20 10:51 编辑 ]

zhaohj

超屏了，再贴一下详细的

chenall

忘了问一下，
unmap之前(hd0,0)可以正常访问吗？
也就是进入DOS后访问的C:是否正常的。

另外再试一下使用map --hook而不是map --rehook看一下数据。

[ 本帖最后由 chenall 于 2009-11-20 13:35 编辑 ]

chenall

@zhaohj ，上面的信息如果不点有看到应该就可以处理了，前后的长度变了。所以就不能正常访问了。

有空的话麻烦再做一下以下测试。
首先开启debug
debug on
然后显示当前状态
map --status
....
map --rehook
map --status
所有的提示信息截图，看一下.

zhaohj

unmap之前(hd0,0)不能正常访问。在下面
ls (fd0)/to128.flg && map --mem (hd1,0)+1 (hd0)
checkrange 6009 read 0x60008 && map --mem (fd1)+1 (fd0)
geometry (hd0)
ls (hd0,0)/

chenall

原帖由 zhaohj 于 2009-11-20 14:16 发表
unmap之前(hd0,0)不能正常访问。在下面
ls (fd0)/to128.flg && map --mem (hd1,0)+1 (hd0)
checkrange 6009 read 0x60008 && map --mem (fd1)+1 (fd0)
geometry (hd0)
ls (hd0,0)/

那就是启动后进入DOS后就已经访问不了了。

zhaohj

现在说rehook有毛病还为时过早，6.20、11.5、11.14版本都如此。看来是历史遗留问题。

chenall

原帖由 zhaohj 于 2009-11-20 14:36 发表
现在说rehook有毛病还为时过早，6.20、11.5、11.14版本都如此。看来是历史遗留问题。

以前的版本不支持4G内存。

你试了确定以前的版本都会这样吗？把GRLDR和GRUB.EXE都换成以前的版本。

zhaohj

我测试一下6.20号版本，把这两个都换了测试一下能不能访问(hd0,0)。

zhaohj

这个测试太难了，需要实机测试。本来我怀疑PXE问题，但用光驱测试也一样。
发觉非PXE启动，新版CSPE也不支持SRS拆开（txtsetup.sif方式）。
>=4G就等不点大人解决吧。

chenall

原帖由 zhaohj 于 2009-11-20 17:24 发表
这个测试太难了，需要实机测试。本来我怀疑PXE问题，但用光驱测试也一样。
发觉非PXE启动，新版CSPE也不支持SRS拆开（txtsetup.sif方式）。
>=4G就等不点大人解决吧。

要求CSPE所在磁盘是FAT格式的，否则在DOS下无法访问了。
我使用U盘启动是可以的。同PXE启动的格式一样。

zhaohj

我用的是光盘，DOS下没加载驱动也无法访问光盘。这样看来PXE优势明显。
SRS拆开方式（指TXTSETUP.SIF方式）是为了驱动更新方便，可以方便的拿来主义。
这样看来，这种方式还是局限性较多，仅PXE较好。

pseudo

拆开后，pxe访问、本地访问有局限，不一致。所以目前还是zip格式打包通用，清爽。双击zip文件自动用winrar打开，把文件拖进拖出，很方便。

zhaohj

原帖由 pseudo 于 2009-11-20 23:04 发表
拆开后，pxe访问、本地访问有局限，不一致。所以目前还是zip格式打包通用，清爽。双击zip文件自动用winrar打开，把文件拖进拖出，很方便。

赞成这个观点，主要是希望ZIP打包也支持里面的TXTSETUP.SIF，也就是PE内置驱动的格式打包，里面是SYS（或SY_)文件和txtsetup.sif。
拆开是无所谓的，ZIP打包一样方便。

pseudo

原帖由 zhaohj 于 2009-11-20 23:13 发表
赞成这个观点，主要是希望ZIP打包也支持里面的TXTSETUP.SIF，也就是PE内置驱动的格式打包，里面是SYS（或SY_)文件和txtsetup.sif。
拆开是无所谓的，ZIP打包一样方便。

10.06测试版@livemesh
===================
1. 允许SRS*.ZIP由txtsetup.sif文件和含.sy?的Drivers目录构成。方便将其它PE带的SRS驱动直接搬到0PE中使用。但目前暂时限制
    txtsetup.sif不能超过60K，每个SRS*.ZIP文件不能超过3M.

10.11测试版@livemesh
===================
5. 压缩后SRS1.ZIP、SRS2.ZIP、F6.ZIP、OEM_SRS.ZIP每个文件不要超过10000K。由于这次加大上限时采用笨办法没作优化，现在
   启动PE所需内存略超128M，以后再考虑降低。

不点

有机会上网回复一下。

貌似 displaymem 仅仅显示系统内存，不会包括 map 之后的影响。所以，由 displaymem 显示的内存总是一样的，不必显示很多次。

map --status 的显示当然很重要。chenall 怀疑 --rehook 有问题，我也怀疑。但是目前我不能看代码，所以，希望 chenall 再研究一下 rehook 的代码部分，看看是否能找出什么毛病来。

另外，虽然你的 displaymem 显示你的内存已经超过了 4G，但是，map 所映射的内存并未放在 4G 以上，而是在 4G 以内。因此，这个问题似乎与内存的大小无关。

另外，测试者应该很容易确定，究竟为什么 (hd0,0) 不能被识别。比如，测试者可以运行 cat --hex (hd0,0)+XXXXXXXX 之类的命令，看看 (hd0,0) 的扇区数据是否被破坏了。另外，当 ls (hd0,0)/ 报错时，紧接着再尝试一次 root (hd0,0)，看看能否成功。