[ECOS] ROM-startup RedBoot can't load RAM-startup RedBoot

[ECOS] ROM-startup RedBoot can't load RAM-startup RedBoot

[Grant Edwards]

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

Here is the memory map for the ROM-startup version:

Idx Name          Size      VMA       LMA       File off  Algn
  0 .entry        00000020  00000000  00000000  000000b4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .exceptions   0000002c  00000020  00000020  000000d4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  2 .text         0001f39c  0000004c  0000004c  00000100  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  3 .rodata       00004fb0  0001f3e8  0001f3e8  0001f49c  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  4 .rom_monitor_rwdata 00000108  08000000  00024398  0002444c  2**0
                  ALLOC
  5 .rwdata       00000f88  08000108  000244a0  0002444c  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  6 .bss          00020158  08001090  08001090  000253d4  2**4
                  ALLOC

And here is the memory map for the RAM-startup version:

Idx Name          Size      VMA       LMA       File off  Algn
  0 .entry        00000000  00000000  00000000  000000d4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  1 .exceptions   00000000  00000020  00000020  00023e60  2**0
                  CONTENTS
  2 .rom_monitor_rwdata 00000108  08000000  08000000  000000d4  2**0
                  ALLOC
  3 .text         0001deac  08000108  08000108  000000d4  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, CODE
  4 .rodata       00004f9c  0801dfb4  0801dfb4  0001df80  2**2
                  CONTENTS, ALLOC, LOAD, READONLY, DATA
  5 .rwdata       00000f44  08022f50  08022f50  00022f1c  2**2
                  CONTENTS, ALLOC, LOAD, CODE
  6 .bss          00020094  08023ea0  08023ea0  00023e60  2**4
                  ALLOC

-- 
Grant Edwards                   grante             Yow!  World War Three can
                                  at               be averted by adherence
                               visi.com            to a strictly enforced
                                                   dress code!


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

Re: [ECOS] ROM-startup RedBoot can't load RAM-startup RedBoot

[Gary Thomas]

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

Try looking at some PowerPC platform:
MEMORY
{
     ram : ORIGIN = 0x0000000, LENGTH = 0x8000000 // 128MB
     rom : ORIGIN = 0xf0000000, LENGTH = 0x04000000
}

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)
     SECTION_rodata1 (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_rodata (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_fixup (ram, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_gcc_except_table (ram, ALIGN (0x1), LMA_EQ_VMA)
     SECTION_data (ram, ALIGN (0x8), LMA_EQ_VMA)
     SECTION_sbss (ram, ALIGN (0x4), LMA_EQ_VMA)
     SECTION_bss (ram, ALIGN (0x10), LMA_EQ_VMA)
     CYG_LABEL_DEFN(__heap1) = ALIGN (0x8);
     SECTIONS_END
}

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.

> 
> Here is the memory map for the ROM-startup version:
> 
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .entry        00000020  00000000  00000000  000000b4  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .exceptions   0000002c  00000020  00000020  000000d4  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   2 .text         0001f39c  0000004c  0000004c  00000100  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   3 .rodata       00004fb0  0001f3e8  0001f3e8  0001f49c  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   4 .rom_monitor_rwdata 00000108  08000000  00024398  0002444c  2**0
>                   ALLOC
>   5 .rwdata       00000f88  08000108  000244a0  0002444c  2**2
>                   CONTENTS, ALLOC, LOAD, CODE
>   6 .bss          00020158  08001090  08001090  000253d4  2**4
>                   ALLOC
> 
> And here is the memory map for the RAM-startup version:
> 
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .entry        00000000  00000000  00000000  000000d4  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   1 .exceptions   00000000  00000020  00000020  00023e60  2**0
>                   CONTENTS
>   2 .rom_monitor_rwdata 00000108  08000000  08000000  000000d4  2**0
>                   ALLOC
>   3 .text         0001deac  08000108  08000108  000000d4  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, CODE
>   4 .rodata       00004f9c  0801dfb4  0801dfb4  0001df80  2**2
>                   CONTENTS, ALLOC, LOAD, READONLY, DATA
>   5 .rwdata       00000f44  08022f50  08022f50  00022f1c  2**2
>                   CONTENTS, ALLOC, LOAD, CODE
>   6 .bss          00020094  08023ea0  08023ea0  00023e60  2**4
>                   ALLOC
> 


-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

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

[ECOS] Re: ROM-startup RedBoot can't load RAM-startup RedBoot

[Grant Edwards]

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

[ECOS] Re: ROM-startup RedBoot can't load RAM-startup RedBoot

[Grant Edwards]

On 2006-12-28, Grant Edwards <grante@visi.com> wrote:
> 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).
[...]
>>> 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.

This time it was my fault, not Altera's. :)

I hadn't set CYGSEM_HAL_USE_ROM_MONITOR like I should have.

After I set CYGSEM_HAL_USE_ROM_MONITOR, there was a CDL option
that let me specify the amount of RAM to reserve for the ROM
monitor's rwdata.  It doesn't work quite right, since it always
allocates 256 bytes more than you ask for, but once you know to
ask for 256 less than you want, it's usable.

-- 
Grant Edwards                   grante             Yow!  I just had my entire
                                  at               INTESTINAL TRACT coated
                               visi.com            with TEFLON!


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