47f6d77690
This is a common problem that proprietary tools don't handle ELF files correctly. ELF sections use a virtual address and the virtual -> physical translation is done though segments. This allows to have a load (physical) address different from the virtual one. Here is the trick: proprietary tools usually don't take the pain to do the translation and just grab the virtual address. This commit implements proper translation in elftosb1 knowing that this introduce a deviation from the behaviour of the proprietary tool. Change-Id: I91721a3a8dead382a0603f84ae3b35c5eb9704eb |
||
---|---|---|
.. | ||
aes128.c | ||
crc.c | ||
crypto.c | ||
crypto.h | ||
dbparser.c | ||
dbparser.h | ||
elf.c | ||
elf.h | ||
elftosb.c | ||
elftosb1.c | ||
fuze+_key_file.txt | ||
Makefile | ||
misc.c | ||
misc.h | ||
README | ||
rsrc.c | ||
rsrc.h | ||
rsrctool.c | ||
sb.c | ||
sb.h | ||
sb1.c | ||
sb1.h | ||
sbloader.c | ||
sbtoelf.c | ||
sha1.c | ||
xorcrypt.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.