Re: Wierd code in Entry.S

[Artem Alimarine <artem.alimarine@stromasys.com>]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

Hi Grant,

Bit 44 falls into the access_id area. So, access id get corrupted. As 
far as I understand we should get interrupt 18 (access check trap) on 
such TLB  entries. However we do not. The bug can go unnoticed when the 
access id is smaller than 31 bits. The PA2.0 manual says in the IDTLBT 
description: If smaller than 31-bit access IDs are implemented, only the 
appropriate number of the
rightmost bits of GR[r]{32..62} are stored in the TLB. Obviously, bit 44 
is not among the stored bits.

Actually, I have no idea on how many bits are used by the hardware. 
Myself I have rp2470.

Best regards,
Artem

> But I'm still wondering what the effect of this bug will be.
> The first order (not setting U-bit) should only affect ZX1 (pa8800/pa8900)
> machines. Those have uncacheable IO space between 2GB-4GB physical address.
> My guess is the machines should HPMC since the CPU would attempt to access
> those ranges as a cacheline read/write instead of sub-cacheline transactions.
>
> It's not clear from the arch manual what happens if bit 44 is set in R2.
> I didn't look far enough to see where the auth ID gets corrupted.
>
>   

[-- Attachment #2: artem_alimarine.vcf --]
[-- Type: text/x-vcard, Size: 283 bytes --]

begin:vcard
fn:dr. Artem Alimarine
n:Alimarine;Artem
org:STROMASYS SA
adr:;;De Zaale 11;Eindhoven;;5612AJ;The Netherlands
email;internet:artem.alimarine@stromasys.com
title:Software Architect
tel;work:+31-40-2390863
tel;fax:+31-40-2390800
x-mozilla-html:FALSE
version:2.1
end:vcard