Towards BeagleBoard "CMOS RAM"

Strange.

Next question then: What OS did you use to write the CMOS file? :) Dave’s code should be case insensitive, and copes with long filenames (which I believe Windows will use for any short filename that isn’t all capitals), so I’m not sure how you could end up with a file that doesn’t work.

In fact – I’m sure Dave will ask you to do this when he comes along – can you try enabling the DEBUG_ENABLED #define in common.h and see what output you get on the serial port when it looks for a file to load?

I’m using Ubuntu. The card was also formatted in Ubuntu.

I tried renaming the file back to upper case. I got an error about the file already existing. Renamed to another name then back to ‘CMOS’. Rebooted and now it is working OK.

Dave’s read-only CMOS-on-SD/MMC code is now in CVS

I tried renaming the file back to upper case. I got an error about the file already existing.

The only way I can rationalise this is that there must be two copies of the file allocation table, only one of which is being correctly updated in some circumstances. Also that the fact that the two tables are different is ignored, each computer using the table it thinks it knows about. Horrible, isn’t it!

If I want to replace a file on an SD card, I rename the ‘old’ version and then copy over the ‘new’ version, and make sure I can see both on all computers in which the card is to be used before deleting the ‘old’ version.

Does this mean it is included in the ROM image?

I think they should be, although haven’t checked myself yet.

• The current Beagle ROM is dated ‘2011-01-23 23:27:44’
• The CVS commits seem to be individually dated ‘Sun Jan 23 22:48:14 2011 UTC’
• But the change summary is dated ’ Sun. January 23, 2011 at 11:48:07 PM BST’

It’s probably safe to assume that the build was done after the commits.

[Edit: Except the ROM has a timestamp of 21:50. I hadn’t accounted for the delay between build completion and upload.]

Sometimes we get an announcement or someone asks a question.

ROOL: something somewhere thinks we’re still on BST. Could this pose a problem if not fixed?

I have created a file ‘cmos’ on the SD card, generated using

*savecmos

*con.scsifsdrive 4

*status

It doesn’t look like my changes made it into the ROM that was built last night (the ROM image had a timestamp of 21:50!).

I’ll try and get a new image uploaded somewhere tonight. In fact I think I’ll ask Steve if he’d prefer me to send him a quick email each time I make a big change (I often seem to end up submitting changes slightly too late to make it into any builds that Steve makes!)

Considering the addition of CMOS RAM capability is a pretty big step it seems odd that a new build should be so badly timed!! I’ll wait for the ROM image to be updated.

Latest ROM image: http://www.phlamethrower.co.uk/misc2/OMAP3Dev.zip

Latest ROM image

*configure SCSIFSDrive 4
*SAVECMOS cmos

which correctly now saves 2k bytes, put the file ‘cmos’ onto the SD card and started up again.

*status scsifsdrive
SCSIFSDrive 4
[the other *STATUS items remain unchanged]

RISC OS 512MB

Cortex-A8 Processor

Acorn SCSIFS

No keyboard present - autobooting
Supervisor

*

Any ideas please?

If I rename the file ‘cmos’ (so that it is not seen) then RISC OS boots up into the USB pendrive (SCSI drive 0) as before. SCSI drive 4 is a USB drive connected to the OTG port, which works normally.

Just tried the same *commands as Chris, but my bad news is that the startup stops with the error message Internal error. abort on data transfer at &FC129310

Any ideas please?

Are you sure your drive 4 is bootable?

Are you sure your drive 4 is bootable?

Yes. With the DEFAULT SCSI drive set to 4 in a bespoke ROM image it boots up correctly.

After some experimenting, I am now able to boot into drive 4. My original attempt seems to have been scuppered by something in my !Boot, so an attempt with the vanilla !Boot from the ROOL site cured the problem. I’m now putting gradually putting things back into this new !Boot, to see what might have caused the original problem.

Just to check, I did a

*SaveCMOS

Comparing files cmosDrive0 and CMOSDRIVE4
00000080: 0B 04 - this is the current year 2011 (00B) (NetTime is now working)
000000D0: 00 20 - this is SCSIFS flags - drive 4 (020) or drive 0 (000)
000000EF: 5F 79 - this is the checksum
00000100: FE 00 - this is (IIRC) the RISC OS version number
00000101: 01 00 - this is (IIRC) the RISC OS version number

[SD card contains 'cmos' as 'cmosdrive4' above]

RISC OS 512MB

Cortex-A8 Processor

Acorn SCSIFS

No keyboard present - autobooting
Supervisor
*.
<b>The disc drive is empty (Error number &11AD3)</b>
*show Boot$Dir
*cat
[short pause while drive is mounted]
Dir. SCSI::HardDisc4.$ Option 02 (Run)
--reset--
[SD card now contains 'cmos' as 'cmosdrive0' above]

RISC OS 512MB

Cortex-A8 Processor

Acorn SCSIFS

No keyboard present - autobooting
[boots normally, f12]
*show Boot$Dir
Boot$Dir : SCSI::HardDisc2.$.!BOOT
*cat
Dir. SCSI::HardDisc2.$ Option 02 (Run)

So why is it not working?

Ah! In the first [drive 4 selected] attempt, if I immediately type ’.’ at the Supervisor prompt and press return I get the error shown above. If I then type ’.’ again and press return then the disc contents are shown. Puzzled. Wait a few seconds before the first ’.’ and the disc contents are shown correctly with no error. Looks like RISC OS is not giving the disc enough time to initialise.

Strange goings on with Jeffery’s latest ROM image and CMOS file

