Zero page protection

If your thinking was that an attempt to claim FIQs at the old address would simply never be granted

Yes, that’s what I was thinking of.

then there’s a problem – Service_ClaimFIQ (as opposed to Service_ClaimFIQInBackground) is basically defined to block until FIQs have been released. So any caller of Service_ClaimFIQ is likely to just go ahead and starting writing over zero page as soon as the service call returns anyway.

Good point.

If that’s the case, then maybe it isn’t worth worrying about the FIQ claim mechanism. The only released machine which is capable of using high processor vectors and has an established collection of third-party hardware drivers is the Iyonix. Although I doubt there are many Iyonix users who use FIQ-reliant third-party software/hardware, there will be lots of people who are reliant on Aemulor. So I doubt we’d ever be able to switch the official Iyonix ROM images over to using high processor vectors, because it’s highly unlikely that Aemulor (or the software that people are using it for) will work any more.

Today I managed to get an Iyonix ROM booting with high processor vectors/zero page relocation. Since that was the last thing on my todo list, I went ahead and checked in the kernel changes (with the high vectors/zero page relocation option disabled). Commit log here.

OS_PlatformFeatures 0 bit 20 is used to indicate to programs whether high processor vectors are in use. I haven’t changed the FIQ claim/release process.

Nice work Jeffrey!!

Is Zero page relocation now enabled by default for the OMAP ROM if built from the CVS?

cough

… (with the high vectors/zero page relocation option disabled)

I guess it was a bit misleading to say that getting the changes working on the Iyonix was the last thing on my todo list; instead it was just the last thing before I was happy to check in the code. There’s still a few other bits that need sorting out:

• Updating the closed source components (mainly a job for ROOL)
• Finding out how much third-party stuff is broken (I’ll probably use an Iyonix ROM for this, since I’ve got more software installed there)
• Creating a support module to allow most/all of the broken software to run. I’m hoping to have lots of logging features to make tracking down the broken code a lot easier (e.g. I found that if you pass a bad pointer to OS_Module 0 you get a crash deep deep deep down inside FileSwitch, which took me at least an hour or two to unravel!)

But if you want to try building your own ROM for testing, there’s some notes about it here

So, what are the chances of us getting this sorted out in time for RISC OS 5.20? The sooner we can get zero page relocation enabled (for ARMv6+, at least), the more time third-party developers will have to fix any broken apps. From my post above I can see there’s still a couple of bits I was intending to do, but there’s also some things that are going to have to be done by ROOL:

• ShareFS (and any other closed source bits) need updating to use OS_ReadSysInfo 6 to read the location of the zero page locations it uses (sub-reason codes are in Hdr:OSRSI6). For when/if OS_ReadSysInfo 6 failes they should also be using the “Legacy_” definitions from Hdr:PublicWS instead of the non-legacy ones.
• VProtect needs the nasty crash bug fixing. I know the bug tracker is still down, so that link isn’t going to be particularly useful. But I should still have a patched version of the module on my BB, so I can easily find out where the bug was if extracting it from the bug tracker is going to be tricky.

Regarding VProtect: I’ve just checked my patched version and it looks like the bug is with the code at offsets &1DBC and &1DC0. Judging by my reading of the disassembly, the LDR R4,&1D2C and CMP R4,#0 should be changed to LDR R0,&1D2C and CMP R0,#0

The routine that code is located in seems to have two entry points – one at &1D14 for checking individual modules for viruses (called with R3 = module ptr) and one at &1D30 for checking the entire module chain.

The bug is that if it’s checking the entire module chain, then after the code at &1DBC/&1DC0 checks the flag at &1D2C, it will branch back up to the OS_Module SWI. Except something in the list of module check functions has corrupted R0, causing OS_Module to be called with the wrong reason code. I’m not sure whether the R0 corruption is a bug or not (too much disassembled code to examine!), but since &1D2C is initialised with the OS_Module reason code the simplest fix seems to be to update the code to load &1D2C into R0 instead of R4.

I just built an omap4 rom to try out the zero page protection. I set HiProcVecs, FPEAnchor, unplugged ShareFS and removed VProtect from boot.
It got to the desktop and then I got a couple of aborts,

FC0270E4 in Utility Module
FC2A929C in SCSIdriver (Attempt to use badly nested error handler (or corrupt R13))
then filecore in use.

I have a working desktop now. I made the mistake of not using a fresh !Boot folder.

I’ve been testing the latest rom and disk build. One major problem is ‘Filer action window’ aborts at fc151ee8. Quite a few configure plugins cause an abort too.

Looks like very few applications work reliably, if at all. Anything linked with Unixlib crashes immediately. Even a simple ‘hello world’.

One major problem is ‘Filer action window’ aborts at fc151ee8. Quite a few configure plugins cause an abort too.

OK, I’ll look into those.

Anything linked with Unixlib crashes immediately. Even a simple ‘hello world’.

Hmm, that’s disappointing. Hopefully it’s just looking at bits of kernel workspace (e.g. IRQsema) instead of dereferencing null pointers.

It’s working much better with the latest rom. It’s possible to test applications now. Do you still want to know what aborts are happening or should I wait for the debug symbol stuff?

There are a couple more fixes I need to check in, as well as a couple of crashes I still need to investigate. I’ll let you know once they’re sorted so that you can start your testing (thanks for giving this a go, by the way!)

From this point on I’m planning to use builds with high processor vectors as much as possible, so between the two of us I think we should be able to track down most of the issues pretty quickly.

My fixes are now checked in. All the configure plugins should now load, but I haven’t checked if they crash during use.

Note that although I did find and fix a bug that was common to several of the plugins, there isn’t an immediate need to update your disc image, as the bug will only cause the plugins to crash if you run them manually outside of Configure.

