Dear Aneesh V,
In message 4DD27819.7010600@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 ;-)
- 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?
- 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