Re: [ECOS] redboot on STM3240G-EVAL board

[Sergei Gavrikov <sergei.gavrikov@gmail.com>]

On Fri, 10 Oct 2014, Oleg Uzenkov wrote:

> 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.

<snip>

> 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.

Well, you want to minimize size of image to upload. Use any compressed
image to upload it with X/YMODEM (must have zlib package in RedBoot)

Continue with tm_basic example ([RAM] startup)

  size    name
  ----    ----
  621463  install/tests/kernel/current/tests/tm_basic
  47248   install/tests/kernel/current/tests/tm_basic.bin
  80936   install/tests/kernel/current/tests/tm_basic.img
  141868  install/tests/kernel/current/tests/tm_basic.srec

NOTE: `tm_basic.img' is stripped ELF (no debug info) you can get such an
       image as,  arm-eabi-strip -s <name> -o <name>.img

Compressed (gzip -9) images

  size    name
  ----    ----
  23998   install/tests/kernel/current/tests/tm_basic.bin.gz
  222086  install/tests/kernel/current/tests/tm_basic.gz
  24471   install/tests/kernel/current/tests/tm_basic.img.gz
  42290   install/tests/kernel/current/tests/tm_basic.srec.gz

> But I am unable to load .bin with "load -m x" and create fis with "fis
> create <name>"

As you can see, *.img.gz has almost the same size as *.bin.gz. So, to
upload *.img.gz files you need to add the only -d(ecompress) switch.

  load -m x -d
  fis create <name>

For binaries you have to know the first LMA address (rom_vectors
address) to specify that address on a command line.

For binary image

  load -m x -r -b <LMA>
  fis create -b <LMA> <name>

For gzipped binary image

  load -d -m x -r -b <LMA>
  fis create -b <LMA> ?-l <LENGTH>? <name>

But I suggest you to compress stripped ELFs and use simple sequence

  load -d -m x
  fis create <name>
  ...
  fis load <name>
  go

The above is about how you would upload (load cmd), save (fis create),
load (fis load) and run (go cmd) when image is built for RAM startup
and of course, your target must have enough RAM to spin *LOAD* bytes
(i.e. do load, load-decompress, or fis-load, fis-load-decompress).

For FLASH XIP images you have to use another sequences of RedBoot
commands, perhaps, load -> fis write -> go <LMA>.

You can find all needed info on RedBoot commands here

  http://ecos.sourceware.org/docs-latest/redboot/redboot-guide.html

REMEMBER: using ELFs means using less of switches in RedBoot commands
and using blobs means that you have to use more "smart" switches and
sequences the commands and you have to know where LOAD bytes are and
what LMA is.

Yet another story if you have file system support in RedBoot. Sorry, I
can't reproduce all scenarios in short answer and I don't want annoy the
list by retelling the RedBoot guide. Please, Read The Fine Manual :-)

Regarding your environment and requirements. Sure, all is possible, but
I would  prefer to get more RAM on the board that lets use standard ways
to manage all issues. However, they do design hardware and we must solve
the puzzles :-)

Happy Hacking!

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