* [ECOS] ROM-startup RedBoot can't load RAM-startup RedBoot
@ 2006-12-22 2:29 Grant Edwards
2006-12-22 12:42 ` Gary Thomas
0 siblings, 1 reply; 4+ messages in thread
From: Grant Edwards @ 2006-12-22 2:29 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] ROM-startup RedBoot can't load RAM-startup RedBoot
2006-12-22 2:29 [ECOS] ROM-startup RedBoot can't load RAM-startup RedBoot Grant Edwards
@ 2006-12-22 12:42 ` Gary Thomas
2006-12-28 20:48 ` [ECOS] " Grant Edwards
0 siblings, 1 reply; 4+ messages in thread
From: Gary Thomas @ 2006-12-22 12:42 UTC (permalink / raw)
To: Grant Edwards; +Cc: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ECOS] Re: ROM-startup RedBoot can't load RAM-startup RedBoot
2006-12-22 12:42 ` Gary Thomas
@ 2006-12-28 20:48 ` Grant Edwards
2006-12-29 15:48 ` Grant Edwards
0 siblings, 1 reply; 4+ messages in thread
From: Grant Edwards @ 2006-12-28 20:48 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* [ECOS] Re: ROM-startup RedBoot can't load RAM-startup RedBoot
2006-12-28 20:48 ` [ECOS] " Grant Edwards
@ 2006-12-29 15:48 ` Grant Edwards
0 siblings, 0 replies; 4+ messages in thread
From: Grant Edwards @ 2006-12-29 15:48 UTC (permalink / raw)
To: ecos-discuss
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2006-12-29 15:48 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-12-22 2:29 [ECOS] ROM-startup RedBoot can't load RAM-startup RedBoot Grant Edwards
2006-12-22 12:42 ` Gary Thomas
2006-12-28 20:48 ` [ECOS] " Grant Edwards
2006-12-29 15:48 ` Grant Edwards
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).