RedBoot ROM-startup linker script broken?

[Altera_Forum]

I've got the "ROMRAM" startup version of RedBoot running fine when loaded into RAM using gdb/JTAG. However, the "ROM" startup version doesn't work at all when programmed into flash (no diagnostic output, no network activity). 

 Other stand-alone programs work fine when programmed into flash, so I know the hardware works fine.  Looking at the section headers for redboot.elf reveals what appears to be a serious problem. Flash is at address 0x00000000, RAM is at address 0x08000000:  redboot.elf:     file format elf32-littlenios2 Sections: Idx Name          Size      VMA       LMA       File off  Algn  0 .entry        00000020  08000000  08000000  00025380  2**2                  CONTENTS, ALLOC, LOAD, READONLY, CODE  1 .text         0001f174  00000000  00000000  000000f4  2**2                  CONTENTS, ALLOC, LOAD, READONLY, CODE  2 .rodata       00005164  0001f174  0001f174  0001f268  2**2                  CONTENTS, ALLOC, LOAD, READONLY, DATA  3 .exceptions   0000002c  08000020  000242d8  000243cc  2**2                  CONTENTS, ALLOC, LOAD, READONLY, CODE  4 .rom_monitor_rwdata 00000108  0800004c  00024308  000243f8  2**0                  ALLOC  5 .rwdata       00000f88  08000154  00024410  000243f8  2**2                  CONTENTS, ALLOC, LOAD, CODE  6 .bss          0002014c  080010e0  080010e0  000253a0  2**4                  ALLOC  The problem is that the .entry section has an LMA in _RAM_ but it has its CONTENTS and LOAD attributes set. That indicates that the program expects that sections to be initialized, in RAM, _before_execution_starts_. Since that section is in RAM, that's clearly not going to happen: only sections with an LMA in flash ROM will contain initialized values when program execution starts.  How can the ROM startup version of RedBoot expect a section in _RAM_ to be initialized? Only sections located in flash should have their LOAD attribute set. The ROM startup linker script seems to be just plain broken: it is placing code in RAM.  I haven't touched the linker script, so I presume other people have run into similar problems? Has anybody got fixed versions of the RedBoot ROM-startup linker scripts?

[Altera_Forum]

Sorry, don't know what your specific problem is but I have run through the ecos for nios II guide using the Altera example design on the Altera dev board and the ROM configuration works ok for me. 

 **** IP: 172.25.170.209/255.255.224.0, Gateway: 172.25.184.246 Default server: 0.0.0.0  RedBoot™ bootstrap and debug environment [ROM] Non-certified release, version UNKNOWN - built 09:46:07, Nov 16 2006  Copyright © 2000, 2001, 2002, 2003, 2004 Red Hat, Inc.  RAM: 0x01000020-0x02000000, [0x01009770-0x01fec000] available FLASH: 0x80000000 - 0x80800000, 128 blocks of 0x00010000 bytes each. RedBoot> ****  Have you checked under 'eCos HAL->Nios2 architecture' in the config tool to make sure that your text and rodata region are set to your flash memory ?

[Altera_Forum]

--- Quote Start ---  originally posted by nigelatta@Dec 1 2006, 07:26 AM sorry, don&#39;t know what your specific problem is but i have run through the ecos for nios ii guide using the altera example design on the altera dev board and the rom configuration works ok for me.  --- Quote End ---  Does your setup use a second bootloader to start RedBoot? When I look at the program_flash script generated when I build the ROM-startup version of RedBoot, I see that it appears another bootloader is being added by elf2flash when it is used to generate an .srec file: echo Generating flash file for device cfi_flash_0... elf2flash --silent --input=$1 --flash= --boot=`$QUARTUS_ROOTDIR/sopc _builder/bin/find_sopc_component_dir altera_nios2`/boot_loader_cfi.srec --outfil e=$TMP/ecos.flash --sim_optimize=0 --base=0x00000000 --end=0x003fffff --reset=0x 08000000 I can&#39;t figure out what that bootloader is supposed to do (I&#39;m not using it). Can anybody point me to documentation on what the boot_loader_cfi.srec file does? Neither am I using elf2flash, since I can&#39;t get it to actually generate any output. Is there any documentation on exactly what efl2flash does and why the standard gnu binutils nios2-elf-objcopy utility isn&#39;t used to convert from elf format to motorola S-record format? <div class='quotetop'>QUOTE </div>  --- Quote Start ---  Have you checked under &#39;eCos HAL->Nios2 architecture&#39; in the config tool to make sure that your text and rodata region are set to your flash memory?[/b]  --- Quote End ---  Yes. That&#39;s clear from my original posting: the text and rodata sections are in flash. However, the .entry section _isn&#39;t_ in flash, and I suspect that&#39;s the problem (as I stated in my original posting).  Where is your .entry section? --  Grant

[Altera_Forum]

