[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