Important software compatibility notice
Posted by Steve Revill Sun, 05 Jul 2015 09:54:00 GMT
Starting from tomorrow, July 5th, the Iyonix, OMAP3, OMAP4 and Raspberry Pi development ROM images will be making use of “zero page relocation”, a change to the RISC OS memory map which moves the kernel’s “zero page” workspace away from address zero and up to the high end of the memory map. This greatly increases the system’s resilience to a common type of software bug known as a “null pointer dereference”. However, there is a catch: because the OS has always had memory mapped to address zero, large amounts of RISC OS software contains cases of “harmless” null pointer dereferences where the code reads from page zero and then does something insignificant with the result (usually ignoring it completely). With the new memory map, these programs will most likely cease to operate, exiting with a data abort as soon as they try to access page zero.
Since relocating zero page is very beneficial to the stability and security of the OS, the goal is to have the feature enabled for all future stable releases, starting with RISC OS 5.24. But due to the large amount of buggy software out there we can’t simply turn it on and be done with it – we need to have a transition period in which developers can fix their code without worrying about the fact their compilers, text editors, etc. are buggy too. We also need a way for regular users to get involved with the testing process.
With that in mind, we are putting into effect a two-phase testing process:
Phase 1 of the testing process begins tomorrow. Zero page relocation is enabled, but a compatibility/logging module (“ZeroPain”) is provided to you in order to allow most buggy software to continue to run unmodified. ZeroPain traps most attempts to read page zero and emulates the operation, providing a safe level of compatibility with the old memory map. And for any page zero access which it emulates, it adds an entry to a log file so that the user/developer is aware of the issue.
Phase 2 of the testing process is due to begin on 1st Jan, 2016. ZeroPain will refuse to run on any ROM built on or after that date. This will help to ensure that any previously unnoticed bugs are found and fixed prior to the release of RISC OS 5.24.
ZeroPain can be found within each ROM download archive. Make sure to install it before installing the new ROM, otherwise your system may not boot correctly. Please help ROOL make RISC OS a better OS by testing all your software and reporting any issues you find to the developers.
High processor vectors and IOMD support
Modern ARM CPUs support a feature known as ‘high processor vectors’, whereby the processor vectors are moved from their old location at &0 to a new location at &FFFF0000. Zero page relocation within RISC OS makes use of this feature – without it we would still need some memory mapped to address zero in order to contain the processor vectors. Although high processor vectors is currently a requirement for zero page relocation, this is likely to change in the future, in order to support zero page relocation on the IOMD (RiscPC/A7000/RPCEmu) build of RISC OS.
OS_PlatformFeatures 0 can be used to determine whether high processor vectors are in use (flag returned in bit 20). Software which needs to interact with the processor vectors directly should use this to determine their location. The address of the processor vectors should not be used to infer the address of the zero page workspace, and vice-versa.
Apart from the change in location, the processor vectors continue to operate as normal – so for FIQ handlers, you can still rely on having 228 bytes of space available for your handler code (from &FFFF001C to &FFFF00FF inclusive). Also, for future compatibility, code should not assume that the processor vectors are readable from user mode – regardless of whether high processor vectors are in use or not.
Unaligned loads
Another change that is planned for RISC OS 5.24 is to re-enable support for unaligned loads/stores on ARMv6+. For the past few years this feature has been disabled by default, to protect you against potential compatibility issues with software which assumes the older ARMv5 “rotated load” behaviour is in effect. But we believe the time to re-enable the feature is drawing near – expect to see it happen sometime during the zero page relocation testing process. By re-enabling support for unaligned loads/stores the performance of some OS operations will be improved, and third-party software aimed at ARMv6+ can more easily make use of the feature.
