From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25581 invoked by alias); 5 Sep 2006 09:31:21 -0000 Received: (qmail 25571 invoked by uid 22791); 5 Sep 2006 09:31:21 -0000 X-Spam-Check-By: sourceware.org Received: from snape.ecoscentric.com (HELO snape.ecoscentric.com) (212.13.207.199) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 05 Sep 2006 09:31:16 +0000 Received: from localhost (localhost [127.0.0.1]) by snape.ecoscentric.com (Postfix) with ESMTP id 0D27FC540E1; Tue, 5 Sep 2006 10:31:12 +0100 (BST) Received: from snape.ecoscentric.com ([127.0.0.1]) by localhost (snape.ecoscentric.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MDoP4fIDV4N3; Tue, 5 Sep 2006 10:31:08 +0100 (BST) Received: from delenn.bartv.net (snape.ecoscentric.com [212.13.207.199]) by snape.ecoscentric.com (Postfix) with ESMTP id A81B4C54004; Tue, 5 Sep 2006 10:31:08 +0100 (BST) Date: Tue, 05 Sep 2006 09:31:00 -0000 Message-Id: To: ilijak@siva.com.mk CC: ecos-discuss@sources.redhat.com In-reply-to: <44FD39D4.3040008@siva.com.mk> (message from Ilija Koco on Tue, 05 Sep 2006 10:48:20 +0200) From: Bart Veer References: <44FD39D4.3040008@siva.com.mk> Mailing-List: contact ecos-discuss-help@ecos.sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@ecos.sourceware.org Subject: Re: [ECOS] Multiple code images in flash X-SW-Source: 2006-09/txt/msg00020.txt.bz2 >>>>> "Ilija" == Ilija Koco writes: Ilija> Bart Veer wrote: >> You do not say whether or not the application is an eCos one. >> eCos applications are not position-independent, they are linked >> to run at specific addresses. Ilija> Could it be possible with some compile/link options to Ilija> produce position independent code? I have experience with Ilija> other RTOS (Microware OS-9) that is completely position Ilija> independent, and I may say that it would bring a benefit. Ilija> It would provide simple method for dynamic loading of user Ilija> applications, remote (through net) updates, etc. Position-independent code that resides in flash and with no MMU mangling? Rather tricky. Consider the following: const CYG_FLASH_FUNS(cyg_mcf52xx_cfm_core_funs, &cyg_mcf52xx_cfm_init, &cyg_flash_devfn_query_nop, &cyg_mcf52xx_cfm_erase, &cyg_mcf52xx_cfm_program, (int (*)(struct cyg_flash_dev*, const cyg_flashaddr_t, void*, size_t))0, 0, 0 ); i.e. define a data structure that contains a number of function pointers like &cyg_mcf52xx_cfm_init(). That statically initialized data structure needs to have the real function addresses, no amount of PC-relative addressing in the instruction set is going to help with that. Because the structure is const it is going to reside in flash rather than RAM, so there is no opportunity at run-time to process relocation information and update the data structure. So either: 1) ban this sort of construct. Sorry, but there may be any number of places within the existing source code that already uses such constructs. 2) use an MMU to rearrange the memory map to match what the application expects. By design eCos does not play games with the MMU like that. 3) perform some sort of relocation as you are programming the application into flash at one of the three addresses. 4) forget about position-independent code and link for a fixed address, which is the way eCos is designed to work. In theory you could link your application three times, once for each of the valid addresses, and install the appropriate application image when you have decided which block of flash to overwrite. Ilija> I would like to have some comments from eCos architects. Check my signature. Bart -- Bart Veer eCos Configuration Architect http://www.ecoscentric.com/ The eCos and RedBoot experts -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss