[U-Boot-Users] Re: MPPC8560ADS and U-Boot 1.1.1 problems ?

[Jon Loeliger]

On Tue, 2004-06-29 at 03:13, Yuli Barcohen wrote:

> Jon> Excellent.  So you have applied the patch of 17-June-2004 as well,
> Jon> right?  It is necessary as the top-of-CVS is broken and will not
> Jon> compile as it is now.
> 
> Wolfgang already described the patch when tried to apply it so I doubt
> it would help.

I may not be understanding what you are saying here,
but I believe  you don't understand the sequence of
events properly.

I submitted 8540/8560 ADS patches.  They contained a few bogus
changes.  Parts of that patch were applied to the top of CVS
by Wolfgang.  Wolfgang then stopped mid-way through my first
set of patches.  This left the top of CVS broken WRT 8540/60 ADS.

Wolfgang asked me to clean it up.  I worked up a new set
of patches that need to be applied to the top of CVS to
rectify the partially applied patch.  I submitted that patch
as the 17-June-2004 patch.  This patch has not been applied
to the CVS tree yet.

One must apply that patch to clean things up and make the 8540
and 8560 ADS work at all.


>  I work with MPC8560ADS and I managed to get working
> U-Boot from the CVS top with some changes. Maybe some of the changes are
> included in the patch, I didn't check. It looks like they can be
> relevant for 8540 too but I haven't got the hardware to verify this
> assumption. First of all, I changed the memory map to make it consistent
> with the README, i.e.
> 
> #define CFG_CCSRBAR		0xE0000000
> #define CFG_LBC_SDRAM_BASE	0xf0000000
> #define CFG_PCI_MEM_BASE	0x80000000
> #define CFG_PCI_MEM_PHYS	0x80000000
> #define CFG_PCI_MEM_SIZE	0x20000000
> #define CFG_PCI_IO_BASE         0xe2000000
> #define CFG_RAPID_IO_BASE       0xc0000000
> 
> Then I noted that TSEC initialisation (tsec_initialize in
> cpu/mpc85xx/tsec.c) is defined with two parameters but called with
> one. I just hard-coded the missing parameter (TSEC number) to zero. I
> also commented out all the version check code in checkcpu
> function. After making these changes, I was able to compile and run the
> U-Boot ... until the first saveenv command. A quick look into the
> configuration file showed that the environment is placed in the middle
> of the U-Boot's code. I moved the environment to (CFG_MONITOR_BASE -
> 0x40000) and now it's OK.

Yeah, all that stuff, oddly enough, is in the patch I sent in.

> A note about building the U-Boot. I don't what tool chain you're using
> but if it's not Freescale-tweaked GCC 2.95 you probably will have a
> problem because target CPU type is missing from cpu/mpc85xx/config.mk. I
> added `-mcpu=8540 -mno-string' to PLATFORM_RELFLAGS.

I have used both native and cross compilers, and versions 2.95, 3.2 and
3.3.  3.4 is being addressed still.

> I could submit a patch cleaning up all this (and many other things) but
> IMHO preparing a patch against current CVS top does not make sense
> because Jon is working on a new version of his patch.

Agreed.

>  We'll be just
> removing each other's code.

Please apply my patch first, or wait for it to be applied to the
CVS tree.  Then let me know what (if anything) is broken _after_ that.

Thanks,
jdl