AnsweredAssumed Answered

iMX6SX Redundant Boot

Question asked by David Patton on Oct 24, 2017
Latest reply on Nov 1, 2017 by Yuri Muhin

I have been trying to get redundant boot working on an iMX6SX based board with eMMC; I have studied the little information in the reference manual, found and attempted suggestions from both of these discussions:

Redundant Boot in sdcard failed 

i.MX53 Redundant Boot -blog archive 

but to no avail

I am not (yet) using HAB so no image authentication, that comes later; for now, I just want to prove to myself, I can boot from either image.

 

As I was gathering all my information for this post and looking through it, it occurred to me how the bootrom might work overall; we already know it reads the first 4KB from eMMC, ignores the first 512B, assuming it's the MBR, assumes the next 512B is the secondary image table, then expects the IVT for the primary image at a 1024B offset from the beginning.

 

Here is my secondary image table; 0x800 is the first block of the secondary image, so that's where I assumed I should put the secondary IVT:

root@cpng:~# hexdump -Cv -n 64 -s 512 /dev/mmcblk3boot0
00000200 00 00 00 00 00 00 00 00 33 22 11 00 00 08 00 00 |........3"......|
00000210 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000220 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000230 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
00000240
root@cpng:~#

And here is the first block of the secondary image, containing the secondary IVT:

root@cpng:~# hexdump -Cv -n 128 -s 1048576 /dev/mmcblk3boot0
00100000 d1 00 20 40 00 00 80 87 00 00 00 00 2c f4 7f 87 |.. @........,...|
00100010 20 f4 7f 87 00 f4 7f 87 00 00 00 00 00 00 00 00 | ...............|
00100020 00 f0 7f 87 00 20 05 00 00 00 00 00 d2 02 58 40 |..... ........X@|
00100030 cc 02 54 04 00 90 70 00 12 34 5a 5a 02 0c 40 68 |..T...p..4ZZ..@h|
00100040 ff ff ff ff 02 0c 40 6c ff ff ff ff 02 0c 40 70 |......@l......@p|
00100050 ff ff ff ff 02 0c 40 74 ff ff ff ff 02 0c 40 78 |......@t......@x|
00100060 ff ff ff ff 02 0c 40 7c ff ff ff ff 02 0c 40 80 |......@|......@.|
00100070 ff ff ff ff 02 0e 06 08 00 02 00 00 02 0e 05 fc |................|
00100080
root@cpng:~#

Needless to say, this setup did not work, when trying to boot the secondary image.

 

But considering what I said above, if the bootrom operates the same on the secondary image as it does on the primary, it will read 4KB starting at the , skip the first 512B even though we all know there cannot be an MBR there, skips the next 512B for the secondary image table, even though again, there cannot be one there.

 

So I moved the secondary IVT to 0x100400:

 

root@cpng:~# hexdump -Cv -n 128 -s 1049600 /dev/mmcblk3boot0
00100400 d1 00 20 40 00 00 80 87 00 00 00 00 2c f4 7f 87 |.. @........,...|
00100410 20 f4 7f 87 00 f4 7f 87 00 00 00 00 00 00 00 00 | ...............|
00100420 00 f0 7f 87 00 20 05 00 00 00 00 00 d2 02 58 40 |..... ........X@|
00100430 cc 02 54 04 00 90 70 00 12 34 5a 5a 02 0c 40 68 |..T...p..4ZZ..@h|
00100440 ff ff ff ff 02 0c 40 6c ff ff ff ff 02 0c 40 70 |......@l......@p|
00100450 ff ff ff ff 02 0c 40 74 ff ff ff ff 02 0c 40 78 |......@t......@x|
00100460 ff ff ff ff 02 0c 40 7c ff ff ff ff 02 0c 40 80 |......@|......@.|
00100470 ff ff ff ff 02 0e 06 08 00 02 00 00 02 0e 05 fc |................|
00100480
root@cpng:~#

and lo and behold I can boot either image.

 

My question is: did I miss something somewhere that indicates this is how the setup should be? I can find very little info on redundant boot and nothing that indicates the offset for the secondary image. In section 8.5.3.5 of the iMX6SoloX reference manual, table 8-21, it indicates that the "firstSectorNumber is the first 512B sector numberof the secondary image", to me that says put the secondary IVT in that block, not 2 512B blocks after it.

 

So NXP, please update your documentation with a much more thorough explanation of how redundant boot images are to be placed in the storage device. A quick blurb of how the secondary IVT should be 1024B after the firstSectorNumber, and 'why', would have saved me an awful lot of time and frustration!

 

I hope this post helps someone...

Outcomes