On 19.7.2017 13:10, York Sun wrote:
>
>> On Jul 19, 2017, at 19:06, Michal Simek <michal.si...@xilinx.com> wrote:
>>
>>> On 19.7.2017 12:10, York Sun wrote:
>>>
>>>>> On Jul 19, 2017, at 17:18, Michal Simek <michal.si...@xilinx.com> wrote:
>>>>>
>>>>> On 19.7.2017 11:11, York Sun wrote:
>>>>>
>>>>>>> On Jul 19, 2017, at 16:25, Michal Simek <michal.si...@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.si...@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.si...@xilinx.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> From: Siva Durga Prasad Paladugu <siva.durga.palad...@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.
Agree but depends on emulators :-).
M
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
