[U-Boot-Users] Re: PATCH MPC86xADS and MPC860FADS bug fixes
On Tue, Jun 03, 2003 at 11:43:36PM +0200, Wolfgang Denk wrote:
Right. Let's have separate #defines for the processors in case we need to really keep them apart (for example, to print a correct id string), and have some central header file which contains something like
#if defined(MPC866P) || \ defined(MPC866T) || \ defined(MPC859T) || \ defined(MPC859DSL) || \ defined(MPC852T) #define MPC866_et_al #endif
I'm working on this now, where should i put this header file and what should I name it?
also, this patch is pretty important; typo in mpc8xx.h; you might want this in CVS (also cc'ing to the list):
Index: include/mpc8xx.h =================================================================== RCS file: /cvsroot/u-boot/u-boot/include/mpc8xx.h,v retrieving revision 1.1.1.1 diff -u -w -b -B -r1.1.1.1 mpc8xx.h --- include/mpc8xx.h 17 Sep 2002 20:57:30 -0000 1.1.1.1 +++ include/mpc8xx.h 3 Jun 2003 21:35:12 -0000 @@ -367,7 +388,7 @@ #define MAMR_G0CLB_A9 0x00006000 /* General Line 0 : A9 */ #define MAMR_G0CLB_A8 0x00008000 /* General Line 0 : A8 */ #define MAMR_G0CLB_A7 0x0000a000 /* General Line 0 : A7 */ -#define MAMR_G0CLB_A6 0x0000b000 /* General Line 0 : A6 */ +#define MAMR_G0CLB_A6 0x0000c000 /* General Line 0 : A6 */ #define MAMR_G0CLB_A5 0x0000e000 /* General Line 0 : A5 */ #define MAMR_GPL_B4DIS 0x00001000 /* GPL_B4 ouput line Disable */ #define MAMR_RLFB_MSK 0x00000f00 /* Read Loop Field B mask */
In message 20030603215854.GA19306@zumanetworks.com you wrote:
On Tue, Jun 03, 2003 at 11:43:36PM +0200, Wolfgang Denk wrote:
Right. Let's have separate #defines for the processors in case we need to really keep them apart (for example, to print a correct id string), and have some central header file which contains something like
#if defined(MPC866P) || \ defined(MPC866T) || \ defined(MPC859T) || \ defined(MPC859DSL) || \ defined(MPC852T) #define MPC866_et_al #endif
I'm working on this now, where should i put this header file and what should I name it?
We have similar styuff already (for CONFIG_TQM8xxL) in "include/common.h", o please add your stuff there, too.
also, this patch is pretty important; typo in mpc8xx.h; you might want this in CVS (also cc'ing to the list):
Added to local tree, will push to CVS later. Thanks.
Best regards,
Wolfgang Denk
On Wed, Jun 04, 2003 at 12:22:25AM +0200, Wolfgang Denk wrote:
In message 20030603215854.GA19306@zumanetworks.com you wrote:
On Tue, Jun 03, 2003 at 11:43:36PM +0200, Wolfgang Denk wrote:
Right. Let's have separate #defines for the processors in case we need to really keep them apart (for example, to print a correct id string), and have some central header file which contains something like
#if defined(MPC866P) || \ defined(MPC866T) || \ defined(MPC859T) || \ defined(MPC859DSL) || \ defined(MPC852T) #define MPC866_et_al #endif
I'm working on this now, where should i put this header file and what should I name it?
We have similar styuff already (for CONFIG_TQM8xxL) in "include/common.h", o please add your stuff there, too.
Ok. I've done this, but one unfortunate side effect is that things can't depend on MPC866_et_al in include/configs/[board].h ... the user will have to make sure things are correct for a given board. Opinions?
I'm getting close to another patch set, should be done by the end of the week (pending a few other unresolved issues, which I will summarize when im done).
also, the MAMR/MBMR -> MxMR patch set I will be putting off indefinitely, the amount of work involved in changing all the include/configs is pretty daunting.
warmest regards, Nye
In message 20030609225816.GA21925@zumanetworks.com you wrote:
Ok. I've done this, but one unfortunate side effect is that things can't depend on MPC866_et_al in include/configs/[board].h ... the user will have to make sure things are correct for a given board. Opinions?
Well, this seems acceptable: the user should ALWAYS make sure things are correct for a given board.
I'm getting close to another patch set, should be done by the end of the week (pending a few other unresolved issues, which I will summarize when im done).
Is there anything important in this patch set? I mean important enough to wait with the next release?
also, the MAMR/MBMR -> MxMR patch set I will be putting off indefinitely, the amount of work involved in changing all the include/configs is pretty daunting.
I have to admit that I'm not really surprised ;-)
Best regards,
Wolfgang Denk
participants (2)
-
Nye Liu -
Wolfgang Denk