From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15978 invoked by alias); 10 Oct 2014 15:58:24 -0000 Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Received: (qmail 15950 invoked by uid 89); 10 Oct 2014 15:58:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-la0-f45.google.com Received: from mail-la0-f45.google.com (HELO mail-la0-f45.google.com) (209.85.215.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 10 Oct 2014 15:58:21 +0000 Received: by mail-la0-f45.google.com with SMTP id q1so3548001lam.18 for ; Fri, 10 Oct 2014 08:58:17 -0700 (PDT) X-Received: by 10.152.206.5 with SMTP id lk5mr2691094lac.20.1412956697429; Fri, 10 Oct 2014 08:58:17 -0700 (PDT) Received: from sg-laptop ([178.121.182.52]) by mx.google.com with ESMTPSA id dw2sm1927533lbc.38.2014.10.10.08.58.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 10 Oct 2014 08:58:16 -0700 (PDT) Date: Fri, 10 Oct 2014 15:58:00 -0000 From: Sergei Gavrikov To: Oleg Uzenkov cc: eCos Discussion In-Reply-To: <54379E39.4070804@unicore.co.ua> Message-ID: References: <542D110B.9080002@unicore.co.ua> <542E8B41.8030905@dallaway.org.uk> <5436726C.8000703@unicore.co.ua> <543696C4.2040201@unicore.co.ua> <5437742F.7020908@unicore.co.ua> <54379E39.4070804@unicore.co.ua> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-IsSubscribed: yes Subject: Re: [ECOS] redboot on STM3240G-EVAL board X-SW-Source: 2014-10/txt/msg00017.txt.bz2 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. > 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 -o .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 " 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 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 fis create -b For gzipped binary image load -d -m x -r -b fis create -b ?-l ? But I suggest you to compress stripped ELFs and use simple sequence load -d -m x fis create ... fis load 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 . 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