ppc440 caches - change proposal [RFC]

ppc440 caches - change proposal [RFC]

[John Bonesio]

Hi all,

We've discovered something interesting when not using a bootloader such as uboot to start Linux.

The Linux kernel seems to be depending on the bootloader to set up the ppc440 cache control registers, ivlim and dvlim, to set up the Normal and Transient areas in the caches. When a separate bootloader is not used, these cache control registers have random values.

I can think of a couple reasons why somone might not want to use a separate bootloader. Their device could be so small that there's not enough flash to store booth the bootloader, the kernel image, and other things they need in flash. They could want to improve bootup time for their device.

I was thinking it might be good to have the kernel initialize these cache control registers in it's own start up code. Or perhaps this could be done in the kernel's simple bootloader. We could probably put this change in a Xilinx specific startup file, but this change doesn't seem specific to Xilinx FPGA boards.

Thoughts?

- John

Re: ppc440 caches - change proposal [RFC]

[Benjamin Herrenschmidt]

On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
> I was thinking it might be good to have the kernel initialize these
> cache control registers in it's own start up code. Or perhaps this
> could be done in the kernel's simple bootloader. We could probably put
> this change in a Xilinx specific startup file, but this change doesn't
> seem specific to Xilinx FPGA boards.

The kernel's wrapper would be a good place to put that I suspect. That's
the kind of thing that should be provided as a "library" function to be
optionally called by platform code. Either in the wrapper or the main
kernel platform code.

Cheers,
Ben.

Re: ppc440 caches - change proposal [RFC]

[Grant Likely]

On Tue, Apr 8, 2008 at 4:56 PM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
>
>  On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
>  > I was thinking it might be good to have the kernel initialize these
>  > cache control registers in it's own start up code. Or perhaps this
>  > could be done in the kernel's simple bootloader. We could probably put
>  > this change in a Xilinx specific startup file, but this change doesn't
>  > seem specific to Xilinx FPGA boards.
>
>  The kernel's wrapper would be a good place to put that I suspect. That's
>  the kind of thing that should be provided as a "library" function to be
>  optionally called by platform code. Either in the wrapper or the main
>  kernel platform code.

Code is already queued up for 2.6.26 to do exactly this on ppc405
virtex platforms.  We can do the same thing for 440.  Look at
virtex405-head.S in the following patch:

http://patchwork.ozlabs.org/linuxppc/patch?person=486&id=17410

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: ppc440 caches - change proposal [RFC]

[Josh Boyer]

On Tue, 8 Apr 2008 17:15:44 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:

> On Tue, Apr 8, 2008 at 4:56 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> >  On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
> >  > I was thinking it might be good to have the kernel initialize these
> >  > cache control registers in it's own start up code. Or perhaps this
> >  > could be done in the kernel's simple bootloader. We could probably put
> >  > this change in a Xilinx specific startup file, but this change doesn't
> >  > seem specific to Xilinx FPGA boards.
> >
> >  The kernel's wrapper would be a good place to put that I suspect. That's
> >  the kind of thing that should be provided as a "library" function to be
> >  optionally called by platform code. Either in the wrapper or the main
> >  kernel platform code.
> 
> Code is already queued up for 2.6.26 to do exactly this on ppc405
> virtex platforms.  We can do the same thing for 440.  Look at
> virtex405-head.S in the following patch:
> 
> http://patchwork.ozlabs.org/linuxppc/patch?person=486&id=17410

That patch is already in Paul's tree btw.

As for 440, yes it might be good to init the cache registers in the
wrapper.

josh

Re: ppc440 caches - change proposal [RFC]

[John Bonesio]

Hi Grant,

I have a question about your patch. It appears as if the cache setup code is in a file that would be used only on Xilinx FPGA devices.

I understand that many people are using a bootloader that already sets up the cache for the kernel, but I'm wondering if Xilinx boards are really a special case, or if there may be other non-Xilinx related systems that would also not be using a bootloader.

I also understand the desire to avoid code that does the same work more than once, but I wonder if in this case, it's creating too strong a dependence on the specific behavior of a certain bootloader.
I also wonder if arch/powerpc is being made more complex by trying to split out this code change into a Xilinx specific area, when the change could just be rolled into head_40x.S and we could do away with virtex405-head.S.

