[U-Boot-Users] Reading out version_string from a binary

[U-Boot-Users] Reading out version_string from a binary

[Fredrik Roubert]

Hi!

I use U-Boot (1.1.4) on a custom PowerPC (MPC8347) based board, and from
my application I need to read out the value of version_string from the
U-Boot binary, for logging. I've written some code that does this (see
attached sample program), but would like some comments if someone has
suggestions on how to do it more robust.

On MPC83XX, version_string is stored at the beginning of .rodata, so if
only the offset for .rodata is found, reading out version_string is
quite straightforward.

The offset of .rodata changes, however, when code is added or removed
from U-Boot. I've found that an offset is being written at the end of
start.o, from which it is possible to calculate the offset of .rodata,
and even though this works for my current needs, it's hardly what one
would call a robust solutions.

Does anyone have ideas about a better way to do this?

Cheers // Fredrik Roubert

-- 
Barco Medical Imaging          |  +32 56 233549
http://www.barco.com/medical/  |  fredrik.roubert at barco.com
-------------- next part --------------

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdint.h>
#include <unistd.h>
#include <fcntl.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <arpa/inet.h>
#include <errno.h>


static char *
ubootver(const char *path)
{
	/* This code assumes big-endian U-Boot binaries. */

	enum /* Magic constants to find the .reloc segment. */
	{
		START = 0x3748,
		MAGIC = 0x7ea8,
	};

	static char buf[128]; /* Must be large enough. */

	int fd, err;
	uint32_t tmp, offset, base;

	if (path == NULL)
	{
		errno = EINVAL;
		return NULL;
	}

	if ((fd = open(path, O_RDONLY)) == -1)
		return NULL;

	/* Get offset for .reloc segment. */

	if
	(
		lseek(fd, START, SEEK_SET) != START ||
		read(fd, &tmp, sizeof tmp) != sizeof tmp
	)
		goto error;

	offset = ntohl(tmp) - MAGIC;

	/* Get base for address space. */

	if
	(
		lseek(fd, offset, SEEK_SET) != offset ||
		read(fd, &tmp, sizeof tmp) != sizeof tmp
	)
		goto error;

	base = ntohl(tmp) - offset;

	/* Get offset for version_string. */

	if (read(fd, &tmp, sizeof tmp) != sizeof tmp)
		goto error;

	offset = ntohl(tmp) - base;

	/* Read version_string. */

	if
	(
		lseek(fd, offset, SEEK_SET) != offset ||
		read(fd, buf, sizeof buf) != sizeof buf
	)
		goto error;

	if (close(fd) == -1)
		return NULL;

	return buf;

error:
	err = errno;
	close(fd);
	errno = err;
	return NULL;
}


int
main(int argc, char *argv[])
{
	char *ver;

	if (argc != 2)
	{
		fprintf(stderr, "Usage: %s [PATH]\n", argv[0]);
		return EXIT_FAILURE;
	}

	if ((ver = ubootver(argv[1])) == NULL)
	{
		perror("ubootver()");
		return EXIT_FAILURE;
	}

	printf("\"%s\"\n", ver);

	return EXIT_SUCCESS;
}

[U-Boot-Users] Reading out version_string from a binary

[Markus Klotzbücher]

Hi Frederik,

Fredrik Roubert <fredrik.roubert@barco.com> writes:

> I use U-Boot (1.1.4) on a custom PowerPC (MPC8347) based board, and from
> my application I need to read out the value of version_string from the
> U-Boot binary, for logging. I've written some code that does this (see
> attached sample program), but would like some comments if someone has
> suggestions on how to do it more robust.
...
> Does anyone have ideas about a better way to do this?

If it doesn't have to be in C you could do something like

$ strings < u-boot.bin | grep  "U-Boot \([0-9]\.\)\{2\}[0-9]-"
VU-Boot 1.1.6-g13e2fe54 (Nov 21 2006 - 11:37:26)

Regards

Markus Klotzbuecher

[U-Boot-Users] Reading out version_string from a binary

[Wolfgang Denk]

In message <20061121130236.GC3803@igloo.df.lth.se> you wrote:
> 
> I use U-Boot (1.1.4) on a custom PowerPC (MPC8347) based board, and from
> my application I need to read out the value of version_string from the
> U-Boot binary, for logging. I've written some code that does this (see
> attached sample program), but would like some comments if someone has
> suggestions on how to do it more robust.

Why make it so complicated?

For me, a simple

	strings -a u-boot.bin  | grep 'U-Boot '

usually does the job.

> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline; filename="ubootver.c"

That's >100 lines of error-prone C code versus 1 line of shell...

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
"A fractal is by definition a set for which the Hausdorff Besicovitch
dimension strictly exceeds the topological dimension."
- Mandelbrot, _The Fractal Geometry of Nature_

[U-Boot-Users] Reading out version_string from a binary

[Fredrik Roubert]

On Tue 21 Nov 15:47 CET 2006, Wolfgang Denk wrote:

> Why make it so complicated?

Oh, I'm not doing this for myself ...

> For me, a simple
>
> 	strings -a u-boot.bin  | grep 'U-Boot '
>
> usually does the job.

