Re: port to the Nios II processor

[Bart Veer <bartv at ecoscentric dot com>]

    Iain> Recently we've been working on a port of eCos to Altera's
    Iain> Nios II soft processor. A preliminary version based on the
    Iain> 2.0 release of eCos is available for download through the
    Iain> Nios forum (http://www.niosforum.com). This patch updates
    Iain> that initial port with the intention of getting it included
    Iain> in the public CVS repository.=20

    <snip>

    Iain> The Nios II processor is intended for use in a programmable
    Iain> FPGA device, which means that the hardware environment can
    Iain> be configured by the user. This is done using the Altera
    Iain> SOPC Builder tool. This allows you to: select memory
    Iain> devices; map in peripherals; select processor features; etc.
    Iain> etc. What this means is that no two Nios II users will have
    Iain> exactly the same platform, since each user will configure
    Iain> their FPGA contents to match their specific requirements.

    Iain> When a system is built using SOPC builder, a description of
    Iain> the system is stored in a generated text file (called a PTF
    Iain> file). One of the goals of this port is to take a users PTF
    Iain> file and automatically configure eCos to match their
    Iain> hardware, i.e. we wanted to avoid requiring the user to have
    Iain> to write their own platform port, or manually edit a lot of
    Iain> CDL options to set base addresses, irq numbers etc., given
    Iain> that all the information was already there in a machine
    Iain> readable format.

    Iain> This is done in two parts. Firstly a CDL fragment is
    Iain> automatically generated based on the PTF contents. This sets
    Iain> default values and limits available options to match what's
    Iain> actually present in the hardware. This CDL fragment is
    Iain> generated using a wrapper script for configtool named
    Iain> (imaginatively) nios2configtool. It is still possible to run
    Iain> configtool directly when targeting Nios II, but that means
    Iain> you will then have to set all options manually.=20

    <snip>

    Iain> All feedback greatly appreciated,

I know it has been a while, but I have now taken a look at the
host-side, and in particular the configuration issues. I am not
entirely happy with the way this is currently implemented.

It is certainly desirable to generate CDL based on the PTF contents.
However doing this via a nios2configtool wrapper script is not the
best way of achieving this. The graphical configtool is only one of
the ways of manipulating an eCos configuration. There is also the
ecosconfig command line tool, and there may be other tools using the
underlying libcdl.

There are various ways of tackling the problem. For example
gtf-generate could be invoked from inside the hal_nios2.cdl script
using a Tcl exec command, followed by an eval to process the
gtf-generate output. However anything like this quickly gets
complicated - too many parts of the configuration technology are not
yet implemented.

Instead I think the clean way is to use the multiple repository
support. gtf-generate should not produce a CDL fragment. Instead it
should generate an eCos component repository where the ecos.db file
lists just a single package, CYGPKG_HAL_NIOS2_SOPC, and that package
consists only of a CDL script along similar lines to the current CDL
fragment. Developers would then update the ECOS_REPOSITORY environment
variable to place the generated repository ahead of the normal one.

One snag: the multiple repository support is currently only fully
supported by ecosconfig. The graphical config tool still needs work,
and I don't know when that is going to happen.

Generating the repository may be integrated into the SOPC builder tool
or it could require a manual step by developers. That is something for
Altera to decide.

If the developer switches between several different NIOS2 targets then
the ECOS_REPOSITORY environment variable would have to be updated each
time. I suspect this will be a fairly uncommon event, so it shouldn't
be too big a problem. I don't know if there is an easy way within the
HAL to check that the chip really is set up as expected.


So, the ecos.db in the main repository would contain:

    package CYGPKG_HAL_NIOS2 {
        <as at present>
    }

    package CYGPKG_HAL_NIOS2_SOPC {
        directory hal/nios2/sopc_default
	script    sopc.cdl
	description "
	  This is a default implementation of the SOPC package. It
        should not get used. Instead tdf-generate should be invoked
	to generate a separate version appropriate for the target
	hardware."
    }

    target nios2_dev_board {
        alias		{ "Nios II Development Board (Altera)" }
	packages        { CYGPKG_HAL_NIOS2
                          CYGPKG_HAL_NIOS2_SOPC
                          CYGPKG_ALTERA_AVALON_UART
			  ...
   }

The ecos.db in the generated repository would just contain:

    package CYGPKG_HAL_NIOS2_SOPC {
        directory hal/nios2/sopc_default
	script    sopc.cdl
	description "
	  This version of the SOPC package has been generated
	  using TDF file <path> on <time+date>. It allows
          the generic eCos code to configure itself appropriately
	  for this hardware."
    }

   
I don't like the current approach of allowing users to use the default
version rather than the generated one - too many opportunities for
things to go wrong. Instead I suggest that CYGPKG_HAL_NIOS2 requires a
generated version of CYGPKG_HAL_NIOS2_SOPC:

    cdl_package CYGPKG_HAL_NIOS2 {
        ...
	requires CYGPKG_HAL_NIOS2_SOPC_GENERATED
	description "
	    ...
	    The eCos NIOS2 support requires an eCos package generated
          from a SOPC TDF file, to ensure that the software is
          properly configured for the target hardware."
    }

where the specified option is present in the generated package but
not in the default version. Hence if the developer fails to generate a
hardware-specific package or update ECOS_REPOSITORY the resulting
configuration will have a conflict that cannot be resolved.


A few other points:

1) you have placed the device drivers in a devs/sopc directory, rather
   than below devs/serial, devs/eth, etc. This breaks the current
   convention. The advantage of organizing things the way are at
   present is that if I have to change e.g. io/serial in a way that
   might affect serial drivers, all the serial drivers are in place in
   the hierarchy so it is easier to check them all. The disadvantage
   is that if something changes in the SOPC world then it is more
   difficult to find all the places that might be affected.

   My personal preference would be to stick to the current convention.

2) related to this, the package CYGPKG_SOPC seems undesirable. In the
   configuration tool it would cause all your device drivers to be
   grouped together, as opposed to the current approach where e.g.
   serial device drivers go below CYGPKG_IO_SERIAL. Again I think it
   is better to stick to the current convention.

3) the directory hal/nios2/tools should not exist. Any tool like the
   nios2configtool script should probably live in the SOPC world
   rather than the eCos world. If there is a tool or script that
   should live in the eCos world then it should probably live in a
   hal/nios2/sopc_default/current/host subdirectory, as per other
   package-specific host-side tools, and integrated into the
   autoconf/automake support. See various synthetic target packages
   for some examples.

4) most/all of the files contain the following in the banner:

  ## Alternative licenses for eCos may be arranged by contacting Red Hat, Inc.
  ## at http://sources.redhat.com/ecos/ecos-license/

  This is inappropriate - Red Hat can only arrange alternative
  licenses for code for which it owns the exclusive copyright. Since
  the assignment has gone to eCosCentric, to be transferred to the FSF
  when possible, Red Hat are not involved.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts
 >>>>> Visit us in booth 2539 at Embedded Systems Conference 2005 <<<<<
 >>>>> March 8 - 10, San Francisco http://www.embedded.com/esc/sf <<<<<