[U-Boot] [PATCH 1/2] armv8: caches: Disable dcache after flush

Mark Rutland mark.rutland at arm.com
Mon Apr 20 12:18:29 CEST 2015


> > > Thanks for explanation.
> > > So in that case, the flushing of the required stack or any other data
> > > which needs to be flushed should be part of board specific. Am I
> > > correct?
> >
> > It could be done in generic code, assuming we know the bounds of memory
> > which will be used, because maintenance by VA should always work.
> >
> > Do we know which memory U-Boot might use (e.g. does it all fall within some
> > static carveout?), or can it dynamically allocate from anywhere in memory?
> >
> > > If yes, then this disable_dcache() should contain a asm call to a
> > > routine() (which might be board specific) after disabling the cache to
> > > flush the required data and then flush_dcache_all() followed by flush
> > > L3 cache..
> >
> > You could probably get away with:
> >
> > * Load the memory bounds that we need to flush into some registers, or
> >   flush some datastructure containing these to memory.
> > * In assembly:
> >   - disable the MMU.
> >   - flush the PA range(s) we need to use to be able to use C safely.
> >   - flush by Set/Way to empry the CPU-local caches
> > * Implementation-specific L3 flushing for anything else.
> >
> > If we only map a small amount of memory, we could simply flush this by VA
> > (knowing that this will drain the CPU and L3 caches, without any special
> > maintenance).
> I just looked at one of the old patch from York in the link below. Can you look at this.
> http://lists.denx.de/pipermail/u-boot/2015-January/200514.html

I'm not sure what you're expecting me to say w.r.t. that. Is there a
particular question you have?

Thanks,
Mark.



More information about the U-Boot mailing list