Hi Masahiro,
On 6 September 2014 09:34, Masahiro YAMADA yamada.m@jp.panasonic.com wrote:
Hi Simon,
2014-09-06 3:59 GMT+09:00 Simon Glass sjg@chromium.org:
Hi Masahiro,
On 4 September 2014 23:50, Masahiro Yamada yamada.m@jp.panasonic.com wrote:
init_page_table
Why do you need a full page table in this code? Can you not use the existing page table features in U-Boot?
I assume you mentioned mmu_setup() function in arch/arm/lib/cache-cp15.c. I do know it and actually my boards are using it too.
The hardware specification of UniPhier platform is a little special and unfortunate in terms of RAM / Cache handling. UniPhier SoCs have no on-chip SRAM!
Let's assume U-boot is booting from NOR Flash.
We have to setup the stack before junping to board_f(), but there is no writable memory at this moment on our SoCs. (UniPhier has SDRAMs, of course, but it is intialized in board_f().)
To solve the problem, our SoCs use a trick to have stack on L2Cache. To use cache, MMU must be turned on. (This is ARM specification)
That's why hard-coded, full page table must be placed in the code.
When SDRAM is available, the page table is switched to the one created in arch/arm/lib/cached-cp15.c, but which is much lator (board_r() func.)
OK I see. It is a big hassle not having any SRAM available. Yes maybe this is better than a macro/loop in an assembler file.
Regards, Simon