Boot Code Integrity check with CRC
Raymond Yeung
Boot code, persistent data and VxWorks (i.e. application) are all
on flash.
One self-test I'm considering for the flash is CRC check. When it
comes to the boot code, I've the following questions:
+ Boot code resides in a erasable sector (it's an AMD flash part with
equal sector size). We normally burn boot code with emulator. But
in future, we may implement S/W upgrade of the boot code by FTP transfer
from host.
Given this background, is it common for people to do CRC on boot code?
+ If I implement my own S-record based loader to flash, and since S-record
specifies address, actual data, and its length, boot code content can
be scattered over distiguous flash memory regions. How does CRC program
figure out where to pick up the "pieces" to compute CRC?
+ How do we compute CRC on host? I presume we won't compute over an S-record
file?
Would appreciate any comments or references to articles.
Thanks,
Raymond
Graham Baxter
Consider also using a "magic" number just before the checksum. If it is not
in the correct place there is no point in validating the CRC.
Any gaps in S-records would be filled with 0xFFFFFFFF as with uninitialized
flash.
I always leave space for the magic number and checksum at the very end of
the image.
I build a binary image which just has a checksum set to 0xFFFFFFFF right at
the end.
As soon as the binary image is built, I use a utility to perform the
checksum calculation and write a new file with the correct checksum.
You should find a some checksum code free on the web to enable you to write
this utility.
The same code that you use on your host to compute the checksum can be
compiled into your target to validate a checksum.
S-records are very wasteful. A binary image with a 32-bit checksum is very
safe and does not waste any space.
A final word of warning, be careful if your host and target have different
Endianesses.
--
Regards,
Graham Baxter
Freelance Software Engineer (VxWorks and pSOS BSPs) - available shortly for
a new assignment
Graham Baxter (Software) Limited
gba...@NOSPAMbcs.org.uk
"Raymond Yeung" <rye...@earthlink.net> wrote in message
news:d83bb8e3.02101...@posting.google.com...
joe durusau
Raymond Yeung wrote:
> We're developing diagnostics for our 8260 based processor board.
> Boot code, persistent data and VxWorks (i.e. application) are all
> on flash.
>
> One self-test I'm considering for the flash is CRC check. When it
> comes to the boot code, I've the following questions:
>
> + Boot code resides in a erasable sector (it's an AMD flash part with
> equal sector size). We normally burn boot code with emulator. But
> in future, we may implement S/W upgrade of the boot code by FTP transfer
> from host.
> Given this background, is it common for people to do CRC on boot code?
>
Never heard of anyone bothering, since there are checks on the net
transfer already. Most checks are some sort of a addition. Nothing
wrong with a CRC, I just haven't seen anybody doing it.
>
> + If I implement my own S-record based loader to flash, and since S-record
> specifies address, actual data, and its length, boot code content can
> be scattered over distiguous flash memory regions. How does CRC program
> figure out where to pick up the "pieces" to compute CRC?
>
If you are flashing vxWorks_rom or something similar, it doesn't
have any "holes" - that is, it fill up from wherever it starts to wherever it
ends. You would have to tell the CRC program the starting and ending
addresses.
>
> + How do we compute CRC on host? I presume we won't compute over an S-record
> file?
>
You would do it easily if the two machines have the same wordsize and
endian-ness. Otherwise, it can be a mess. I've seen it done by flashing,
then computing the CRC on the target, then putting the result somewhere
it can be found. There are programs that can verify the flash against the
S-records, bit for bit if you wish.
>
> Would appreciate any comments or references to articles.
>
> Thanks,
> Raymond
Speaking only for myself,
Joe Durusau
Stephen
Yeung <rye...@earthlink.net> writes
>We're developing diagnostics for our 8260 based processor board.
>Boot code, persistent data and VxWorks (i.e. application) are all
>on flash.
>
>One self-test I'm considering for the flash is CRC check. When it
>comes to the boot code, I've the following questions:
>
>+ Boot code resides in a erasable sector (it's an AMD flash part with
> equal sector size). We normally burn boot code with emulator. But
> in future, we may implement S/W upgrade of the boot code by FTP transfer
> from host.
> Given this background, is it common for people to do CRC on boot code?
Sure. I'd certainly consider doing it if there were no other reasons not
to, but it might depend on how important CRC integrity was - such as
what sort of damage or data loss might occur if the boot code was bogus.
>+ If I implement my own S-record based loader to flash, and since S-record
> specifies address, actual data, and its length, boot code content can
> be scattered over distiguous flash memory regions. How does CRC program
> figure out where to pick up the "pieces" to compute CRC?
One suggestion would be to make a policy of having the unused areas of
flash contain a known pattern, such as 0x00 or 0xFF, and then compute
the CRC over the whole lot.
>+ How do we compute CRC on host? I presume we won't compute over an S-record
> file?
Either write a program to analyse the S-record file and compute the CRC,
or if you have the capability, allow a special diagnostics mode on the
target to *report* the CRC it was expecting when the CRC fails. With a
bit of appropriate number handling, you should be able to use this to go
back to the source and enter the correct CRC (without modifying anything
else).
David Laight
> + Boot code resides in a erasable sector (it's an AMD flash part with
> equal sector size). We normally burn boot code with emulator. But
> in future, we may implement S/W upgrade of the boot code by FTP transfer
> from host.
> Given this background, is it common for people to do CRC on boot code?
I did the following (remember the image you want is binary, not S
records...)
1) Add a header to the vxworks image (the ARM one has one we hacked)
2) Put a checksum and size in the header
3) Load the entire image onto the system, validate the checksum before
writing to flash (makes sure the file hasn't gine through an ascii
ftp)
4) On boot (in rominit.s) validate the checksum - will explode if the
update was only partial, instead on going really badly wrong during
the uncompress.
David
Wolfgang Denk
>We're developing diagnostics for our 8260 based processor board.
I guess you've looked around for existing solutions to that problem?
> Given this background, is it common for people to do CRC on boot code?
Yes.
>+ If I implement my own S-record based loader to flash, and since S-record
If you implement your own S-record based loader to flash, you're
wasting your time. This has been done many times before. Did you -
for example - have a look at the PPCBoot code?
> specifies address, actual data, and its length, boot code content can
> be scattered over distiguous flash memory regions. How does CRC program
> figure out where to pick up the "pieces" to compute CRC?
It doesn't figure it out, you tell it.
>+ How do we compute CRC on host? I presume we won't compute over an S-record
> file?
Why not run the CRC code over a binary image?
>Would appreciate any comments or references to articles.
<comment>
use PPCBoot
</comment>
Best regards,
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de
How does a project get to be a year late? ... One day at a time.
Grant Edwards
> Given this background, is it common for people to do CRC on boot code?
Some sort of checksum. It doesn't have to be CRC. I've never seen any
failure mode data on flash ROM to indicate that CRC provides better
protection than faster methods. CRC has proven advantages for use on
communications lines, but I'm not convinced the failure patterns observed on
communications lines are the same as those observed in ROMs.
> + If I implement my own S-record based loader to flash, and since S-record
> specifies address, actual data, and its length, boot code content can
> be scattered over distiguous flash memory regions. How does CRC program
> figure out where to pick up the "pieces" to compute CRC?
I require that the "file" be contiguous. The checksum is added to the image
before it is downloaded.
> + How do we compute CRC on host? I presume we won't compute over an S-record
> file?
I wrote a C program to do it on a binary file. In the past, I've used
and/or written programs that would operate on hex files (they would also
fill in holes in the file).
--
Grant Edwards
gra...@visi.com
Raymond Yeung
following thoughts:
1. S-record is a wrong form to use. Initially, I explored what
format to use; VxWorks generates elf, hex (S-record). But I'm
not sure I found the binary version that I can load directly to
flash and have the processor boot. That's why I thought about
using S-record, and write a loader on target to interpret all
S-records.
2. Incidentally, has anyone done the following below: Use the bin
file from visionCLICK Convert utility. Strip off the 32-bytes
header, and load the remaining data section directly to flash
for boot up purpose, starting at reset vector location.
3. Checksum instead of CRC may be used for boot code integrity.
Assuming I'm dealing with binary, there'd be no "holes" as in
S-record. Thus, I can compute the checksum from start to end
of the entire binary.
4. On the host, I can put checksum at end of the boot code binary
file. But once I "load" it onto flash, would I put this
checksum at a fixed known location (e.g. last 32-bit of an
erase sector)? Or would I create a global variable in boot code
to store that? I suppose I can't just stick it at the "end" as
the code doesn't know where the location of this end is, does it?
In the case of using global, how do I commuicate with the
host tool to initialize it to the proper checksum when I build
the file? Or am I off-track here?
5. What is PPCBoot? I try searching for it on Googles, and got
too many returns. Would appreciate it if one can provide a
link to its tutorial? (Note: I'm currently booting using VxWorks
boot rom. Is PPCBoot another boot rom?)
6. To evaluate usefulness of this checksum thing (to tell people why
I even bother to go through all these), I've the following points:
+ flash could be defective: certain cells may have faults (e.g.
stuck-at).
+ Boot image may first have to be transferred to RAM before
writing to flash (buffer for FTP). Similar memory related
problem could happen here in RAM. Furthermore, a strayed thread
could overwrite its content before it's written to flash.
+ Read back could have problems (either address/data/flash-device)
issue.
+ Verifying checksum right after file transfer ensures the file
is not screwed up due to ASCII transfer (as David pointed out).
But this would not be applicable if I program boot code only
with Emulator.
Did I miss anything?
Thanks,
Raymond
nospam
>4. On the host, I can put checksum at end of the boot code binary
> file. But once I "load" it onto flash, would I put this
> checksum at a fixed known location (e.g. last 32-bit of an
> erase sector)? Or would I create a global variable in boot code
> to store that?
If you calculate a checksum for the entire boot block (assuming it begins
in an erased state) and insert somewhere into that block the inverse of the
checksum. The system then checksums the entire boot block and will always
get the same value. You don't need to know what or where the checksum is,
you arrange for the block to always have the same checksum.
To verify the contents in RAM prior to FLASH programming you can still
pretend to check the whole block or why not use a block sized amount of
RAM, one day the code may occupy the whole block so you probably have to be
able to allocate that amount of RAM anyway.
Rajesh Tripathi
Raymond Yeung wrote:
> Thanks for all the replies. Having read all of them, I've the
> following thoughts:
>
> 1. S-record is a wrong form to use. Initially, I explored what
> format to use; VxWorks generates elf, hex (S-record). But I'm
> not sure I found the binary version that I can load directly to
> flash and have the processor boot. That's why I thought about
> using S-record, and write a loader on target to interpret all
> S-records.
I used elfToBin utility for generating binary file form elf file. That was
two years ago on Tornado 2.0 for PPC and I don't find that file on my T2.1
for MIPS installation now. I believe the recommended way now is to use
"objcopyppc -O binary --binary-without-bss xyz.elf xyz.bin"
Which version of Tornado you are using?
>
> 2. Incidentally, has anyone done the following below: Use the bin
> file from visionCLICK Convert utility. Strip off the 32-bytes
> header, and load the remaining data section directly to flash
> for boot up purpose, starting at reset vector location.
It Should work although I never tried. Now I'm using our own utility to
extract the text and data sections from elf file and prepend with a header. A
bootrom update utility on target loads the file via tftp and burns the flash.
You can even embed the bootrom image it in application image to be
automatically or manually updated in field.
>
> 3. Checksum instead of CRC may be used for boot code integrity.
> Assuming I'm dealing with binary, there'd be no "holes" as in
> S-record. Thus, I can compute the checksum from start to end
> of the entire binary.
Checksum is fine.
>
> 4. On the host, I can put checksum at end of the boot code binary
> file. But once I "load" it onto flash, would I put this
> checksum at a fixed known location (e.g. last 32-bit of an
> erase sector)? Or would I create a global variable in boot code
> to store that? I suppose I can't just stick it at the "end" as
> the code doesn't know where the location of this end is, does it?
> In the case of using global, how do I commuicate with the
> host tool to initialize it to the proper checksum when I build
> the file? Or am I off-track here?
It works fine both ways. On PPC declare a global and initialize it with a
Macro say CKSUM defined as zero in Makefile. After linking is done, extract
the bin file, calculate checksum and save the compliment of checksum in a
temporary file tchksum. Now do a second link and pass it at link time as
$(LD) $(LDFLAGS) -defsym CKSUM=`cat tchksum` -e $(ROM_ENTRY)
The global variable now has compliment of checksum and if you calculate the
checksum during POST, it should always be zero. You've to play with Makefile
a little but it works fine.
The other way is to have a utility calculate checksum and append it to
binary file at the end. The bootcode calculates checksum from start upto
_edata and compares it to the stored checksum at _edata. The data section is
normally linked at ram address so calculate it's size by _edata - _fdata and
add it to _etext to find the last address of image in flash.
>
> 5. What is PPCBoot? I try searching for it on Googles, and got
> too many returns. Would appreciate it if one can provide a
> link to its tutorial? (Note: I'm currently booting using VxWorks
> boot rom. Is PPCBoot another boot rom?)
This is a great bootloder for PowerPc . Documentation should be available at
http://ppcboot.sourceforge.net
>
> 6. To evaluate usefulness of this checksum thing (to tell people why
> I even bother to go through all these), I've the following points:
> + flash could be defective: certain cells may have faults (e.g.
> stuck-at).
> + Boot image may first have to be transferred to RAM before
> writing to flash (buffer for FTP). Similar memory related
> problem could happen here in RAM. Furthermore, a strayed thread
> could overwrite its content before it's written to flash.
> + Read back could have problems (either address/data/flash-device)
> issue.
> + Verifying checksum right after file transfer ensures the file
> is not screwed up due to ASCII transfer (as David pointed out).
> But this would not be applicable if I program boot code only
> with Emulator.
> Did I miss anything?
>
> Thanks,
> Raymond
Regards,
Rajesh
Raymond Yeung
on all the good insights provided so far.
Raymond Yeung
> Hi Raymond,
>
> Raymond Yeung wrote:
>
> > Thanks for all the replies. Having read all of them, I've the
> > following thoughts:
> >
> > 1. S-record is a wrong form to use. Initially, I explored what
> > format to use; VxWorks generates elf, hex (S-record). But I'm
> > not sure I found the binary version that I can load directly to
> > flash and have the processor boot. That's why I thought about
> > using S-record, and write a loader on target to interpret all
> > S-records.
>
> I used elfToBin utility for generating binary file form elf file. That was
> two years ago on Tornado 2.0 for PPC and I don't find that file on my T2.1
> for MIPS installation now. I believe the recommended way now is to use
> "objcopyppc -O binary --binary-without-bss xyz.elf xyz.bin"
>
> Which version of Tornado you are using?
>
I use Tornado 2.0. I tried out elfToBin. When I diff its output with
Emulator's convert utility output (with header stripped), I find that elfToBin's
output contains lots of extra 0's at the end of the file (hence 2-3 times
larger than the other file). Otherwise, it looks like the two binaries are
the same. Are all those 0's the BSS?
I also tried your "objcopyppc -O binary --binary-without-bss xyz.elf xyz.bin"
command. Apparently, my version of objcopyppc don't seem to support
"--binary-without-bss" option. Any other way to strip all the extra zeros?
Wolfgang Denk
>5. What is PPCBoot? I try searching for it on Googles, and got
> too many returns. Would appreciate it if one can provide a
> link to its tutorial? (Note: I'm currently booting using VxWorks
> boot rom. Is PPCBoot another boot rom?)
Urrrrrghhh...
If you google just for "PPCBoot", the very first link that turns up
is the PPCBoot home page at Sourceforge ("Embedded PowerPC Linux Boot
Project"), and the second link is the "PPCBoot-users Info Page".
That was too many links for you to follow?
Wolfgang Denk
--
Software Engineering: Embedded and Realtime Systems, Embedded Linux
Phone: (+49)-8142-4596-87 Fax: (+49)-8142-4596-88 Web: www.denx.de
As long as we're going to reinvent the wheel again, we might as well
try making it round this time. - Mike Dennison
Raymond Yeung
mentioned as the 1st and 2nd links, now that I tried again.
Previously, I tried my search on the advanced_group_search, which
I suppose returns things from newsgroups only. My regular search engine
is alta-vista. :) Perhaps I should start using Google in other aspect
more....
Wolfgang Denk <w...@denx.muc.de> wrote in message news:<H45IzB.DnC....@denx.muc.de>...