eCos for Nios II 5.0 now available

[Altera_Forum]

eCos for Nios II 5.0 is now available for download from the downloads section of this forum.

[Altera_Forum]

Sorry but... is there any document with the changes from one version to the new one? 

  I've looked for it, but I haven't found...   Alex

[Altera_Forum]

This is essentially a bug fix release to track the new version of the Nios II kit. The headline changes are: 

 - Changes in driver layout requested by the eCos maintainers. This is just a reorganisation of the directory structure of the code. It should not change the functionality of the drivers.  - Removal of the ability to use the vanilla configtool rather than the nios2configtool wrapper when building for Nios II. This was a change requested by the eCos maintainers, and is intended to reduce the risk of confusion.  - Addition of a nios2ecosconfig wrapper to allow projects to be build from the command line rather than through the nios2configtool GUI.  - Removal of the unused boot stub in ROMRAM mode to allow applications to succesfully download through nios2-download.  - Provided replacment stub for the C++ exception terminate handler to allow eCos to build succesfully with the latest version of GCC.  - Reformatted the Redboot debug information to be compatible with the new version of GDB.  - Set the MicroWindows defaults to be more Nios II freindly.  - Increased the default web server stack size to avoid overflow when using DHCP.  - ROMRAM is now the default configuration rather than RAM.  - The license text was updated as requested by the eCos maintainers.  - Makefile changes were made to avoid unecessary regeneration of PTF dependent files (i.e. the linker script etc.) which had previously been slowing build times.  - The location of the Nios II host side tools was changed to be more consistent with other ports.  - Fixed RTC constant definitions to support more than just the default tick rate.

[Altera_Forum]

Iam unable to find the eCos source code for download. 

Where can i download the eCos source code and associated tools? Thanks in advance, Kamal

[Altera_Forum]

There is a forum titled "Download ecos" in the downloads section of this forum. i.e. click on the "Nios Discussion Board" link above, and then click on "Download ecos".

[Altera_Forum]

--- Quote Start ---  originally posted by monkeyboy@Jun 29 2005, 04:34 AM - removal of the unused boot stub in romram mode to allow applications to succesfully download through nios2-download.  --- Quote End ---   Is this the code in the .entry segment? Just asking because we're using that and I'd like to know what I'd need to replace it with. We had to write our own bootloader for the EPC16 chip, which basically copies the program from a fixed flash base address to the base of our SDRAM, then jumps to the base of SDRAM (i.e. the .entry section). If there's a better way (EPC16 is not CFI compliant, so the default bootloader won't work), I'd love to know.

[Altera_Forum]

This is the code in the .entry section, which is placed by the linker script at the reset address of the processor - which in your case would be a location in the EPCS device, not the SDRAM. Have you modified the linker script as well?  

 In any case, you can either just jump to the _start location instead, or if you really do need the code in the .entry section, you can remove the conditional compilation of this section (i.e. the use of CYG_HAL_STARTUP_ROM) in vectors.S.

[Altera_Forum]

--- Quote Start ---  originally posted by monkeyboy@Aug 11 2005, 03:44 AM this is the code in the .entry section, which is placed by the linker script at the reset address of the processor - which in your case would be a location in the epcs device, not the sdram. have you modified the linker script as well?  --- Quote End ---   We wrote a BASH script that remaps all the sections in SDRAM (i.e. everything except .entry) into flash. Then our bootloader just copies a fixed block of flash to the base of SDRAM and jumps to the first address in SDRAM. We didn't modify the linker script because we wanted it to only see the RAM addresses it will be executing from. Our bootloader didn't have access to _start; the Quartus II programmer discarded that info in its Convert Programming Files... command. BTW, this is an EPC device, not an EPCS device; it's on a parallel bus, not the active serial bus.  I guess we'll just need to change our script to get the _start address and put it where .entry used to be, and change the bootloader so it fetches that address. Or figure out how to get RedBoot fit in 64K.