On 03.07.17 09:03, Siva Durga Prasad Paladugu wrote:
Hi Alex,
-----Original Message-----
From: Alexander Graf [mailto:ag...@suse.de]
Sent: Monday, July 03, 2017 12:24 PM
To: Michal Simek <michal.si...@xilinx.com>; Siva Durga Prasad Paladugu
<siva...@xilinx.com>; u-boot@lists.denx.de; Tom Rini
<tr...@konsulko.com>; Simon Glass <s...@chromium.org>
Cc: Siva Durga Prasad Paladugu <siva...@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().
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
