[U-Boot] [PATCH] arch: armv8: Remove the error when dcache is off

[Siva Durga Prasad Paladugu]

Hi Alex,

> -----Original Message-----
> From: Alexander Graf [mailto:agraf at suse.de]
> Sent: Monday, July 03, 2017 12:24 PM
> To: Michal Simek <michal.simek at xilinx.com>; Siva Durga Prasad Paladugu
> <sivadur at xilinx.com>; u-boot at lists.denx.de; Tom Rini
> <trini at konsulko.com>; Simon Glass <sjg at chromium.org>
> Cc: Siva Durga Prasad Paladugu <sivadur at 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