This is the mail archive of the ecos-discuss@sourceware.org mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: MCF5282 - bits for DACRx registers


>>>>> "Christian" == Christian Meusel <christian.meusel@inf.tu-dresden.de> writes:

    Christian> I'm currently backporting our eCos port for the
    Christian> ColdFire MCF5282 (based= on the old coldfire
    Christian> architecture) to the MCF52xx processor HAL (based on=
    Christian> m68k) contributed by eCosCentric.

    Christian> The archictecture HAL for MCF52xx processors provides
    Christian> quite a lot of definitions for the MCF5282. Amongst
    Christian> others, bit definitions for the SDRAM controller's DACR
    Christian> registers where the motivation behind is not clear to
    Christian> me. For example, the port size bits
    Christian> (HAL_MCFxxxx_SDRAMC_DACRx_PS_32, ...) are alredy
    Christian> shifted to the appropriate position within a DACR
    Christian> register where the command and bank MUX bits
    Christian> (HAL_MCFxxxx_SDRAMC_DACRx_CBM) are not.

    Christian> Is there a special intention for not shifting the
    Christian> command and bank MUX bits to their appropriate
    Christian> position? Has these definitions be made for allowing to
    Christian> redefine HAL_MCFxxxx_SDRAMC_DACRx_CBM_SHIFT for other
    Christian> ColdFire processors? Is there already productive code
    Christian> out there which relies on this definition of the
    Christian> command and bank MUX bits?

    Christian> If not, I would like to change the bit defintions for
    Christian> the command and bank MUX bits in var_io.h. If there is
    Christian> a reason for not doing so, our MCF5282 port will live
    Christian> with the definitions already provided for this bits. We
    Christian> are planning to contribute this port when it is
    Christian> finished and therefor we would like to minimize the
    Christian> impact of such "global" changes.

The definitions in var_io.h are not necessarily 100% consistent,
partly because the Freescale reference manuals are not 100% consistent
especially between processors, and partly because it is actually quite
hard to avoid mistakes when typing in very large numbers of these
definitions. The particular case of the _CBM settings does look an
oversight and can be fixed with relatively low risk, so I'll make the
change. If there are other problems it may or may not be possible to
fix them. It will depend on the risk to existing production systems.

Bart

-- 
Bart Veer                                   eCos Configuration Architect
eCosCentric Limited    The eCos experts      http://www.ecoscentric.com/
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales: Reg No 4422071.
Besuchen Sie uns vom 3.-5.03.09 auf der Embedded World 2009, Stand 11-300
Visit us at Embedded World 2009, Nürnberg, Germany, 3-5 Mar, Stand 11-300

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]