Just some thoughts,

- John

On Tuesday 08 April 2008 16:15, you wrote:
> On Tue, Apr 8, 2008 at 4:56 PM, Benjamin Herrenschmidt
> <benh@kernel.crashing.org> wrote:
> >
> >  On Tue, 2008-04-08 at 15:53 -0700, John Bonesio wrote:
> >  > I was thinking it might be good to have the kernel initialize these
> >  > cache control registers in it's own start up code. Or perhaps this
> >  > could be done in the kernel's simple bootloader. We could probably put
> >  > this change in a Xilinx specific startup file, but this change doesn't
> >  > seem specific to Xilinx FPGA boards.
> >
> >  The kernel's wrapper would be a good place to put that I suspect. That's
> >  the kind of thing that should be provided as a "library" function to be
> >  optionally called by platform code. Either in the wrapper or the main
> >  kernel platform code.
> 
> Code is already queued up for 2.6.26 to do exactly this on ppc405
> virtex platforms.  We can do the same thing for 440.  Look at
> virtex405-head.S in the following patch:
> 
> http://patchwork.ozlabs.org/linuxppc/patch?person=486&id=17410
> 
> Cheers,
> g.
> 
> 
> -- 
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> 
> 

Re: ppc440 caches - change proposal [RFC]

[Grant Likely]

On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio <john.bonesio@xilinx.com> wrote:
> Hi Grant,
>
>  I have a question about your patch. It appears as if the cache setup code is
> in a file that would be used only on Xilinx FPGA devices.

That is correct.

>
>  I understand that many people are using a bootloader that already sets up the
> cache for the kernel, but I'm wondering if Xilinx boards are really a special
> case, or if there may be other non-Xilinx related systems that would also not
> be using a bootloader.

I think there are very few cases of platforms not using some form of firmware.

>
>  I also understand the desire to avoid code that does the same work more than
> once, but I wonder if in this case, it's creating too strong a dependence on
> the specific behavior of a certain bootloader.
>  I also wonder if arch/powerpc is being made more complex by trying to split
>  out this code change into a Xilinx specific area, when the change could just
> be rolled into head_40x.S and we could do away with virtex405-head.S.

In general, I think that the wrapper does not want to touch the cache
settings.  In the common case where firmware exists and sets up the
cache then to turn off the cache again would throw away what firmware
already had in cache and slow down the boot.

That being said, I'm not the bootwrapper expert.  If other think that
it belongs in head_40x.S then I have no objections.

Josh, any thoughts?

Cheers,
g.


-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.

Re: ppc440 caches - change proposal [RFC]

[Josh Boyer]

On Wed, 9 Apr 2008 13:50:43 -0600
"Grant Likely" <grant.likely@secretlab.ca> wrote:

> On Wed, Apr 9, 2008 at 12:00 PM, John Bonesio <john.bonesio@xilinx.com> wrote:
> >  I understand that many people are using a bootloader that already sets up the
> > cache for the kernel, but I'm wondering if Xilinx boards are really a special
> > case, or if there may be other non-Xilinx related systems that would also not
> > be using a bootloader.
> 
> I think there are very few cases of platforms not using some form of firmware.

Indeed.

> >  I also understand the desire to avoid code that does the same work more than
> > once, but I wonder if in this case, it's creating too strong a dependence on
> > the specific behavior of a certain bootloader.
> >  I also wonder if arch/powerpc is being made more complex by trying to split
> >  out this code change into a Xilinx specific area, when the change could just
> > be rolled into head_40x.S and we could do away with virtex405-head.S.
> 
> In general, I think that the wrapper does not want to touch the cache
> settings.  In the common case where firmware exists and sets up the
> cache then to turn off the cache again would throw away what firmware
> already had in cache and slow down the boot.
> 
> That being said, I'm not the bootwrapper expert.  If other think that
> it belongs in head_40x.S then I have no objections.
> 
> Josh, any thoughts?

This may or may not be OK.  In the general case, I think Grant is right
in that the wrapper tends to avoid mucking with cache settings that
were already setup by the firmware.

For 405 specifically, it could go either way.  And we actually already
ignore the cache settings for real mode anyway once it gets to
MMU_init_hw, but I wouldn't be surprised if an assumption was made
there as well.

josh