Permission Faults

Whilst testing ADFFS on RPCEmu 0.8.11, I’ve noticed it’s not generating Permission Faults.

If I set a memory page to Read only access for User mode and then write to it, I’m not seeing an Abort with FSR bits 3:0 set to 1111 (Page permission).

Well…that’s not strictly true, I see one raised then no more.

I spent a few hours the other day trying to track this issue down and sent details to Tom Walker. From adding debug info to the RPCEmu source, as per my observations, it does generate one Abort correctly and then no more.

I’m not certain of the exact cause yet, it could be related to the way the Abort handler exits and switches the CPU back to user mode. If that’s not working correctly it will cause the issue. From the debug info, RPCEmu is switching the CPU state correctly, but has another variable that tracks the “privilege” state (0=User26/User32, 1=all other CPU modes) used to access memory and I’m not certain that’s being set correctly. Memory access from there on may stay stuck in privileged mode.

I need to do more debugging to confirm that theory though, which I’ll do in a few weeks.

Hi Jon, before you spend too much time on this, there are some known faults in RPCEmu that may be causing the faults you are seeing.

The tlb does not cache permissions, this can result in a number of subtle and unsubtle problems. The symptoms of this would be memory permissions which are not always consistent with the permissions set in the translation table.

The abort behaviour is believed to be correct only in StrongARM mode, there are several aspects of abort behaviour that differ on earlier processors that are not implemented in correctly in the emulator.

Dynamic recompiler has some issues where a block of code that could be executed in a 26 and 32 bit mode, could result in incorrect behaviour, the work around for this issue only is to use the interpreter.

Some of the long term refactoring that has been going on with RPCEmu has the eventual goal of resolving these issues. A lot of the current emphasis is on developing test code to identify, resolve and verify these sort of problems.

In addition RPCEmu does not emulate cache behaviour (and to do so would be a performance loss). For this reason it is important to test low level code on real hardware, otherwise bugs may be hidden by running your code in the emulator.

But Jon, if you have any test programs that demonstrate the issues you’re seeing, can you send us the code, as we can use this in the debugging of these issues.

Some of the long term refactoring that has been going on with RPCEmu…

Speaking of things changing – the RPCEmu + RO5 use page is drastically out of date.

I have an updated offering if you’d care to use it.

I’ll get around to it at some point, but I wouldn’t update it without retesting it personally.

I had been tempted to update the docs to match the rool docs on installing ro5 on a real Risc PC, and just deleting the page in its entirity ;)

I’ll get around to it at some point, but I wouldn’t update it without retesting it personally.

and amending the offering. The style is slightly different for a start.

I had been tempted to update the docs to match the rool docs on installing ro5 on a real Risc PC, and just deleting the page in its entirity ;)

Using the version I have would be the same effect, but the basis of the text is Tony Moores install sequence.
I’ve started looking at the Windows networking sequence.

steven pampling at btinternet.com if you’re interested.

Peter, I’m not sure I have your eMail address. Drop my a mail and I’ll send over a repro: jon at jaspp dot org dot uk

I should have said I was running as a StrongARM.

Whilst wading through the code I did consider rewriting the memory subsystem to properly emulate the split cache and add in step debugging – for my purposes I could really do with a true CPU emulator. Speed isn’t really an issue but having at least one emulator that does properly emulate a StrongARM would really help developers such as myself. At the minute I do it all on physical machine, but that makes debugging damn near impossible, particularly where issues with caching are concerned.

I didn’t understand why there’s two variables for tracking the privilege level, one for the CPU mode and one for memory. I’d expect the later to come from the TLB on each memory read and the former to come from the CPSR.

Well I took a stab at updating the rpcemu and ro5 page, retesting with the latest of everything found a few different caveats that are now mentioned.

http://www.marutan.net/rpcemu/ro5.html

Well I took a stab at updating the rpcemu and ro5 page, retesting with the latest of everything found a few different caveats that are now mentioned.

Nice quick rewrite.

My install sequence version includes selection of the VRAM and StrongARM so the caveat on those hadn’t been noted.
If I recall there was another combination that didn’t work well – I will try and pin it down.

NB. Redraw issues – if you use an emulation mode¹ that causes the RPCEmu window to overlap the windows taskbar then the taskbar redraw mucks up and you get bits of RPCEmu frame left on the taskbar until you refresh it. Could just be an XP bug. I will test it on the Win7 laptop.

Maybe more later – got to go and hand over the on-call pager.

¹ 1024 × 768 on a 1280 × 800 windows display.

http://www.marutan.net/rpcemu/ro5.html
“This change first happened for other hardware in approximately 2003/2004”

Developer Castle Technology
Manufacturer Castle Technology
Release date October 22, 2002¹
Units first went on sale in December 2002. (still got it, but the lightning strike didn’t do the NIC much good.

¹ T’was the start of the war… :) or :(

Getting my thread back on track, repro info has now been sent. Hopefully it will help resolve the issue.

Does RPCEmu support subpages? These were only ever used by RO4 to lock down some of the pages below &4000, so may not have been tested. RedSquirrel for example doesn’t support them, but runs RO4 quite happily.

If / when the permission fault issue is fixed, you may want to check all four subpages raise abort correctly within an L2PT entry.

How’s the refactoring coming along?

Is there any update on this issue, subpage support or the refactoring?

Was the repro code I sent in 2013 sufficient?

Jon: Might be worth a posting on the RPCEmu mailing list, as I believe this sub-forum is strictly for ‘RISC OS 5 on RPCEmu’ (as opposed to RPCEmu itself).