Got a question for the bootloader/flash gurus

[Altera_Forum]

If I run elf2flash with the --boot option I can make a .flash file out of a .elf file identical to the ext_flash.flash file the Nios IDE makes for me. Both files have 8 bytes I can't account for though. All the bytes from the boot_loader_cfi.srec file are at the beginning of the file, and all the bytes from the .exceptions, .text, .rodata, and .rwdata sections are after that, but inbetween there's 8 bytes that I can't identify. 

 The weird part is that it&#39;s not always the same 8 bytes, but they only show up if I use the --boot option. If I don&#39;t use that option the .flash file starts with the bytes from the ELF file. The only commonality I&#39;ve found in the various flash files is that the last 4 bytes are "20000001" sometimes.   I suppose it doesn&#39;t really matter what they are, but it&#39;s bugging me that there&#39;s 8 bytes I can&#39;t identify in the flash file. I tried decoding them by hand and they don&#39;t seem to be instructions.  Edit: The "20000001" is actually 0x01000020, or my exception address. Duh. That still leaves the other 4 bytes though...I have a project where I went through the multiprocessor tutorial. For cpu 1 the 8 bytes are (big endian):  00012970 01000020  and for cpu 2:  0000eff0 01100020  What do 0x00012970 and 0x0000eff0 represent?  Edit 2: They&#39;re the sum of the filesz members of the program headers for the ELF file. Or to put it another way, they&#39;re how many bytes the .exceptions, .text, .rodata, and .rwdata sections take up.  Well that was fun. Hopefully this helps someone and I haven&#39;t just been talking to myself. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/ph34r.gif

[Altera_Forum]

Hi bkucera, 

 > What do 0x00012970 and 0x0000eff0 represent?  You are, of course, correct. The boot loader expects a sequence of length-address-data records -- one for each linker output section that is loaded. The final record normally has a length of zero, which indicates that the following address is the "jump" target.  You read through the bootloader code and comments from boot_loader.S in:  $SOPC_KIT_NIOS2/components/altera_nios2/sdk/src/bootloader_sources/  Regards, --Scott

[Altera_Forum]

--- Quote Start ---  originally posted by smcnutt@Dec 19 2005, 08:37 PM hi bkucera,  > what do 0x00012970 and 0x0000eff0 represent?  you are, of course, correct. the boot loader expects a sequence of length-address-data records -- one for each linker output section that is loaded. the final record normally has a length of zero, which indicates that the following address is the "jump" target.  you read through the bootloader code and comments from boot_loader.s in:  $sopc_kit_nios2/components/altera_nios2/sdk/src/bootloader_sources/  regards, --scott <div align='right'><{post_snapback}> (index.php?act=findpost&pid=11655)  --- quote end ---    --- Quote End ---    I did read through that, it just wasn&#39;t clicking at the time.  Related question - I followed your advice from my other thread and generated a map file from the linker. The only confusing part is the BSS section. I see it&#39;s being used for storage of global variables, but according to the ELF file it doesn&#39;t take up any space in the object file, which I gather is how it&#39;s supposed to be. I also see that the crt0.s file has some code that clears the BSS section.  So what happens to the .BSS section when you run elf2flash?

[Altera_Forum]

Hi bkucera, 

 > So what happens to the .BSS section when you run elf2flash?  Nothing. Try objdump -h on your application elf. The .bss section is for uninitialized objects (variables). A static object that isn&#39;t initialized (doesn&#39;t have an explicit initializer) must be assigned the value 0 before main() is called.  When you look at the objdump -h output, you&#39;ll see that the .bss section has only the "allocated" (ALLOC), but does not have the load attribute (LOAD) like .data or .text. The allocated attribute basically means it occupies memory; the load attribute means a loader must actually copy the elf section into the target memory. The absence of the load attribute means the loader doesn&#39;t have to copy the elf section to the target memory space.  crt0.s however, clears the target memory region since the C language requires uninitialized objects to be set to zero prior to calling main().  Regards, --Scott

[Altera_Forum]

I guess what I&#39;m still confused about is how the memory gets allocated for those global variables then. For instance, I have an app based off the simple socket server. It tells me the heap starts at 0x01076520. If I subtract the sizes of .exceptions, .text, .rodata, .rwdata, and .bss (as reported by the ELF file) from that I get 0x1000020, which is my exception address.  

 As I understand it my code gets compiled into an ELF file, elf2flash is called to create a flash file with the bootloader code added onto the front, then that flash file is transmitted to the board, where the bootloader copies everything into RAM and runs it.   So how does the .bss section get allocated in memory if the sections that refer to it in the ELF file don&#39;t make it into the .flash file?

[Altera_Forum]

--- Quote Start ---  originally posted by bkucera@Dec 20 2005, 04:39 PM so how does the .bss section get allocated in memory if the sections that refer to it in the elf file don&#39;t make it into the .flash file? <div align='right'><{post_snapback}> (index.php?act=findpost&pid=11677)  --- quote end ---    --- Quote End ---    smcnutt, you&#39;re really good at these so please correct me if I&#39;m wrong!....  I think the .elf just leaves this... blank. Again, crt0 has to know where the bss is to initialize it. The linker provides these as global symbols that crt0 has access to.   The .elf file itself does not contain data for the entire system memory map.. there are address/data &#39;records&#39; defining what should be initialized and where. The boot loader source code reads data out of flash, extracting address/data pairs as it goes. The result of this should be that the bss section of ram is not written over by the boot loader at all; again crt0 will initialize it.

[Altera_Forum]

Hi bkucera & Jesse, 

 > > So how does the .bss section get allocated in memory if the sections that refer to > > it in the ELF file don&#39;t make it into the .flash file?  The linker groups all .bss input sections into the .bss output section and assigns addresses to the symbols that end up in the .bss output section. So, the linker allocates the memory -- or maybe better -- the linker reserves/assigns the address range occupied by .bss (as well as the other sections).  Your executable code (.text) and sometimes your initialized data (.data -- e.g. a pointer to a buffer in .bss that has an initializer such as: unsigned char *p = mybuf) refer to .bss -- and sections that contain initialized data make it into the flash file (the LOAD attribute is set). After initialization, accessing data in .bss is the same as accessing data in any other section (ignoring .sbss and .sdata).  So the only practical difference between .data and .bss is: .data is initialized by copying an image into the memory and .bss is initialized by clearing the memory.  > I think the .elf just leaves this... blank. Again, crt0 has to know where the bss > is to initialize it.   Correct. Take a look at objdump output. The size of the .bss elf file section is zero. crt0 knows the start and end address of .bss based on the symbols __bss_start and __bss_end which are provided by the linker. You can find these symbols in the linker command file (generated.x) -- which is in the system_description directory in your syslib build tree.  Regards, --Scott