[U-Boot] [PATCH 1/2] mips: mt76xx: Flush d-cache in arch_misc_init() to solve d-cache issues

[Stefan Roese]

Hi Daniel,

On 18.12.18 13:16, Daniel Schwierzeck wrote:
> 
> 
> Am 18.12.18 um 10:27 schrieb Stefan Roese:
>> It has been noticed, that sometimes the d-cache is not in a
>> "clean-state" when U-Boot is running on MT7688. This was detected when
>> using the ethernet driver (which uses d-cache) and a TFTP command does
>> not complete. Flushing the complete d-cache (again?) here seems to fix
>> this issue.
>>
>> Signed-off-by: Stefan Roese <sr at denx.de>
>> Cc: Daniel Schwierzeck <daniel.schwierzeck at gmail.com>
>> ---
>>   arch/mips/Kconfig           |  2 +-
>>   arch/mips/mach-mt7620/cpu.c | 14 +++++++++++++-
>>   2 files changed, 14 insertions(+), 2 deletions(-)
>>
>> diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig
>> index 1b1b1d7d00..355d3b4d91 100644
>> --- a/arch/mips/Kconfig
>> +++ b/arch/mips/Kconfig
>> @@ -79,7 +79,7 @@ config ARCH_MT7620
>>   	select DM_SERIAL
>>   	imply DM_SPI
>>   	imply DM_SPI_FLASH
>> -	select ARCH_MISC_INIT if WATCHDOG
>> +	select ARCH_MISC_INIT
>>   	select MIPS_TUNE_24KC
>>   	select OF_CONTROL
>>   	select ROM_EXCEPTION_VECTORS
>> diff --git a/arch/mips/mach-mt7620/cpu.c b/arch/mips/mach-mt7620/cpu.c
>> index 87cc973b75..9e0ca716f7 100644
>> --- a/arch/mips/mach-mt7620/cpu.c
>> +++ b/arch/mips/mach-mt7620/cpu.c
>> @@ -89,9 +89,21 @@ void watchdog_reset(void)
>>   		wdt_reset(watchdog_dev);
>>   	}
>>   }
>> +#endif
>>   
>>   int arch_misc_init(void)
>>   {
>> +	/*
>> +	 * It has been noticed, that sometimes the d-cache is not in a
>> +	 * "clean-state" when U-Boot is running on MT7688. This was
>> +	 * detected when using the ethernet driver (which uses d-cache)
>> +	 * and a TFTP command does not complete. Flushing the complete
>> +	 * d-cache (again?) here seems to fix this issue.
>> +	 */
>> +	flush_dcache_range(gd->bd->bi_memstart,
>> +			   gd->bd->bi_memstart + gd->ram_size - 1);
> 
> I noticed that in cache_init.S the i-cache lines is always invalidated
> regardless of CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD whereas the d-cache
> lines are not. I think we could always invalidate the d-cache lines and
> only fill them with zero when CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD is
> enabled to force good cache parity.
> 
> Could you retry with this little change?
> 
> --- a/arch/mips/lib/cache_init.S
> +++ b/arch/mips/lib/cache_init.S
> @@ -344,10 +344,10 @@ l1_init:
>   2:     LONG_L          zero, 0(t0)
>          PTR_ADDU        t0, R_DC_LINE
>          bne             t0, t1, 2b
> +#endif
>          /* clear all tags */
>          PTR_LI          t0, CKSEG0ADDR(CONFIG_MIPS_CACHE_INDEX_BASE)
>          cache_loop      t0, t1, R_DC_LINE, INDEX_STORE_TAG_D
> -#endif
>   3:
> 

Thanks for the idea, but this patch does not fix the issue, I'm afraid.
Still hangs in the first TFTP command most of the time after power-up.

Please note that I also tested with CONFIG_SYS_MIPS_CACHE_INIT_RAM_LOAD
enabled and this issue also occurs in this setup. The only real help
to fix this first TFTP command hang is in my tests to either use the
dcache_flush (as done in this current patch) or some user help command,
like "cp.b 81000000 82000000 8000" to copy 32KiB of memory.

Frankly I'm also not very happy with this patch as the real reason why
it is needed is not 100% clear to me. But its definitely better than
using such user "cp.b xxx" hacks.

Thanks,
Stefan