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(). Also other thought is, If we are providing the flexibility of caches off in other arm architectures then why not here? Thanks, Siva. > > > Alex _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
