On 04/01/2012 12:33, Aneesh V wrote:
Hi Stefano,
Hi,
On Wednesday 04 January 2012 09:25 AM, Stefano Babic wrote:
Signed-off-by: Stefano Babicsbabic@denx.de CC: Tom Rinitom.rini@gmail.com CC: Wolfgang Denkwd@denx.de CC: Simon Schwarzsimonschwarzcor@gmail.com
Changes since V11:
- enable cache files in Makefile after checking build for OMAP4/5
How are you allocating memory for the page-tables(gd->tlb_addr)? Also we need to take care of the complexities when u-boot runs after SPL.
I know, and the patch can be considered a preparation for adding d-cache later - dcache is not enabled at all in this patchset. At the moment, cleanup_before_linux() is called as in U-Boot, but caches are already disabled. I know memory for the page tables must be reserved, but this part is not yet done.
Please have a look at this.
http://article.gmane.org/gmane.comp.boot-loaders.u-boot/100012/match=spl+cac...
I am aware of this. And this is also the reason I see caches as a second-step approach. Firstly, we should have a way to boot linux directly from SPL, without enabling cache. Then we have the possibility to increase the mumber of our testers, because, as far as I know, only me and Simon have tried with this patchset to get some measurement.
In my current tests on the twister board (AM3517 based), most time is spent really to load the kernel (~2MB, with a lot of drivers..). As answer to your point 1 in the previous thread, maybe it is really worth to enable cache to speed up the loading part respecting enabling DMA. Adding DMA means adding DMA support in each specific driver (NAND vs MMC vs..), while with d-cache we have a solution working independenlty from the supported media. But it makes sense to have a large number of boards supporting direct booting before making some wrong assumptions ;-)
Best regards, Stefano Babic