Vybrid secondary image table format for redundant boot from SD card

[mpfgregory]

In the VYBRIDRM, chapter 19.5.5.6 the format of the secondary image table is described. I'm trying to create a secondary image table with a hex editor. Currently it looks like this:

$ hexdump secondaryImageTable

0000000 0000 0000 0000 0000 2233 0011 0000 0000

I set the PERSIST_SECONDARY_BOOT in u-boot. I assume this is working, because the soft reset doesn't work anymore after u-boot starts. A memory dump in u-boot also shows that the bit is set correctly. But I think something is wrong with my secondary image table. I have written zeroes for the reserved chipNum and driveType fields, assuming they are both 32bits wide. Then I've written the tag (0x00112233). I've tried both big and little endian, it still doesn't work. For firstSectorNumber I use 0, because for now I want to boot just the normal image to see that it's working. I've written the secondary image table to my SD card at address 0x200:

dd if=secondaryImageTable of=/dev/sdd seek=1 bs=512

What am I doing wrong here?

I also don't understand why the VYBRIDRM says: "If PERSIST_SECONDARY_BOOT is 0, the boot ROM uses address 0x0 for primary

image." At adress 0x0 the master boot record of the SD card is stored. The IVT is at address 0x400.

[karina_valencia]

rendy​ do you have an update?

[rendy · Accepted solution]

Hello, I think this is closed. Now we have to wait for RM update.

[rendy]

Hello,

in my opinion your observation are aligned with the content of the reference manual. However we appreciate opinions of our customers so if you want, please specify exactly what statements in the RM are not correct and propose new form which is more clear. I can pass your proposals to documentation team.

As you mentioned, one of these statements is:

"If PERSIST_SECONDARY_BOOT is 0, the boot ROM uses address 0x0 for primary image."

To be honest, I don't understand this too so I will report at least that.

Regards

Rene

[mpfgregory]

That's exactly what I was referring to. My other point is "Table 19-30. Secondary Image Table Format". It should be noted that each entry is 4 bytes wide.

[timesyssupport]

Hi,

I reviewed your image table format, but nothing stood out to me that is incorrect. It is also unclear to me the size of the chipNum and driveType fields, and if 0x0 or 0x400 is intended for the primary image location. Unfortunately, we have not used this boot feature with Vybrid, so I cannot provide a sample table for you to use.

Karina Valencia Aguilar, can the Freescale Vybrid team please clarify the table format, and provide an example table if one is available?

Thanks,

Timesys Support

[mpfgregory]

Meanwhile I have found this thread, where someone managed to get redundant boot working on an iMX.53:

i.MX53 Redundant Boot -blog archive

This works on Vybrid, too. You just have to know that the boot address is NOT the address of the IVT. The IVT is located 1k after the boot address. This is also true for the secondary image. In my case I have the primary u-boot at 0x400 (starting with the IVT):

$ hexdump /dev/sdd -n 16 -s 1024

0000400 00d1 4020 8000 3f40 0000 0000 7918 3f40

The secondary u-boot is at 501k:

&hexdump /dev/sdd -n 16 -s 501k

007d400 00d1 4020 8000 3f40 0000 0000 7918 3f40

The firstSectorNumber in the secondary image table is set to 500k (0x3e8 = 1000 blocks of 512 bytes):

$ hexdump /dev/sdd -n 20 -s 512

0000200 0000 0000 0000 0000 2233 0011 03e8 0000

I think it would be helpful to clarify this in the VYBRIDRM, or at least in the Vybrid Security RM. Also in the description of the secondary image table format it should be noted that each entry is 4 bytes wide.

[rendy]

Hello,

please could you send me the working and non-working images?

Thanks

Rene

[mpfgregory]

Hello Rene,

The secondary image table in this blog post works:

i.MX53 Redundant Boot -blog archive

The technical side of the problem is solved. But in opinion the documentation inside VYBRIDRM and VYBRIDSRM is unclear, see my last post.

[karina_valencia]

rendy​ did you see previous comment?

[karina_valencia]

jiri-b36968​ can you comment?

[jiri-b36968]

Hello,

rendy​ will help.

/Jiri

[karina_valencia]

timesyssupport​ can you help to review this case?