Got a question for the bootloader/flash gurus

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

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

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

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?

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

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