[U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off
Remove the error which causes compilation failure when dcache is off for builds otherthan SPL. There may be cases where user wants to disable dcache completely eventhough it is not SPL.
Signed-off-by: Siva Durga Prasad Paladugu sivadur@xilinx.com --- arch/arm/cpu/armv8/cache_v8.c | 9 --------- 1 file changed, 9 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index adc7e17..d11efcc 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -647,15 +647,6 @@ void mmu_change_region_attr(phys_addr_t addr, size_t siz, u64 attrs)
#else /* CONFIG_SYS_DCACHE_OFF */
-/* - * For SPL builds, we may want to not have dcache enabled. Any real U-Boot - * running however really wants to have dcache and the MMU active. Check that - * everything is sane and give the developer a hint if it isn't. - */ -#ifndef CONFIG_SPL_BUILD -#error Please describe your MMU layout in CONFIG_SYS_MEM_MAP and enable dcache. -#endif - void invalidate_dcache_all(void) { }
Hi guys,
do you have any concern about this change?
Thanks, Michal
On 22.6.2017 12:00, Siva Durga Prasad Paladugu wrote:
Remove the error which causes compilation failure when dcache is off for builds otherthan SPL. There may be cases where user wants to disable dcache completely eventhough it is not SPL.
Signed-off-by: Siva Durga Prasad Paladugu sivadur@xilinx.com
arch/arm/cpu/armv8/cache_v8.c | 9 --------- 1 file changed, 9 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index adc7e17..d11efcc 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -647,15 +647,6 @@ void mmu_change_region_attr(phys_addr_t addr, size_t siz, u64 attrs)
#else /* CONFIG_SYS_DCACHE_OFF */
-/*
- For SPL builds, we may want to not have dcache enabled. Any real U-Boot
- running however really wants to have dcache and the MMU active. Check that
- everything is sane and give the developer a hint if it isn't.
- */
-#ifndef CONFIG_SPL_BUILD -#error Please describe your MMU layout in CONFIG_SYS_MEM_MAP and enable dcache. -#endif
void invalidate_dcache_all(void) { }
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.
Alex
On 27.06.17 11:04, Michal Simek wrote:
Hi guys,
do you have any concern about this change?
Thanks, Michal
On 22.6.2017 12:00, Siva Durga Prasad Paladugu wrote:
Remove the error which causes compilation failure when dcache is off for builds otherthan SPL. There may be cases where user wants to disable dcache completely eventhough it is not SPL.
Signed-off-by: Siva Durga Prasad Paladugu sivadur@xilinx.com
arch/arm/cpu/armv8/cache_v8.c | 9 --------- 1 file changed, 9 deletions(-)
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c index adc7e17..d11efcc 100644 --- a/arch/arm/cpu/armv8/cache_v8.c +++ b/arch/arm/cpu/armv8/cache_v8.c @@ -647,15 +647,6 @@ void mmu_change_region_attr(phys_addr_t addr, size_t siz, u64 attrs)
#else /* CONFIG_SYS_DCACHE_OFF */
-/*
- For SPL builds, we may want to not have dcache enabled. Any real U-Boot
- running however really wants to have dcache and the MMU active. Check that
- everything is sane and give the developer a hint if it isn't.
- */
-#ifndef CONFIG_SPL_BUILD -#error Please describe your MMU layout in CONFIG_SYS_MEM_MAP and enable dcache. -#endif
- void invalidate_dcache_all(void) { }
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?
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.
Thanks, Michal
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/...
In the booti case, disabling dcache seems to be legitimate. In the bootefi case however, it's not.
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 :).
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 :).
Alex
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/...
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.
Thanks, Michal
Am 27.06.2017 um 13:52 schrieb Michal Simek michal.simek@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/...
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
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 sivadur@xilinx.com Subject: Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off
Am 27.06.2017 um 13:52 schrieb Michal Simek michal.simek@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 :).
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.
Thanks, Siva.
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
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 sivadur@xilinx.com Subject: Re: [U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off
Am 27.06.2017 um 13:52 schrieb Michal Simek michal.simek@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 :).
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.
Alex
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 sivadur@xilinx.com 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/Documentati 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? I don’t have idea on UEFI side, all assume unaligned instructions work or it is configurable when building?
Thanks, Siva
Alex
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 sivadur@xilinx.com 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/Documentati 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.
Alex
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
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/...
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.
Alex
Hi Alex,
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Monday, July 03, 2017 12:24 PM To: Michal Simek michal.simek@xilinx.com; Siva Durga Prasad Paladugu sivadur@xilinx.com; u-boot@lists.denx.de; Tom Rini trini@konsulko.com; Simon Glass sjg@chromium.org Cc: Siva Durga Prasad Paladugu sivadur@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().
Also other thought is, If we are providing the flexibility of caches off in other arm architectures then why not here?
Thanks, Siva.
Alex
On 03.07.17 09:03, Siva Durga Prasad Paladugu wrote:
Hi Alex,
-----Original Message----- From: Alexander Graf [mailto:agraf@suse.de] Sent: Monday, July 03, 2017 12:24 PM To: Michal Simek michal.simek@xilinx.com; Siva Durga Prasad Paladugu sivadur@xilinx.com; u-boot@lists.denx.de; Tom Rini trini@konsulko.com; Simon Glass sjg@chromium.org Cc: Siva Durga Prasad Paladugu sivadur@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-alignplus 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
participants (3)
-
Alexander Graf -
Michal Simek -
Siva Durga Prasad Paladugu