[ECOS] ROMRAM start on ARM platform

[ECOS] ROMRAM start on ARM platform

[Koeller, T.]

Hi,

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.

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?

tk
----------------------------------------------- 
Thomas Koeller, Software Development 

Basler Vision Technologies 
An der Strusbek 60-62 
22926 Ahrensburg 
Germany 

Tel +49 (4102) 463-390 
Fax +49 (4102) 463-46390

mailto:Thomas.Koeller@baslerweb.com 
http://www.baslerweb.com 



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

Re: [ECOS] ROMRAM start on ARM platform

[Gary Thomas]

On Thu, 2003-08-28 at 12:45, Koeller, T. wrote:
> Hi,
> 
> 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?

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.

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

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

Re: [ECOS] ROMRAM start on ARM platform

[Andrew Lunn]

On Thu, Aug 28, 2003 at 08:45:51PM +0200, Koeller, T. wrote:
> Hi,
> 
> 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.
> 
> 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?

Speaking for the EBSA285 ROMRAM which i wrote, LMA_EQ_VMA is totally
ignored. Also, it copies from CYGMEM_REGION_rom+reset_vector, to
CYGMEM_REGION_rom_SIZE, where rom size is the size of one flash block.

[Hang on a minute. cvs annotate. Huh!]

Strange, thats not what i wrote! Someone has changed it...  What i
wrote used a symbol the linker inserted at the end of the data
sections. I copied everything up to that symbol. The current
implementation is enough for a ROMRAM redboot, but will break for a
large ROMRAM app!

OK. Give me an example platform you think is broken.

    Andrew

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

Re: [ECOS] ROMRAM start on ARM platform

[Thomas Koeller]

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

Re: [ECOS] ROMRAM start on ARM platform

[Gary Thomas]

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

Re: [ECOS] ROMRAM start on ARM platform

[Jonathan Larmour]

Andrew Lunn wrote:
> On Thu, Aug 28, 2003 at 08:45:51PM +0200, Koeller, T. wrote:
> 
>>Hi,
>>
>>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.

FAOD, the reason is that when we do get a new MLT, we can import all the 
old MLT files. With arbitrary stuff included, it won't happen and things 
will need to be brought over by hand; or more likely platforms will have 
to be dropped because we can't test them and there would be other changes 
in the arch .ld file. That would suck.

If you want to add arbitrary stuff in the .ldi file, your platform is at 
risk of being dropped in future unless someone is prepared to clean it up.

>>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?
> 
> Speaking for the EBSA285 ROMRAM which i wrote, LMA_EQ_VMA is totally
> ignored. Also, it copies from CYGMEM_REGION_rom+reset_vector, to
> CYGMEM_REGION_rom_SIZE, where rom size is the size of one flash block.
> 
> [Hang on a minute. cvs annotate. Huh!]
> 
> Strange, thats not what i wrote! Someone has changed it...  What i
> wrote used a symbol the linker inserted at the end of the data
> sections. I copied everything up to that symbol. The current
> implementation is enough for a ROMRAM redboot, but will break for a
> large ROMRAM app!

How so? It will copy up to the end of .data which looks right.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine


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

Re: [ECOS] ROMRAM start on ARM platform

[Jonathan Larmour]

Koeller, T. wrote:
> 
> The ecos EB40 platform HAL only supports the board in the factory
> configuration. Since 64KB is only sufficient for tiny programs, a very
> minimal redboot for example, it would greatly enhance the boards usefulness
> if all of the flash memory were available. The ecos .ldi file accounts for
> the lower half of the flash being unavailable in the following way:
> [snip]
> My idea was to make the '__reserved_bootmon' stuff a configurable option,
> so it could be enabled or disabled via cdl, but that would of course require
> modification of the .ldi file and the related memory layout header (to
> #include
> the header files generated from cdl). The only other option would be to
> create
> an additional set of .ldi and .h files, named differently, and select
> between
> those sets via cdl. I feel that's a rather clumsy solution, especially if
> there
> were more than two memory layouts to choose between.

That's what's been done before, and doesn't seem that clumsy to me. It's 
the same file with only a few lines different after all. Yes CDL-awareness 
is a "must have" for MLT v2 whenever that comes.

Jifl
-- 
eCosCentric    http://www.eCosCentric.com/    The eCos and RedBoot experts
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine


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

RE: [ECOS] ROMRAM start on ARM platform

[Koeller, T.]

Gary Thomas wrote:

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

The EB40 has one single flash chip, an AT29LV1024 which is 128KB. The
board ships with the Angel boot monitor installed in the lower 64 KB;
these addresses are write-protected by hardware, leaving the upper 64KB
for application programs. There is a switch that changes the address
decoding so that only the upper half of the flash is visible and a reset
directly starts code located there. The write protection on the lower half
of the flash can be removed by soldering a bridge or jumper to the board,
which would then allow to overwrite the Angel monitor and use the entire
flash for (ecos) applications.

The ecos EB40 platform HAL only supports the board in the factory
configuration. Since 64KB is only sufficient for tiny programs, a very
minimal redboot for example, it would greatly enhance the boards usefulness
if all of the flash memory were available. The ecos .ldi file accounts for
the lower half of the flash being unavailable in the following way:

// eCos memory layout - Wed Apr 11 13:49:55 2001

// This is a generated file - do not edit

#include <cyg/infra/cyg_type.inc>

MEMORY
{
    sram : ORIGIN = 0x00000000, LENGTH = 0x2000
    ram : ORIGIN = 0x02000000, LENGTH = 0x80000
    rom : ORIGIN = 0x01000000, LENGTH = 0x20000
}

SECTIONS
{
    SECTIONS_BEGIN
    CYG_LABEL_DEFN(__reserved_bootmon) = 0x01000000; . =
CYG_LABEL_DEFN(__reserved_bootmon) + 0x10000;
    SECTION_rom_vectors (rom, ALIGN (0x8), LMA_EQ_VMA)
    SECTION_text (rom, ALIGN (0x1), LMA_EQ_VMA)
    SECTION_fini (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata1 (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixup (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_gcc_except_table (rom, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fixed_vectors (sram, 0x20, LMA_EQ_VMA)
    SECTION_data (ram, 0x02000000, FOLLOWING (.gcc_except_table))
    SECTION_bss (ram, ALIGN (0x4), LMA_EQ_VMA)
    CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
    SECTIONS_END
}


My idea was to make the '__reserved_bootmon' stuff a configurable option,
so it could be enabled or disabled via cdl, but that would of course require
modification of the .ldi file and the related memory layout header (to
#include
the header files generated from cdl). The only other option would be to
create
an additional set of .ldi and .h files, named differently, and select
between
those sets via cdl. I feel that's a rather clumsy solution, especially if
there
were more than two memory layouts to choose between. Or, of course, I could
fork
the entire HAL (EB40-small vs. EB40-big), an even more awkward solution.

To me it still seems much more natural to handle these things via cdl,
instead of
detaching the memory layout definition from everything else and mandate use
of a
separate tool for this task, that is not even available on the prefered
development
platform.

tk

----------------------------------------------- 
Thomas Koeller, Software Development 

Basler Vision Technologies 
An der Strusbek 60-62 
22926 Ahrensburg 
Germany 

Tel +49 (4102) 463-390 
Fax +49 (4102) 463-46390

mailto:Thomas.Koeller@baslerweb.com 
http://www.baslerweb.com 



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