Armx6 not booting
Barrie Clark (7019) 3 posts |
Hello everyone. I was a RiscOS user back in the 1990s with an A5000 and then RiscPC. I have missed the OS dearly since and recently decided to take the plunge and buy an ArmX6 from R-Comp. The computer arrived and worked okay for a few days. However Last week I turned it on and it crashed on loading after init mod NFS with the message mod init doneError: DataAbort:Abort on data transfer at &FC222D84 and sat there. I can still type *Desktop and get to a rudimentary desktop but I have no idea what to do from here. I reached out to R-Comp a few times but have been greeted with silence. I am not sure if they are just closed for the holidays (in which case an automated email response would have been nice) or that they don’t really care once they have your money (which I hope is not the case). So, before I started demanding a refund I thought I would ask here in case its something of an easy fix. I never had any issues with my old machines so this is all a bit new to me. Thank you in advance for any help you can give. |
Steve Pampling (1551) 7929 posts |
It will be the holidays. You may get a response via these forums if the email isn’t picked up soon.
Sounds like a failed/corrupt boot sequence.
If the boot structure is still visible – in the desktop hold down shift and double-click on boot (remember that old trick to open application directories?) then you can mouse around the structure to check things out. If it’s a bit of added software (non-32bit, or non-ARMv7) then simply removing that item from the boot should fix things. |
andym (447) 463 posts |
It might be worth doing the following: *configure filesystem SCSI just in case the CMOS battery has gone. Also, on the ARMX6, there is a recovery partition on the SD card that holds the ROM that you may be able to use to recover your !Boot sequence. You may also be able to boot from it but you may not want to as this will potentially muck up your recovery image. |
Barrie Clark (7019) 3 posts |
Thanks for the suggestions. I did go to the SD card and drag over the !boot from the recovery folder to the SSD drive and replace the one there. Same result sadly. |
Steve Fryatt (216) 2045 posts |
OK.
Assuming this means that you’re at a Whilst you’re there, also do Knowing the results of both of those would be useful.
As others have said, it’s the holidays! R-Comp are largely a one-man band (albeit with a good network of additional help), so allowing them a little time off seems only fair. An automated response would be nice, but sometimes circumstances intervene… Andrew and I have certainly disagreed on his approach to support on occasions, but I would genuinely be surprised if he had decided that he would ignore you because you had paid him in full.
That feels a little premature. :-)
It sounds as if something is broken in your boot sequence. That kind of thing can be a pain to diagnose because RISC OS is fundamentally a toy OS from the 1980s with little or no robustness in its handling of !Boot1, but once found, is usually fairly simple to fix. 1 OK, I might be a little biased on that, having rendered machines unbootable several times over the years. |
Barrie Clark (7019) 3 posts |
Thanks for all the help. It was fixed with a CMOS reset (Thank you Andrew). Everything seems fine now. |
Steve Pampling (1551) 7929 posts |
Indeed. You have thought that by now a coder round here might have written something to sit in the very early !Boot that would catch the stumbles of the built in Boot sequence and maybe even log the result in a nice file that said what exactly had gone A-over-T and taken the Boot sequence down with it… Barrie you’ve been away awhile so my comments might seem cryptic. |
B Clark (7019) 9 posts |
Thank you Steve. That is a great looking app and I am going to give it a try. Thanks again. |
Andrew Rawnsley (492) 1405 posts |
Just in case anyone else comes across this thread, and is struggling… If the error occurs during the “ModInit” stage (ie. before the screen clears and shows “RISC OS 2048MB RAM” (etc or similar), it is almost certainly not a !Boot related problem, as the Boot sequence doesn’t kick in until after that point. Any software solution (eg. Harinezumi or Reporter) won’t help, therefore. Problems (with any RISC OS system) at that point will be either hardware or CMOS related. A module may be unplugged, or a USB device or SSD or ethernet issue may trigger an error at that point – it is when the various OS modules are initialising and “coming up”. The modules will pull their settings from CMOS, and interact with any relevant hardware. Personally, I’ve seen crashes (on various machines) during this phase cased by corrupt CMOS, incompatible USB hardware, a peculiar CD ROM left in the CD drive which confused PartMan module, a failing SSD and so on. Resetting CMOS (either by delete-power-on or reflashing the OS [doesn’t apply to all boards]) tends to be an excellent place to start, as does disconnecting USB devices/drives. |
Jon Abbott (1421) 2598 posts |
The number one killer I have is upgrading the ROM to a newer build when new Modules have been added or the order changed. Before upgrading to the latest ROM, you should *RMReInit any *Unplug ROM Modules, save the CMOS, upgrade the ROM, reboot then *Unplug any Modules you had previously unplugged. |
Steve Pampling (1551) 7929 posts |
I do wonder whether there might be a good use for a utility that could:
Preferably built into the ROM and with a simple keypress for a boot restoration. (Ctrl-Home perhaps?) 1 and now RMReInit joins the local dictionary. I’m teaching this thing RO jargon bit by bit. :) |
Jon Abbott (1421) 2598 posts |
Or change the code that initialises the ROM Modules so each (CMOS Module table) bit is allocated to a specific Module name, instead of its bit position being used as the Module number…so the issue doesn’t exist in the first place 🤔 |
Andrew Rawnsley (492) 1405 posts |
Since this is an ARMX6 thread, I should point out the the standard OS updater tool we supply with our OS upgrades deals with the issue of unplugged modules and changing module numbers automatically. There’s no need for a user to do any of this. Indeed, one of the suggestions I made to Barrie over on the Iconbar thread was (if del-power-on didn’t work) was to run the OS updater, as I knew it’d deal with that (since he could get to a desktop). Of course not everyone has ARMX6 or TiMachine. But this is another reason why they make a good choice! |
Steve Pampling (1551) 7929 posts |
However, that doesn’t cover the instances of a migration of more extensive rebuild.
I was thinking wider than a single product or supplier.
Mind you the origin of the thread does point to a requirement for better documentation on problem recovery. Improvement suggestions are fashionable :) |
Alan Adams (2486) 1125 posts |
I also have an intermittent problem that sounds quite similar to this. When attempting to restart the ArmX6 I get nothing displayed in the monitor, except it’s own message “out of range”. During a successful boot this message appears for around a second before the desktop is displayed. During the failures it shows for a minute or so, then the monitor goes dormant. |