[U-Boot] CONFIG_MP affects ability to erase upper portions of flash on 8572
Hi everyone,
I just wanted to share something that I discovered with our 8572-based board. The board's 4Mbyte flash is mapped starting at address 0xFFC00000. When moving to U-boot v2008-10, I discovered that I had lost the ability to erase the entire flash (in order to update the U-boot binary). After the erase operation, the flash device would contain the erased value, 0xFF, up to the address 0xFFFFF000 with non-FF data after that point. After some investigation, it appears that defining the macro CONFIG_MP was causing the issue. With CONFIG_MP not defined, the entire upper portion of flash could be verified as erased. My guess is that it has something to do with the start page for the secondary processor. Ultimately, the solution for me was to move the flash from 0xFFC00000 to 0xEFC00000 and all was well with CONFIG_MP defined.
Scott
___________________________________________________________________
Scott N. Coulter Senior Software Engineer
Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com U.S.A. Web: http://www.cyclone.com ___________________________________________________________________
On Feb 5, 2009, at 1:16 PM, Scott Coulter wrote:
Hi everyone,
I just wanted to share something that I discovered with our 8572-based board. The board's 4Mbyte flash is mapped starting at address 0xFFC00000. When moving to U-boot v2008-10, I discovered that I had lost the ability to erase the entire flash (in order to update the U-boot binary). After the erase operation, the flash device would contain the erased value, 0xFF, up to the address 0xFFFFF000 with non-FF data after that point. After some investigation, it appears that defining the macro CONFIG_MP was causing the issue. With CONFIG_MP not defined, the entire upper portion of flash could be verified as erased. My guess is that it has something to do with the start page for the secondary processor. Ultimately, the solution for me was to move the flash from 0xFFC00000 to 0xEFC00000 and all was well with CONFIG_MP defined.
Scott
This is correct. As the only 8572 board that exists in the u-boot tree is for the Freescale MPC8572DS I didn't query anyone else on possible impact of the change.
- k
Kumar,
This is correct. As the only 8572 board that exists in the u-boot tree is for the Freescale MPC8572DS I didn't query anyone else on possible impact of the change.
Certainly not a problem. Moving the flash address was relatively painless. I just wanted to post in case someone bumps into this issue down the line.
Scott
___________________________________________________________________
Scott N. Coulter Senior Software Engineer
Cyclone Microsystems 370 James Street Phone: 203.786.5536 ext. 118 New Haven, CT 06513-3051 Email: scott.coulter@cyclone.com U.S.A. Web: http://www.cyclone.com ___________________________________________________________________
On Fri, 2009-02-06 at 10:51 -0500, Scott Coulter wrote:
Kumar,
This is correct. As the only 8572 board that exists in the u-boot tree is for the Freescale MPC8572DS I didn't query anyone else on possible impact of the change.
Certainly not a problem. Moving the flash address was relatively painless. I just wanted to post in case someone bumps into this issue down the line.
I ran into the same issue on the XPedite5370 which also uses the 8572. I worked around it initially by disabling CONFIG_MP. I was recently working on an 86xx board and it has the same issue as well when CONFIG_NUM_CPUS > 1.
We try and use the same memory layout (which unfortunately has flash at the top of memory) on all our boards so I'll send a patch to fix this issue at some point unless someone beats me too it:)
Best, Peter
participants (3)
-
Kumar Gala -
Peter Tyser -
Scott Coulter