[U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off

[Alexander Graf]

On 03.07.17 09:03, Siva Durga Prasad Paladugu wrote:
> Hi Alex,
> 
>> -----Original Message-----
>> From: Alexander Graf [mailto:agraf at suse.de]
>> Sent: Monday, July 03, 2017 12:24 PM
>> To: Michal Simek <michal.simek at xilinx.com>; Siva Durga Prasad Paladugu
>> <sivadur at xilinx.com>; u-boot at lists.denx.de; Tom Rini
>> <trini at konsulko.com>; Simon Glass <sjg at chromium.org>
>> Cc: Siva Durga Prasad Paladugu <sivadur at xilinx.com>
>> Subject: Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is
>> off
>>
>>
>>
>> On 27.06.17 13:52, Michal Simek wrote:
>>> On 27.6.2017 13:46, Alexander Graf wrote:
>>>>
>>>>
>>>> On 27.06.17 13:20, Michal Simek wrote:
>>>>> Hi,
>>>>>
>>>>> On 27.6.2017 13:01, Alexander Graf wrote:
>>>>>> I don't think that's going to work - at least not without compiler
>>>>>> flag changes. By default, gcc will happily generate unaligned
>>>>>> accesses. If you disable dcache, these will trap.
>>>>>
>>>>> What's that compiler flags we should be using to avoid that?
>>>>
>>>> It's a combination of
>>>>
>>>>     -mstrict-align
>>>>
>>>> plus crossing fingers with lots of praying plus making sure that
>>>> every code you call also follows -mstrict-align plus double-checking
>>>> that you don't break the kernel booting ABI:
>>>>
>>>>
>>>> http://elixir.free-electrons.com/linux/v4.12-rc7/source/Documentation
>>>> /arm64/booting.txt
>>>>
>>>>
>>>> In the booti case, disabling dcache seems to be legitimate. In the
>>>> bootefi case however, it's not.
>>>
>>> Non wants to boot the kernel. It is really about programming stuff.
>>>
>>>>
>>>> So you will also need to set CONFIG_EFI_LOADER to depend on
>>>> !CONFIG_SYS_DCACHE_OFF which means you will want to convert
>>>> CONFIG_SYS_DCACHE_OFF to Kconfig first :).
>>>
>>> ok. I will let Siva to do it just wanted to refresh this topic.
>>>
>>>
>>>>> The reason for this change is to have really small u-boot which fits
>>>>> to OCM without DDR to be able to do initial programming.
>>>>
>>>> Yup, makes sense. I'm just slightly scared by the idea :).
>>>
>>> The same stuff we did on Zynq in past.
>>> I have never had enough time to look at that MMU mapping why it is so
>>> huge. Maybe reduce size of that tables or using different page size is
>>> better way to go.
>>
>> Actually thinking about this one again. I'm fairly sure you could provide
>> page-aligned gigabyte page maps in .rodata manually for your board in your
>> specific configuration. The mmu setup function is weak, so you can simply
>> override it and have it point the mmu to your pregenerated page table.
>>
>> With that, the overhead of having caches on shouldn't be too much.
>> Especially if you can make the page table aligned, but not padded to 4k.
> 
> Yeah you are correct, I considered this, the other issue is that while relocating, we are aligning it
> to 64K boundary which again result in eating up more space in my case.
> Refer file common/board_f.c and routine reserve_mmu().

Yes, you would need to have a special case - something like 
CONFIG_SYS_STATIC_MMU_CONFIG and in that case not reserve anything.

> 
> Also other thought is, If we are providing the flexibility of caches off in other arm architectures
> then why not here?

Because when I went through all supported boards, a lot of them had 
caches disabled by accident. And almost nobody wants to run with caches 
off. It's significantly slower for almost no gain.


Alex