Problem with hard drive on BeagleBoard 5.18

Now that the frenzy of software development for the Wakefield Show is out of the way I thought it was about time to update the Beagleboard to 5.18 from a rather old 5.17.

I have an SD card which dual-boots Ubuntu if you hold the user button down, so I did not use !SDCreate. Instead I went into Linux, downloaded the new ROM image, OMAP3-518.zip and put the new “riscos” file on the SD card in place of the old one. I had already checked my CMOS settings: no modules were unplugged.

The Beagleboard has a USB hard drive attached. It’s a genuine spinning hard disc rather than solid state, and I have cunningly wangled it so that the first partition, as RISC OS sees it, is a 75G Filecore disc, and the first partition as Linux sees it is an ext4 disc (they don’t overlap: don’t worry!). The hard drive needs more power than can be supplied by a single USB socket, so it is attached via a Y-cable to two of the motherboard sockets. None of this may be relevant, but I note it just in case.

The Beagleboard is an xM.

On booting into RISC OS the following now occurs:

The green LED between the USB sockets comes on.
The hard drive powers up.
The hard drive powers down.
The hard drive powers up.
The Num Lock light on the keyboard comes on.
Then on the screen we see:

RISC OS 512MB
Cortex-A8 Processor
Acorn SCSIFS
Waiting for boot drive to be ready; press Escape to cancel.

If I wait, nothing changes. If I press Escape nothing appears to happen. (I know the keyboard must be detected to some extent because Ctrl-Break will work at this point.) The only way I can find of getting further is by unplugging the drive and plugging it back in again, because fairly soon after the supervisor prompt appears. Then entering *. gives

The disc drive is empty (Error number &11AD3)

If I then do

*dir scsi::4.$
*.
we see the root of the hard drive (though not every time: sometimes we have a message about the disc drive being empty).

If the *dir and *. work, then entering “!Boot” will resume the boot process, albeit after a slight delay. But before we reach the desktop we get a Wimp error box saying

Message from Desktop
Machine startup has not been completed successfully: ‘Escape’

If I click Cancel, rather than “Floppy boot” or “Retry” then the desktop is largely functioning though the boot process has not completed.

Under 5.17 the sequence was rather simpler:

Green LED between USB sockets comes on.
Hard drive starts up.
Num lock LED comes on
Stuff starts appearing on the screen, including:
RISC OS 512MB
Cortex-A8 Processor
Acorn SCSIFS
then a message about “No keyboard present – autobooting” and then the usual boot messages.

Does anyone know what might be going on here? Has the initialisation of the USB stuff changed, with my hard drive not initialising fast enough to be ready for the boot process to work properly?

You probably need to save a new cmos file to your SD card with *configure SCSIFSdrive 4 if you aren’t booting from a USB stick. I believe the default in 5.18 is to boot from drive 0. Check with a *status

Thanks, Andrew. That set me on the right track. I had got a CMOS file with the correct settings but on checking *status it was clear that the SCSIFSDrive was incorrect, so for some reason the CMOS file was not being loaded.

I found an SD card I could wipe and used SDCreate, and got a working card. I then compared with what I had done. The two main differences were the CMOS file and the uenv.txt file. I am not sure whether the latter is necessary: I tried adding that to my boot card first. Still no joy, so I then tried the CMOS file. When I compared the two files the only difference was that !SDCreate had created one wchich was 0×804 bytes long rather than 0xF4, so I guess my CMOS file was failing the checksum and not being used.

Anyway, it’s all working now, and I still have the ability to boot into Linux, though the microswitch on the user button is not very reliable any more. I must have been pressing it too hard.

The drive still powers up, down and up again, which it did not used to under whatever stage of 5.17 I was using. I no longer get the message about no keyboard being present, but the boot process feels a bit longer (perhaps it’s waiting to detect keypresses before doing the disc-based !Boot?). I expect this has been covered in another thread.

Next to try is the CMOS widget I think.

(perhaps it’s waiting to detect keypresses before doing the disc-based !Boot?)

Yes, that sounds about right. There are a few things I can do to reduce the amount of time it spends doing the keyboard scan, so things should get a bit quicker once I get round to making the changes.

The addition of the keyboard scan code also explains why your hard drive powers up twice. Although the keyboard scan code (held in the HAL) initialises all the USB devices, there’s no easy way for it to pass the device list over to RISC OS once the USB modules initialise – so the OS resets the USB controllers and initialises everything all over again.