Still UBoot ing...

[Altera_Forum]

Well thanks to everyone one and all my UBoot seems to be up and running fine however I'm still having a little bit of grief getting the final bits working (think I'm gonna write an app note on this once I get it going). But I thought I'd start a new thread. 

 My system (lets says it's a Cyclone Dev kit board)  Has Flash at 0x00000000, EPCS at 0x00810800, and SDRAM at 0x01000000 Reset address in SOPC builder is set to EPCS and Exception Address is set to 0x01000020, UBoot has been compiled to run at 0x01C000000 so its clear of the download area.  Now UBoot is stored in the EPCS and that correctly boots up an runs. I can download via dhcp application images and successfully write them to the FLASH at location 0. The problem I have is in getting them to be in the correct format in oder to convince UBoot to execute them.  Let's say i have an example (small app) built without OS in the NIOS IDE, naturally it has defined reset address as0x00810800 and exception address is 0x01000020 in system.h  Now I take the elf and do a: nios2-elf-objcopy -O binary sample.elf sample.bin  This generates from an approx 1000 byte image file (nios2-elf-size) an 8Meg binary file. (Why is this?).  I then gzip this up gzip -c --best sample.bin > sample.gz  Size comes down to something reasonable.  finally I mkimage on this to create something reasonable for UBoot to load mkimage -A nios2 -O linux -T kernel -C gzip -a 0x01000000-e 0x01000000 -n "MyAPP" -d sample.gz sample.img  Now do those addresses make sense for load and execute? Presumably the execute address ought to be set to _start or something similar? what about the load address?  Anyway after dhcp'ing this onto the target board (Normally I use 0x01100000 as the copy area), and then flash it into 0x00000000. The program appears to be there (in zip form), however when I do a bootm, nothing much happens, it finds and says it is being uncompressed but locks at calling the kernel start address. By commenting out the call to kernel start and returning to U-Boot, when i look at the area that should have had the program put into it nothing appears.  What is up here?   Regards,

[Altera_Forum]

Hi cybdenw, 

 > Now I take the elf and do a: > nios2-elf-objcopy -O binary sample.elf sample.bin > > This generates from an approx 1000 byte image file (nios2-elf-size) an > 8Meg binary file. (Why is this?).  The output sections are probably not contiguous ... you might be getting large fill areas. Can you post the output of:  nios2-elf-objdump -h sample.elf  > mkimage -A nios2 -O linux -T kernel -C gzip -a 0x01000000 > -e 0x01000000 -n "MyAPP" -d sample.gz sample.img  This is correct if your text base is 0x01000000  > Presumably the execute address ought to be set to _start or something similar?  Correct.  > what about the load address?  The load address is the address where u-boot copies/decompresses the image. Basically the destination copy address.  In most cases, your load address and entry point will be the same. If your entry point is not at the start of your binary image, then you must set the entry point appropriately. For example, if you link a jump table and exception trampoline at offsets 0x0000 and 0x0020, respectively, but your actual start offset is at 0x0040, you would use a load address of 0x0100_0000 and an entry point address of 0x0100_0040. The entry point is the target address of a jump (call) from the bootm command.  > What is up here?   Let's look at the objdump ... an see if anything shows up.  Regards, --Scott

[Altera_Forum]

Hi Scott,  

thanks for the speedy reply, here is the objdump   blmsimple.elf: file format elf32-littlenios2  Sections: Idx Name Size VMA LMA File off Algn  0 .entry 00000020 00810800 00810800 00000094 2**2  CONTENTS, ALLOC, LOAD, READONLY, CODE  1 .exceptions 00000248 01000020 01000020 000000b4 2**2  CONTENTS, ALLOC, LOAD, READONLY, CODE  2 .text 000000f0 01000268 01000268 000002fc 2**3  CONTENTS, ALLOC, LOAD, READONLY, CODE  3 .rodata 00000000 01000358 01000358 000003ec 2**0  CONTENTS  4 .rwdata 00000000 01000358 01000358 000003ec 2**0  CONTENTS, ALLOC, LOAD, DATA  5 .bss 00000000 01000358 01000358 000003ec 2**0  ALLOC  6 .ext_flash 00000000 00000000 00000000 000003ec 2**0  CONTENTS  7 .sdram 00000000 01000358 01000358 000003ec 2**0  CONTENTS  8 .epcs_controller 00000000 00810820 00810820 000003ec 2**0  CONTENTS  9 .comment 0000002c 00000000 00000000 000003ec 2**0  CONTENTS, READONLY  10 .debug_aranges 00000068 00000000 00000000 00000418 2**3  CONTENTS, READONLY, DEBUGGING  11 .debug_pubnames 0000001f 00000000 00000000 00000480 2**0  CONTENTS, READONLY, DEBUGGING  12 .debug_info 00000244 00000000 00000000 0000049f 2**0  CONTENTS, READONLY, DEBUGGING  13 .debug_abbrev 0000008a 00000000 00000000 000006e3 2**0  CONTENTS, READONLY, DEBUGGING  14 .debug_line 000002d0 00000000 00000000 0000076d 2**0  CONTENTS, READONLY, DEBUGGING  15 .debug_frame 00000030 00000000 00000000 00000a40 2**2  CONTENTS, READONLY, DEBUGGING  16 .debug_str 000000e9 00000000 00000000 00000a70 2**0  CONTENTS, READONLY, DEBUGGING   Now I can see that it is insitisting on sticking entry in the EPCS location (which of course is no good to me since U-boot actually comes from there). so it is almost like I want to omit/strip that bit of code from the elf so that it just loads up at 0x0100_0000 or whatever. Can this be simply done from the NIOS IDE or is it going to take a bit of trickery?

[Altera_Forum]

Cruddy format, here it is again. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/wink.gif  

 blmsimple.elf:     file format elf32-littlenios2 Sections: Idx Name          Size      VMA       LMA       File off  Algn  0 .entry        00000020  00810800  00810800  00000094  2**2                  CONTENTS, ALLOC, LOAD, READONLY, CODE  1 .exceptions   00000248  01000020  01000020  000000b4  2**2                  CONTENTS, ALLOC, LOAD, READONLY, CODE  2 .text         000000f0  01000268  01000268  000002fc  2**3                  CONTENTS, ALLOC, LOAD, READONLY, CODE  3 .rodata       00000000  01000358  01000358  000003ec  2**0                  CONTENTS  4 .rwdata       00000000  01000358  01000358  000003ec  2**0                  CONTENTS, ALLOC, LOAD, DATA  5 .bss          00000000  01000358  01000358  000003ec  2**0                  ALLOC  6 .ext_flash    00000000  00000000  00000000  000003ec  2**0                  CONTENTS  7 .sdram        00000000  01000358  01000358  000003ec  2**0                  CONTENTS  8 .epcs_controller 00000000  00810820  00810820  000003ec  2**0                  CONTENTS  9 .comment      0000002c  00000000  00000000  000003ec  2**0                  CONTENTS, READONLY 10 .debug_aranges 00000068  00000000  00000000  00000418  2**3                  CONTENTS, READONLY, DEBUGGING 11 .debug_pubnames 0000001f  00000000  00000000  00000480  2**0                  CONTENTS, READONLY, DEBUGGING 12 .debug_info   00000244  00000000  00000000  0000049f  2**0                  CONTENTS, READONLY, DEBUGGING 13 .debug_abbrev 0000008a  00000000  00000000  000006e3  2**0                  CONTENTS, READONLY, DEBUGGING 14 .debug_line   000002d0  00000000  00000000  0000076d  2**0                  CONTENTS, READONLY, DEBUGGING 15 .debug_frame  00000030  00000000  00000000  00000a40  2**2                  CONTENTS, READONLY, DEBUGGING 16 .debug_str    000000e9  00000000  00000000  00000a70  2**0                  CONTENTS, READONLY, DEBUGGING

[Altera_Forum]

Ok ... 

 > nios2-elf-objcopy -O binary sample.elf sample.bin >  > This generates from an approx 1000 byte image file (nios2-elf-size) > an 8Meg binary file. (Why is this?).  objcopy is copying sections .entry, .exceptions and .text ... and filling the hole between .entry and .exceptions:  0081_8000 ... 0081_801F : .entry 0081_8020 ... 0100_001F : fill (about 8 MB) 0100_0020 ... 0100_0267: .exceptions 0100_0268 ... 0100_0357: .text  You need to locate your .entry code to SDRAM -- then things should work ok.  Regards, --Scott

[Altera_Forum]

In the objcopy command you can remove the section .entry with -R .entry. 

 nios2-elf-objcopy -R .entry -O binary sample.elf sample.bin

[Altera_Forum]

> you can remove the section .entry with -R .entry 

 Agreed ... but the code in .entry jumps to a location within section .text ... and unfortunately, the jump target is not guaranteed to be at the start of the section ( ... unless the linker command file is coded appropriately -- I haven&#39;t looked at this).  I don&#39;t use the HAL. Can you specify where .entry is located via a wizard?  Regards, --Scott

[Altera_Forum]

The .entry section is specified by the ptf file (based on the reset location of the hardware), the other option would be to modify the linker script (generated.x) and move the .entry section as you had suggested.  

 original portion of linker script: MEMORY {  reset : ORIGIN = 0x00000000, LENGTH = 32  ext_flash : ORIGIN = 0x00000020, LENGTH = 16777184  ext_ram : ORIGIN = 0x02000000, LENGTH = 1048576  onchip_ram_64_kbytes : ORIGIN = 0x02100000, LENGTH = 65536  sdram_UNUSED : ORIGIN = 0x01000000, LENGTH = 32  sdram : ORIGIN = 0x01000020, LENGTH = 16777184 }  updated: MEMORY {  reset : ORIGIN = 0x01000000, LENGTH = 32  ext_flash : ORIGIN = 0x00000020, LENGTH = 16777184  ext_ram : ORIGIN = 0x02000000, LENGTH = 1048576  onchip_ram_64_kbytes : ORIGIN = 0x02100000, LENGTH = 65536  sdram : ORIGIN = 0x01000020, LENGTH = 16777184 }

[Altera_Forum]

Soooo if I get you right (and I&#39;m not at my desk now to verify it) 

 If when I do an elf-objcopy I specify that just the .entry portion is relocated to 0x0100_0000 then we should be okay?   I note that the .entry section is just 32 bytes in length therefore it should be possible to relocate it just under the exception code at 0x0100_0020 .  Will try it in the morning, thanks guys.  Regards,

[Altera_Forum]

The _reset function contains 2 call assembly instructions. Those instructions are PC relative instructions. So it depends on whether objcpy will update the call instruction correctly. I am not sure if objcopy&#39;s relocate feature changes the dependencies. 

 I haven&#39;t ever done that.

[Altera_Forum]

Cool, that got it, 

I had a look at the code in the .entry section and it is only a loop to clear the instruction cache followed by an absolute jump (not relative), so just relocating that section to the boot address (0x0100_0000) resolves the problem and it works.  thanks for your help all.  Regards,

[Altera_Forum]

The assembly code that generated the jump call was relative. The linker changed it because it was too far away. This means that if your memory layout changes, the process you used this time may not work in the future.  

 Good to see you have it working though.  regards,