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

Paul Walmsley
2007-11-16T19:33:43Z

Hi Richard,

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.

> - 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.

Thanks for the review.

- Paul