[U-Boot] [Patch] MPC83XX: Fix PCI express clock setup
On a 8308 based board it was found that the PEX_GLK_RATIO register (programmed in arch/powerpc/cpu/mpc83xx/pcie.c) was getting set to 0, This was tracked to the fact that the pci express clock frequency was not being assigned to the pciexp1_clk entry in the global data structure in file arch/powerpc/cpu/mpc83xx/speed.c. Fix this and a similiar issue in 'do_clocks' command. Signed-off-by: Bill Cook c...@isgchips.com --- This also points to another problem. The description of the PEX_CLK_RATIO for the various SOCs in question (I checked the RMs for 8308, 8315, and 8378) shows a different maximum freqency for the PCIe core. So the divider in the equation on line 271 should reflect these differences. This seems to be the only mention of a maximum core frequency though, so I hesitate to patch pcie.c without feedback from Freescale. As I'm not a PCI expert, I would rather someone at Freescale look at this and provide appropriate patches. Also, if the max PCIe core frequency on the 8308 is really 125MHz, shouldn't the SCCR PCIEXPCM field of the SCCR be programmed with a 2 instead of 1, this is given by the definition of CONFIG_SYS_SCCR_PCIEXP1CM in the board config file. arch/powerpc/cpu/mpc83xx/speed.c |6 -- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git a/arch/powerpc/cpu/mpc83xx/speed.c b/arch/powerpc/cpu/mpc83xx/speed.c index 5e616dd..86d2e18 100644 --- a/arch/powerpc/cpu/mpc83xx/speed.c +++ b/arch/powerpc/cpu/mpc83xx/speed.c @@ -481,7 +481,8 @@ int get_clocks(void) gd-qe_clk = qe_clk; gd-brg_clk = brg_clk; #endif -#if defined(CONFIG_MPC837x) +#if defined(CONFIG_MPC8308) || defined(CONFIG_MPC831x) || \ + defined(CONFIG_MPC837x) gd-pciexp1_clk = pciexp1_clk; gd-pciexp2_clk = pciexp2_clk; #endif @@ -541,7 +542,8 @@ int do_clocks (cmd_tbl_t * cmdtp, int flag, int argc, char * const argv[]) #if defined(CONFIG_MPC834x) printf( USB MPH: %-4s MHz\n, strmhz(buf, gd-usbmph_clk)); #endif -#if defined(CONFIG_MPC837x) +#if defined(CONFIG_MPC8308) || defined(CONFIG_MPC831x) || \ + defined(CONFIG_MPC837x) printf( PCIEXP1: %-4s MHz\n, strmhz(buf, gd-pciexp1_clk)); printf( PCIEXP2: %-4s MHz\n, strmhz(buf, gd-pciexp2_clk)); #endif -- 1.7.2.3 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Question on usage of #define in mpc83xx.h
I have a board based on the Freescale MPC8313ERDB configuration. I was having a problem with the output of the USBDR_DRIVE_VBUS pin (we have flakey power on USB devices). I traced this to an incorrect configuration of the SICRL register. The definition in mpc83xx.h for SICRL_USBDR is 0x0C00 which seems to be a mask telling which bits control that pin. However, when used in MPC8313ERDB.h and SIMPC8313.h board configurations (and hence my configuration), it is or'd into the definition of SICRL. The problem is that according to the reference manual setting both bits in this field is undefined. So the question, are the #defines in mpc83xx.h meant to be bit masks? or should these (at least SICRL_USBDR) be changed to reflect intended usage? Alternatively, the board configuration files should be updated to set this field correctly. I see Ron Madrid i...@sheldoninst.com as the maintainer of SIMPC8313 and no one as the maintainer of the Freescale MPC8313ERDB. Regards, Bill Cook c...@isgchips.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/7] fec_imx27: driver for FEC Ethernet controller on i.MX27
-Original Message- From: Eric Lammerts [mailto:u-b...@lists.lammerts.org] Sent: Monday, June 15, 2009 3:59 PM To: Johan Cc: u-boot@lists.denx.de; Ilya Yanok Subject: Re: [U-Boot] [PATCH 3/7] fec_imx27: driver for FEC ethernet controller on i.MX27 On 06/15/09 10:01, Johan wrote: I have trouble using your patch together with our LogicPD iMX27 Litekit. Seems like the FEC driver does not work well. Here is some output from when I try to load files with tftp snip Loading: #T #T #T T# #T ##T T #T T # Retry count exceeded; starting again snip I have downloaded the imx27lite head from the u-boot testing branch. I have also tried to patch the u-boot-2009.06-rc3 branch with your patches, but it does not seem to be any different. Do you have any ideas what might be wrong? Did you have working ethernet before (with a different bootloader or in Linux)? Do you have the breakout board installed? I have the same board (but maybe an older revision; about a year old) and with the breakout board mounted my ethernet would behave the same way as yours. They routed the MII signals all the way to the headers on the breakout board, and that causes signal integrity problems. It could be that they fixed it on later revisions though (not sure). I'm using u-boot-v2, so I don't know anything about the u-boot fec driver. Eric I'm trying to debug ethernet problems on a custom iMX27 board with same LAN chip as the logicPD liteKit. I don't claim to be an expert, but it seems that in the fec driver posted by Ilya, the phy address for MII access is hard coded to a 0, whereas on the board it defaults to 0x1f. When I turned on DEBUG in fec_imx27.c, the MII reads always return all 1's. The phy works, but maybe by good fortune, not intent. Bill Cook c...@isgchips.com Imaging Solutions Group Inc; http://www.isgcameras.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Build errors u-boot-v2 iMX27
-Original Message- From: saschaha...@web.de [mailto:saschaha...@web.de]on Behalf Of Sascha Hauer Sent: Monday, April 20, 2009 12:57 PM To: Bill Cook Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] Build errors u-boot-v2 iMX27 Hi Bill, On Mon, Apr 20, 2009 at 10:57:49AM -0400, Bill Cook wrote: Dear ML, I'm trying to build u-boot-v2 for an iMX27 based board. I'm getting a HW/SW floating point mismatch error and hope someone will point me to a solution. Building with: snip Error is: arm-eabi-ld: ERROR: arch/arm/lib/_ashldi3.o uses hardware FP, whereas arch/arm/lib/built-in.o uses software FP arm-eabi-ld: failed to merge target specific data of file arch/arm/lib/_ashldi3.o The source files are assembly, any C files have the -msoft-float compile option. What gives? All our toolchains produce soft float by default, so this does not show up here. U-Boot does not use floating point, so I think we do not have to care what the compiler produces. Does it help to remove the -msoft-float from arch/arm/Makefile? Yes, this did the trick, I knew it had to be something simple... Thanks. Bill Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Build errors u-boot-v2 iMX27
Dear ML, I'm trying to build u-boot-v2 for an iMX27 based board. I'm getting a HW/SW floating point mismatch error and hope someone will point me to a solution. Building with: make ARCH=arm CROSS_COMPILE=arm-eabi- It works along fine until I get an error on each of these files: arch/arm/lib/_ashldi3.o arch/arm/lib/_ashrdi3.o arch/arm/lib/_divsi3.o arch/arm/lib/_modsi3.o arch/arm/lib/_udivsi3.o arch/arm/lib/_umodsi3.o arch/arm/lib/_lshrdi3.o arch/arm/lib/findbit.o arch/arm/lib/io-readsb.o arch/arm/lib/io-readsw-armv4.o arch/arm/lib/io-writesb.o arch/arm/lib/io-writesw-armv4.o Error is: arm-eabi-ld: ERROR: arch/arm/lib/_ashldi3.o uses hardware FP, whereas arch/arm/lib/built-in.o uses software FP arm-eabi-ld: failed to merge target specific data of file arch/arm/lib/_ashldi3.o The source files are assembly, any C files have the -msoft-float compile option. What gives? Regards, Bill Cook c...@isgchips.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
