!Store sale starts Jan 1st

I think the use of ZeroPain should remain an option for the long term (which it effectively is, albeit unofficially)

Hmmm, if you’re talking about use by non-programmers there is the small issue of those not in the know creating a 2016-valid or forever-valid¹ version of ZeroPain.

¹ “Forever” in this instance having an unknown endpoint that is probably a lot sooner than most peoples definition of forever.

I’ve just got data power, which has reader 3.16 (14-Mar-2014) for RISC OS
Anyway, back on topic are we not forgetting the long standing issue of the pixie mites?
Isn’t that a real RISC they may burrow into our ARMs?

as this isn’t a problem that’s going to get fixed overnight.

Not to mention future problems and screw ups. The wonky pointer problem is as old as C itself, some might suggest that various “attributes” of the language make it rather too easy to stumble into…

Until there is a stable build for the Pi the arguments about development builds only being aimed at developers don’t ring very true to me…

Ah, I was wondering why I couldn’t spot any big arguments about the ZeroPain deadline. They were all hidden in this thread!

A few key points:

1. Yes, the 2016 ZeroPain deadline & RISC OS 5.24 zero page relocation deadline were a bit aggressive. Probably a bit too aggressive, judging by the fact that ROOL have yet to release a zero-page safe version of the DDE. But without an aggressive deadline there’d be the risk that people wouldn’t take the change seriously enough and we’d end up having to push back the deadline more than we’d like.
2. Andrew Rawnsley’s suggestion of keeping RISC OS 5.24 with zero page in its old configuration and pushing the zero page relocation deadline back to RISC OS 5.26 is sensible, and IIRC it’s an idea that was raised when I was first working out the deadlines with ROOL.
3. There’s no future hardware technical requirement which is forcing us to implement the zero page changes. The decision to implement the changes is based purely on some shared beliefs that ROOL and other developers (like myself) have on how the OS should be. There are two core beliefs behind the change:
   1. Having kernel workspace (“zero page”) located at address zero has an adverse effect on the stability of the OS. If a module accidentally writes to a null pointer it will overwrite the processor vectors and the machine will hang. If you perform the same action with zero page relocated then there’s a good chance that only the module will crash, not the entire machine. Reading from zero page can also cause issues – in released software these will usually be in the “mostly harmless” category, but during development it’s nice to know about the problems right away rather than having to spend hours debugging your code only to find that the bug you were seeing was caused by a null pointer dereference that could have been identified in a matter of minutes had the software simply crashed straight away.
   2. Software shouldn’t be accessing (private) kernel workspace by hardcoded addresses (and ideally, software shouldn’t be accessing private kernel workspace at all). Moving the kernel workspace to another location allows us to ensure the policy of “don’t do that” is enforced, and it gives us the freedom to make large, sweeping changes to the kernel workspace in the future (multi-monitor support; threading/pre-emptive multitasking; memory management improvements; etc.) without having to constantly worry about breaking legacy software which directly accesses kernel workspace.

I’ll chase down some members of ROOL and see how they feel about the way things are progressing (I know I said I’d do this a few weeks ago, but sadly I didn’t get round to it).

There’s no future hardware technical requirement which is forcing us to implement the zero page changes.

Oh, okay. Five…four…three…two…one…

I’ve been following the arguments in this thread as best I can – I’m not a programmer and have only a shallow understanding of the systematic elements under discussion, so hope I will be forgiven if I say something stupid. As a RISC OS user of long standing (22 years and counting!) and having used most flavours of RISC OS on most platforms (starting with 2 on an Arc 400/1, currently 5.21 on a Pi2) including RPCEmu for a while, I am strongly in favour of zero page relocation because I believe the OS should continue to develop, and I think it is worth taking some risks to achieve that. After all, at least two effective emulators are available – one for free – if one must run legacy software, as well as the Pi A, B and Zero running 5.21 RC14 in ARMv5 mode plus Aemulor, so I don’t buy the argument that the risk of breakage should prevent development. The full benefits probably won’t be seen for years, but the possibility of having an OS that is fast, stable and able to use the full capacity of modern multi-core chips is too appealing to spurn, IMHO. Such an OS would be considerably more attractive commercially too, I dare say.

I agree – the only difficult decision is in the detail – exactly when and exactly how should this be implemented. My view is that we should make it as easy as possible for those using the Raspberry Pi to (1) update their system to a ‘zeropain enabled’ one that will log errors and (2) encourage them to post ZeroPain logs somewhere specific for developers to assess and identify which application caused the error report and provide feedback to the relevant software author (if any). I have made a suggestion as to how this might be achieved by private message.

Is there a preferred ‘zero page relocated’ Pi ROM? Is it just a question of replacing RISCOS.IMG and offering up a quick prayer before rebooting (having first cloned the RC14 SD card image just in case)?

Is there a preferred ‘zero page relocated’ Pi ROM?

Until the situation with zeropain expiry is addressed I’d say peoples best bet would be to use the build that was done immediately pre-Xmas as that contains the most bug fixes. That way you can use a 2015 build and a 2015 zeropain module.
That of course assumes the person concerned has a copy of that build, or knows where to ask for one.

Is it just a question of replacing RISCOS.IMG and offering up a quick prayer before rebooting (having first cloned the RC14 SD card image just in case)?

Pretty much.

Andrew Rawnsley’s suggestion of keeping RISC OS 5.24 with zero page in its old configuration and pushing the zero page relocation deadline back to RISC OS 5.26 is sensible,

I rarely disagree with your comments Jeffrey but in this instance I’d say current ROM build and a working zeropain module to thus maximise the use of a setup that logs ZPP errors is probably best.
That combined with Chris’s suggestion of making it as easy as pie to post all recorded errors.