I haven’t checked what the UnixLib issues are yet, but I guess that’ll be next on my list.

there isn’t an immediate need to update your disc image, as the bug will only cause the plugins to crash if you run them manually outside of Configure.

I had to update !Boot to get the plugins to run.

I haven’t checked what the UnixLib issues are yet, but I guess that’ll be next on my list.

This has fixed itself with the changes you made over the weekend.

Here’s a list of aborts I’ve found so far (tested on a Beagleboard Xm),

• On initial power on there’s an abort at 0xfc026bc0 0×80000002. On rebooting there is no abort.

• Attempting a !Boot or a !System merge.

• Clicking set in the following plugins, pinboard, keyboard, screen and filer.

• Clicking set clock from !Alarm.

• Attempting to drag and drop the save icon in !Draw, !Edit and !Paint.

• Running !Printers and !Maestro.

Clicking set clock from !Alarm

Looks like one of the plugins got missed, so I’ve updated that one. All the plugins come from 2 parents, so the gene pool is pretty small!

Looks like one of the plugins got missed, so I’ve updated that one.

Ah yes, I don’t think I’ve updated my source trees since Sprow checked in his time changes, so would have missed that one.

When I get a chance I’ll update to the latest code and start looking into those issues you’ve found. As you’ve probably guessed from the checkin comments so far I’ve only been testing on a Pi, so would have missed the abort on startup on the Beagle (presumably something to do with power on resets, if it goes away on the 2nd attempt)

Here’s a few more aborts,

• run !Help, click select on icon to suspend, then click select again.
• clicking set in fonts configure plugin after changing font to ‘Newhall.Medium’
• Attempting to install a font using the fonts configure plugin.
• clicking connect in omniclient after filling in ‘Name’, ‘Server Name’ and ‘Directory Path’
• attempting rmkill of omniclient module after the above abort.

I’ve just finished checking in another batch of fixes, for both the ROM and disc image. This should fix everything you’ve listed above, except !Printers (for me it gets stuck on startup and needs alt-break to recover, I haven’t investigated why), and omniclient (wasn’t on my USB stick for some reason; it’s in the build output on my Iyonix, so I guess I just haven’t updated my Apps folder in a long time).

Also you don’t need to worry about unplugging ShareFS anymore; a couple of days ago CVS was updated with a new build which works properly with zero page relocation, after I managed to sweet-talk ROOL into giving me access to the sources.

Everything is working really well. I haven’t found any more aborts testing the ROM and the disc image.

Cool.

FWIW, there is at least one bug in unixlib – on startup it tries to get the DDE prefix, and if you don’t have DDEUtils loaded or Prefix$Dir set, it’ll crash. I’ve reported it on their bug tracker, but for now an easy workaround (apart from loading DDEUtils) is just to do *set Prefix$Dir "".

It looks like the bug’s been around for at least a year or two, but since there’s a simple workaround I don’t think it’s something we need to worry too much about with respect to patching or support modules.

Here’s a couple more aborts.

This happens sometimes when attempting to drag and drop files in the filer.

Abort at &FC12B634 offset &0000DCD8 in WindowManager

This one occurs occasionally when copying files from sharefs which then results in
‘ShareFS may not be used recursively’

Abort at &FC11B660 offset &00000CF4 in MessageTrans

I’m also getting a lot of aborts in modules in the rom caused by third party applications. Do you want to know these as well?

I’m also getting a lot of aborts in modules in the rom caused by third party applications. Do you want to know these as well?

Sure. Although I’m sure some of them will be the fault of the application, others might be bugs in the OS. Plus I’m sure any application author that spots this thread will want to know where their code is falling over!

This happens sometimes when attempting to drag and drop files in the filer.

Abort at &FC12B634 offset &0000DCD8 in WindowManager

This one should now be fixed, I think. I couldn’t reproduce it myself, but judging from where it crashed it looked like it was pretty obvious what the cause was.

This one occurs occasionally when copying files from sharefs which then results in
‘ShareFS may not be used recursively’

Abort at &FC11B660 offset &00000CF4 in MessageTrans

If this one happens again, can you get me a register dump? I haven’t seen it myself, but after checking the ShareFS sources I’ve spotted some code that looks like it could cause this.

I’m about to build myself an up to date disc image, so will hopefully be able to get to the bottom of the Printers and Omniclient crashes sometime soon.

This one should now be fixed, I think. I couldn’t reproduce it myself, but judging from where it crashed it looked like it was pretty obvious what the cause was.

I haven’t had the abort since so looks fixed.

Here’s a few more,

I’m now getting an abort on startup, abort at &fc3230b8 0×80000002. I have to unplug sharefs and reboot to continue.

Digital CD 3.06
Play wav, mp3 etc..
Address &FC144AE0 is at offset &00013078 in module SharedCLibrary

ArtWorks 2.XI.01
Click in ArtWorks window
Address &FC12D614 is at offset &00017E04 in module WindowManager

In the Boot configuration plugin clicking on ‘Add to Apps’, ‘Look at’ and ‘Run’ produces an abort.

clicking on zap iconbar icon. this is with a fixed zap module which you won’t have.
Address &FC1EEE58 is at offset &00000798 in module International

I’m now getting an abort on startup, abort at &fc3230b8 0×80000002. I have to unplug sharefs and reboot to continue.

Ah, looks like a bit of a mixup when a new version of the binary was checked in earlier today – it’s reverted back to the version just before my fixes.

Jeffrey, the printers error is from SharedCLibrary Address FC14CAA4 offset 12EF4
It happens at the first SYS “XRemotePrinterSupport_Enable” call in the Sparrow source file.