在看DownloaderImage的时候遇见一些问题，希望各位能够指点小弟一二：
1. // verify the packet checksum.
//
if (!VerifyChecksum((g_DownloadManifest.dwNumRegions * sizeof(RegionInfo)), (LPBYTE) &g_DownloadManifest.Region[0], dwRecChk))
{
KITLOutputDebugString ("\r\nDownload manifest packet failed checksum verification.\r\n");
HALT (BLERR_CHECKSUM);
return (FALSE);
}
这里校验的原理是什么？
追踪static BOOL VerifyChecksum (DWORD cbRecord, LPBYTE pbRecord, DWORD dwChksum)
{
// Check the CRC
DWORD dwCRC = 0;
DWORD i;
for (i = 0; i < cbRecord; i++)
dwCRC += *pbRecord ++;
if (dwCRC != dwChksum)
KITLOutputDebugString ("ERROR: Checksum failure (expected=0x%x computed=0x%x)\r\n", dwChksum, dwCRC);
return (dwCRC == dwChksum);
}
我的理解是记录条目的总和和获得的4字节的校验数据作比较？请问是这样理解的嘛？
2. // Look for ROMHDR to compute ROM offset. NOTE: romimage guarantees that the record containing
// the TOC signature and pointer will always come before the record that contains the ROMHDR contents.
//
if (dwRecLen == sizeof(ROMHDR) && (*(LPDWORD) OEMMapMemAddr(pCurDownloadFile->dwRegionStart, pCurDownloadFile->dwRegionStart + ROM_SIGNATURE_OFFSET) == ROM_SIGNATURE))
{
DWORD dwTempOffset = (dwRecAddr - *(LPDWORD)OEMMapMemAddr(pCurDownloadFile->dwRegionStart, pCurDownloadFile->dwRegionStart + ROM_SIGNATURE_OFFSET + sizeof(ULONG)));
ROMHDR *pROMHdr = (ROMHDR *)lpDest;
......
}
这里面的OEMMapMemAddr最后返回的地址到底是什么？
3.查看NK.bin，镜像运行时偏移地址0X40位置处的数据刚好是0X43454345，紧随其后的是4字节的镜像运行时的ImageStart。
在romldr.h中有如下定义：
#define ROM_SIGNATURE_OFFSET 0X40
#define ROM_SIGNATURE 0X43454345
可是上面这句话：
if (dwRecLen == sizeof(ROMHDR) && (*(LPDWORD) OEMMapMemAddr(pCurDownloadFile->dwRegionStart, pCurDownloadFile->dwRegionStart + ROM_SIGNATURE_OFFSET) == ROM_SIGNATURE))
查看MSDN，OEMMapMemAddr返回的是个地址，而ROM_SIGNATURE是个数据啊，应该怎么理解呢？
问题有点多，还望不要嫌烦！呵呵~~~
------解决方案--------------------
1 我的理解是记录条目的总和和获得的4字节的校验数据作比较？请问是这样理解的嘛？
是这样的。
2 这里面的OEMMapMemAddr最后返回的地址到底是什么？
在EBOOT的WriteRawImageToBootMedia函数中调用了OEMMapMemAddr，返回的地址是所要烧录数据的地址。
第三个问题你看下EBOOT中OEMMapMemAddr函数的具体内容对理解可能会有帮助。
------解决方案--------------------
借用Veabol兄博客的EBOOT.BIN例子
Offset 0 1 2 3 4 5 6 7 8 9 A B C D E F
00000000 42 30 30 30 46 46 0A 00 80 03 80 88 20 07 00 00 B000FF..?.??...
00000010 80 03 80 04 00 00 00 E2 01 00 00 9B 5C 01 EA 40 ?.?....?..沑.闌
00000020 80 03 80 08 00 00 00 F1 02 00 00 45 43 45 43 F0 ?.?....?..ECEC?
00000030 67 0A 80 48 80 03 80 04 00 00 00 DD 01 00 00 F0 g.?H?.?....?..
我觉得应该是这样的：EBOOT.BIN和NK.BIN被分为了很多段上面04 00 00 00就是一个dwRecLen对应9B 5C 01 EA 这4个字节的数据，地址为8003800
然后往后是dwRecAddr=80038040 dwRecLen= 08 00 00 00 dwRecChk=F1 02 00 00 这个校验和为45 43 45 43 F0 67 0A 808个字节的数据之和，这个是通过VerifyChecksum()函数计算的。下面个段一次类推~~~·直到调用
// last record of .bin file uses sentinel values for address and checksum.
if (!dwRecAddr && !dwRecChk)
{
break;
}
函数后，BIN文件下载完成。
在EBOOT的WriteRawImageToBootMedia函数中调用了OEMMapMemAddr（）
我觉得OEMMapMemAddr（）应该是先吧数据放到CACHE中吧，返回的应该是CACHE的地址。。
------解决方案--------------------