[U-Boot-Users] Re: MPPC8560ADS and U-Boot 1.1.1 problems ?
Scott Harper writes:
Scott> I am working with the MPPC8540ADS and I am having problems.
Scott> I have followed the discussion about the MPPC8560ADS and have Scott> tried the top of the CVS tree.
Scott> I have the following undefined. Note I have defined these in Scott> include/asm-ppc/processor.h
Scott> #define SVR_MAJ SVR_MJREV Scott> #define SVR_MIN SVR_MNREV Scott> #define SVR_8540 0x80300010 Scott> #define SVR_8560 0x80700010 Scott> #define SVR_8541 0x80b00010 // Just guesses Scott> #define SVR_8555 0x80f00010 // Just guesses
Scott> #define PVR_85xx_REV1 0x80200010 Scott> #define PVR_85xx_REV2 0x80200020 Scott> #define PVR_85xx 0x80200020
Scott> My problem is that I am stuck looping through at 0xfff81400 Scott> <DataTLBError>
Scott> I have other software working on the board so I am pretty sure Scott> that the board works. My chip is a REV2.
Scott> I would appreciate any help any one has.
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 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.
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 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. We'll be just removing each other's code.
Hope this helps,
Thanx for all your help guys, just one more question ....
Do you's know whether all these patches/information are relevant for Rev 1 of the silicon ?
Cheers, Rob Farmer Senior Software Engineer Accton Technology Ltd UK
Tel: +44 (0) 8700 990400 Fax: +44 (0) 8700 990401 Cell: +44 (0) 7791 509347
In message 16609.9367.682834.887803@gargle.gargle.HOWL you wrote:
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
Which is perfectly OK (and often a good idea).
of the U-Boot's code. I moved the environment to (CFG_MONITOR_BASE - 0x40000) and now it's OK.
OK as a temporary (read: quick & dirty) work-aroud, but not acceptable for check-in.
[Just to avoid misunderstandings.]
Best regards,
Wolfgang Denk
Wolfgang Denk writes:
Wolfgang> In message 16609.9367.682834.887803@gargle.gargle.HOWL Wolfgang> you wrote:
Yuli> function. After making these changes, I was able to compile Yuli> and run the U-Boot ... until the first saveenv command. A Yuli> quick look into the configuration file showed that the Yuli> environment is placed in the middle
Wolfgang> Which is perfectly OK (and often a good idea).
... if it's embedded environment, usually on variable sector size flashes. It's not the case.
Yuli> of the U-Boot's code. I moved the environment to Yuli> (CFG_MONITOR_BASE - 0x40000) and now it's OK.
Wolfgang> OK as a temporary (read: quick & dirty) work-aroud, but Wolfgang> not acceptable for check-in.
Just as most of the described changes. As I wrote, I'm waiting for Jon's patch to resolve all the issues cleanly.
Wolfgang> [Just to avoid misunderstandings.]
If you can suggest another place I'll be glad to use it. The U-Boot occupies two last sectors of the flash (BTW, one is enough) so you can't put the environment after U-Boot as it's usually done. You can't embed it either (unless you want to continue allocating 512KB for the U-Boot) because embedding would mix code and environment in one sector which is unsafe.
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
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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
On Tue, 2004-06-29 at 15:56, Scott Harper wrote:
I have it up and working on the MPPC8540ADS. I am using the latest cvs and have added the June 17th patch.
This is good to know!
Some minor changes to the MPC8540ADS.h that reflect my board.
Thank you all for your help.
Most welcome.
Please let me know if you stumble across other problems or pitfalls.
Note that I am still working on a few things here:
- An improved version of a DDR initialization for large memory - Errata fixes that allow for faster parts and SDRAM initialization - Minor PCI fixes
Scott
Thanks, jdl
Jon Loeliger writes:
...
Yuli> A note about building the U-Boot. I don't what tool chain Yuli> you're using but if it's not Freescale-tweaked GCC 2.95 you Yuli> probably will have a problem because target CPU type is Yuli> missing from cpu/mpc85xx/config.mk. I added `-mcpu=8540 Yuli> -mno-string' to PLATFORM_RELFLAGS.
Jon> I have used both native and cross compilers, and versions 2.95, Jon> 3.2 and 3.3. 3.4 is being addressed still.
So probably your compiler was configured with different defaults. I use 3.3.2 and by default it emits string instructions which are OK for other PPCs but not for e500. I think that specifying target CPU in the Makefile is good idea because the compiler defaults can vary.
participants (5)
-
Jon Loeliger -
Rob Farmer -
Scott Harper -
Wolfgang Denk -
Yuli Barcohen