1. If I use the latest ROM image to boot from the pen drive, then all is well, SCSIFS 0 is mounted and all applications (which are on HardDisc4) are available. 2. If I use the same ROM image and use the CMOS file to boot from HardDisc4 I get the message, halfway through booting (mentioned above) Error: Internal error. abort on data transfer at &FC129310 (Error number &80000002) 3. Using a vanilla !Boot from the ROOL site I am able to boot into HardDisc4, and can then rebuild the Boot file so that it is very nearly the same as the one that was on the pen drive. However, some applications – notably Ovation Pro and Easiwriter – fail to run, while DigitalCD runs but does not play the mp3s. 4. If I then save this boot file as a backup in another directory and then copy it back to HardDisc4.$ it fails as in 2 above, even though it was working before I backed it up!

Any ideas?

To reply to my own post, I’ve now successfully booted to HardDisc4. The problem seems to have been caused by a couple of corrupt sprite files in Boot.Resources.configure. I replaced them with uncorrupted sprites, and everything seems to be fine. Everything working, including Easiwriter, OvationPro and DigitalCD – touch wood! I’ve a feeling the sprites may have been corrupted by an underlying problem with the Hard Drive and the way it’s been formatted.

Chris: There’s now a new ROM build up on the downloads page which should contain a fix for the problems you’re having. Hopefully it’ll also fix Dave’s problems with his memory sticks which suddenly stop booting after being used too much.

Basically what will happen now is that if the boot drive isn’t ready by the time RISC OS tries to boot from it (e.g. the USB system hasn’t detected it yet, or it’s still initialising) then it will print out a message warning the user and then sit and retry the boot procedure until it succeeds or escape is pressed.

The new ROM image (27 Jan 2011) now allows me to set SCSI drive 4 as the boot drive and boot from it. The pen drive is no longer needed! Well done, many thanks. CMOS RAM is working….

@Chris: I’m glad it’s all working. I couldn’t have done it without a lot of help and work from Jeffrey.

To everybody: is it all working for you?

I still have to check out why there appears to be this filename case issue. (It’s not as simple as just making a case-independent string comparison; anything that isn’t the old 8.3 all-upper-case format is stored differently in the directory.) My BB was tied up earlier in the week copying the contents of my old NAS drive to my new one. Painfully slow, but RISC OS and EtherUSB held up flawlessly, and I didn’t want to interrupt the copy, so I haven’t been able to try to reproduce the symptoms.

The new ROM image (27 Jan 2011) now allows me to set SCSI drive 4 as the boot drive and boot from it. The pen drive is no longer needed! Well done, many thanks. CMOS RAM is working….

RISC OS 512MB

Cortex-A8 Processor

Acorn SCSIFS

No keyboard present - autobooting

[Hold CTRL & SHIFT]
Waiting for boot drive to be ready; press Escape to camcel.
Boot:Utils.UnplugTbox
Boot:Choices.Boot.PreDesk.!+Resource
Repeat: The area reserved for relocatable modules is full
Boot:Choices.Boot.PreDesk.DALimit
Boot:Choices.Boot.PreDesk.NewLook
Repeat: Internal error: abort on data transfer at &FC129348
...
Error: Internal error: abort on data transfer at &FC129348 (Error number &80000002)
*MODULES
..
9  FC111744 20003314 WindowManager
10 FC12CCC0 00000000 Desktop
..

Any ideas please? I get the same error if I try a vanilla HardDisc4 image on drive 4. The same !Boot and HardDisc contents on SCSI drive 0 boot perfectly OK!

Before you ask, I didn’t keep a copy of the disc image on drive 4 that was working perfectly. Silly isn’t it?

Chris. This seems to be a similar problem to mine. See my earlier postings. It would seem that COPYING something runs the danger of corrupting it. (I get the impression that MOVING something doesn’t have the same effect). I’m afraid that the only solution might be that you have to do what I did -i.e. go through every directory in !Boot and delete each item one by one, rebooting each time, until you get to the stage where the boot up continues. Took me ages yesterday, but was ultimately successful.

To everybody: is it all working for you?

The new ROM seems to be working fine for me, thanks to Dave & Jeffrey for their work on achieving this!

(I’m booting from a USB HD plugged into one of the standard USB ports)

Just tried the latest ROM on my xM. Booted up, manually set the usual Configure parameters (SCSI::4.$), ran !boot manually and ran configure to set all the required settings. Saved CMOS, copied to Iyonix and overwrote the copy on the MicroSD card, put the card back in the xM and shutdown/restart – this ROM now seems to work across a restart. Due to an issue with the test EtherUSB I had to power off anyway (see EtherUSB thread), but once done I was straight to the desktop with no errors or issues along the way. Excellent work Dave & Jeffrey!

No official download yet, but over here is a new ROM image that contains a fix for a couple of bugs in SCSIFS that crept in while I was making these changes. The bugs would have resulted in the wrong areas of the disc being read/written under some situations (in fact it could even result in the wrong disc being accessed!), and is most likely the cause of the crashes on startup that Kevin/Chris have been seeing.

If anyone’s been using a ROM image from december or newer then it’s probably a good idea to reformat your boot drive to make sure there aren’t any lingering issues with files (or bits of files) having been written to the wrong place.

Just tried the new ROM image, and have been able to COPY from place to place on the hard drive, and also from the pen drive to the hard drive with no apparent problems. Thanks, Jeffrey.

Just one thing (of many!) I’m not sure of. Why should I need to reformat the hard drive, when it was originally formatted using SCSIForm on my Iyonix?