[U-Boot-Users] mpc8245 changed from u-boot-1.0.0 to uboot-1.0.2
Hi all, I've run into a problem on our board with the latest u-boot-1.0.2. Prior to this problem u-boot-1.0.0 worked flawlessly. So I am assuming the problem is from a change between those two versions.
The problem is pretty simple, when u-boot is copying itself from flash to ram it does not get copied correctly. If I step through the copying of u-boot from flash to ram it copies fine, however if I let it copy at full speed it does not get copied correctly. It seems like a memory timing issue. But nothing has changed in cpu/mpc824x/cpu_init.c. I've briefly looked through everything and I have not discovered any obvious changes that could be causing this problem.
So I was hoping someone has seen something similar recently with their mpc824x boards? Or if anyone else has any ideas about something that might have changed?
Thanks, Matthew
Matthew S. McClintock wrote:
Hi all,
I've run into a problem on our board with the latest u-boot-1.0.2. Prior to this problem u-boot-1.0.0 worked flawlessly. So I am assuming the problem is from a change between those two versions.
The problem is pretty simple, when u-boot is copying itself from flash to ram it does not get copied correctly. If I step through the copying of u-boot from flash to ram it copies fine, however if I let it copy at full speed it does not get copied correctly....
I've used U-Boot on the Artis SBC-A3000, which is based on the MPC8245. I downloaded U-Boot 1.0.2 and compiled it with ELDK 2.0.2. I was unable to recreate this problem--the board boots and starts Linux with no apparent problems.
-Robert
Some files where changed in our board directory, I am not sure how or why they were changed. I do not see a mention of it in the changelog. Attached is a patch correcting the problem, Wolfgang could you please apply it?
Thanks, Matthew
On Sat, 2004-03-27 at 18:00, DeLaGarza, Robert wrote:
Matthew S. McClintock wrote:
Hi all,
I've run into a problem on our board with the latest u-boot-1.0.2. Prior to this problem u-boot-1.0.0 worked flawlessly. So I am assuming the problem is from a change between those two versions.
The problem is pretty simple, when u-boot is copying itself from flash to ram it does not get copied correctly. If I step through the copying of u-boot from flash to ram it copies fine, however if I let it copy at full speed it does not get copied correctly....
I've used U-Boot on the Artis SBC-A3000, which is based on the MPC8245. I downloaded U-Boot 1.0.2 and compiled it with ELDK 2.0.2. I was unable to recreate this problem--the board boots and starts Linux with no apparent problems.
-Robert
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
I'm sorry ignoring that last patch it still had crud in it, here is the patch to apply.
Matthew
On Thu, 2004-04-01 at 10:02, Matthew S. McClintock wrote:
Some files where changed in our board directory, I am not sure how or why they were changed. I do not see a mention of it in the changelog. Attached is a patch correcting the problem, Wolfgang could you please apply it?
Thanks, Matthew
On Sat, 2004-03-27 at 18:00, DeLaGarza, Robert wrote:
Matthew S. McClintock wrote:
Hi all,
I've run into a problem on our board with the latest u-boot-1.0.2. Prior to this problem u-boot-1.0.0 worked flawlessly. So I am assuming the problem is from a change between those two versions.
The problem is pretty simple, when u-boot is copying itself from flash to ram it does not get copied correctly. If I step through the copying of u-boot from flash to ram it copies fine, however if I let it copy at full speed it does not get copied correctly....
I've used U-Boot on the Artis SBC-A3000, which is based on the MPC8245. I downloaded U-Boot 1.0.2 and compiled it with ELDK 2.0.2. I was unable to recreate this problem--the board boots and starts Linux with no apparent problems.
-Robert
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
In message 1080835333.3255.47.camel@sabrina.arlut.utexas.edu you wrote:
Some files where changed in our board directory, I am not sure how or why they were changed. I do not see a mention of it in the changelog.
The relevant entry in the changelog is this:
Add a common get_ram_size() function and modify the the board-specific files to invoke that common implementation.
Attached is a patch correcting the problem, Wolfgang could you please apply it?
No, I will not. Please make your board use the common code instead.
Best regards,
Wolfgang Denk
Here is the fix as you requested. But this begs the question, can our board specific files change at anytime? And not only be changed but be changed into something that does not work?
I can understand changing code in the rest of u-boot and having that break our board code, but I don't see the problem with our own board code using a depreciated method? Maybe just a note in our board code that a certain method is depreciated would be more appropriate? Is there another reason I am missing?
Matthew
On Thu, 2004-04-01 at 13:29, Wolfgang Denk wrote:
In message 1080835333.3255.47.camel@sabrina.arlut.utexas.edu you wrote:
Some files where changed in our board directory, I am not sure how or why they were changed. I do not see a mention of it in the changelog.
The relevant entry in the changelog is this:
Add a common get_ram_size() function and modify the the board-specific files to invoke that common implementation.
Attached is a patch correcting the problem, Wolfgang could you please apply it?
No, I will not. Please make your board use the common code instead.
Best regards,
Wolfgang Denk
Ugh, forgot CHANGELOG entry... here is the patch one more time.
On Fri, 2004-04-02 at 10:57, Matthew S. McClintock wrote:
Here is the fix as you requested. But this begs the question, can our board specific files change at anytime? And not only be changed but be changed into something that does not work?
I can understand changing code in the rest of u-boot and having that break our board code, but I don't see the problem with our own board code using a depreciated method? Maybe just a note in our board code that a certain method is depreciated would be more appropriate? Is there another reason I am missing?
Matthew
On Thu, 2004-04-01 at 13:29, Wolfgang Denk wrote:
In message 1080835333.3255.47.camel@sabrina.arlut.utexas.edu you wrote:
Some files where changed in our board directory, I am not sure how or why they were changed. I do not see a mention of it in the changelog.
The relevant entry in the changelog is this:
Add a common get_ram_size() function and modify the the board-specific files to invoke that common implementation.
Attached is a patch correcting the problem, Wolfgang could you please apply it?
No, I will not. Please make your board use the common code instead.
Best regards,
Wolfgang Denk
In message 1080925072.4706.13.camel@sabrina.arlut.utexas.edu you wrote:
Here is the fix as you requested. But this begs the question, can our board specific files change at anytime? And not only be changed but be changed into something that does not work?
Actually this can happen any time. It is pretty unlikely, though.
But as maintainer of the U-Boot project I will occasionally decide to check in patches which may effect board specific code, too.
To perform a global clean-up operations, for example to eliminate redundand code and replace it by a common implementation like in this case, I have no other choice but to implement this change everywhere and for every board. Of course we try to test on as many different boards as possible, but we cannot test on all boards.
Although never put down in writing I consider it one of the responsibilities of a board maintainer to check current versions every now and then - and this definitely means more frequently than once every three months.
I can understand changing code in the rest of u-boot and having that break our board code, but I don't see the problem with our own board code using a depreciated method? Maybe just a note in our board code
Experience has shown that it simply does not work to change the im- plementation or to provide new interfaces and simpy hope that all board maintainers will adapt these changes in a resonable time. Others staring with a new port will are guaranteed to pick up such old files as model, and continue to use the old stuff.
The only way to get consistent code is to enforce the change for all boards.
In your case it took nearly 3 months until you even noticed that something was changed.
that a certain method is depreciated would be more appropriate? Is there another reason I am missing?
Guess how many board maintainers will change working code just because there is another way to do it?
Sorry, but in my experience this doesn't work.
I apologize for breaking your board.
Now for your patch:
/* This code does not work, and needs to be fixed at a laterdate */
Do you really want me to check this in? I feel you should spend some more time and fix the code first and submit a new patch then.
Best regards,
Wolfgang Denk
Now for your patch:
/* This code does not work, and needs to be fixed at a laterdate */Do you really want me to check this in? I feel you should spend some more time and fix the code first and submit a new patch then.
The problem is time, no one has anytime to invest in the problem at the moment. I've put the marker there so if someone else here needs that functionality to work they will take the time to fix the problem (and they will also quickly find what the problem is). I think the advantage of having the latest u-boot working outweighs the incorrect code at the moment considering all other factors.
Thanks, Matthew
Is there a U-boot for MPC8560 processor based target?. We need to build a u-boot for 8560 based wind river board.
Thanks -Kodis
In message 6.0.0.22.2.20040405141129.01c5f400@jittlov.qualcomm.com you wrote:
Is there a U-boot for MPC8560 processor based target?. We need to build a u-boot for 8560 based wind river board.
Yes, there is.
Why do you post your question under a completely unrelated subject??
Please don't do that!
Best regards,
Wolfgang Denk
You should not reply to messages and start a new topic, instead make new topic for discussion.
And to answer you question, yes there is one board for the mpc8560 checked into u-boot that you could use as a starting point for your new board. The board name is mpc8560ads if your interested in looking into that.
Matthew
On Mon, 2004-04-05 at 16:13, Kodis Babu Janardhanan wrote:
Is there a U-boot for MPC8560 processor based target?. We need to build a u-boot for 8560 based wind river board.
Thanks -Kodis
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
My mistake, I forgot to change the subject line.
-Kodis
At 02:13 PM 4/5/2004, Kodis Babu Janardhanan wrote:
Is there a U-boot for MPC8560 processor based target?. We need to build a u-boot for 8560 based wind river board.
Thanks -Kodis
This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ U-Boot-Users mailing list U-Boot-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/u-boot-users
On Fri, 2004-04-02 at 12:05, Wolfgang Denk wrote:
Now for your patch:
/* This code does not work, and needs to be fixed at a laterdate */Do you really want me to check this in? I feel you should spend some more time and fix the code first and submit a new patch then.
Attached is a new, working, patch. Could you please apply it when you have time?
Thanks, Matthew
In message 1081955666.31819.5.camel@sabrina.arlut.utexas.edu you wrote:
+* Patch by Matthew McClintock, 14 April 2004
- fix initdram function for utx8245 board
Added, thanks.
Best regards,
Wolfgang Denk
participants (5)
-
Dan Malek -
DeLaGarza, Robert -
Kodis Babu Janardhanan -
Matthew S. McClintock -
Wolfgang Denk