HELP assigning function to specific address

Hi Rasdan,

> Is there a way to force the linker/compiler to place a variable or function at a

> specific memory address by using the __attribute__ command in my c code.

This is _normally_ done with the linker command file. For example, a function with

a section attribute of ".startfn" in the file start.c can be placed in whatever section you

want. If you identify the object file and the input section name as the first entry, it will

be located at the start of the output section: <div class='quotetop'>QUOTE </div>

--- Quote Start ---

SECTIONS

{

.whatever :

{

start.o (.startfn)

*(.whatever)

}

...[/b]

--- Quote End ---

Everything else from start.o (all other input sections) will be located

to their associated output sections as normal.

Regards,

--Scott

Hi Scott,

As i understand you are telling me that i need to make a costum linker script(or edit) generated.x file (the auto linker script).

Find the section where i want to place my function eq .text and insert "start.o (.startfn)" before anything else.

will look something like this

SECTIONS

{

.text :

{

start.o (.startfn) "line added"

*(.interp)

*(.hash)

*(.dynsym)

*(.dynstr)

*(.gnu.version)

}

right ?

the result will be that my function is placed (if .text is defined in sdram) at SDRAMbase+.textoffset (the start of text section in sdram).

Do you have any clue about my bootloader jmp question?

thx for all your help

Hi Rasdan,

> the result will be that my function is placed (if .text is defined in sdram) at

> SDRAMbase+.textoffset (the start of text section in sdram).

Yes, in the example you provide, your function (if it&#39;s the only .startfn input section in

start.o) will be placed at the start of the output .text section.

> Do you have any clue about my bootloader jmp question?

You&#39;ll need to provide more details ... but it&#39;s probably a problem with your

app format, your loader, or your startup code.

> My bootloader app is placed in internal memory so it executes every time I reset the

> nois, then it loads a user app into sdram. This works fine but when I jump to "entry"

> (as defined in the objdump file) nothing happens.

What do you mean "it loads a user app"? Are you using an instruction cache and do

you flush before jumping? What code did you implement at the entry point? What

happens when you download the code (e.g. using nios2-download) ... does it work?

Use nios2-console and set a breakpoint just before jumping to your code. Then step

through ... see what happens.

Regards,

--Scott

Hi Scott,

>You&#39;ll need to provide more details ... but it&#39;s probably a problem with your

>app format, your loader, or your startup code.

Ok here is the detail:

I’m coding a standalone bootloader for use with custom fpga hardware.

The fpga includes a nios with instruction cache.

On this hardware there is also a PowerPC (not in the fpga).

The setup should work as follows: In the fpga, at power on, a fpgaimage is loaded from the PowerPC.

This image includes a nios and the bootloader code.

Bootloader code is placed in internal fpga memory when I build the quartus project.

The PowerPC resets the niosCPU and the bootloader starts.

The bootloader app requests a binary file from the PowerPC.

The file is loaded, by the nios bootloader, into SDRAM.

All this works perfect.

The last thing the bootloader has to do is to start the user program it just placed in sdram, and here is the problem.

It wont start the program.

Btw. the user app is compiled with the same nios system as the bootloader,

but is set to use only sdram for .text .ro .rw and so on

What I do at the end of the bootloader is: use a void pointer and load this with the address I want to call

Looks something like this (haven’t got the code in front of me right now) but its only these 2 lines

userapp = 0x1000000 ; // or 0x1000034 ; _start or _main

userapp();

I can see (in the objdump.file) that this creates a ADDI, a "I cant remember instruction" and at last a CALLR instruction.

So this c code seems to work ok, but nothing happens.

For starters my user app is simple: main calls a function that runs some LED&#39;s

As described, if I jump to sdram base (_entry)(address found in user app objdump file) nothing happens.

If I jump to (_start) nothing happens.

If I jump to (_main) the program runs,

and if I jump to (myLEDfunc) it runs.

The problem is that I can see that the .heap, .stack and .exceptions +++ still uses the internal fpga memory

(led flash slower when running from SDRAM).

If I init irq&#39;s or init other features in my user app the jump to _main from bootloader doesn’t work.

my conclusion: I’m missing something but what?

>What do you mean "it loads a user app"? Are you using an instruction cache and >do you flush before jumping?

NO, how do I do that ?

What code did you implement at the entry point?

none (using default compiler script)

> What happens when you download the code (e.g. using nios2-download) ... does it work?

I&#39;m not using any tools provited with the nios software

>Use nios2-console and set a breakpoint just before jumping to your code. Then >step

Bootloader jumps but user app crash depending on address I jump to

thx for all your help and time Scott I think I need it.

Hi Rasdan,

Sounds like a problem with a stray interrupt and/or the exception trampoline. If your

exception address is in SDRAM, you need to: (1) disable interrupts, (2) load the

image into SDRAM, (3) flush icache and the pipeline, (4) finally jump to _start.

Actually you should flush the icache/pipeline no matter where your exception

address is -- otherwise you run the risk of executing stale code in the icache.

And even though you don&#39;t have a data cache, it&#39;s a good idea to go through the

motions anyway (which will be the equivalent of a few nops) ... it will save you some

headaches in the future if you decide to add dcache.

But a few more questions:

1. Where is your exception address located? SDRAM?

2. How do you generate the binary file?

And a few comments:

> If I jump to (_start) nothing happens.

- _start is the correct entry point. In your case, since .text is not in the boot device,

and you have no data cache, all _start does is: (1) set the stack pointer to the top

of memory, (2) sets the gp, (3) clears .bss, and (4) calls alt_main. Check your

system library properties to make sure you have your stack, heap, etc. set

properly.

- _start does NOT call alt_load when .text is NOT in the boot device. It&#39;s your loader&#39;s

responsibility to load the various sections to their proper VMA.

Regards,

--Scott

Hi Scott,

>1. Where is your exception address located? SDRAM?

For the bootloader application all system library properties is set to internal nios memory

(.text .ro .rw .exception .heap and stack) including the sopc builder settings reset addr and exception (as if the sdram didn’t exist)

For the user application, all settings are in sdram,

except SOPC .reset setting it&#39;s still in internal memory.

The reset addr for both bootloader and user application is in internal memory.

So if I reset the nios, at any point in any application(s), the nios would reboot and start the bootloader.

What I’m trying to do is to have one application in internal memory (bootloader) and another in sdram (user app).

My goal with this is to load and execute the user app (via. the bootloader)

as if it was downloaded by the nios IDE (-run as nios hardware)

but without using the nios IDE software.

>2. How do you generate the binary file?

This took me some time to figure out, but i use the elf2hex tool and run it from nios2 sdk shell:

elf2hex --input=userapp.elf --output=userapp.bin --width=8 --start=0x1000000 --end=0x1FFFFFF

This creates my binary file.

I have compared the file with the memory content of the sdram when I use the nios IDE to download the user app they are the same.

So it seems my file is valid.

I have also compared the sdram memory content, when using my bootloader,

with the sdram memory content, when using the nios IDE to download my user app.

Again it’s the same result.

My conclusion is that my file transfer works.

>exception address is in SDRAM, you need to: (1) disable interrupts, (2) load the

>image into SDRAM, (3) flush icache and the pipeline, (4) finally jump to _start.

Ok I understand my bootloader should do this. Is there a function(s) to flush icache,dcache and pipeline that i can use?

my guess is:

alt_icache_flush_all(), alt_dcache_flush_all()

> _start is the correct entry point.

Ok so my target is to call _start. I haven&#39;t seen this work jet, but it probably helps when I flush icache

>Check your system library properties to make sure you have your stack, heap, etc. set properly.

Bootloader sets stack pointer top of internal Memory.

User application sets stack pointer top of SDRAM Memory. 0x2000000

> _start does NOT call alt_load when .text is NOT in the boot device. It&#39;s your loader&#39;s responsibility to load the various sections to their proper VMA.

I’m not sure that this means?

As i understand alt_load normally copys .ro .rw .exceptions from LMA to VMA or am i wrong ?

In my user app, the objdump file shows me that LMA and VMA for .ro and .rw are the same, all located in sdram.

When i create my binary file, these addresses are included.

So when the bootloader copys the user app bin file to SDRAM the .ro .rw are initialised. Or are they??

Regards Rasdan

Hi Rasdan,

> For the bootloader application all system library properties is set to internal nios

> memory (.text .ro .rw .exception .heap and stack) including the sopc builder settings

> reset addr and exception (as if the sdram didn’t exist)

Ok, so your processor&#39;s exception address is in the internal memory.

> For the user application, all settings are in sdram,

> except SOPC .reset setting it&#39;s still in internal memory.

If I understand you correctly, for your user application, you are placing the .exception section in SDRAM??? If this is the case, this is your problem. That is:

- the exception address is set in SOPCBuilder ... it&#39;s fixed ... your .exception section in

your user application MUST be assigned to this address. Simply changing the VMA

in your application is useless.

- If you&#39;re downloading the app, the on chip memory (where the exception address is

set) must be ram ... otherwise you can&#39;t overwrite the exception handler. If it&#39;s

rom, the handler isn&#39;t overwritten, and an interrupt in your user app will cause the

exception handler in your bootloader to execute -- probably not what you want.

- If the on chip memory is actually ram, then resetting the CPU (not the FPGA)

also cause problems if your bootloader code enables interrupts -- since the

exception handler has been overwritten by the application.

- And finally, if alt_load is not called, then your application&#39;s exception handler is

not copied to the correct address -- you&#39;re app will have to do that itself -- unless

your bootloader is smart enough to do it.

Regards,

--Scott

Hi Scott,

>Ok, so your processor&#39;s exception address is in the internal memory.

Yes

>If I understand you correctly, for your user application, you are placing >the .exception section in SDRAM???

>If this is the case, this is your problem. :

Sorry my fault. No the user app .exception segment is set to internal memory. so it should be ok.

> If the on chip memory is actually ram, then resetting the CPU (not the FPGA)

>also cause problems if your bootloader code enables interrupts -- since the

> exception handler has been overwritten by the application.

The on chip memory is ram, and i&#39;m not using interrupts in the bootloader.

However the bootloader project is not a freestanding application.

So if this enables interrupts i&#39;m not avere of it, but i don&#39;t use them anyway, so this shouldn&#39;t be a problem?

>- And finally, if alt_load is not called, then your application&#39;s exception handler is

>not copied to the correct address -- you&#39;re app will have to do that itself -- unless

>your bootloader is smart enough to do it.

My user application is a freestanding project.

I don&#39;t call alt_load in my user application or in the bootloader.

If I understand you correct, this is a problem because the .exception segment,

from my bootloader program, is still in internal memory when the user application is started.

This fact will course a conflict when the user application uses or initialises interrupt.

So to sum up, this is really important.

-BOOTLOADER

After transfer of user application to SDRAM:

-make sure interrupts is not used

If your not using _alt_load in the user application.

-Copy .exception from user app image(now in sdram, look in objdump file to locate, normally sdrambase + 0x20 to ??).

Copy this segment to the .exception address defined in SOPC builder, overwriting the bootloaders .exception code.

-flush icache, dcache and the pipeline, using alt_icache_flush_all(), alt_dcache_flush_all()

-Call _start address to start the user application

USER APPLICATiON

If boot loader doesn’t handle the .exception copy thing.

Call the alt_load function at the start of main/alt_main to do the same job.

-Do whatever to code needs to do.

Hope this is correct?

Regards,

Rasdan

EDIT UPDATE!!

Ok I still have the same questions

I tried flushing icache and dcache.

The result was the same no execution of the user program.

Then I tried something new:

I edited the bootloader so it only loads code into sdram nothing more, no calls, no flush.

Then I made a new freestanding project witch sole purpose was to call/jump to _start (were my userprogram is located after the bootloader ends)

I compiled the quartus project with the new no_jump bootloader, reset my board and let the bootloader load the user app into sdram.

Then I used the nios IDE to run my new jump program into internal ram (making sure not to destroy the user program in sdram).

The jump program look like this:

int alt_main(void)

{

void (*AppStartP)(void);

alt_irq_init (ALT_IRQ_BASE);

alt_sys_init();

alt_icache_flush_all();

alt_dcache_flush_all();

AppStartP = (void*)0x1000000; //_start

AppStartP();

}

I run the jump program and nothing happen, no led flashing.

I then edit the jump program to look like this:

int alt_main(void)

{

void (*AppStartP)(void);

//alt_irq_init (ALT_IRQ_BASE);

alt_sys_init();

alt_icache_flush_all();

alt_dcache_flush_all();

AppStartP = (void*)0x1000000; //_start

AppStartP();

}

I run it and my user application starts and the led flashing begins.

My conclusion:

If the bootloader (nonfreestanding) init interrupts the jump/call doesn’t work.

I think this happens with a non freestanding application just before main

QUESTION: Why does this irq init affect the call/jump to the user application?

Hi Rasdan,

> However the bootloader project is not a freestanding application.

...

> My user application is a freestanding project.

> I don&#39;t call alt_load in my user application or in the bootloader.

Ok. Just to be sure we&#39;re on the same page:

--The difference between freestanding and hosted basically boils down to who

implements alt_main ... the application or the HAL. In a freestanding app, the

application (programmer) implements alt_main by overriding alt_main.c. In a

hosted app, the HAL implements alt_main (which calls the app&#39;s main routine).

--alt_load on the other hand is called by the startup code (crt0) when: (1) your .text

section is located in the boot device AND (2) your .rodata, .rwdata, or .exceptions are

_NOT_ in the boot device.

So "freestanding" v. "hosted" really doesn&#39;t affect the sections being loaded:

--Your bootloader does not call alt_load since the bootloader&#39;s .rodata, .rwdata and

.exceptions are all in the on chip ram (everything is already where it needs to be).

--Your application does not call alt_load because its .text section is not in the boot

device.

I think the short answer (sorry for rambling above) is your plan sounds fine to me.

But you need to consider a few things for everything to work the way you want it to:

1. After your application is loaded and successfully executed, your bootloader&#39;s

exception handler has been overwritten. If your application exits (returns to the

bootloader) or the CPU is reset, your bootloader will not restore its exception

handler.

2. If the exception handler in your application and the handler in your bootloader are

not the same size (e.g. different versions of the HAL or the app has a custom

handler, etc) it is possible for the application handler to corrupt you bootloader code.

That is, if the app exception handler is longer than the loader&#39;s, you&#39;ll spill over into

an adjacent section of you boot loader&#39;s image (probably the HAL irq dispatch code).

Which may or may not be fatal ;-)

You can probably resolve most of these issues by placing your exception address in

SDRAM. In this case, the bootloader code should relocate its exception handler each

time it runs (since .exceptions are not in the boot device). And, your application will

already have the exception handler where it needs to be when it is loaded -- just

food for thought -- you may want to experiment with it regardless :-)

