rockbox/utils/sbtools
Amaury Pouly 8fa0e13c9f sbtools: generate a unique name for each section
This allows to manipulate the elf file more easily with objcopy for example. Executable sections are named .text0, .text1, ..., bss sections are named .bss0, .bss1, ...

git-svn-id: svn://svn.rockbox.org/rockbox/trunk@29817 a1c6a512-1295-4272-9138-f99709370657
2011-05-02 22:52:52 +00:00
..
aes128.c
crc.c sbtoelf: fix to handle unencrypted files (minor tweak) 2011-04-17 22:30:09 +00:00
crypto.h sbtoelf: fix to handle unencrypted files (minor tweak) 2011-04-17 22:30:09 +00:00
elf.c sbtools: generate a unique name for each section 2011-05-02 22:52:52 +00:00
elf.h sbtools: move internal elf definition to elf.c, implement elf reading 2011-04-17 15:49:58 +00:00
elftosb.c sbtools: do not rely on the ELF flags and always assume the entry point is valid 2011-05-01 12:44:57 +00:00
fuze+_key_file.txt
Makefile sbtools: update Makefile; fix whitespaces 2011-04-17 01:43:48 +00:00
README sbtools: document a bit the command file format 2011-04-17 23:40:14 +00:00
sb.h sbtoelf: fix to handle unencrypted files (minor tweak) 2011-04-17 22:30:09 +00:00
sbtoelf.c sbtoelf: fix to handle unencrypted files (minor tweak) 2011-04-17 22:30:09 +00:00
sha1.c

This file document the format of the command file used by the elftosb tool.
By no way our tools tries to be compatible with Freescale's elftosb2.
However, our format is more subset of the general one.

The parse supports a limited form of comments: comments starting with // and ending at the end of the line.

A file first contains the list of sources:

sources
{
    hw_init = "sdram_init.elf";
    rockbox = "rockbox.elf";
}

It can then contain an arbitrary number of section. A section is identified by a number.
Within a section, three commands are supported: "load", "jump" and "call":

section(0x626f6f74) // hex for 'boot'
{
    load hw_init;
    call hw_init;
    load rockbox;
    jump rockbox;
}

Finally, both elftosb and sbtoelf tools use key files. A key file is a list of keys.
Each key consist is 128-bit long and is written in hexadecimal:

00000000000000000000000000000000

The parser does not handle blank line and only allows a final newline at the end of the file.
A file is allowed to contain zero (0) keys.