
Hi Alex,
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Monday, July 03, 2017 12:19 PM To: Siva Durga Prasad Paladugu sivadur@xilinx.com; Michal Simek michal.simek@xilinx.com Cc: u-boot@lists.denx.de; Tom Rini trini@konsulko.com; Simon Glass sjg@chromium.org Subject: Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off
On 03.07.17 08:29, Siva Durga Prasad Paladugu wrote:
Hi Alex,
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Thursday, June 29, 2017 7:34 PM To: Siva Durga Prasad Paladugu sivadur@xilinx.com; Michal Simek michal.simek@xilinx.com Cc: u-boot@lists.denx.de; Tom Rini trini@konsulko.com; Simon Glass sjg@chromium.org Subject: Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off
On 29.06.17 15:44, Siva Durga Prasad Paladugu wrote:
Hi,
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Tuesday, June 27, 2017 6:08 PM To: Michal Simek michal.simek@xilinx.com Cc: Siva Durga Prasad Paladugu sivadur@xilinx.com; u-boot@lists.denx.de; Tom Rini trini@konsulko.com; Simon Glass sjg@chromium.org; Siva Durga Prasad Paladugu
Subject: Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off
Am 27.06.2017 um 13:52 schrieb Michal Simek
> 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/Documenta > ti > on > /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 :).
I can see that, we are anyway avoiding that error message for SPL BUILD where dcache is off. Also, dcache will be ON by default, until and unless user disable it through CONFIG_SYS_DCACHE_OFF.
-mstrict-align is already used for armv8 in arch/arm/cpu/armv8/config.mk
Finally I feel, we can remove this check or atleast we should make it as
#warning instead of #error.
I put it in because UEFI binaries can assume that unaligned instructions work. So please at least convert CONFIG_SYS_DCACHE_OFF to Kconfig and make it mutually exclusive to CONFIG_EFI_LOADER.
I got your point but, Iam bit concerned to do this change as it may break for someone if they are using both DCACHE_OFF and EFI_LOADER,
Isn't it?
Today you can not use DCACHE_OFF at all, so I don't think it'd be a regression ;). I want to make sure that we prohibit the combination on the Kconfig level already to make sure that we do not break anyone using DCACHE_OFF if we start to allow it.
I don’t have idea on UEFI side, all assume unaligned instructions work or it
is configurable when building?
With UEFI you run 3rd party binaries in U-Boot context. The UEFI spec explicitly states that unaligned accesses are valid. So because we by definition don't control the payloads, we can not break unaligned accesses which DCACHE_OFF does.
Thanks for clarification, then I will go ahead and make the change as you suggested.(convert CONFIG_SYS_DCACHE_OFF to Kconfig and make it mutually exclusive to CONFIG_EFI_LOADER).
Thanks, Siva
Alex