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

York Sun york.sun at nxp.com
Wed Jul 19 11:10:21 UTC 2017


> On Jul 19, 2017, at 19:06, Michal Simek <michal.simek at xilinx.com> wrote:
> 
>> On 19.7.2017 12:10, York Sun wrote:
>> 
>>>> On Jul 19, 2017, at 17:18, Michal Simek <michal.simek at xilinx.com> wrote:
>>>> 
>>>> 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?
>> 
>> It may be several hundreds milliseconds difference on real silicon, depends on core speed and booting device speed and booting method. For example, the NOR flash boot is very slow due to the interface.
> 
> Ok. I see. Time to do some measurements and see if makes sense to invest
> our time to do this. Till now I am not aware about any request to speed
> up u-boot boot time.
> Definitely thanks for pointer.
> 
It makes sense on emulators because they runs thousands times slower. 

York


More information about the U-Boot mailing list