On 09/24/2018 03:31 PM, Peter Maydell wrote: > On 24 September 2018 at 14:28, Cédric Le Goater <c...@kaod.org> wrote: >> On 09/24/2018 01:41 PM, Peter Maydell wrote: >>> On 19 September 2018 at 11:19, Cédric Le Goater <c...@kaod.org> wrote: >>>> These are the number of read operations done on the flash memory region : >>>> >>>> 922478 ~ 3.5 MBytes OpenBMC U-Boot >>>> 20569977 ~ 80 MBytes Mainline U-Boot >>>> >>>> >>>> So we are trashing the TBs I would say. Is there a way to increase the >>>> TB size ? or some other TB parameter ? Is that directly linked to the >>>> instruction cache size ? >>> >>> Well, execution direct from MMIO means we read each instruction >>> as we execute it -- there's no caching of TBs. (We generate a >>> temporary TB with a single insn and throw it away after executing >>> from it.) This is because we can't be sure that we would get the >>> same data value the next time we read from the address. >> >> In our case, we should have the same data. So may be I can introduce >> a read-only region with a cache to speed up the accesses. A bit like >> this was done with the previous mmio inteface. > > Yes, this is in theory possible, but we dropped the old > mmio-exec interface because it had some nasty race conditions: > the problem is being able to be sure you've properly dropped > the cached TBs when the device contents change. > > Which flash device is this? For pflash typically the 'romd mode' > stuff suffices to allow execution as-if-from-ram most of the time.
It's a SPI slave flash device attached to the Aspeed SMC controller. It works very well with in a 'romd mode'. I am just stressing a bit more the model with MMIO execution but it's not something we really need. So we can just drop this patch in the v2 patchset "aspeed: misc fixes and enhancements (SMC)" in which I fixed a few other things. Thanks, C.