Regards,

--Scott

Hi Scott,

Thx for the outstanding explanation on the difference between

hosted and freestanding applications.

This has answered all questions I might have on this topic.

> Your plan sounds fine to me.

I&#39;m very happy you think my approach is fine

>1. After your application is loaded and successfully executed, your bootloader&#39;s

>exception handler has been overwritten. If your application exits (returns to the

>bootloader) or the CPU is reset, your bootloader will not restore its exception

>handler.

This shouldn&#39;t be a problem.

My user application never exits and my bootloader doesn’t do anything that uses exceptions.

>2. That is, if the app exception handler is longer than the loader&#39;s, you&#39;ll spill

>over into

>an adjacent section of you boot loader&#39;s image (probably the HAL irq dispatch >code).

>Which may or may not be fatal ;-)

Yes I guess this would be fatal, but only if the bootloader .exception segment

is placed is internal ram.

If so, I would have to copy the user app .exception segment to internal ram overwriting

the bootloaders .exception segment and probably some other bootloader code

due to the segment size difference.

You mention placing exception address in SDRAM (SOPC builder).

As i understand this would eliminate the overwriting problem because

at power on the boot loader is started and copies (crt0) the exception segment

to SDRAM automatically.

After this the bootloader (my code) probably overwrites the exception segment with the user app and calls it.

My user application doesn’t need to copy anything because all segments (except reset)

are defined in sdram so they are already there.

If I, at this point, reset the cpu the bootloader should work just fine.

Is this correct?

>You can probably resolve most of these issues by placing your exception address in sdram

Yes i have done this, and finally something works.

Bootloader calls user program (_start) after load to SDRAM and

the program runs (led flashing).

However this is not the end (sorry).

This only works IF the bootloader is freestanding and it doesn’t call :

alt_irq_init (ALT_IRQ_BASE);

Any use of this function in the bootloader will somehow crash the user application when i call (_start).

I don&#39;t understand why?

Do u have any clue to this?

What I’m afraid of is that this is a symptom of a problem I might encounter

later on, when I start using interrupts in my user application.

I don&#39;t want to have some strange "why doesn’t the interrupt work" problem

later on if I can help it.

Regards,

Rasdan