i.MX: Boot alternate image from NAND -blog archive

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

i.MX: Boot alternate image from NAND -blog archive

1,105 Views
GraceH
Senior Contributor II

In reference manual, it states
"If ROM NAND driver fails to load from primary boot image due to non-ECC failures like invalid header, and so on, it will return an error code to the ROM loader. The secondary boot will be initiated by the loader if the driver supports redundant boot. ROM NAND driver and ROM SD driver are the only two drivers that currently support ROM redundant boot."

 

MX28 NAND has FCB(Firmware Configuration Block), ROM loader will read the m_u32Firmware1_StartingSector and m_u32Firmware2_StartingSector from FCB and load the firmware image from that address. The address of m_u32Firmware1_StartingSector and m_u32Firmware2_StartingSector are not fixed with difference NAND.
The addresses are calculated when use kobs-ng to program firmware image and written to FCB.
So to support alternate image boot, you must use kobs-ng to program image to NAND.
You can use "./ltib -p kobs-ng.spec -m prep" to generate kobs-ng source code to learn more how FCB is created.

 

When I use command "kobs-ng init -v $FILE" to program the image to NAND, It shows the below log.
It means the first firmware image is at address 0x200000 and the second image is at 0xb00000.

 

Firmware: image #0 @ 0x200000 size 0x24f000 - available 0x900000
Firmware: image #1 @ 0xb00000 size 0x24f000 - available 0x900000 NCB versions differ, 3 is used.
mtd: erasing @0:0x0-0x80000
mtd: Writing FCB0 @0:0x0(1080)
mtd: Writing FCB1 @0:0x40000(1080)
mtd: erasing @0:0x80000-0x80000
mtd: Writing FCB2 @0:0x80000(1080)
mtd: Writing FCB3 @0:0xc0000(1080)
mtd: erasing @0:0x0-0x80000
mtd: Writing FCB0 @0:0x0(1080)
mtd: Writing FCB1 @0:0x40000(1080)
mtd: erasing @0:0x80000-0x80000
mtd: Writing FCB2 @0:0x80000(1080)
mtd: Writing FCB3 @0:0xc0000(1080)
mtd_commit_bcb(FCB): status 0
mtd: erasing @0:0x100000-0x80000
mtd: Writing DBBT0 @0:0x100000(1000)
mtd: Writing DBBT1 @0:0x140000(1000)
mtd: erasing @0:0x180000-0x80000
mtd: Writing DBBT2 @0:0x180000(1000)
mtd: Writing DBBT3 @0:0x1c0000(1000)
mtd: erasing @0:0x100000-0x80000
mtd: Writing DBBT0 @0:0x100000(1000)
mtd: Writing DBBT1 @0:0x140000(1000)
mtd: erasing @0:0x180000-0x80000
mtd: Writing DBBT2 @0:0x180000(1000)
mtd: Writing DBBT3 @0:0x1c0000(1000)
mtd_commit_bcb(DBBT): status 0
mtd: Writting firmware image #0 @0: 0x00200000 - 0x0044f000
mtd: erasing @0:0x200000-0x80000
mtd: erasing @0:0x280000-0x80000
mtd: erasing @0:0x300000-0x80000
mtd: erasing @0:0x380000-0x80000
mtd: erasing @0:0x400000-0x80000
mtd: Writting firmware image #1 @0: 0x00b00000 - 0x00d4f000
mtd: erasing @0:0xb00000-0x80000
mtd: erasing @0:0xb80000-0x80000
mtd: erasing @0:0xc00000-0x80000
mtd: erasing @0:0xc80000-0x80000
mtd: erasing @0:0xd00000-0x80000

Tags (1)
0 Kudos
Reply
2 Replies

693 Views
stefanroese
Contributor II

A quick update:

I got it working. The main problem was, that the IVT did initialize the clock gating registers wrong for NAND booting. So after loading the first page with the IVT table and executing this table (writing the regs), the NAND interface stopped working correctly. With the correct clock-gating register setup its working now.

Thanks,

Stefan

0 Kudos
Reply

693 Views
Gatts
Contributor I

Can you let me know if you've any pointers for how to boot up as redundant boot in SD Card.This is in case if it fails to boot up from the primary partition.

0 Kudos
Reply