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

[bugzilla-daemon@bugs.ecos.sourceware.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 #21 from Jonathan Larmour <jifl@ecoscentric.com> 2011-11-14 00:27:37 GMT ---
(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.

> 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?

> 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.

Just another little issue: in
CYGSEM_HAL_CORTEXM_A2FXXX_DEFINES_IDLE_THREAD_ACTION it talks about
"overwriting" but I believe it was intended to say "overriding".

Jifl

-- 
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.