有关KernelRelocate的说明

KernelRelocate() copies initialized global variables to RAM, and sets uninitialized global variables to zero.   KernelRelocate() is called from both the bootloader and the kernel.

KernelRelocate函数将已初始化的全局变量拷贝到内存，并且将未初始化的全局变量置0。bootloader和kernel都会调用KernelRelocate函数。

If you are more familiar with writing applications that run within an Operating System (OS) then needing KernelRelocate() is different. When you run an application within an OS, initialization of global variables is automatically performed for the application by the OS. But, the bootloader and the kernel are the OS, so they must initialize global variables themselves.

如果你能够熟练开发OS下运行的应用程序，那么可能不需要KernelRelocate函数初始化应用程序的全局变量。因为当你运行程序的时候，OS已经自动将应用程序的全局变量进行了初始化(PE结构及重定位段)。但是，bootloader和kernel是OS的一部分，它们必须调用KernelRelocate来初始化自身的全局变量。

The bootloader calls KernelRelocate() in BootloaderMain() if it uses BLCommon. Since KernelRelocate() isn’t called until BootloaderMain(), the code must not access the global variables until after BootloaderMain() calls kernel Relocate(). If the code reads a global variable prior to KernelRelocate() the data will be invalid, if the code writes to a global variable prior to KernelRelocate() the data will be lost when KernelRelocate() runs.

如果bootloader是使用的BLCommon，它将在BootloaderMain函数中调用KernelRelocate。因为这个原因，bootloader代码必须在调用KernelRelocate后才能存取全局变量，否则在之前读取的数据是无效的，另外在之前赋给全局变量的值在KernelRelocate调用后将丢失。

Taking that a step further, if the initialized global variable is a pointer initialized with an address the bootloader could fail to run successfully. That means that if you make the mistake of dereferencing an initialized global pointer prior to calling KernelRelocate() you will probably need to get out a JTAG tool to reprogram the bootloader.

 再进一步分析，如果将全局变量初始化为地址指针，那么bootloader将运行失败。这意味着在调用KernelRelocate之前，全局变量指向了一个无关的地址，只能用JTAG工具来重写bootloader。(此处不是很理解)

我的理解：

1、MSDN上的说法是：nb0文件用于第一次用JTAG工具将EBOOT.nb0写入到Flash中，bin文件用于更新Flash中的bootloader映象。这是由两者的差异造成的。参： http://blog.csdn.net/xiaoxiangtian/archive/2008/09/23/2963028.aspx

2、对于有IROM方式的，第一次也可以从SD卡启动直接写EBOOT.bin。

3、eboot.bin中没有填充pTOC结构体,必须使用parser解释器[类似于romimage.exe]将全局变量数据段解压释放到运行时使用的地址才行；eboot.nb0中经过romimage.exe填充了pTOC结构体,所以eboot.nb0可以自己将自己用到的全局量通过KernelRelocate()函数进行解压释放,这就是为什么eboot.nb0比eboot.bin的size大的原因。参： http://blog.chinaunix.net/u1/38994/showart_1879289.html

The kernel calls KernelRelocate() prior to calling functions in the OAL, so it is generally safe to access global variables from OAL code.

kernel在调用OAL的函数前调用KernelRelocate，因此在OAL函数中存取全局变量是安全的。

One question that comes up is why does KernelRelocate() need to be called in the bootloader if the bootloader is running in RAM? KernelRelocate() must be called to initialize global variables because while the data is within the bootloader, the initialization data cannot be accessed by the bootloader directly for a few reasons; first the code doesn’t assume that the data is in RAM (in some cases it isn’t in RAM), second the code is looking for the data in RAM and third the code is compiled and linked using the same tools as general applications are build with.

涉及到的一个问题就是bootloader在内存中运行的时候，为什么还需要调用KernelRelocate？这是因为bootloader不能直接存取包含在它内部的初始数据，具体原因有：1、bootloader代码不会假定这些数据在内存中(在有些情况下不在内存中)；2、bootloader代码会在内存中搜寻数据；3、编译和生成bootloader代码所使用的工具是和应用程序一样的工具(是不是因为相同的工具，应用程序是PE结构，而bootloader却不是，需要重定位代码数据段等)。

===========================================================================

我的补充:

1、bootloader和kernel调用的KernelRelocate所处的位置是不同的，前者是public代码，后者是private代码

2、kernelRelocate以pToc为参数，那么pToc的值从何而来呢？即便你搜索完所有的文件也找不到在那里pToc被赋值。因为pToc是在makeimage阶段被romimage.exe赋值的，也就是说pToc并不是在代码中被赋值的，是由外力（romimage.exe)改动nk.bin的内容赋值的。

3、是不是可以这样理解：kernelRelocate做的事就好比OS加载PE文件完成的事，对段进行重定位生成内存布局。

===========================================================================

附：public下的KernelRelocate代码

// // KernelRelocate: move global variables to RAM // static BOOL KernelRelocate (ROMHDR *const pTOC) { ULONG loop; COPYentry *cptr; if (pTOC == (ROMHDR *const) -1) { return (FALSE); // spin forever! } // This is where the data sections become valid... don't read globals until after this for (loop = 0; loop < pTOC->ulCopyEntries; loop++) { cptr = (COPYentry *)(pTOC->ulCopyOffset + loop*sizeof(COPYentry)); if (cptr->ulCopyLen) memcpy((LPVOID)cptr->ulDest,(LPVOID)cptr->ulSource,cptr->ulCopyLen); if (cptr->ulCopyLen != cptr->ulDestLen) memset((LPVOID)(cptr->ulDest+cptr->ulCopyLen),0,cptr->ulDestLen-cptr->ulCopyLen); } return (TRUE); }

private下的KernelRelocate代码

//------------------------------------------------------------------------------ // Relocate the kernel //------------------------------------------------------------------------------ void KernelRelocate(ROMHDR *const pTOC) { ULONG loop; COPYentry *cptr; #ifdef DEBUG // Can't do much here, no r/w data or real stack, no VM if (pTOC == (ROMHDR *const) 0xffffffff) { OEMWriteDebugString(TEXT("ERROR: Kernel must be part of ROM image!/r/n")); while (1) ; // spin forever! } #endif KInfoTable[KINX_PTOC] = (long)pTOC; // This is where the data sections become valid... don't read globals until after this for (loop = 0; loop < pTOC->ulCopyEntries; loop++) { cptr = (COPYentry *)(pTOC->ulCopyOffset + loop*sizeof(COPYentry)); if (cptr->ulCopyLen) { memcpy((LPVOID)cptr->ulDest,(LPVOID)cptr->ulSource,cptr->ulCopyLen); } if (cptr->ulCopyLen != cptr->ulDestLen) { memset((LPVOID)(cptr->ulDest+cptr->ulCopyLen),0,cptr->ulDestLen-cptr->ulCopyLen); } } // Now you can read global variables... PtrKData = &KData; // Set this to allow displaying the kpage from the KD. MainMemoryEndAddress = pTOC->ulRAMEnd; FirstROM.pTOC = pTOC; FirstROM.pNext = 0; ROMChain = &FirstROM; }