In 2015年11月20日 下午7:07於 "Patrick Wildt" <m...@patrick-wildt.de>寫道: > > Hi, > > Some might call it unimplemented feature, other might call it a bug. > > In essence this code is wrong. The value has to match the cache line > size used in the specific CPU that we’re running on. > > If you look at NetBSD, you’ll see that they always read out the size > prior to doing that sync. FreeBSD reads it out once on bootup, stores > it in a variable and uses that. OpenBSD hardcodes this value because > no one yet came to do it right. > > Patrick >
The cache linesize was not hardcoded, it is read from global variable, and the global variable was initialized by reading from cache type register. I think the limitation is not necessary. I found the size of range (r1) subtract from one, this also unnecessary. It seems coherent walk on translation table not supported, page table is non-cacheable (why not write-back and flush?) May I give a patch to correct size of range and support coherent walk on translation table? > > Am 20.11.2015 um 07:21 schrieb 游俊德 <jeund...@gmail.com>: > > > > Hello, > > > > I have a question for armv7_icache_sync_range function in > > sys/arch/arm/arm/cpufunc_asm_armv7.S > > > > ENTRY(armv7_icache_sync_range) > > ldr ip, .Larmv7_line_size > > cmp r1, #0x8000 > > movcs r1, #0x8000 > > > > The register r1 is the size of range to sync. > > My question is, why it is limited to 0x8000 (32K bytes) ? > > > > Similar limitation also existed in following functions: > > armv7_dcache_wb_range > > armv7_idcache_wbinv_range > > armv7_dcache_wbinv_range > > armv7_dcache_inv_range > > > > It's so strange! > > > > The function armv5_ec_icache_sync_range in > > sys/arch/arm/arm/cpufunc_asm_armv5_ec.S > > > > ENTRY_NP(armv5_ec_icache_sync_range) > > ldr ip, .Larmv5_ec_line_size > > cmp r1, #0x4000 > > bcs .Larmv5_ec_icache_sync_all > > > > It will use icache_sync_all function if size greater than 0x4000, > > is this logic suitable for armv7_icache_sync_range function? > > Is there any performance consideration? > > > > Any comment? > > > > BRs, > > Joey > > >