Re: [ECOS] ROMRAM start on ARM platform

[Gary Thomas <gary at mlbassoc dot com>]

On Thu, 2003-08-28 at 15:41, Thomas Koeller wrote:
> 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).

I've been waiting for a MLT replacement for years now, and since it 
seems nowhere in sight, I'm willing to do whatever it takes to move
forward.  That said, *trying* to preserve compatability with the
old MLT formats should be attempted, but not obviously absolute.

As for what you were trying to do, I'm not sure that MLT is the place
to specify this directly.  Can you explain a little more how the memory
map changes with jumpers?  There may be other ways to solve this.

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

OK.

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

You can also look at some of the newer PowerPC platforms (adder, 
rattler).  These all use symbolic addresses - no "magic" numbers
or anything there.

-- 
Gary Thomas <gary@mlbassoc.com>
MLB Associates


-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss