public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: "Christopher Cordahi" <christopher.cordahi@gmail.com>
To: "Sergei Gavrikov" <w3sg@softhome.net>
Cc: ecos-discuss@ecos.sourceware.org
Subject: Re: [ECOS] Adding checksum to elf file
Date: Thu, 14 Jun 2007 18:48:00 -0000	[thread overview]
Message-ID: <a1a7967e0706140846u6c9f4544j38d2f8561ec4f05@mail.gmail.com> (raw)
In-Reply-To: <20070610110013.GA12904@ubuntu>

On 10/06/07, Sergei Gavrikov <w3sg@softhome.net> wrote:
> On Sat, Jun 09, 2007 at 11:46:18AM +0300, Sergei Gavrikov wrote:
> > On Fri, Jun 08, 2007 at 10:08:28PM -0400, Christopher Cordahi wrote:
> > > On 05/06/07, Sergei Gavrikov <w3sg@softhome.net> wrote:
> > > >On Tue, Jun 05, 2007 at 01:49:36PM -0400, Christopher Cordahi wrote:
> > > >> Hello ecos
> > > >>
> > > >> I'd like to add some sort of checksum into the .elf files.
> > > >> Is there a standard way of doing this?
> > > >>
> > > >> Googling I see some mention of a .dynamic tag DT_CHECKSUM
> > > >> but not how to use it properly
> > > >> and a short discussion in
> > > >> http://ecos.sourceware.org/ml/binutils/2003-02/msg00242.html
> > > >> but it doesn't seem very standard.
> > > >>
> > > >> Any ideas?
> > > >
> > > >It seems, it's more suitable to verify ELF using a parallel md5sum file
> > > >That is 128-bit! There are sources http://www.ietf.org/rfc/rfc1321.txt.
> > >
> > > Thanks,
> > > However I only want it to detect accidental file corruption, something that
> > > can be added to the file at file creation and can be easily verified by the
> > > program loader (redboot).  At most I was thinking about implementing a
> > > 32 bit CRC algorithm and probably only a 16 bits.  Maintaining and
> > > distributing only 1 file is much easier than 2 so I am hoping to add the
> > > CRC to the file in a standard way.  If there is no such standard I'll have
> > > to resort to a method similar to that mentioned in the discussion.
> >
> > I have an idea to do it with no blood. You won't need tweak ELF. You can
> > use zipped ELF and use RedBoot's [fis load] command with -d option
>   ^^^^^^^^^^^^^^
>
> Ups, I should correct myself. That should be compressed binary BFD.
>
> > (decompress).  Any corruption in your gzip file will be found by gzip
> > layer as well. Gzip has a nice crc checking. It quite works. There is a
> > demo below
> >
> > Let's do it in shell
> >
> > make hello
>
> objcopy -O binary hello ;# <-- I passed this conversion
>
> > gzip hello
> > nano hello.gz ; imitate a corruption :-)
> >
> > and this one let's do in RedBoot
> >
> > load -r -b %{freememlo}
> > fis create hello.gz
> > fis load -d hello.gz
> > decompression error: invalid literal/lengths set
> >
> > If you can see, we catch that corruption before a run! More that, I
> > build-in GUNZIP behavior in RedBoot every time to decrease an upload
> > time when I use Ymodem to load ELFs. Gzipped, even non-stripped ELF
> > files don't eat my FLASH.
> >
> > Note: your redboot_ROM.ecm should contain such things
> >
> > cdl_configuration eCos {
> > ...
> >     package CYGPKG_COMPRESS_ZLIB current ;
> > };
> >
> > ...
> >
> > cdl_option CYGBLD_BUILD_REDBOOT_WITH_GUNZIP {
> >     user_value 1
> > };
> >
> >
> > -- Sergei
>

Thanks,
that's a very good solution, I hadn't noticed the zip option,
I also like the idea of saving 50 % of the Flash and transfer time.
also less data = less chance of corruption.

How much longer does it take to do the decompression?
Loading the .elf file takes long enough.
However reading less data from slow Flash should speed it up.
Guess I'll just have to try it out.

Thanks again,
-- 
Chris

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

  reply	other threads:[~2007-06-14 15:46 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-06-06  6:50 Christopher Cordahi
2007-06-06  8:50 ` Sergei Gavrikov
2007-06-11 20:35   ` Christopher Cordahi
2007-06-11 21:15     ` Sergei Gavrikov
2007-06-11 21:25       ` Sergei Gavrikov
2007-06-14 18:48         ` Christopher Cordahi [this message]
2007-06-14 23:50           ` Sergei Gavrikov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=a1a7967e0706140846u6c9f4544j38d2f8561ec4f05@mail.gmail.com \
    --to=christopher.cordahi@gmail.com \
    --cc=ecos-discuss@ecos.sourceware.org \
    --cc=w3sg@softhome.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).