This is the mail archive of the
ecos-discuss@sourceware.org
mailing list for the eCos project.
Re: redboot on STM3240G-EVAL board
- From: Oleg Uzenkov <o dot uzenkov at unicore dot co dot ua>
- To: Sergei Gavrikov <sergei dot gavrikov at gmail dot com>
- Cc: eCos Discussion <ecos-discuss at sourceware dot org>
- Date: Fri, 10 Oct 2014 11:52:09 +0300
- Subject: Re: redboot on STM3240G-EVAL board
- Authentication-results: sourceware.org; auth=none
- References: <542D110B dot 9080002 at unicore dot co dot ua> <542E8B41 dot 8030905 at dallaway dot org dot uk> <5436726C dot 8000703 at unicore dot co dot ua> <alpine dot DEB dot 2 dot 00 dot 1410091628430 dot 5392 at sg-laptop> <543696C4 dot 2040201 at unicore dot co dot ua> <alpine dot DEB dot 2 dot 00 dot 1410091716530 dot 5580 at sg-laptop> <5437742F dot 7020908 at unicore dot co dot ua> <alpine dot DEB dot 2 dot 00 dot 1410100906150 dot 1839 at sg-pc dot belvok dot com>
Thanks Sergei,
ELF files are quite large, what is the preferred format for an image
to be passed to redboot? what "load" and "fis create" command look
like?
**Roughly** speaking, you save .text segment in FLASH (adjusted to
flash block erase size), you save not ELF image! So, do not mess
with binaries. Also `load' command does not carry whole ELF image
into RAM, but .text segment with a few other segments.
The thing is:
I will need to work with files (new firmware should arrive to sdcard
on the board through ftp in a main app). I want redboot to pick a new
^^^^^^^^^^^
image up from sdcard at reset.
If your board has Ethernet, then you can build RedBoot with networking
support and use TFTP or HTTP protocols to load firmware blobs from the
NET. Why not? Or you talk about "main app" on a host side?
No there is no Ethernet chip. I have GPRS modem on the board and I use
LWIP 1.3.2 stack from eCos. FTP is to be custom made using RAW sockets.
Extracting sections from received ELF file and transferring them to
redboot is more of a manual work.
So, I think I am kind of stuck with ELF files.
So I am thinking:
* Should I load compressed ELF file (gzip) with -d switch?
* Should I load SREC file (they are usually smaller than ELF)?
If you talk about eCos executables (to load) then regardless of the
source format you have to keep in a place only sections with LOAD
attribute. Look
stat -c %s install/tests/kernel/current/tests/tm_basic
608261
Thus, ELF size is 608K. Let's get a binary to load (in RAM for my case)
arm-eabi-objcopy -O binary install/tests/kernel/current/tests/tm_basic{,.bin}
stat -c %s install/tests/kernel/current/tests/tm_basic.bin
47248
Binary image size is 47K or exactly 47248 bytes. What that 47K is? Let's
print all section's headers of ELF
arm-eabi-objdump -h install/tests/kernel/current/tests/tm_basic
You will see all sections its sizes, locations and even more. But we
need to load only the sections which have attribute *LOAD* (not bad
name for 'load' command). Filter those sections
arm-eabi-objdump -h install/tests/kernel/current/tests/tm_basic | grep LOAD -B1
8 .rom_vectors 00000040 81008000 81008000 00008000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
9 .text 0000a704 81008040 81008040 00008040 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
10 .rodata 00000e60 81012744 81012744 00012744 2**2
CONTENTS, ALLOC, LOAD, READONLY, DATA
11 .data 000002ec 810135a4 810135a4 000135a4 2**2
CONTENTS, ALLOC, LOAD, DATA
Let's calculate sum of all sizes
echo "ibase=16; 40+A704+E60+2EC" | bc
47248
We got exactly 47248 bytes. Again, regardless source file format (srec,
elf, bin) you have to save on a media *at least* those *LOAD* bytes and
you (or loader) have to know all LMA (Load Memory Address) addresses to
relocate the sections (if that is needed) in the right places.
* Should I save executable sections and store them in a file. Transfer
that file to sdcard for redboot to pick it up at reset. (nor sure how
to do it actually)
What do you want to save? SD card space? Internal FLASH space? Loading
time?
I meant saving *LOAD* bytes in a file and sending that file to the board
via ftp.
Not sure how to specify that info, i.e. what to get from a file (section
addresses and sizes) and where to relocate them in memory (LMA).
ELF contains this info.
* Can I actually load a .bin (image in binary format)?
Yes, you can. You would even manage the loading of compressed binary images
(.bin.gz).
Oh, that sounds promising.
But I am unable to load .bin with "load -m x" and create fis with "fis
create <name>"
RedBoot> load -m x
CUnrecognized image type: 0x64200000
xyzModem - CRC mode, 32(SOH)/0(STX)/0(CAN) packets, 4 retries
RedBoot> fis create appbin
*** invalid 'fis' command: required parameter missing
...
What is the correct usage of "load" and "fis create" when you deal with
.bin file?
(Perhaps I need to specify switches, not sure which ones. Sorry for
being dumb )) )
info about my app.bin:
Entry point address: 0x64008111 (from elf file)
mlt_*.ldi file used:
SECTIONS
{
SECTIONS_BEGIN
SECTION_sram (sram, hal_virtual_vector_table_end, LMA_EQ_VMA)
SECTION_rom_vectors (ram, 0x64008000, LMA_EQ_VMA)
SECTION_RELOCS (ram, ALIGN (0x8), LMA_EQ_VMA)
SECTION_text (ram, ALIGN (0x8), LMA_EQ_VMA)
SECTION_fini (ram, ALIGN (0x8), LMA_EQ_VMA)
SECTION_rodata (ram, ALIGN(0x8), LMA_EQ_VMA)
SECTION_rodata1 (ram, ALIGN (0x8), LMA_EQ_VMA)
SECTION_fixup (ram, ALIGN (0x8), LMA_EQ_VMA)
SECTION_gcc_except_table (ram, ALIGN (0x8), LMA_EQ_VMA)
SECTION_eh_frame (ram, ALIGN (0x8), LMA_EQ_VMA)
SECTION_got (ram, ALIGN (0x8), LMA_EQ_VMA)
SECTION_data (ram, ALIGN (0x8), LMA_EQ_VMA)
SECTION_bss (ram, ALIGN (0x8), LMA_EQ_VMA)
CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
SECTIONS_END
}
HTH
Sergei
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss