This is the mail archive of the ecos-discuss@sources.redhat.com 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: ROMRAM stand-alone application


Thank you Mr. Bowman and everyone who gave suggestions.

Finnaly I got an EPROM with the modification in the romram.ldi file.

I needed to do some little modifications in my hal_platform_setup.h to meet my board specifications. I cut out the code in LED macro and made some PIO initializations.

My board has 256Kx16 of fast SRAM for code and data and 256Kx16 of slow battery backuped SRAM. Also I am using part of AT91M55800 internal SRAM to save a PDC SPI transmit buffer. My target.ld file has these regions defined as .iram, .ram and .nvram. I put it bellow.

But I needed to use a little manoeuvre to make the EPROM possible.

After I generate my .elf file I am using objcopy to generate a .bin and a .hex file. It happens that the .hex did not work and the .bin file was huge. So, I edited the .bin file and cut out all bytes until the beginning of the code, that I supposed should be at 0x0200:0000 but it was at 0x1FF:FC00... strange...

Afterwards I saved the new .bin file and recorded my EPROM and voilá, it worked!!

Regards,

Marco Aurélio da Cruz


STARTUP(vectors.o) ENTRY(reset_vector) INPUT(extras.o)

   GROUP(libtarget.a libgcc.a libsupc++.a)
   MEMORY
   {
       sram : ORIGIN = 0x00000000, LENGTH = 0x400
       sram2 : ORIGIN = 0x00000400, LENGTH = 0x1C00
       ram : ORIGIN = 0x02000000, LENGTH = 0x80000
       ram2 : ORIGIN = 0x03000000, LENGTH = 0x80000
   }

   SECTIONS
   {
       .debug_aranges 0 : { *(.debug_aranges) } .debug_pubnames 0 : {
   *(.debug_pubnames) } .debug_info 0 : { *(.debug_info) }
   .debug_abbrev 0 : { *(.debug_abbrev) } .debug_line 0 : {
   *(.debug_line) } .debug_frame 0 : { *(.debug_frame) } .debug_str 0 :
   { *(.debug_str) } .debug_loc 0 : { *(.debug_loc) } .debug_macinfo 0
   : { *(.debug_macinfo) } .note.arm.ident 0 : { KEEP
   (*(.note.arm.ident)) }
       .fixed_vectors 0x20 : { . = .; KEEP (*(.fixed_vectors)) } > sram
       .iram : { __iram_start = ABSOLUTE (.); *(.iram) __iram_end =
   ABSOLUTE (.); } > sram2
       .rom_vectors 0x02000000 : { __rom_vectors_vma = ABSOLUTE(.); . =
   .; KEEP (*(.vectors)) } > ram __rom_vectors_lma =
   LOADADDR(.rom_vectors);
       .text ALIGN (0x4) : { _stext = ABSOLUTE(.); PROVIDE (__stext =
   ABSOLUTE(.)); *(.text*) *(.gnu.warning) *(.gnu.linkonce.t.*)
   *(.init) *(.glue_7) *(.glue_7t) } > ram _etext = .; PROVIDE (__etext
   = .);
       .fini ALIGN (0x4) : { . = .; *(.fini) } > ram
       .rodata ALIGN (0x4) : { . = .; *(.rodata*) *(.gnu.linkonce.r.*)
   } > ram
       .rodata1 ALIGN (0x4) : { . = .; *(.rodata1) } > ram
       .fixup ALIGN (0x4) : { . = .; *(.fixup) } > ram
       .gcc_except_table ALIGN (0x4) : { . = .; *(.gcc_except_table) }
    > ram
       .data ALIGN (0x4) : { __ram_data_start = ABSOLUTE (.); *(.data*)
   *(.data1) *(.gnu.linkonce.d.*) . = ALIGN (4); KEEP(*( SORT
   (.ecos.table.*))) ; . = ALIGN (4); __CTOR_LIST__ = ABSOLUTE (.);
   KEEP (*(SORT (.ctors*))) __CTOR_END__ = ABSOLUTE (.); __DTOR_LIST__
   = ABSOLUTE (.); KEEP (*(SORT (.dtors*))) __DTOR_END__ = ABSOLUTE
   (.); *(.dynamic) *(.sdata*) *(.gnu.linkonce.s.*) . = ALIGN (4);
   *(.2ram.*) } > ram __rom_data_start = LOADADDR (.data);
   __ram_data_end = .; PROVIDE (__ram_data_end = .); _edata = .;
   PROVIDE (edata = .); PROVIDE (__rom_data_end = LOADADDR (.data) +
   SIZEOF(.data));
       .bss ALIGN (0x4) : { __bss_start = ABSOLUTE (.); *(.scommon)
   *(.dynsbss) *(.sbss*) *(.gnu.linkonce.sb.*) *(.dynbss) *(.bss*)
   *(.gnu.linkonce.b.*) *(COMMON) __bss_end = ABSOLUTE (.); } > ram
       __heap1 = ALIGN (0x8);
       . = ALIGN(4); _end = .; PROVIDE (end = .);
       .nvram (NOLOAD) : { __nvram_start = ABSOLUTE (.); *(.nvram)
   __nvram_end = ABSOLUTE (.); } > ram2
   }


Alan Bowman wrote:


I found a discrepancy in the EB55 ROMRAM code, between the section that masks addresses before copying ROM to RAM, and the memory map that the linker uses to determine where to put code. I used the following patch to adjust the memory map:

Index: mlt_arm_at91_eb55_romram.ldi
===================================================================
RCS file: /cvs/ecos/ecos/packages/hal/arm/at91/eb55/current/include/pkgconf/mlt_arm_at91_eb55_romram.ldi,v
retrieving revision 1.1
diff -u -r1.1 mlt_arm_at91_eb55_romram.ldi
--- mlt_arm_at91_eb55_romram.ldi	13 May 2003 18:27:59 -0000	1.1
+++ mlt_arm_at91_eb55_romram.ldi	17 Dec 2003 14:43:48 -0000
@@ -14,7 +14,7 @@
{
    SECTIONS_BEGIN
    SECTION_fixed_vectors (sram, 0x20, LMA_EQ_VMA)
-    SECTION_rom_vectors (ram, 0x02008000, LMA_EQ_VMA)
+    SECTION_rom_vectors (ram, 0x02000000, LMA_EQ_VMA)
    SECTION_text (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_fini (ram, ALIGN (0x4), LMA_EQ_VMA)
    SECTION_rodata (ram, ALIGN (0x4), LMA_EQ_VMA)


This alters the location that ROMRAM code is linked at (I think) and matches the startup code for the ROMRAM version of the EB55. Only problem - if you try to use a ROMRAM version of Redboot to load a RAM version of your application, the same bit of memory is used for both and they clash. However, this change worked perfectly well for us to develop ROMRAM applications for our EB55.


Hope this helps

Alan Bowman




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