Vybrid secondary image table format for redundant boot from SD card

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

Vybrid secondary image table format for redundant boot from SD card

Jump to solution
2,540 Views
mpfgregory
Contributor III

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.

Labels (2)
0 Kudos
1 Solution
1,879 Views
rendy
NXP Employee
NXP Employee

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

View solution in original post

12 Replies
1,879 Views
karina_valencia
NXP Apps Support
NXP Apps Support

rendy​ do you have an update?

0 Kudos
1,880 Views
rendy
NXP Employee
NXP Employee

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

1,879 Views
rendy
NXP Employee
NXP Employee

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

1,879 Views
mpfgregory
Contributor III

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.

0 Kudos
1,879 Views
timesyssupport
Senior Contributor II

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

0 Kudos
1,879 Views
mpfgregory
Contributor III

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.

0 Kudos
1,879 Views
rendy
NXP Employee
NXP Employee

Hello,

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

Thanks

Rene

0 Kudos
1,879 Views
mpfgregory
Contributor III

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.

0 Kudos
1,879 Views
karina_valencia
NXP Apps Support
NXP Apps Support

rendy​ did you see previous comment?

0 Kudos
1,879 Views
karina_valencia
NXP Apps Support
NXP Apps Support

jiri-b36968​ can you comment?

0 Kudos
1,879 Views
jiri-b36968
NXP Employee
NXP Employee

Hello,

rendy​ will help.

/Jiri

0 Kudos
1,879 Views
karina_valencia
NXP Apps Support
NXP Apps Support

timesyssupport​ can you help to review this case?

0 Kudos