visionCLICK & flash image size...

Hello, All!

I started to use WindRiver JTAG emulator and supplied program visionCLICK
7.10a.

And I faced with some issue. I have to prepare image for downloading to
flash. I use convert utility from visionCLICK suite, actually I'm using GUI
frontend for it. So, my input file is ELF format.

Documentation is saying that I can specify range addresses for BIN image
like: 0x00000000 to 0xffffffff. But using this way I get an error from
convert utility:

error #220: flat binary file would be very large (specify upper and lower
addresses)

So, how should I calculate the flash image size, if I know only the original
size of ELF-file ?

With best regards, Roman Mashak.  E-mail: mrv@tusur.ru

> And I faced with some issue. I have to prepare image for downloading to
> flash. I use convert utility from visionCLICK suite, actually I'm using GUI
> frontend for it. So, my input file is ELF format.
> 
> Documentation is saying that I can specify range addresses for BIN image
> like: 0x00000000 to 0xffffffff. But using this way I get an error from

The problem is that a raw binary image does not include any
information about which addresses are implemented and which are not;
it's just a memory dump. If your program/processor has multiple
segments that straddle large memory areas (which is very common) then
you cannot use raw binary as your file format; you need a
scatter-loadable format like ELF or COFF, which is capable of
specifying things like "Here is 8K of data to be loaded at $00000000,
then 32K more to be loaded at $F0000000" without having to dump out a
byte for every address in between. Can this "visionCLICK" program not
load ELF directly? It's rather useless for embedded development if it
can only load binary files.

If binary is the ONLY option then maybe you can hack together some
combination of scripts that will split your bin up into sections and
you can load them individually. But it shouldn't be necessary.

Hello, Lewin!
You wrote  on 7 Sep 2004 03:16:41 -0700:

 [skip]

 LAW> you cannot use raw binary as your file format; you need a
 LAW> scatter-loadable format like ELF or COFF, which is capable of
 LAW> specifying things like "Here is 8K of data to be loaded at $00000000,
 LAW> then 32K more to be loaded at $F0000000" without having to dump out a
 LAW> byte for every address in between. Can this "visionCLICK" program not
 LAW> load ELF directly? It's rather useless for embedded development if it
 LAW> can only load binary files.

The docementation doesn't mention about opportunity to load ELF file
directly onto flash, that's why the utility 'convert' is included to
visionCLICK.

With best regards, Roman Mashak.  E-mail: mrv@tusur.ru

> The docementation doesn't mention about opportunity to load ELF file
> directly onto flash, that's why the utility 'convert' is included to
> visionCLICK.

If this is ONLY for burning flash, then you should strip out the bss
section at the very least. Massage the file with binutils before
trying to convert it to binary. It might in some cases be necessary to
decompose it (I'm thinking of code and pre-initialized writable data
segment here) manually, convert them to binary with objcopy, and then
concatenate them at the command line.

Sounds like a pretty braindead product... hope it wasn't expensive
(but I'm sure it was!)

Hello, Lewin!
You wrote  on 7 Sep 2004 15:32:45 -0700:

 LAW> If this is ONLY for burning flash, then you should strip out the bss
 LAW> section at the very least. Massage the file with binutils before
 LAW> trying to convert it to binary. It might in some cases be necessary to
 LAW> decompose it (I'm thinking of code and pre-initialized writable data
 LAW> segment here) manually, convert them to binary with objcopy, and then
 LAW> concatenate them at the command line.

I suppose it's the ONLY way to program the flash (albeit I started to study
this s/w recently), but documentation is saying the following:

"to program target flash, visionICE requires that all object modules be
converted into flat binary format .BIN.. The Convert utility takes S-Record,
COFF, A.OUT, ELF/DWARF object modules and convert them to downloadable
object modules and optional symbol files...."

I tried the method you recommended, perhaps I did it in a wronf way. After
stripping BSS section from .ELF binary:

#strip --remove-section=.bss yamon-02.23DB1550_el.elf

final binary yamon-02.23DB1550_el.elf  doesn't contain definition of target
machine anymore. And therefore 'convert' utility cannot handle it..

With best regards, Roman Mashak.  E-mail: mrv@tusur.ru

> final binary yamon-02.23DB1550_el.elf  doesn't contain definition of target
> machine anymore. And therefore 'convert' utility cannot handle it..

What does objdump tell you about the size and position of the segments
inside this file?

Did you build this file, or is it a black box you downloaded from
somewhere?

Hello, Lewin!
You wrote  on Wed, 08 Sep 2004 01:40:00 GMT:


 ??>> final binary yamon-02.23DB1550_el.elf  doesn't contain definition of
 ??>> target machine anymore. And therefore 'convert' utility cannot handle
 ??>> it..

 LAW> What does objdump tell you about the size and position of the segments
 LAW> inside this file?

'objdump' is telling the following (I omitted the symbol information):

yamon-02.23DB1550_el.elf:     file format elf32-little
yamon-02.23DB1550_el.elf
architecture: UNKNOWN!, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x9fc10000

Program Header:
    LOAD off    0x00000000 vaddr 0x8003d000 paddr 0x8003d000 align 2**12
         filesz 0x00000680 memsz 0x000456a4 flags rw-
    LOAD off    0x00001000 vaddr 0x9fc10000 paddr 0x9fc10000 align 2**12
         filesz 0x00002308 memsz 0x00002308 flags r-x
    LOAD off    0x00004000 vaddr 0x80005000 paddr 0x9fc12308 align 2**12
         filesz 0x00038680 memsz 0x00038680 flags rwx

Sections:
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text_init    00002308  9fc10000  9fc10000  00001000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .text_ram     0002b190  80005000  9fc12308  00004000  2**3
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .data         0000d4f0  80030190  9fc3d498  0002f190  2**2
                  CONTENTS, ALLOC, LOAD, DATA
  3 .bss          00045024  8003d680  8003d680  00000680  2**4
                  ALLOC
  4 .pdr          00007cc0  00000000  00000000  0003c680  2**2
                  CONTENTS, READONLY
  5 .mdebug.abi32 00000000  00000000  00000000  000d6b80  2**0
                  CONTENTS, READONLY

LAW> Did you build this file, or is it a black box you downloaded from
LAW> somewhere?

No, these are the sources of Yamon bootloader, provided by AMD with their
devel. board Alchemy AU1550. Also they provided toolchain, based on GNU
tools, for building.

I followed the instructions and build the code.. Now I'm trying to debug in
the JTAG emulator. That's the story.

With best regards, Roman Mashak.  E-mail: mrv@tusur.ru