This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ROM-startup RedBoot can't load RAM-startup RedBoot


On 2006-12-22, Gary Thomas <gary@mlbassoc.com> wrote:

>> I've built ROM-startup and RAM-startup versions of RedBoot for
>> the NIOS2 architecture.  When loaded into RAM via JTAG, the
>> RAM-startup version works fine. The ROM-startup verions works
>> fine (except that it erases itself anytime it tries to write to
>> flash).
>> 
>> What I can't seem to be able to do is to use RedBoot in ROM to
>> load the RAM-startup version of RedBoot.

Or any other RAM-starup applications, for that matter.

>> I think it's because the text section in the RAM-startup
>> version loads on top of the running ROM-startup RedBoot's
>> ".rwdata" section.
>> 
>> Is that the way things are supposed to work?
>
> No.

I wish I were surprised.  ;)

> The RAM 'mlt*' files are normally organized such that their
> requirements (TEXT, DATA, etc) are outside what might be used
> by a ROM (or ROMRAM) RedBoot.

Rats. I was afraid I was going to mess with the mlt*.ldi files.

For the current half-baked NIOS2 eCos port the .ldi files are
generated on the fly using some proprietary Java/XML templating
scheme that roots around in the guts of Altera's proprietary
hardware design file/database/whatever for various values such
as the ROM and RAM addresses.  Apparently Altera thinks its
customers are too stupid to be trusted with information such as
the addresses of ROM and RAM.

It looks like I'm going to have to either reverse engineer
Altera's Java/XML templating scheme or figure a way to automate
the hacking of the .ldi files after the "ecosconfig tree"
operation is done. The latter is probably going to be easier.

> SECTIONS
> {
>      SECTIONS_BEGIN
>      CYG_LABEL_DEFN(__reserved_vectors) = 0; . = CYG_LABEL_DEFN(__reserved_vectors) + 0x3000;
>      CYG_LABEL_DEFN(__reserved_vsr_table) = ALIGN (0x10); . = CYG_LABEL_DEFN(__reserved_vsr_table) + > 0x200;
>      CYG_LABEL_DEFN(__reserved_virtual_table) = ALIGN (0x10); . = CYG_LABEL_DEFN(__reserved_virtual_table) + 0x100;
>      CYG_LABEL_DEFN(__reserved_for_rom) = ALIGN (0x10); . = CYG_LABEL_DEFN(__reserved_for_rom) + 0x7cd00;
>      SECTION_vectors (ram, ALIGN (0x10), LMA_EQ_VMA)
>      SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
>      SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
[...]

> In this case the physical RAM starts at 0x0, but the lines
> labeled __reserved_XXX show what memory should not be used.
> The actual image will be built following this area.  This
> method also allows for [crude] sharing of data between the two
> environments, e.g. exception handlers, virtual vector tables,
> etc.

I guess I'll slap together a sed or awk script to add some
lines like the "CYG_LABEL_DEFN" ones above to the .ldi files to
add some reserved space in RAM-startup programs so that they
don't load on top of RedBoot's data.

-- 
Grant Edwards                   grante             Yow!  I want to read my new
                                  at               poem about pork brains and
                               visi.com            outer space...


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]