[U-Boot] [PATCH v3 05/10] armv7: integrate cache maintenance support

[Wolfgang Denk]

Dear Aneesh V,

In message <4DD27819.7010600 at ti.com> you wrote:
> 
> > I was especially talking about the loading from external storage, not
> > primarily relocation.  This will even be mnore important if we had
> > (much) bigger images - like when loading an OS kernel as second stage
> > payload instead of U-Boot.
> 
> Are you talking about enabling D-cache in SPL? Technically, this should

I + D cache, actually.

> be possible as soon as DRAM is initialized(because internal RAMs
> typically do not have enough memory for page-tables(16KB) in addition
> to the SPL itself). But you might want to consider these.

Ah, I see.  Well, you see, I have the big advantage over you that my
imagination is not limited by the ugly details of the real ARM
hardware in question here ;-)

> 1. We need to setup the page tables, invalidate the cache, enable it
> and before jumping to kernel flush and disable it again. Is that all
> worth just for speeding up the loading part? I think one must consider
> DMA for loading the image instead.

If it's available, for sure :-)  But then, for example when loading
from NAND flash (which is probably the most common use case these
days), would DMA help?

> 2. What happens if the payload is U-Boot? You still have the problem of
> flushing. Besides after reaching U-Boot do we setup MMU again or
> not? If we decide to retain the page-tables setup by SPL then U-Boot
> and SPL needs to align on the location of page-tables. This is
> difficult because U-Boot dynamically determines the memory for
> page-tables where as SPL doesn't have such intelligence.  If we decide
> to do the MMU setup again, then it means setting up the page-tables
> twice in the bootloaders!

I guess in the general case we will have to do this twice.  And Linux
will do it again.  It would be nice if we canmake this optional, like
we can avoid the copy operation of the relocation part when we know we
load to the final address (all this keeping in mind the requirements
for ultra short boot times).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Quantum Mechanics is God's version of "Trust me."