While I stand by my other comments of the timetable being a touch aggressive that does not mean the idea should be abandoned. Just a little refinement: more time and easier reporting.
After all the developers responsible for the DDE and the OS need time to fix the errors there before we start chopping out the ZP “patch” and reporting.

Is there a preferred ‘zero page relocated’ Pi ROM?

My preference is for the 30-Dec-2015 build Edit: (which is the same as the 20-Dec-2015 build as no further changes were made to CVS in 2015) which includes EtherUSB 0.35 (AX8872B-based USB to Ethernet adaptors now supported).

I rarely disagree with your comments Jeffrey but in this instance I’d say current ROM build and a working zeropain module to thus maximise the use of a setup that logs ZPP errors is probably best.

Concur. We still need a little more time to log errors from ZeroPain. And to get the bugs fixed…

My preference is for the 30-Dec-2015 build which includes EtherUSB 0.35 (AX8872B-based USB to Ethernet adaptors now supported).

Reasonable. But I didn’t download anything in that time period 2015-12-20 jump to 2016-01-03 so I’d rather blanked my mind¹

We still need a little more time to log errors from ZeroPain.

Indeed, hence the pointer to a stable ZPP version to iron things out.
After all “After all the developers responsible for the DDE and the OS need time to fix the errors”

¹ Or, if you like I’d rather blanked my mind in the festive period. Nothing to do with wine I assure you. Beer and Scotch might have a bearing…

After all “After all the developers responsible for the DDE and the OS need time to fix the errors”

Ironic isn’t it?

Ironic isn’t it?

Irony? Isn’t that something to do with getting creases out of freshly washed clothes? :)

“My preference is for the 30-Dec-2015 build”: any idea where/how/from whom I might get this?

I rarely disagree with your comments Jeffrey but in this instance I’d say current ROM build and a working zeropain module to thus maximise the use of a setup that logs ZPP errors is probably best.

I agree with this approach as well.

“My preference is for the 30-Dec-2015 build”: any idea where/how/from whom I might get this?

No.

The problem is that you also need updated firmware (BOOTCODE.BIN, START.ELF and FIXUP.DAT) as well as the ZeroPain module (still available with the development rom from the downloads site). None of this is nicely packaged for you…

Note: the 20-Dec-2015 is the same as the 30-Dec-2015 build as no further changes to CVS were made in 2015 after 20-Dec-2015 (but before 20-Dec-2015 the changes to EtherUSB to support AX8872B had not been added to CVS).

Is it just a question of replacing RISCOS.IMG and offering up a quick prayer before rebooting (having first cloned the RC14 SD card image just in case)?

No, see above (assuming no divine intervention for a miracle). ROM builds after Jan 1st 2016 will be no use to you, as any zero page access, e.g. during boot, will cause an error (rather than just be logged) so you may not be able to boot up again.

Neither the 20 Dec nor 30 Dec 2015 ROM builds seem to be available from the Downloads section of this site. The updated firmware is presumably available for download from here: https://github.com/raspberrypi/firmware/tree/master/boot ?
Re errors during boot, I’d be inclined to remove all ‘Look at’ and ‘Run’ applications in !Configure-Boot before changing over in any case.

*fx0
RISC OS 5.23 (03 Jan 2016)
*help ZeroPain
No help found.

I am staying in High Vector land on the Raspberry Pi for now. For my usage there is not really much to comment on.

1. Backing my SCSI pen with 7backup to a Fat32 SSD results in FileSwitch pain previously logged by ZeroPain but now errors and stops.

7backup: Internal error: abort on data transfer at &FC052CB8 (4940)
*where
Address &FC052CB8 is at offset &0000C854 in module 'FileSwitch'
*

The work around is to backup to SCSI.

2. NetFetch/Hermes fails on fetching mail.

08 Jan 16:51:42 000 00800E07: Error from (unknown): Internal error, no stack for trap handler: Internal error: abort on data transfer at &FC170C98, pc = FC170C90: registers at 000430E0

*where
Address &FC170C98 is at offset &000010DC in module 'SharedCLibrary'
*

Which is a trifle odd as previously ZeroPain reported an issue within SecureSockets. (I note RComp suggest a delay in High Vector enforcement until after OS5.24. Not an unreasonable notion, end the Low Vector era with a formal release rather than the current mid air.)

3. The biggest loss is the ROOL Tools for ROM building, to save time the less said about that the better.

HTH.

Just out of interest why does the zeropain module need to be removed?

Just out of interest why does the zeropain module need to be removed?

A vanilla 2015 ZeroPain module removes itself.

Error from (unknown): ZeroPain is not supported by this RISC OS version

Yes I know that, the question is why.

Okay… So it’s been a week and the latest available build for the Beagle and the Pi is the 3rd (AutoBuilder problem?). The Panda build is more recent, but akin to the others, is a 2016 ROM build supplied with the version of ZeroPain that only works on 2015 builds. A bit…ludicrous.

With this in mind:

http://www.heyrick.co.uk/random/zeropain_noexpire.zip

As the filename implies, it is a hacked version of ZeroPain that will not expire. Not now, not next year, not ever.

ZeroPain is being removed ahead of RISC OS 5.24 to try and make sure that any bugs that are left in the OS (or other software, for that matter) actually get reported – it’s all too easy to ignore/forget about the ZeroPain log file that’s in the root of your hard disc.

Of course there is the slight problem that removing ZeroPain reduces the amount of debug information you’re likely to get when things do go wrong – which is why one of the things on my todo/wish list is to build some better crash logging tools directly into the OS.