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

[Scott Harper]

I have it up and working on the MPPC8540ADS.  I am using the latest cvs and 
have added the June 17th patch.

Some minor changes to the MPC8540ADS.h  that reflect my board.  

Thank you all for your help.

Scott



 On Tuesday 29 June 2004 09:33, Jon Loeliger wrote:
> 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
>
>
>
>
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Briefings & Training.
> Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
> digital self defense, top technical experts, no vendor pitches,
> unmatched networking opportunities. Visit www.blackhat.com
> _______________________________________________
> U-Boot-Users mailing list
> U-Boot-Users at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/u-boot-users