Re: [ECOS] ROMRAM start on ARM platform

[Thomas Koeller <thomas at koeller dot dyndns dot org>]

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