.rwdata

Altera_Forum · ‎02-04-2005

According to last version of the SW user manual, alt_load() must be called to copy .rwdata sections to RAM. (when there is no bootloader in teh system)

Where can I find info about alt_load() My kit does not contain any info.

Altera_Forum · ‎02-04-2005

Are you using nios 1.0 ? This is what I am struggling with now, I found that in order to get my internal ROM code to operate I needed to initialise some variables myself, so it involves inspecting driver code/etc to see if anything needs setup.

An example to get up-and-running with only the timer interrupt taken care of is.

alt_main.c:

# include <stdio.h># include <stdlib.h># include "system.h"# include "sys/alt_sys_init.h"# include "sys/alt_irq.h"# include "sys/alt_alarm.h"

extern void* altera_avalon_timer_ts_base;

extern alt_u32 altera_avalon_timer_ts_freq;

extern alt_u32 alt_priority_mask;

extern alt_u32 alt_irq_active;

extern alt_u32 _alt_tick_rate;

extern volatile alt_u32 _alt_nticks;

extern alt_llist alt_alarm_list;

void alt_main(void)

{

altera_avalon_timer_ts_base = (void*) 0;

altera_avalon_timer_ts_freq = 0;

alt_priority_mask = (alt_u32) -1;

alt_irq_active = 0;

_alt_tick_rate = 0;

_alt_nticks = 0;

alt_alarm_list.next = &alt_alarm_list;

alt_alarm_list.previous = &alt_alarm_list;

alt_irq_init (ALT_IRQ_BASE);

alt_sys_init();

main();

for(;;)

;

}

Altera_Forum · ‎02-04-2005

if there is a version of alt_load() available for the Nios1.0 kit then that is great.

however, i see the plan is typically to creep fixes into the online manuals first - and only later on release the actual software tools??

i guess the gate-slingers at Altera are finding software development a bit of a chore. http://forum.niosforum.com/work2/style_emoticons/<#EMO_DIR#>/blink.gif

Altera_Forum · ‎02-04-2005

What can I say? If you need this feature badly enough, download and install the 1.1 version of the kit.

The software included in this version only requires that .rwdata be placed in volatile memory.

- slacker

Altera_Forum · ‎02-04-2005

question: does Nios 1.1 actually require quartus 4.2 to operate? and if so, how come? My version is 4.1 which is sp2. That is what came with my Nios devkit.

additionally, is it possible to change the exception address? basically my bootstrap code operates out of internal ROM (so reset/exception are located there) - however after loading my main program I'd need to re-position that exception address from the internal ROM to the real program's handler in SDRAM.

Is there a jump vector as such (changeable) - or is that exception address effectively hard-wired at nios-compile-time?

Thanks.

ps. in case you're wondering why I am doing this, it is because mk_target_board does not work and I am trying my best to get my design to operate standalone........ a feature which i do indeed need badly.

Altera_Forum · ‎02-04-2005

You should be able to use a custom linker script to do what you like, with the current rev. of tools that you have. However, I would advocate upgrading to Quartus II 4.2 and Nios II 1.1.....if still possible!

The default linker script is "generated.x", located in the System Library project....post build. Just copy this into the _top_ level of your syslib project, change it's name, and edit where you'd like your code to reside. Then, disable the "use auto-generated linker script" on the syslib properties page and point it at your script, instead.

Note that, for the tools you're using, stack and heap will always follow .rwdata. There is already a .exceptions section in the linker script. ... All you'd have to do is change it's > <memory> target. You could also define your own sections and locate them in a memory of your choice... Take a look at

http://www.altera.com/literature/hb/nios2/...n2sw_nii5v2.pdf (http://www.altera.com/literature/hb/nios2/n2sw_nii5v2.pdf)

on page 4-32. That's only if you're getting extremely anal about where your code resides, though! :-)

Hope you find this helpful, regardless of which path you decide to take.

Cheers,

- slacker

P.S.: I think support is generally tied to dollars, right? I've been on both sides of the vendor/client relationship at startup shops and large companies. All I can say, is that if you're a small/startup shop, you shouldn't expect premium support... That being said, this forum should provide most of the info. you need... If you are with a large company with large dollars, I'd expect that you'd be beating Altera's door down by now :-)

Altera_Forum · ‎02-04-2005

The difficulty may be getting the exceptions to work for both the boot code (in on-chip memory) and subsequently getting the nios2 to vector to the program handler in SDRAM?

The exception setting appears to be set within the NIOS FPGA build, and is bound to a particular section(address)

I guess I can locate the exception handler part of the boot ROM actually in a small block RAM, and part of my boot copier will load the applications handler on-top of the boot-RAM one (which is initialised via initial FPGA bitstream) ?

However - this presents a problem upon nios_reset since the original exception handler for the boot RAM will now be lost (overwriting by the boot-copier)

Thanks for your efforts anyway!

Altera_Forum · ‎02-07-2005

If you do not have a bootloader in your system, and you want to copy sections from your boot device to volatile memory, then look at the thread "Running from Flash" in this forum. This explains the procedure required when using the 1.0 kit.

However I'd recommend upgrading to the 1.1 kit. In this case section loading will be taken care of for you without any special effort on your part. With the 1.1 kit there is no need to explicitly call alt_load() yourself, since this will be called by the startup code automatically when required.

When using a multistage boot, I'd recommend that you run the download + boot in polled mode. That way there is no issue with overwriting the exception section (you will of course have to place your exception vector in RAM and not flash).

However if you do need to use interrupts in the boot loader then you should construct your downloaded code so that it will unpack the exception code into the correct location once it has started executing; i.e. you should use a similar scheme to that used by alt_load(). The warning is that this is a relatively involved procedure that will require you to write your own linker script. The thread "Running from Flash" may help to explain what is required.

Finally, if you don't want to go to all the effort of writing your own bootloader then you might want to consider UBoot or Redboot (supplied with eCos). Both of these are available for download from this forum.