* [ECOS] MCF5282 - bits for DACRx registers
@ 2009-02-09 18:51 Christian Meusel
2009-02-09 20:39 ` Bart Veer
0 siblings, 1 reply; 2+ messages in thread
From: Christian Meusel @ 2009-02-09 18:51 UTC (permalink / raw)
To: eCos Disuss
[-- Attachment #1: Type: text/plain, Size: 1573 bytes --]
Hello!
I'm currently backporting our eCos port for the ColdFire MCF5282 (based
on the old coldfire architecture) to the MCF52xx processor HAL (based on
m68k) contributed by eCosCentric.
The archictecture HAL for MCF52xx processors provides quite a lot of
definitions for the MCF5282. Amongst others, bit definitions for the
SDRAM controller's DACR registers where the motivation behind is not
clear to me. For example, the port size bits
(HAL_MCFxxxx_SDRAMC_DACRx_PS_32, ...) are alredy shifted to the
appropriate position within a DACR register where the command and bank
MUX bits (HAL_MCFxxxx_SDRAMC_DACRx_CBM) are not.
Is there a special intention for not shifting the command and bank MUX
bits to their appropriate position? Has these definitions be made for
allowing to redefine HAL_MCFxxxx_SDRAMC_DACRx_CBM_SHIFT for other
ColdFire processors? Is there already productive code out there which
relies on this definition of the command and bank MUX bits?
If not, I would like to change the bit defintions for the command and
bank MUX bits in var_io.h. If there is a reason for not doing so, our
MCF5282 port will live with the definitions already provided for this
bits. We are planning to contribute this port when it is finished and
therefor we would like to minimize the impact of such "global" changes.
Best regards,
Christian
--
Christian Meusel
TU Dresden
Fakultät für Informatik
Professur Mikrorechner
Internet: www.mr.inf.tu-dresden.de
Telefon: +49 351 463-37902
Telefax: +49 351 463-38245
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/x-pkcs7-signature, Size: 3380 bytes --]
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [ECOS] MCF5282 - bits for DACRx registers
2009-02-09 18:51 [ECOS] MCF5282 - bits for DACRx registers Christian Meusel
@ 2009-02-09 20:39 ` Bart Veer
0 siblings, 0 replies; 2+ messages in thread
From: Bart Veer @ 2009-02-09 20:39 UTC (permalink / raw)
To: Christian Meusel; +Cc: ecos-discuss
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2925 bytes --]
>>>>> "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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2009-02-09 20:39 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-02-09 18:51 [ECOS] MCF5282 - bits for DACRx registers Christian Meusel
2009-02-09 20:39 ` Bart Veer
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).