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