[U-Boot] [RFC PATCH] common: board_f: Make reserve_mmu a weak function

[Michal Simek]

On 19.7.2017 11:11, York Sun wrote:
> 
>> On Jul 19, 2017, at 16:25, Michal Simek <michal.simek at xilinx.com> wrote:
>>
>>> On 19.7.2017 04:18, York Sun wrote:
>>>> On 07/18/2017 10:59 PM, Michal Simek wrote:
>>>> Hi Simon,
>>>>
>>>>> On 18.7.2017 16:50, Simon Glass wrote:
>>>>> Hi Michal,
>>>>>
>>>>>> On 18 July 2017 at 07:23, Michal Simek <michal.simek at xilinx.com> wrote:
>>>>>> Hi Simon,
>>>>>>
>>>>>>> On 18.7.2017 16:01, Simon Glass wrote:
>>>>>>> Hi Michal,
>>>>>>>
>>>>>>>> On 13 July 2017 at 06:50, Michal Simek <michal.simek at xilinx.com> wrote:
>>>>>>>> From: Siva Durga Prasad Paladugu <siva.durga.paladugu at xilinx.com>
>>>>>>>>
>>>>>>>> Make reserve_mmu a weak so that it provides an option
>>>>>>>> to customize this routine as per platform need
>>>>>>>
>>>>>>> Why do you need this? Can we instead have the generic code do the
>>>>>>> right thing? Or can we use reserve_arch() to handle this?
>>>>>>
>>>>>> reserve_mmu is called just for ARM.
>>>>>
>>>>> What arch are you using?
>>>>
>>>> arm64 - a53s
>>>>
>>>>>
>>>>>> What we need to do is support configuration where we have small memory
>>>>>> OCM and we need to put mmu table to different location (TCM) because it
>>>>>> is simply big and it can't be placed where it is placed now.
>>>>>
>>>>> What is TCM? Is this the internal SRAM?
>>>>
>>>> It is internal sram which is used mostly by R5s in the system but a53
>>>> has also access to it.
>>>>
>>>>>
>>>>> I don't understand 'simply big'. Are you saying it is too big to go
>>>>> into main memory?
>>>>
>>>> These configuration can't use DDR. One of that configuration which we
>>>> are using is DDR memory test. It means you run from internal sram (256kB
>>>> OCM + 256k TCM).
>>>> Another configuration is for loading stuff to EMMC on different boards.
>>>> It means you don't need to setup DDR for generic emmc programming.
>>>>
>>>> All these configurations are using console over DCC - arm jtag uart.
>>>>
>>>>>
>>>>>>
>>>>>> Based on looking at code the key question is if we can call reserve_mmu
>>>>>> at that time when reserve_arch is called now.
>>>>>> On zynqmp I can't see any issue to allocate tlb on the stack and call it
>>>>>> from it. The question is if this is valid for all arms.
>>>>>>
>>>>>> This is just a small hack I have created to move it to stack.
>>>>>>
>>>>>>  diff --git a/common/board_f.c b/common/board_f.c
>>>>>>  index 88e20e0168b2..32386c957962 100644
>>>>>>  --- a/common/board_f.c
>>>>>>  +++ b/common/board_f.c
>>>>>>  @@ -433,13 +433,13 @@ __weak int reserve_mmu(void)
>>>>>>   {
>>>>>>          /* reserve TLB table */
>>>>>>          gd->arch.tlb_size = PGTABLE_SIZE;
>>>>>>  -       gd->relocaddr -= gd->arch.tlb_size;
>>>>>>  +       gd->start_addr_sp -= gd->arch.tlb_size;
>>>>>>
>>>>>>          /* round down to next 64 kB limit */
>>>>>>  -       gd->relocaddr &= ~(0x10000 - 1);
>>>>>>  +       gd->start_addr_sp &= ~(0x10000 - 1);
>>>>>>
>>>>>>  -       gd->arch.tlb_addr = gd->relocaddr;
>>>>>>  -       debug("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
>>>>>>  +       gd->arch.tlb_addr = gd->start_addr_sp;
>>>>>>  +       printf("TLB table from %08lx to %08lx\n", gd->arch.tlb_addr,
>>>>>>                gd->arch.tlb_addr + gd->arch.tlb_size);
>>>>>>
>>>>>>   #ifdef CONFIG_SYS_MEM_RESERVE_SECURE
>>>>>>  @@ -837,7 +837,7 @@ static int initf_dm(void)
>>>>>>   /* Architecture-specific memory reservation */
>>>>>>   __weak int reserve_arch(void)
>>>>>>   {
>>>>>>  -       return 0;
>>>>>>  +       return reserve_mmu();
>>>>>>   }
>>>>>>
>>>>>>   __weak int arch_cpu_init_dm(void)
>>>>>>  @@ -998,10 +998,6 @@ static init_fnc_t init_sequence_f[] = {
>>>>>>          reserve_pram,
>>>>>>   #endif
>>>>>>          reserve_round_4k,
>>>>>>  -#if !(defined(CONFIG_SYS_ICACHE_OFF) &&
>>>>>> defined(CONFIG_SYS_DCACHE_OFF)) && \
>>>>>>  -               defined(CONFIG_ARM)
>>>>>>  -       reserve_mmu,
>>>>>>  -#endif
>>>>>>   #ifdef CONFIG_DM_VIDEO
>>>>>>          reserve_video,
>>>>>>   #else
>>>>>>
>>>>>> For us we can't just rewrite tlb addresses as we want to do because we
>>>>>> can't allow reserve_mmu to allocate 64kB alied PGTABLE_SIZE in
>>>>>> relocation structure.
>>>>>
>>>>> Why not?
>>>>
>>>> Because we need to fit to 256kB of memory also with relocation and also
>>>> space for data. And IIRC MMU table size is 64kB.
>>>> Another option could be to disable relocation.
>>>>
>>> Michal,
>>>
>>> For your reference, we use two stage MMU setup for FSL ARMv8 SoCs. We 
>>> setup an early MMU in arch_cpu_init() so we can enable d-cache very 
>>> early to speed up execution. 
>>
>> How big is this speed up?
> 
> Huge improvement (feeling like 10x faster at least), especially on emulators. 

ok. It means on real silicon I see that improvement could be till a
second right?

Thanks,
Michal