The ROM configuration is not of much interest to us as our target board does not have executable flash, I was simply running through the example guide to check that things worked. I have not looked into the internal workings of program_flash and whatever tinkering it is doing. 

 I can confirm that a ROMRAM configuration of redboot, converted to srec format using nios2-elf-objcopy and then downloaded to our target using the GERMS monitor does work - but that&#39;s about as far as I have got at the moment.  Info for the ROM configuration:-  Elf file type is EXEC (Executable file) Entry point 0x20 There are 5 program headers, starting at offset 52  Program Headers:  Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align  LOAD 0x0000d4 0x00000000 0x00000000 0x229b8 0x229b8 R E 0x1  LOAD 0x022a8c 0x01000020 0x000229b8 0x0002c 0x0002c R E 0x1  LOAD 0x022ab8 0x0100004c 0x000229e8 0x00000 0x00108 RW 0x1  LOAD 0x022ab8 0x01000154 0x00022af0 0x00e08 0x00e08 RWE 0x1  LOAD 0x0238c0 0x01000f5c 0x01000f5c 0x00000 0x08814 RW 0x1   Section to Segment mapping:  Segment Sections...  00 .entry .text .rodata   01 .exceptions   02 .rom_monitor_rwdata   03 .rwdata   04 .bss    There are 19 section headers, starting at offset 0x8bff4:  Section Headers:  [Nr] Name Type Addr Off Size ES Flg Lk Inf Al  [ 0] NULL 00000000 000000 000000 00 0 0 0  [ 1] .entry PROGBITS 00000000 0000d4 000020 00 AX 0 0 4  [ 2] .text PROGBITS 00000020 0000f4 01e054 00 AX 0 0 4  [ 3] .rodata PROGBITS 0001e074 01e148 004944 00 A 0 0 4  [ 4] .exceptions PROGBITS 01000020 022a8c 00002c 00 AX 0 0 4  [ 5] .rom_monitor_rwda NOBITS 0100004c 022ab8 000108 00 WA 0 0 1  [ 6] .rwdata PROGBITS 01000154 022ab8 000e08 00 WAX 0 0 4  [ 7] .bss NOBITS 01000f5c 0238c0 008814 00 WA 0 0 4  [ 8] .debug_aranges PROGBITS 00000000 0238c0 0016c8 00 0 0 8  [ 9] .debug_pubnames PROGBITS 00000000 024f88 002db6 00 0 0 1  [10] .debug_info PROGBITS 00000000 027d3e 024c7c 00 0 0 1  [11] .debug_abbrev PROGBITS 00000000 04c9ba 007ad0 00 0 0 1  [12] .debug_line PROGBITS 00000000 05448a 0295fd 00 0 0 1  [13] .debug_frame PROGBITS 00000000 07da88 003014 00 0 0 4  [14] .debug_str PROGBITS 00000000 080a9c 00776e 01 MS 0 0 1  [15] .debug_ranges PROGBITS 0000776e 08820a 003d20 00 0 0 1  [16] .shstrtab STRTAB 00000000 08bf2a 0000c8 00 0 0 1  [17] .symtab SYMTAB 00000000 08c2ec 002f40 10 18 153 4  [18] .strtab STRTAB 00000000 08f22c 002e15 00 0 0 1 Key to Flags:  W (write), A (alloc), X (execute), M (merge), S (strings)  I (info), L (link order), G (group), x (unknown)  O (extra OS processing required) o (OS specific), p (processor specific)

[Altera_Forum]

--- Quote Start ---  originally posted by nigelatta@Dec 1 2006, 12:46 PM the rom configuration is not of much interest to us as our target board does not have executable flash, i was simply running through the example guide to check that things worked. i have not looked into the internal workings of program_flash and whatever tinkering it is doing.  --- Quote End ---  I&#39;m becoming very suspicious that our processor configuration isn&#39;t right. The CPU reset address is in SDRAM, so that&#39;s where the .entry section is ending up. Your ROM configuration shows the .entry section in flash along with .text, .rodata, etc. <div class='quotetop'>QUOTE </div>  --- Quote Start ---  I can confirm that a ROMRAM configuration of redboot, converted to srec format using nios2-elf-objcopy and then downloaded to our target using the GERMS monitor does work - but that&#39;s about as far as I have got at the moment.[/b]  --- Quote End ---  Thanks. That&#39;s some reassurance that I have a decent chance of getting the ROM configuration running without having to use elf2flash and the bootloader_cfi.srec file.

[Altera_Forum]

<div class='quotetop'>QUOTE </div> 

--- Quote Start ---  I&#39;m becoming very suspicious that our processor configuration isn&#39;t right. The CPU reset address is in SDRAM, so that&#39;s where the .entry section is ending up. Your ROM configuration shows the .entry section in flash along with .text, .rodata, etc.[/b]  --- Quote End ---    Probably makes sense - the Altera example design has a reset address at offset 0x0 in flash and an exception address at offset 0x20 in sdram.

[Altera_Forum]

--- Quote Start ---  originally posted by nigelatta@Dec 1 2006, 10:49 AM <div class='quotetop'>quote   --- quote end ---    --- quote start ---  i&#39;m becoming very suspicious that our processor configuration isn&#39;t right. the cpu reset address is in sdram, so that&#39;s where the .entry section is ending up. your rom configuration shows the .entry section in flash along with .text, .rodata, etc.  --- Quote End ---    Probably makes sense - the Altera example design has a reset address at offset 0x0 in flash and an exception address at offset 0x20 in sdram. <div align='right'><{post_snapback}> (index.php?act=findpost&pid=19766)</div> [/b]  --- Quote End ---    Right. It&#39;s potentially dangerous to point a reset address at volatile memory. All of the examples point to offset 0....likely to the start of some bootloader code.  - slacker