ARM920T debugging with linefills disabled leads to lockup

[Dominic]

Hi,

while working with a Cirrus EP9301 (arm920t based) with my own debugger
(OpenOCD, http://openocd.berlios.de/web/), I stumbled across a somewhat
strange problem. Meanwhile I've verified the problem exists on an
AT91RM9200, too, meaning it's a problem with the core, not the chips.

When entering debug state, the OpenOCD disables linefills for both caches
(CP15 test state register bits 9 and 10), as advised in the ARM920T TRM
(DDI0151C, B-4/5), to preserve the cache content. However, when reading
from certain memory locations using system-speed LDM instructions, I'm able
to reproducibly lockup the memory system.
The symptoms are that any memory reads following the lockup return 0x0 (but
don't cause aborts, and don't fail to complete the system-speed LDM). When
resuming the target, it usually ends up in an endless loop, and while
single stepping, I see the PC stay within a busy waiting loop the processor
executed before the lockup. This behaviour is obviously caused by the loads
in the code returning 0x0, thus never fulfilling the looop exit criteria.

To further debug the problem, I've added functions to the OpenOCD to read
the I/DCache and MMU content. After checking the cache content and
accessing locations contained in the cache as well as locations not in the
cache, I came to the conclusion that accessing memory already contained in
the DCache causes the memory system to lock-up. If for example the MVA TAG
0x000000 is found in segments 3 and 4, but not in 0-2 and 5-7, reading from
0x0-0x5f (segments 0-2) wont cause problems, but reading from 0x60 to 0x9f
(segments 3-4) results in the described lockups.

Maybe someone who reads this has an idea what might cause my problem.

Best regards,

Dominic Rath

[Nishu]

Dominic wrote:
> Hi,
>
> while working with a Cirrus EP9301 (arm920t based) with my own debugger
> (OpenOCD, http://openocd.berlios.de/web/), I stumbled across a somewhat
> strange problem. Meanwhile I've verified the problem exists on an
> AT91RM9200, too, meaning it's a problem with the core, not the chips.
>
> When entering debug state, the OpenOCD disables linefills for both caches
> (CP15 test state register bits 9 and 10), as advised in the ARM920T TRM
> (DDI0151C, B-4/5), to preserve the cache content. However, when reading
> from certain memory locations using system-speed LDM instructions, I'm able
> to reproducibly lockup the memory system.

I think disabling the D cache, with enabled mmu, always leads to
locking up of initial data in the cache.

[Dominic]

Nishu wrote:

>
> Dominic wrote:
>>
>> When entering debug state, the OpenOCD disables linefills for both caches
>> (CP15 test state register bits 9 and 10), as advised in the ARM920T TRM
>> (DDI0151C, B-4/5), to preserve the cache content. However, when reading
>> from certain memory locations using system-speed LDM instructions, I'm
>> able to reproducibly lockup the memory system.
>
> I think disabling the D cache, with enabled mmu, always leads to
> locking up of initial data in the cache.

I can disable the DCache and reenable it with no problems, but when
disabled, there's no data returned from the cache in case of a hit, i.e. I
always read from memory, never from cache. As the ARM920t supports
write-back behaviour, there might be dirty cache lines, and reading with
the cache disabled would return bogus data.

Regards,

Dominic