> > > 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. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
