public inbox for ecos-discuss@sourceware.org
 help / color / mirror / Atom feed
From: Christian Meusel <christian.meusel@inf.tu-dresden.de>
To: eCos Disuss <ecos-discuss@ecos.sourceware.org>
Subject: [ECOS] MCF5282 - bits for DACRx registers
Date: Mon, 09 Feb 2009 18:51:00 -0000	[thread overview]
Message-ID: <49907B2D.1060609@inf.tu-dresden.de> (raw)

[-- 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 --]

             reply	other threads:[~2009-02-09 18:51 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-02-09 18:51 Christian Meusel [this message]
2009-02-09 20:39 ` Bart Veer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49907B2D.1060609@inf.tu-dresden.de \
    --to=christian.meusel@inf.tu-dresden.de \
    --cc=ecos-discuss@ecos.sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).