DownloaderImage的一些有关问题

DownloaderImage的一些问题
在看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的地址。。
------解决方案--------------------