[U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off
Alexander Graf
agraf at suse.de
Tue Jun 27 12:37:54 UTC 2017
> Am 27.06.2017 um 13:52 schrieb Michal Simek <michal.simek at xilinx.com>:
>
>> 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.
If you configure your section boundaries on natural alignments (1GB IIRC), you should get away with quite few tables.
Alex
More information about the U-Boot
mailing list