kobs-ng nand flash and large blocks (1MB) imx6

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

kobs-ng nand flash and large blocks (1MB) imx6

Jump to solution
1,792 Views
flanatic
Contributor I

Hello.  I am currently using kobs-ng to write fcb dbbt and u-boot to nand flash for imx6 processor.  The nand flash I am using has1M blocks  (4096 Bytes per page and 256 pages per block). Does Freescale have a recommended fcb dbbt and bootloader configuration when using blocks of this size? kobs-ng does not seem to handle it efficiently as it's placement of fcb dbbt and bootstreams seems geared towards nand flash with smaller blocks.  In our case I can fit fcb dbbt and u-boot into a single block. Currently kobs-ng with a default stride size of 64 will put all 4 fcb into the first block.  This is not desired since if the first block is bad the system will not boot.  If we change stride size to 128 fcb0 and fcb1 will be put in block0 and fcb2 and fcb3 will be put in block1.  This is better but the dbbt will also span across 2 blocks, and the 2 u-boot images will take up another 2 blocks. This will use up 6 MB of nand flash and result in a lot of wasted space. Is there any reason not to create the fcb dbbt and boot stream as shown below?

block0 = fcb0 dbbt0 u-boot0

block1 = fcb1 dbbt1 u-boot1

If the CPU stride size is set to 256 if block0 is bad it will jump to block1 and load fcb1 dbbt1 and u-boot in block1. These scheme will use only 2 blocks. This could also be done for 4 blocks.

Labels (2)
0 Kudos
1 Solution
616 Views
PeterChan
NXP Employee
NXP Employee

This NAND boot block layout is inherited from previous i.MX processors whose target boot image size is several MB which cannot fit into a single physical NAND block. Using this layout simplifies the work for ROM to search for primary & secondary FCB and DBBT.

According to reference manual, "The search area contains copies of the FCB at each stride distance, so in case the first NAND block becomes corrupted, the ROM will find its copy in the next NAND block. The search area should span over at least two NAND blocks". Otherwise, i.MX6 does not boot if the search area is within a single block and the block is bad.

The size of search area can be adjusted by changing either stride size or the boot search count.

View solution in original post

0 Kudos
2 Replies
616 Views
YixingKong
Senior Contributor IV

Flaanatic

Has your question been answered. If yes, please click Correct Answer/Helpful Answer, otherwise keep exchanging emails with Peter. We would close a DI if no activity is seen in 3 days.

Thanks,

Yixing

0 Kudos
617 Views
PeterChan
NXP Employee
NXP Employee

This NAND boot block layout is inherited from previous i.MX processors whose target boot image size is several MB which cannot fit into a single physical NAND block. Using this layout simplifies the work for ROM to search for primary & secondary FCB and DBBT.

According to reference manual, "The search area contains copies of the FCB at each stride distance, so in case the first NAND block becomes corrupted, the ROM will find its copy in the next NAND block. The search area should span over at least two NAND blocks". Otherwise, i.MX6 does not boot if the search area is within a single block and the block is bad.

The size of search area can be adjusted by changing either stride size or the boot search count.

0 Kudos