Fatal error stops machine Booting

I have a Beagleboard -xM which has just been upgraded to the latest release of RISC OS 5.23. During Boot I’m getting an abort on data transfer error. I suspect one of the programs is failing to run in the upgraded ROM. Is there anyway the Boot procedure can be prevented from running?

On early RISC OS machines you hold down the shift key to stop booting but the Iyonix and I think all? machines after it can’t detect the key press early enough.
Normally pressing the escape key repeatedly will stop most/all of the boot file actions.

As Chris says, spam the ESCape key.

Thanks guys – its been a while since I’ve had a problem like this and I’d forgotten the ESC procedure. I couldn’t use the Beagleboard desktop in the normal way but I could access it from the Iyonix so was able to get access to the Boot file from their. I had to give up in the end with so many machine errors despite removing everything from the ‘Run-at-startup’ and return to the original Boot file and ROM (03-06-15). Has anyone else experienced problems with BB ROM 5.23(16-12-15)?

Have you installed zeropain – it comes with the rom upgrade

Have you installed zeropain – it comes with the rom upgrade

I think the readme actually tells you to install zeropain before booting on the upgraded rom.
I do wonder whether the general test release ROM ought to have zeropain as part of the build to make its presence at boot time unavoidable. Assuming of course that the zero page testing with a working zeropain module carries on beyond the end of this month…

No I didn’t – that may well be why I’m having these issues. I’ll have another ago but do what you suggest when I have a quiet momemt ;-)

What is suggested is to install ZeroPain.

You see, there may be something in your boot sequence that inadvertently accesses “page zero”. It is not unknown in C programs to have erroneous reads from address &0 – this is often a pointer to something that has been set up, but due to error/quirk/bug is never assigned to anything, and this pointer is then used.
Under previous versions of RISC OS, reading from &0 would return the contents of memory (the reset vector instruction) but with the newer ZPP version of RISC OS, address &0 does not exist. That’ll likely be where your abort on data transfer is coming from – the processor is being asked to read something that isn’t there.

What ZeroPain does is it traps accesses to this part of memory and fakes a few specific things (as all of the kernel workspace is there – which is the primary reason for it moving, apps just shouldn’t be poking around in kernel workspace!). At any rate, with ZeroPain, accessing &0 will work so the application won’t crash. This doesn’t mean the software is any good – a flaw is a flaw – but it’s enough of a sticky plaster that the software doesn’t collapse into a miserable heap and cry…

To give you an idea – take a look at http://www.drobe.co.uk/archives//freenet.barnet.ac.uk/Acorn/programming/docs/zeropage.txt

Since Acorn either didn’t provide an API for some values, or they provided an API through a SWI which is slow, some programs made direct accesses into the values in page zero. [if you read that as “they can’t win”, you’d be correct]

I can sort of understand this for games and demos that need the maximum speed out of slower hardware (like an 8MHz CPU), but unfortunately this behaviour carried into the desktop world where the overheads of task switching far outweigh any gains you’re likely to get from reading &10C instead of calling OS_ReadMonotonicTime. It’s pretty bad form to do stuff like this¹; though do note that some things don’t have a way to directly read them. Or, at least, did not – such as DebugTools that has to assume where the ticker chain begins, if this isn’t available from the (newer) API.

Anyway. A combination of software that makes direct access to low level stuff when it shouldn’t, and C’s propensity for polluting &0 (and nearby addresses), mean that what used to be there is being moved elsewhere, out of the way.

¹ …without a damn good reason. Low level stuff like ADDFS is a good reason, running a mite quicker…is not.