That's the normal way to do it and it's a good way to do it, except for
that my employer doesn't want a solution that reads through the whole
binary.

Cheers // Fredrik Roubert

-- 
Barco Medical Imaging          |  +32 56 233549
http://www.barco.com/medical/  |  fredrik.roubert at barco.com

[U-Boot-Users] Reading out version_string from a binary

[Wolfgang Denk]

In message <20061121161859.GG10032@igloo.df.lth.se> you wrote:
> 
> That's the normal way to do it and it's a good way to do it, except for
> that my employer doesn't want a solution that reads through the whole
> binary.

There are two ways of constructing a software design. One way  is  to
make  it  so  simple that there are obviously no deficiencies and the
other is to make it so complicated that there are  no  obvious  defi-
ciencies.                             - Charles Anthony Richard Hoare

You may

a) try to explain to him why a much simpler approach is much  better;
   I  guess  efficiency  it  not exactly an issye here - you won't be
   doing this zillion times per second.
b) do what he wants against your own firm conviction
c) start looking for a new job

Or in short: love it, leave it, or change it.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
While most peoples' opinions change, the conviction of their correct-
ness never does.

[U-Boot-Users] Reading out version_string from a binary

[Jerry Van Baren]

Fredrik Roubert wrote:
> Hi!
> 
> I use U-Boot (1.1.4) on a custom PowerPC (MPC8347) based board, and from
> my application I need to read out the value of version_string from the
> U-Boot binary, for logging. I've written some code that does this (see
> attached sample program), but would like some comments if someone has
> suggestions on how to do it more robust.
> 
> On MPC83XX, version_string is stored at the beginning of .rodata, so if
> only the offset for .rodata is found, reading out version_string is
> quite straightforward.
> 
> The offset of .rodata changes, however, when code is added or removed
> from U-Boot. I've found that an offset is being written at the end of
> start.o, from which it is possible to calculate the offset of .rodata,
> and even though this works for my current needs, it's hardly what one
> would call a robust solutions.
> 
> Does anyone have ideas about a better way to do this?
> 
> Cheers // Fredrik Roubert

Looking in cpu/mpc83xx/start.S I find:

/*
  * Version string - must be in data segment because MPC83xx uses the
  * first 256 bytes for the Hard Reset Configuration Word table (see
  * below).  Similarly, can't have the U-Boot Magic Number as the first
  * thing in the image - don't know how this will affect the image tools,
  * but I guess I'll find out soon.
  */
	.data
	.globl	version_string
version_string:
	.ascii U_BOOT_VERSION
	.ascii " (", __DATE__, " - ", __TIME__, ")"
	.ascii " ", CONFIG_IDENT_STRING, "\0"

so your statement that it is in .rodata is only part of the story - it 
actually is in .data but is initialized so a copy is in .rodata.

I see several ways to accomplish what you want.
1) (Easiest) Duplicate the above stuff at a fixed location.  The best 
fixed location would be in the gap between the HRCW and the 0x100 trap 
offset.  Big hole, mostly unused, fixed location.  Problem solved, at 
least for the 83xx CPU and potentially could be applied to most or all 
of the PowerPC family.

2) Put the above string in a new section and use the linker control file 
(lds) to put it in a fixed location, at least for your board.  Lots of 
work with no obvious benefit and more hassle (unnecessary fixed 
locations are Evil).

3) Variant of #1: the string _should be_ constant, and having someone 
scribbling on it (which .data implies is permissible) would be a Bad 
Thing[tm] in my book.  The variant on #1 would be to _move_ the string 
(rather than replicate it) after the HRCW in the .text section in 
start.S and fix up the users of the string so that they can find it OK 
after relocation.  You could make an argument that this is a Better Way[tm].

gvb

[U-Boot-Users] Reading out version_string from a binary

[Frank]

--- Fredrik Roubert <fredrik.roubert@barco.com> wrote:

> Hi!
> 
> I use U-Boot (1.1.4) on a custom PowerPC (MPC8347) based
> board, and from
> my application I need to read out the value of version_string
> from the
> U-Boot binary, for logging. I've written some code that does
> this (see
> attached sample program), but would like some comments if
> someone has
> suggestions on how to do it more robust.
> 
> On MPC83XX, version_string is stored at the beginning of
> .rodata, so if
> only the offset for .rodata is found, reading out
> version_string is
> quite straightforward.
> 
> The offset of .rodata changes, however, when code is added or
> removed
> from U-Boot. I've found that an offset is being written at the
> end of
> start.o, from which it is possible to calculate the offset of
> .rodata,
> and even though this works for my current needs, it's hardly
> what one
> would call a robust solutions.
> 
> Does anyone have ideas about a better way to do this?

Look at the way objdump finds the offset of the sections for an
elf file and do it the same way. The source to objdump is
readily available or you could pipe the output of objdump to
your application program, parse the output, open u-boot, seek to
the offset of the .rodata section and extract the information.
You could also use the same technique and extarct the symbol
itself from the elf binary. I've done this in the past....


 
____________________________________________________________________________________
Sponsored Link

Compare mortgage rates for today. 
Get up to 5 free quotes. www2.nextag.com