From mboxrd@z Thu Jan 1 00:00:00 1970 From: Timur Tabi Date: Mon, 27 Nov 2006 10:55:20 -0600 Subject: [U-Boot-Users] Please pull u-boot-83xx.git In-Reply-To: <200611261446.24607.sr@denx.de> References: <20061103201138.1d7fe056.kim.phillips@freescale.com> <200611261446.24607.sr@denx.de> Message-ID: <456B1878.6030205@freescale.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Stefan Roese wrote: > Hi Kim, > > On Saturday 04 November 2006 03:11, Kim Phillips wrote: >> Please pull from 'master' branch of: >> >> http://opensource.freescale.com/pub/scm/u-boot-83xx.git >> >> to receive the following updates (essentially MPC8349mITX and MPC8360EMDS >> support): > > I did a quick check. The overall impression is quite good. Thanks a lot > for your contribution (and you colleagues too of course). We're happy to make it available. Once you pull this code into your tree, there's a lot more coming. Kim Phillips is out today, so I'm going to address your concerns in his stead. I can make the changes, but they won't be posted until after Kim reviews them. > Here a few notes: > > - Please don't add changelog comments in the files (like in > cpu/mpc83xx/i2c.c or spd_sdram.c). Instead please remove all the > file internal changelog comments, since we decided to only use > git for this history. Okay. > - Please add the missing entries to the MAINTAINERS files (MPC8349EMDS & > MPC8360EMDS). Okay. > Another idea (this would also affect the other Freescale board ports): > What do you think of moving all your Freescale board ports into a > Freescale board directory (as done for AMCC or esd for example). > So we would get something like: Yes, we can do that. I agree that the current code base is a little messy because of so many board-specific files. We already have plans to address that, but again, we'll start work once the current code has been pulled. > We could start with the mpc83xx boards and contine soon with the > 85xx and 86xx eval boards (and so on...). That's how I was planning on doing it. >> +ulong get_ddr_clk(ulong dummy) >> +{ >> + return gd->ddr_clk; >> +} > > Hmmm. Is this function really needed? I'll check. > >> Author: Timur Tabi 2006-10-26 01:45:23 >> Committer: Kim Phillips 2006-11-04 02:42:19 >> Parent: 31068b7c4abeefcb2c8fd4fbeccc8ec6c6d0475a (mpc83xx: Add support for variable flash memory sizes on 83xx systems) >> Child: bed85caf872714ebf53013967a695c9d63acfc68 (mpc83xx: Add support for Errata DDR6 on MPC 834x systems) >> Branches: master, 83xx >> Follows: U-Boot-1_1_6 >> Precedes: >> >> mpc83xx: fix TQM build by defining a CFG_FLASH_SIZE for it >> >> -------------------------- include/configs/TQM834x.h -------------------------- >> index b1f033d..f0e4900 100644 >> @@ -95,6 +95,7 @@ >> #define CFG_FLASH_CFI_DRIVER /* use the CFI driver */ >> #undef CFG_FLASH_CHECKSUM >> #define CFG_FLASH_BASE 0x80000000 /* start of FLASH */ >> +#define CFG_FLASH_SIZE 8 /* FLASH size in MB */ > > Do you only support sizes bigger or equal to 1 MByte? What if a board > only has 512kBytes? As I mentioned in my other post, this code is for the LBLAWAR1 code in start.S. That code assumes that CFG_FLASH_SIZE is at least 1. I'm not aware of any 83xx board that has less than that much flash, but you're right - it is possible. If you like, I can provide an enhanced version of this code to support flash sizes less than 1MB, but I would prefer to do that after you pull our current code. > I also do get some warning upon compiling for MPC8349ITX: > mpc8349itx.c: In function 'misc_init_r': > mpc8349itx.c:398: warning: pointer targets in passing argument 4 of 'i2c_read' differ in signedness > mpc8349itx.c:443: warning: pointer targets in passing argument 4 of 'i2c_write' differ in signedness > > And for MPC8360EMDS: > uccf.c: In function 'ucc_set_clk_src': > uccf.c:121: warning: 'reg_num' is used uninitialized in this function > uccf.c:105: warning: 'shift' may be used uninitialized in this function > uccf.c:103: warning: 'p_cmxucr' may be used uninitialized in this function > > Could you please clean this up too? I've never seen these, but I'll look into it. -- Timur Tabi Linux Kernel Developer @ Freescale