Clean Boot

Having finally got my Beagleboard to boot into RISC OS I have hit a little problem:

I can’t configure it!

This is a twofold issue:

1) The SD card isn’t showing up as a drive.

2) I don’t have a clean !Boot folder <—even though I have two Iyonixes they have been mucked about with so much over the years I wouldn’t dare use their !Boot folders!

So what can be done?

In response to 1) that is one for the experts on another thread…

In response to 2) (and the reason I have posted this to the General Forum) would it be possible for ROOL to have a link to a “clean” !Boot?

i.e. something similar to the CD you used to be able to buy from Castle which enabled you to rebuild to an “as delivered” state.

We’re working on getting a full RO5 boot sequence available. Keep watching this site… :)

I think this is great. Is the intention that this might be usable on all machines? Say, back to RISC OS 4 (3.7 would probably therefore work, but have to draw the line somewhere). In particular, on RPCEmu (assuming RO5 on that), but also on RiscPCs/ARM7500 machines and Omega, even if have RO4/Adjust (appreciating that you might lose the multi-user stuff for now)?

I appreciate that every machine is a little different (and therefore for the moment excluded A9/Select/RO6 here), and this is a complex problem. It’s also the kind of thing that would fit very well into RiscPkg – there are obvious subdivisions inside !Boot, and it avoids more complex issues of applications moving around, since !Boot is always in a fixed place (at least in relation to the configured filing system).

Yes, we want to construct the Universal disc image, but starting with RISC OS 5 because that’s where we are at now. It should work on RPCemu, assuming we (or someone) were to finish the relatively small amount of work needed on the IOMD HAL to get that ROM working properly.

I’d love to see our downloads moved over to RiscPkg, if someone out there feels like that is a job they could do, then drop us a line at info@riscosopen.org.

Look at the page below for the first release of our experimental HardDisc4 archive. This is the full RISC OS 5 disc image, built using the ‘Disc’ build from published sources.

You should read its associated wiki page (the Info link next to the download) and let us know of any issues you find with it. This is experimental software so don’t go throwing your current disc image away just yet…!

https://www.riscosopen.org/content/downloads/other-zipfiles

I’ve had some success with the hard disc image from the 20030423-019-000 Iyonix upgrade CD on a USB memory key. It has a version of !Configure that works (which I understand isn’t the case for some images) and I’ve even had ARPlayer working. I’ll try to do some proper testing when I have a chance.

I’ve had some success with the hard disc image from the 20030423-019-000

I’m not sure why a 6 year old boot is interesting for testing. If you’re really desperate and have no other choices, yes you could go back to it, but it won’t be at all up to date.

@ Stephen Crocker – I have no idea what the 2003 hard disc image is you are talking about. It’s good that you have a boot sequence showing signs of working, but I’d rather people experiment with a boot sequence which is actually reproduceable – i.e. the one I’ve uploaded. The ROOL boot sequence is built completely from published source code using a released build so we are in a position to identify the source of any problems and fix them.

Ok, these reports aren’t the greatest – my Iyonix has to share the same monitor as Linux PC. But I tried it out.

Perhaps more a reflection of how RISC OS has evolved, rather than a real bug, but something during boot complains about lack of the Zap resources (which naturally the clean boot didn’t contain). I couldn’t find the culprit, but probably something in Apps, which is being booted.

In Configure, screen setup gives me an error (from toolbox) about resource 0xffffffff not being found, but continues after that anyway.

For interface configuration in the network setup, I get a slightly similar error, and no interfaces are shown.

Finally, using the test 5.15 softload (the ROM inside seems to be dated July), and using my existing boot, I get an abort during boot very earlier on. From earlier testing, this is from one of the Basic programs inside !System (again, can’t immediately name it from here).

Some clarification:

On http://www.riscosopen.org/content/downloads/other-zipfiles:

