Re: [PATCH 0/5] SRAM patcher: patch register addresses in SRAM code atruntime

Tony Lindgren
2007-11-16T22:35:20Z

* Woodruff, Richard <r-woodruff2@ti.com> [071116 11:48]:
> Hi Paul,
>
> > On Wed, 14 Nov 2007, Woodruff, Richard wrote:
> >
> > > -*- This code as written today likely won't be used on OMAP3 anyway as
> > > the DVFS procedure will be different. The SRAM code usage can be much
> > > smaller and should also be different.
> > > The aim of making it single kernel for OMAP2 to OMAP3 in this case is
> > > just using the SRAM function for pushing the correct SRAM routine.
> >
> > Yeah, agreed. The main motivation was to share 2420/2430 code here. I'm
> > hoping that there may be some 3430 sharing that can be done also, perhaps
> > some of the SDRAM timing change code, but there's probably other code that
> > won't be sharable without contortions.
>
> Yes it would work here. However, like I was hinting there is another method which 2430's which have been characterized, could try. But that is something else.
>
> > > - Well that does look fine. It kind of feels like a gratuitous cache
> > > range flush should be added. But as its all data side patches it
> > > probably can live with out it. The initial code copy should probably
> > > have this. Caches are VIPT, which means you almost don't have to flush,
> > > but you still do, but it can be in a more optimal way at run time.
> >
> > Want to do a patch for omap_sram_push()? I suppose we're getting away
> > without it now because nothing is running from SRAM before
> > omap_sram_push(), and therefore isn't in I$? sounds like it should be
> > there, though.
>
> It probably needs to be there. The reason for getting away is this is init time stuff not so dynamic, and VIPT means there is only a chance of a conflict. On say an OMAP1 with a VIVT cache it would be a bigger possible problem.
>
> I think in our older images it was non-cached also. In current GIT its MT_MEMORY so it will be.
>
> Its kind of low in things to do today but I might file it away to do. Right now sram only has a push and no pop so its not so dynamic either.

Yeah and we may want to start using SRAM dynamically too at some
point. Pushing Paul's patches today.

Tony