[OpenBIOS] SOLVED: the mystery of Solaris on SPARC32 and the missing Forth arguments

[Mark Cave-Ayland]

Blue Swirl wrote:

>>>> None. It probably tries to access something which is not mapped.
>>> This could be verified by changing a line in helper.c:
>>>    *physical = 0xffffffffffff0000ULL;
>>> to for example
>>>    *physical = 0xfef1f0fef1ff0000ULL;
>>> and see if the address changes.
>> It changes for me here:
>>
>> Unassigned mem write access of 4 bytes to fef1f0fef1ff0ecc from f004127c
> 
> Then it must be no-fault access. But I wonder why there is a fault, in
> no-fault mode there should be no faults. And when MMU is switched back
> to normal mode, the fake TLB mappings should be flushed.
> 
>> But then again I'm not sure whether this comment was aimed at me or Artyom?
>> Does Tarl's suggestion of just ignoring write accesses to the ROM area sound
>> feasible?
> 
> I don't think ROM area is in play, but no-fault mode.

Is this the relevant section from the SPARC v8 manual here?

NF

NF is the “No Fault” bit. When NF = 0, any fault detected by the MMU 
causes FSR and FAR to be updated and causes a fault to be generated to 
the processor. When NF = 1, a fault on an access to ASI 9 is handled as 
when NF = 0; a fault on an access to any other ASI causes FSR and FAR to 
be updated but no fault is generated to the processor.

If a fault on access to an ASI other than 9 occurs while NF = 1, subse-
quently resetting NF from 1 to 0 does not cause a fault to the processor
(even though FSR.FT ≠ 0 at that time). A change in value of the NF bit 
takes effect as soon as the bit is written; a subsequent access to ASI 9 
will be evaluated according to the new value of the NF bit.


ATB,

Mark.

-- 
Mark Cave-Ayland - Senior Technical Architect
PostgreSQL - PostGIS
Sirius Corporation plc - control through freedom
http://www.siriusit.co.uk
t: +44 870 608 0063

Sirius Labs: http://www.siriusit.co.uk/labs