The nbl1.lsb and nbl2 compilation and download of real6410 cannot be started.

* ****************************** Loongembedded ******* *************************

Author: loongembedded (Kandi)

Time: 2012.03.24

Category: wince System Development

* ****************************** Loongembedded ******* *************************

 

The image generated by the nbl1.lsb and nbl2 of the real6410 Development Board is merged into block0img. nb0, but the first-stage bootloader updated using the SD card irom_sd_eboot.nb0 is block0.nb0, so for unification, I modified the nbl1.lsb and nbl2 to generate block0.nb0 (72kb ). Then, the block0.nb0 can be burned based on the SD card startup method, but the system cannot be started. However, if the block0.nb0 (68kb) provided by the real6410 development board manufacturer is used for installation, it can be started normally. To further clarify the problem, I updated block0.nb0 (72kb) which was compiled by myself based on the USB update method, and it can be started normally. If I updated block0.nb0 (68kb) provided by the manufacturer) but cannot start normally.

 

To solve this problem, we carefully checked nbl1.lsb, nbl2, and eboot. whimory and eboot. sdfuser code found that real6410 modified the original Samsung code. Let's analyze this problem. Let's first look at the main function of nbl1.lsb:

Figure 1

We can see that the nbl1 part reads the nbl2 part from 10th pages, and I compared the eboot provided by real6410. sdfuser and Samsung store this folder named NAND. the CPP file is related to the writerawimagetobootmedia function of block0.0. it is found that real6410 has made the following changes:

Figure 2

The size of a page in mlc nand Flash used by real6410 is 2048. Therefore, real6410 writes the nbl2 part of the image file to the address starting from the 6page, as we know above, nbl1 reads nbl2 from the place where 10th pages are stored. This will certainly result in nbl1 being able to copy only the last half of nbl2, so that nbl1 cannot be started normally. Therefore, after testing, the content returned to the original manufacturer of Samsung does not have the problems mentioned above.

 

Next let's take a look at the bib file of nbl1.lsb.

Figure 3

Let's take a look at the statement contained in the nbl1.lsb makefile:

Copy/y/B $ (_ platformroot) \ $ (_ tgtplat) \ target \ $ (_ tgtcpu) \ $ (wincedebug) \ nbl1.nb1 $ (_ platformroot) \ $ (_ tgtplat) \ target \ $ (_ tgtcpu) \ $ (wincedebug) \ nbl1.nb0

Nbl1.nb0 is composed of nbl1.nb1
Copy the file. Next, check the makefile of nbl2:

Copy/B $ (_ platformroot) \ $ (_ tgtplat) \ target \ $ (_ tgtcpu) \ $ (wincedebug) \ nbl1.nb1 + $ (_ platformroot) \ $ (_ tgtplat) \ target \ $ (_ tgtcpu) \ $ (wincedebug) \ nbl1.nb2 +
$ (_ Platformroot) \ $ (_ tgtplat) \ target \ $ (_ tgtcpu) \ $ (wincedebug) \ nbl2.nb0 $ (_ platformroot) \ $ (_ tgtplat) \ target \ $ (_ tgtcpu) \ $ (wincedebug) \ block0.nb0

It means that block0.nb0 = nbl1.nb1 + nbl1.nb2 + nbl2.nb0 is merged. I don't think it is necessary to do this. Since supports 8 KB stepping
Stone, then I tried to change 0x00001000 (4 kb) in Figure 3 to 0x00002000 (8 KB), and removed the statement above nbl1.lsb makefile, change the above part of nbl2 makefile:

Copy/B $ (_ platformroot) \ $ (_ tgtplat) \ target \ $ (_ tgtcpu) \ $ (wincedebug) \ nbl1.nb0 + $ (_ platformroot) \ $ (_ tgtplat) \ target \ $ (_ tgtcpu) \ $ (wincedebug) \ nbl2.nb0 $ (_ platformroot) \ $ (_ tgtplat) \ target \ $ (_ tgtcpu) \ $ (wincedebug) \ block0.nb0

In this way, the size of nbl1.nb0 generated by compilation is 8 KB, nbl2.nb0 is 68kb, and blcok is modified. the nb0 size is 72 KB, and the block is updated based on the SD card and USB card. nb0, can be started normally, so it is easier to understand.