[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