[Bug 1001291] New HAL for Cortex-M3 Smartfusion device

[bugzilla-daemon at bugs dot ecos dot sourceware dot org]

Please do not reply to this email. Use the web interface provided at:
http://bugs.ecos.sourceware.org/show_bug.cgi?id=1001291

--- Comment #23 from Ilija Kocho <ilijak@siva.com.mk> 2011-11-14 22:04:53 GMT ---
(In reply to comment #21)
> (In reply to comment #20)
> > So we can start with HAL.
> > 
> > First one trivial issue:
> > CYGNUM_HAL_KERNEL_COUNTERS_CLOCK_ISR_DEFAULT_PRIORITY is set to 0xE0, and
> > description is "Set clock ISR priority to lowest priority.", probably carried
> > from other HAL. Since device is said to have 5 priority bits, please change
> > either value or description. (I wander if we should consider a CDL for lowest
> > ISR priority on architecture level).
> 
> I would recommend against it at architecture level as it's harder to choose a
> good default_value there - it is only in the context of the processor you are
> likely to know about other interrupt sources.

I am thinking of general macro for lowest interrupt priority (if we find it
useful/desirable). Note: For Cortex-M there is already a CDL for highest
priority. Here is a snippet for lowest:

    cdl_option CYGNUM_HAL_CORTEXM_PRIORITY_MIN {
         display         "Lowest ISR priority"
         flavor          data
         calculated      0xFFFF&\
               ((((1<<CYGNUM_HAL_CORTEXM_PRIORITY_LEVEL_BITS)-1)-1)\
                 <<8-CYGNUM_HAL_CORTEXM_PRIORITY_LEVEL_BITS)
         description     "
             Calculate the lowest interrupt priority."
    }


> 
> > CYG_HAL_STARTUP: I can see that you have followed our discussion from mailing
> > list. Please consider the following:
> 
> I've missed this discussion, can you tell me what the subject was and on which
> list?

Here it is: http://ecos.sourceware.org/ml/ecos-devel/2011-07/msg00002.html

> 
> > Basic idea is to cover all (or most) memory layouts not employing external
> > memory on variant level. Since this is a fresh port I would suggest to do it.
> > 
> > 1. Placing CYG_HAL_STARTUP in variant tree will avoid it's cloning in
> > forthcoming (i hope they will come) platform trees and at the same time provide
> > consistent propagation of it's updates (enhancements and bugs) in each of them.
> > In order to keep all startup together, platform's CYG_HAL_PLF_STARTUP, if
> > present, can be "parenthed" by CYG_HAL_STARTUP. Note: "If present means" if
> > there is external memory, for single-chip boards we can/should omit it.
> >
> > 1.1. Together with CYG_HAL_STARTUP come MLT filesets (fileset = ldi + header)
> > affected by. Normally, this will require a new pkgconf directory in variant.
> > Further, all values in MLT files (memory sizes, locations, etc.) can be
> > parametrized in CDL so it would be possible to cover many, (hopefully all)
> > combinations of on-chip memory with a handful of MLT filesets.
> > 
> > 2. Platforms with external memory is going to use CYG_HAL_PLF_STARTUP as well
> > as their own MLT filesets in order to override CYG_PLF_STARUP. However they
> > will also be able to make use of CYG_HAL_STARTUP (for eventual single-chip
> > emulation, etc.).
> 
> I'm not very keen on the idea of the startup types being split over two
> variables.
> 
> Let's take a step back. What problem is actually needing to be solved by
> CYG_HAL_PLF_STARTUP? I can't help but think that there surely must be a better
> way to improve the abstraction in the architectural HAL if there's insufficient
> abstraction at the moment.

The basic idea is to resolve common memory properties for a given
micro-controller family on variant level (for benefits mentioned above).
Commonly the members of controller families generally share common memory
layout, containing similar memory blocks that differ (mainly) in size. This can
be calculated by CDL and presented as a set of simple macros to MLT fileset MLT
fileset={mlt_*.ldi, mlt_*.h}, which makes it possible to cover a number of
chips with a single, relatively simple (i.e. without #ifdef) MLT fileset.
A handful of filesets shall cover all layouts which do not employ external
memory. For configurations with external memory we can continue to use per
platform MLT filesets. Platform shall be able to use both variant/general and
platform/private MLT.

Now we come to CYG_HAL_STARTUP. Startup is closely connected with memory layout
(hence startup types ROM, RAM, SRAM, etc). Essentially startup type determines
the elements for calculation of MLT fileset name. Having both variant and
platform MLT filesets, implies two startup CDL's: CYG_HAL_STARTUP_VAR and
CYG_HAL_STARTUP_PLF.

The easiest way to see relation between variant and platform startup CDLs isby
example. The mechanism is partly described in
http://ecos.sourceware.org/ml/ecos-devel/2011-07/msg00002.html
and is implemented in Kinetis port. However, the Kinetis code presently
available in CVS contains only the variant MLT/STARTUP (no platforms with
external memory). Platform code with external memory is working in our lab but
we're waiting for final HW (memory module) version. (I can provide it but in
this bug it would be alien, maybe i could open a new bug - although early, I
have some questions to discuss regarding external memory anyway - please
advise).

Ilija

-- 
Configure bugmail: http://bugs.ecos.sourceware.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.