From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5453 invoked by alias); 28 Aug 2003 21:41:41 -0000 Mailing-List: contact ecos-discuss-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: ecos-discuss-owner@sources.redhat.com Received: (qmail 5368 invoked from network); 28 Aug 2003 21:41:38 -0000 Received: from unknown (HELO sarkovy.koeller.dyndns.org) (213.39.133.208) by sources.redhat.com with SMTP; 28 Aug 2003 21:41:38 -0000 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by sarkovy.koeller.dyndns.org (Postfix) with ESMTP id AE9B0120029; Thu, 28 Aug 2003 23:41:34 +0200 (CEST) From: Thomas Koeller To: Gary Thomas , "Koeller, T." Date: Thu, 28 Aug 2003 21:41:00 -0000 User-Agent: KMail/1.5.2 Cc: "ecos-discuss (E-Mail)" References: <850597605E79D21182830008C7A4B9CF1EB4266F@COMM1> <1062096875.22288.48.camel@hermes> In-Reply-To: <1062096875.22288.48.camel@hermes> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200308282341.34182.thomas@koeller.dyndns.org> Subject: Re: [ECOS] ROMRAM start on ARM platform X-SW-Source: 2003-08/txt/msg00616.txt.bz2 Gary Thomas wrote: > > > > I found that most of the *romram.ldi files for the various arm > > platforms are broken, because they all have an LMA_EQ_VMA argument > > in their section definitions for code and read-only data sections, > > and so the contents of these sections are not copied to RAM. I can't > > fix this because the maintainers rigidly insist in using the Windows > > MLT tool to modify those files (I just recently inquired about this on > > ecos-devel again), which I do not have access to. > > I don't recall seeing this on ecos-devel - when was that? http://sources.redhat.com/ml/ecos-devel/2003-08/msg00023.html http://sources.redhat.com/ml/ecos-devel/2003-08/msg00024.html I was preparing a patch for the EB40 that would add a user-selectable option to overwrite the ANGEL rom monitor, but backed away from that because I was under the impression that such a patch, involving manual modification of linker scripts, would have no chance of being accepted. > > As for "insisting", I've not heard that either. For example, I don't > even have a Windows MLT tool anymore and always just do these > modifications by hand. > So do I. After all, Linux is the prefered development platform. People have been advised to use it to avoid problems with that quirky cygwin emulation, and thats good advice. Therefore IMO tools that are not available on this platform should not be required. I remember, however, that statements consistent with the answer I received have been made on various occasions on this list (or maybe it was ecos-devel). > > And then, there is yet another problem: By looking at arm.ld I > > found that even if this were fixed, only the contents of the .data > > section is copied to RAM, the contents of .rodata and .rodata1 > > are not. This is certainly an error, too, or am I getting something > > wrong here? > > ROMRAM mode was never intended to be automatic - all of the copying > takes place manually, in the platform startup code. The assumption > is that the ROM image (which most platforms require for the real > startup) will contain TEXT and initialized DATA in a format that > can be copied to RAM. Once copied thusly, the code passes on to > executing out of RAM. Since there is some raw processing of these > images, typically to binary or whatever, to create the image in ROM, > I think that them LMA_EQ_VMA probably isn't significant. > > Did you have a particular platform that's not working? Sorry, this is indeed my mistake. I am just doing another AT91 platform HAL port, and I used some existing code I had created earlier. What I failed to realize was that the code in my patched repository was not original. So please accept my apologies and ignore the false alarm. Having said that, I still think I may have a point :-) Unlike the existing ARM platforms in the ecos CVS, which use hard coded addresses and sizes to do the copying, my code attempted to use the symbols __ram_data_start, __rom_data_start and __rom_data_end that are defined in the linker script. Of course, this does not work with LMA_EQ_VMA, because then the values of __ram_data_start and __rom_data_start are the same. But I still think taking the address and size parameters for the copy operation from linker-defined symbols is more appropriate than simply copying the entire flash contents to ram. The entire framework for this seems to be ready, but grep tells me that the excalibur HAL seems to be the only ARM HAL that uses this approach. I'll have a closer look at that. tk -- Thomas Koeller thomas@koeller.dyndns.org -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss