visionCLICK & flash image size...

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:

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: snipped-for-privacy@tusur.ru

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: snipped-for-privacy@tusur.ru

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: snipped-for-privacy@tusur.ru