[U-Boot] [PATCH] ppc/85xx: Fix bug in setup_mp code

Peter Tyser ptyser at xes-inc.com
Fri Jan 22 00:27:29 CET 2010


Hi Ed,

On Thu, 2010-01-21 at 15:06 -0700, Swarthout Edward L-SWARTHOU wrote:
> From: Kumar Gala
> 
> > Its possible that we try and copy the boot page code out of flash into
> 
> > a DDR location that doesn't have a TLB cover it.  For example, if we 
> > have 3G of DDR we typically only map the first 2G.  In the cases of 
> > 4G+ this wasn't an issue since the reset page TLB mapping covered the 
> > last page of memory which we wanted to copy to.
> > 
> > We now change the physical address of the reset page TLB to map to the
> 
> > true physical location of the boot page code, copy and than set the 
> > TLB back to its 1:1 mapping of the reset page.
> 
> Why should a boot page TLB still exist?  And if it does exist,
> it may be serving a good purpose and shouldn't be touched.

I imagine Kumar assumed the bootpage was only used for its "intended"
purpose?  Our boards have a large flash mapped on top of the original
bootpage, which caused problems for me too.

> Why not just pick an unused virtual address and map it to bootpg?

You can actually do what you describe since commit
5ccd29c3679b3669b0bde5c501c1aa0f325a7acb.  The CONFIG_BPTR_VIRT_ADDR
feature is enabled for the XPedite5370 in commit
48618126f78f05042dae428811809b594f747eb9.

> This TLB grabbing is giving me problems on my board where I have the
> original 1M bootpage mapped to CPC sram and I want to keep active.

I believe reproducing 48618126f78f05042dae428811809b594f747eb9 for your
board should be a workaround.

Best,
Peter



More information about the U-Boot mailing list