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 <[email protected]> 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.
