Hi!
With this patch: => tftp 100000 big-40mb Speed: 1000, full duplex Using dwmac.ff702000 device TFTP from server 192.168.1.54; our IP address is 192.168.1.252 Filename 'big-40mb'. Load address: 0x100000 Loading: ################################################################# ################################################################# ################################################################# ################################################################# ########################## 7.6 MiB/s
A performance improvement of factor ~3.
Ok, so you turn on write-back cache and it is faster.
Its not only faster. My tests have shown, that the current implementation (WRITEALLOC) does not enable the dcache at all. No performance difference with dcache enable or disabled. I also tested this by removing the dcache flush and invalidate calls from the ethernet driver. And tftp still worked without any problems (same slow speed of course) with dcache enabled. On platforms with a really enabled dcache, such a change leads to a non-working network interface.
Yes, so we were running with dcache disabled, which can mask _many_ programming errors.
Now... do you have an explanation why this is safe to do? Are there cache flushes that need to be added to the code now that we turned on write-back?
I have not found any issues yet with this patch added. The cache handling calls (flush, invalidate) are already included in the code using it (e.g. USB, ethernet, MMC).
For generic code, you are right.
What about socfpga-specific code? Will this still do the right thing with cache enabled? Do we have hardware registers mapped uncacheable?
Ok, I guess we should enable the cache and fix any bugs currently hidden.
Best regards, Pavel
/* Toggle reset signal to watchdog (WDT is disabled after this operation!) */ void socfpga_watchdog_reset(void) { /* assert reset for watchdog */ setbits_le32(&reset_manager_base->per_mod_reset, 1 << RSTMGR_PERMODRST_L4WD0_LSB);
/* deassert watchdog from reset (watchdog in not running state) */ clrbits_le32(&reset_manager_base->per_mod_reset, 1 << RSTMGR_PERMODRST_L4WD0_LSB); }