Hi Masahiro, On 6 September 2014 09:34, Masahiro YAMADA <yamad...@jp.panasonic.com> wrote: > Hi Simon, > > > > 2014-09-06 3:59 GMT+09:00 Simon Glass <s...@chromium.org>: >> Hi Masahiro, >> >> On 4 September 2014 23:50, Masahiro Yamada <yamad...@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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot