From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Gehrlein Date: Tue, 04 Dec 2007 08:56:10 +0100 Subject: [U-Boot-Users] MPC85xx: Question about Local Bus initialization In-Reply-To: <47542F0F.7050901@anagramm.de> References: <474E8C99.90507@tqs.de> <47542F0F.7050901@anagramm.de> Message-ID: <4755081A.4020005@tqs.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.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