To enable secondary IFS restoration, use the -i option to
the startup in the buildfile:
startup-boardname -i ifs2_size[,flags][,paddr_src][,paddr_dst]
The arguments are:
- ifs2_size
- The size of the secondary IFS (note: this can be larger than the
actual size).
- flags
-
- Not specified — load the secondary IFS but don't try
to restore on wake-up
- R — load the secondary IFS and restore
- K or RK — load the secondary IFS and
restore with a checksum
- paddr_src
-
- Not specified — the secondary IFS is located in flash after
the primary IFS
- Specified — the secondary IFS is located at the physical
address specified
- paddr_dst
-
- Not specified — the secondary IFS will be copied to a
default location in RAM
- Specified — the secondary IFS will be copied to the
physical address specified
(choose an address in a "safe" place, such as at the end of
RAM away from where the primary image is copied)
For debugging output, specify at least two levels of debugging via the
-v option:
startup-boardname -i ifs2_size[,flags][,paddr_src][,paddr_dst] -vv
If the checksum is enabled and fails, the entire secondary IFS is reloaded.
Note:
Even if the secondary IFS checksum is disabled, a checksum is still
performed on the IFS Restoration internal data structure (approximately 16 bytes)
to ensure at least some data integrity.
CAUTION:
Kernel and secondary IFS restoration aren't guaranteed to work if the
image is downloaded serially.
This is because the IPL may copy the serially downloaded image to a
location in RAM that overwrites the secondary IFS or data structures
used by the restore features.
In practice, this isn't an issue since serial downloading won't be
used other than for testing.
If serial download is required, try manually setting the destination
location of the secondary IFS to be somewhere away from where the IPL
downloads the image.