There are two versions of the 5.15 ROM - inside the archives, one is dated July, and other September. The implication on the page is perhaps that one is for softload and one for flashing, even though there’s no difference (AFAIK). Plus, the date on the page for all the archives is Oct 2nd.

The abort in !System I’m seeing with both versions of 5.15 is from the Basic program SysPaths. I did a double-check against *unplugged items, but that’s only has 3 ShareFS related modules. That SysPaths is identical to the one in the newer boot sequence, and I think hasn’t changed since 2003.

I hit that problem whilst hacking a simple menu into my boot sequence to softload or boot as normal.

It looks like this is a problem with the BASIC module, RMLoading an older version of BASIC (I used a locally built 1.37) and BASICTrans (2.09) before running the rest of the boot sequence appears to work around the problem and my slightly extended boot sequence completed to give an apparently functioning desktop.

Can someone have a pop at building some of the recent revisions of BASIC and seeing which one introduced the fault? I’d love to offer to do this myself but I’m up to my eyeballs in other work :(

Further to that, looking at the cvs logs, the final revision (from BASIC 1.43 to BASIC 1.44) looks likely to be the suspect. I think someone needs to have a look at the diffs to check if that has caused the new bug.

Having not actually tried the posted !Boot or any of the OS build yet, I’m wondering what could be the process for users updating to the latest pre-built component releases (when more people start running RISC OS on the new hardware)?

Could !Boot automatically load the OS from the newest (date-named, e.g. 20091008) directory location? A manual override would be desirable in order to easily revert to a previous build. An auto updater or other application could then fetch the latest build, which would be used on restarting the system.

Apologies if this has been covered elsewhere.

I’ve been tidying up the boot sequence a bit this weekend. Main changes are:

• The softloaded SCSI modules are now included, so Iyonix users should have working USB mass storage drivers. RTSupport is included as well (in !System) so they’ll benefit from the speed optimisations.
• !SCSIForm is now included
• The broken screen setup & internet setup configure plugins are fixed
• The EtherK autosense file is now included in InetSetup, so Iyonix owners should have their main network interface(s) listed
• !ResetBoot will now work properly

Also, the problem with the broken BASIC module is that it’s using a broken version of the LDW macro. The version of HdrSrc.hdr.Macros on the cortex branch is correct, but the trunk branch is broken – I’m guessing Ben Avison forgot to check in the change for the trunk branch when he updated the macros. I’d fix it myself but I don’t have write access to trunk for HdrSrc :(

It’s great to see some great work being done on RISC OS that will result some in signifcant gains for all users. That being USB support greatly improved, and of course the Cortex-A8 hardware support.

RISC OS has needed a new fast hardware platform for a long time. Looks like we are almost there thanks to your work. Hopefully, the less technical users such as myself will be able to ditch our aging RiscPC hardware soon, and upgrade to a decent hardware platfrom that your port allows.

Excellent work mate.

Excellent work mate.

Cheers!

Also, HdrSrc has now been fixed, so BASIC should work again the next time ROOL run their autobuilder.

I’ll try to do this on Wed if time permits – I’ve also noticed ChangeFSI on our web site is bust (again) – this seems to be very temperamental at building. :(

Thanks for doing this work on the disc image for us! There’s definitely a forum topic potential here to discuss ways to make the boot sequence better. I can think of a number of areas where I’d improve it.

Hi. The BASIC module download which is on our site (and BASIC64) should now be fixed. The crashes were actually caused by another part of the build tree not having had some updates it needed which meant the BASIC module build process was generating broken code.

I’ve not up-versioned the module itself because no (source) code changes have been made.

Oh, and I rebuilt the HardDisk4 RISC OS 5 disc image archive and all of the ROM image archives, as well as making the ROM softloading installation process better (although I’ve not tested it!!) so feedback would be very welcome.

Now using the updated ROM, although the date on the version of April is still a bit confusing.

I still have the very annoying problem (over 5.13) of either or both of the mouse and keyboard being non-responsive after boot, and requiring them to be unplugged then put back in.