From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16895 invoked by alias); 27 Jul 2005 11:17:27 -0000 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 Received: (qmail 16878 invoked by uid 22791); 27 Jul 2005 11:17:22 -0000 Received: from smarthost4.mail.uk.easynet.net (HELO smarthost4.mail.uk.easynet.net) (212.135.6.14) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Wed, 27 Jul 2005 11:17:22 +0000 Received: from [217.207.210.179] (helo=mail.hanoverdisplays.com) by smarthost4.mail.uk.easynet.net with esmtp (Exim 4.10) id 1Dxjua-00063Q-00; Wed, 27 Jul 2005 12:17:20 +0100 Content-Class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Jul 2005 11:17:00 -0000 Message-ID: From: "Matt Sartori" To: "Andrew Lunn" CC: "eCos Discussion" Subject: RE: [ECOS] Simple Redboot Q's X-SW-Source: 2005-07/txt/msg00298.txt.bz2 In fact it turns out that most of the code I'm trying to run is fine (and position independent).=20 Where it falls down is in the interrupt setup which isn't position independent.=20 My code (wrongly) assumes that the interrupt vector is pointing to it's own ISRs whereas interrupts are in fact being handled by Redboot. Fortunately I had written the setup code for interrupts within Redboot and put a bit of code to flash an led whenever the hal_IRQ_handler fun was called or it would have taken me ages to realise what was going on. I guess I have two choices here; If I want to make use of interrupts in Redboot (not sure if flash needs them) I'd have to pass them on to my own app's ISRs when appropriate. If I don't need Redboot interrupts then I could just not set them up in Redboot? I couldn't find a switch in the configtool, so that's probably the way to do it. Many thanks to Andrew and Gary who have had the patience to prod me in the right directions. m@ -----Original Message----- From: Andrew Lunn [mailto:andrew@lunn.ch]=20 Sent: 26 July 2005 18:22 To: Matt Sartori Cc: eCos Discussion Subject: Re: [ECOS] Simple Redboot Q's On Tue, Jul 26, 2005 at 06:03:51PM +0100, Matt Sartori wrote: > Yes, that all the jumps and references within the code are relative,=20 > not absolute. Nope. eCos is position dependant. ie you have to load it where it expects to be loaded. Otherwise it crashes and burns. > I think what I'm not quite understanding is what the load does. > I would expect the loading of an elf to involve the interpretation of > the file as to where to put it (and probably other stuff), however > loading an elf explicitly to a location (with -b) doesn't make logical > sense to me since the elf already knows where it wants to go.=20 Correct. You should not tell the loader where to put the image. You only need this for raw binaries. That format does not contain the position information so you have to tell it. > Equally baffling to me is when I load a .bin to an explicit location=20 > then I can't just run it from that location. > > Only when I load the .bin into the same memory location as what I've=20 > put in the binary's linker script does it work Thats the position independant stuff again... You code appears not to be position independant. It contains absolute addresses, not relative addresses. Hence when its in the wrong place it crashes an burns. If you want to be able to load your application to any random address you need to make your application position independant. This can be quite difficult, so most applications don't do it. Andrew ---------------------------------------------------------------------------= ----- The information transmitted is intended only for the person or entity to wh= ich it is addressed and may contain confidential and/or privileged material= . Any review, retransmission, dissemination or other use of, or taking of a= ny action in reliance upon, this information by persons or entities other t= han the intended recipient is prohibited. If you received this in error, please contact the sender or postmaster (pos= tmaster@hanoverdisplays.com) and delete the material from any computer. Although we routinely screen for viruses, addressees should check this e-ma= il and any attachment for viruses. We make no warranty as to absence of vir= uses in this e-mail or any attachments. Our Company's email policy is to permit incidental personal use. If this em= ail is of a personal nature, it must not be relied upon as expressing the v= iews or opinions of the company. Visit out website at www.hanoverdisplays.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss