All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Gehrlein <sew_s@tqs.de>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] MPC85xx: Question about Local Bus initialization
Date: Tue, 04 Dec 2007 08:56:10 +0100	[thread overview]
Message-ID: <4755081A.4020005@tqs.de> (raw)
In-Reply-To: <47542F0F.7050901@anagramm.de>

Hi Clemens,

thanks for the reply.


Clemens Koller schrieb:
>  > Hi,
>  >
>  > I took a look into the files board/mpc8560ads.c and board/tqm85xx.c and
>  > found something strange:
>  >
>  > 1. In the function local_bus_init() the current CLKDIV is read from the
>  > register LCRR as was set by Hardreset. After that, the decision is made,
>  > wether the DLL has to be enabled/disabled/overridden. Inside the if-else
>  > blocks the new CLKDIV is changed. But IMO the CLKDIV has to be set
>  > before the query.
>  >
>  > This is the current code:
>  >     clkdiv = lbc->lcrr & 0x0f;
>  >     lbc_hz = sysinfo.freqSystemBus / 1000000 / clkdiv;
>  >
>  >     if (lbc_hz < 66) {
>  >         lbc->lcrr = CFG_LBC_LCRR | 0x80000000;    /* DLL Bypass */
>  >
>  >     } else if (lbc_hz >= 133) {
>  >         lbc->lcrr = CFG_LBC_LCRR & (~0x80000000); /* DLL Enabled
>  >     ...
>  > This may be the situation on other 85xx boards, too. I didn't check them
>  > all.
>  > What was the intention, DLL modification dependent on the clock set by
>  > the MPC at hardreset or dependent on the targeted frequency?
> 
> MPC8540 Reference Manual, Page 13-23, LCRR Field Descriptions:
> "DLL bypass. This bit should be set when using low bus clock
> frequencies if the DLL is unable to lock. When in DLL bypass mode,
> incoming data is captured in the middle of the bus clock cycle."

> 
> Usually 85xx boot from Flash connected to the Local Bus, so the bootstrap
> configuration out of a hard reset need to be correct at first place.
> Then, if the bootloader (or later, the kernel) wants to (re-)set it
> during runtime, it also has to set the DLL enable bit depending on the
> desired target frequency.
But the bootloader should not itself pull the rug out from under its 
feet. As I see, the U-Boot works if I change the frequency during 
runtime (changed define CFG_LBC_LCRR). Does anybody know why?
In our Monitor MON85XX we don't change the frequency in flash code, but 
later in RAM code according to the target frequency. Additionally 
LCRR[EADC] and OR[EAD] are modified if the target frequency is greater 
than 83 MHz according to the HW developer's timing calculations.

Regards,
Jens

      reply	other threads:[~2007-12-04  7:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-11-29  9:55 [U-Boot-Users] MPC85xx: Question about Local Bus initialization Jens Gehrlein
2007-12-03 15:39 ` Detlev Zundel
2007-12-04  7:56   ` Jens Gehrlein
2007-12-03 16:30 ` Clemens Koller
2007-12-04  7:56   ` Jens Gehrlein [this message]

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=4755081A.4020005@tqs.de \
    --to=sew_s@tqs.de \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.