Boot Not Run with V5.19 on a BB

My BeagleBoard (not BB-xM) has consitently had this problem of ‘Boot not run’ at powering up since using versions of ROM and HardDisc image from, roughly, August.
BB is using ROM V5.19 and HardDisc4 image downloaded late last night (13th October). With nothing added or changed to the !Boot in this version and the default configuration, on powering up from cold BB still doesn’t read !Boot. I used !SDCreate for the SD card (4GB). To keep things simple, the Ethernet-USB adaptor is not connected.

Some observations
On doing a Restart, !Boot is read.
Under the icon for the 8GB USB stick (holding the HardDisc4 image) is just :0 although the title bar of the root directory says SCSI::HardDisc1.$ .
Under the icon for the SD card is just :0 again, although the title bar of its root directory says SDFS::RISC OS.$ .
In Configuration —> Discs Conventional SCSI is set to 0. As I have no SCSI discs attached, I suppose that is right.

With nothing added or changed to the !Boot in this version and the default configuration, on powering up from cold BB still doesn’t read !Boot.

You might find it useful to run the utility here:
www.heyrick.co.uk/software/harinezumi

and also for more detail on elements of the boot Martin Avisons “Reporter”
http://www.avisoft.force9.co.uk/Reporter.htm

The first pretty well ensures a working desktop and configure (the latter doesn’t seem to happen for you on cold boot) the latter gives details of all the items that ran before you finished booting.
Harinezumi install – just put the files in Boot.Utils and amend the Run file as instructed.
Reporter install – copy to your boot disc along with a copy of Confix (from http://www.xat.nl/en/riscos/sw/confix/), run !Reporter, select Reporters configure option and tick the box to log boot.

At the moment you don’t have a lot of diagnostic information so some means of collecting the info is required.

I already have Reporter, but what use is that if the !Boot is not read? As far as I can see, the same applies to Harinezumi. I did try Harinezumi, but, of course, no BootLog file was to be found in !Boot. I did notice the light on the USB stick flash during the power on sequence. Is the problem to do with the name of the USB stick? Why is it that I can’t get a name for the stick on the iconbar icon? I remember that with some previous versions of the ROM and Harddisc image I had a name for the USB stick below the iconbar icon, not just :0 .

Is anyone actually testing or using the latest BB ROM and HardDisc image on a BeagleBoard, even an -xM one?

I have just done a Restart (i.e., using the restart button after shutdown and guess what, BB starts reading the !Boot (I said it did after a Restart) and immediately after the 3 lines
“RISC OS 256MB
Cortex-A8 Processor
Acorn SCSIFS”
it tells me
“Error: File name ‘/SCSI::HardDisc1.$.!BOOT.Utils.harikick’ not recognised (Error number &CC)”
:-((
So much for harinezumi!

Is anyone actually testing or using the latest BB ROM and HardDisc image on a BeagleBoard, even an -xM one?

I am using the 11 Oct ROM build on the ARMini (BB -xm) without problem, but !Boot hasn’t been checked/updated since early Sept.

Dave

I have regularly updated ROM/HardDisc images as per previous dicussions we have had. I can also confirm that I have today updated to the 14th Oct ROM and had no issues with rebooting or the Boot sequence running. I previously had the 11th Oct HardDisc and 12th ROM OK.

I can’t remember if you said you had updated the contents of your PreDesk with the ones from the !Boot.510Hooks? Be careful not to copy over the SetNetUp file and Configure Directory or if not already done so try a clean !Boot and setup.

It does seem that either it is something to do with your BB Non -Xm set up that the latter ROMs/!Boot do not like or perhaps USB stick/hardware/power issue?

“Error: File name ‘/SCSI::HardDisc1.$.!BOOT.Utils.harikick’ not recognised (Error number &CC)”
:-((
So much for harinezumi!

First question: Is “harikick” present in !Boot.Utils?

Try putting a space between the slash and the filename, see if that makes it work, as the error (if typed correctly) looks like RISC OS is interpreting the “/” as part of the filename!?

The !Boot I use with RPCEmu/RO5 is as follows:

| ...lots of licence stuff snipped for forum post...
RMEnsure UtilityModule 3.10 Error This !Boot structure is only suitable for RISC OS 3.10 or later
Set Boot$Dir <Obey$Dir>
Run <Boot$Dir>.Resources.!System
RMEnsure SharedCLibrary 5.43 RMLoad System:Modules.CLib
RMEnsure SharedCLibrary 5.43 Error This !Boot structure requires SharedCLibrary version 5.43 or later
/<Boot$Dir>.Utils.BootVars
Set Boot$Path <Boot$Dir>.
If "<Boot$State>" <> "desktop" then /<Boot$Dir>.Utils.harikick else Obey -c <Boot$Dir>.Utils.DeskRun

Does yours look the same as this?

You can force it, you know.

Start up, and wait for it to bomb out with the thing about harikick not being found. You should end up at the command line and not the desktop (one hopes!). If so, then simply type:
Run <Boot$Dir>.Utils.harikick
to start it manually. Does this work, or does it still fail?

If it fails, enter:
info <Boot$Dir>.Utils.hari*
and report what it says.

it tells me
“Error: File name ‘/SCSI::HardDisc1.$.!BOOT.Utils.harikick’ not recognised (Error number &CC)”
:-((
So much for harinezumi!

The first message I get if I deliberately rename harikick is:
“Error: File name ‘SCSI::HardDisc1.$.!BOOT.Utils.harikick’ not found (Error number &D6)”

so the first item of note is the “/SCSI” rather than “SCSI”

check the Run file actually reads¹ :

RMEnsure UtilityModule 3.10 Error This !Boot structure is only suitable for RISC OS 3.10 or later

Set Boot$Dir <Obey$Dir>
Set Boot$Path <Boot$Dir>.
Run <Boot$Dir>.Resources.!System
RMEnsure SharedCLibrary 5.43 Error This !Boot structure requires SharedCLibrary version 5.43 or later

/<Boot$Dir>.Utils.BootVars
|If “<Boot$State>” <> “desktop” then Obey -c <Boot$Dir>.Utils.BootRun else Obey -c <Boot$Dir>.Utils.DeskRun
If “<Boot$State>” <> “desktop” then Obey -c <Boot$Dir>.Utils.harikick else Obey -c <Boot$Dir>.Utils.DeskRun

If not modify the last line to match the one above and try again.

If it does match then insert echo <Boot$Dir> on a line after after the sharedCLibrary line – I’m curious about the content of the <Boot$Dir> variable, insert it again on a line after the /<Boot$Dir>.Utils.BootVars line for good measure.

Reboot and check what is echoed.

As a total crowbar item you could edit the last line to:
If “<Boot$State>” <> “desktop” then Obey -c SCSI::HardDisc1.$.!BOOT.Utils.harikick else Obey -c <Boot$Dir>.Utils.DeskRun

Obviously the important item is get the file to run and it seems that on a cold boot the boot variables may not be correct. Needless to say the start of harinenzumi may be suffering the same problem as your cold boot desktop

¹ Assuming textile doesn’t mangle things…

First question: Is “harikick” present in !Boot.Utils?

On my systems that gives a different error number

Try putting a space between the slash and the filename, see if that makes it work, as the error (if typed correctly) looks like RISC OS is interpreting the “/” as part of the filename!?

That I think is the point of interest.

Run <Boot$Dir>.Utils.harikick
to start it manually. Does this work, or does it still fail?

obey -c <boot$dir>.utils.harikick actually. The Run version doesn’t work.

AND by mistyping the <boot$dir>. as /<boot$dir>. I can reproduce the exact error David quotes.

The question is what is setting that extra / in the calling line? is it in the variable or is it a mistype by David?

Time to go, call from work – we lost power in one building and the phones and network are down.

@Doug Webb

I can’t remember if you said you had updated the contents of your PreDesk with the ones from the !Boot.510Hooks? Be careful not to copy over the SetNetUp file and Configure Directory or if not already done so try a clean !Boot and setup.

I have not manually copied these files, but the ones in RO510Hook have been copied into Choices.Boot.PreDesk and Choices.Boot.Tasks , respectively. This would have been done automatically during a successful boot up (i.e., after a Restart).
As for hardware issues, I am using a 7-port powered hub. I will try another hub.

@Rick Murray

First question: Is “harikick” present in !Boot.Utils?
Try putting a space between the slash and the filename, see if that makes it work, as the error (if typed correctly) looks like RISC OS is interpreting the “/” as part of the filename!?

Yes, to first question. As to the forward slash, I was only folowing the instructions in the help file. So these instructions are wrong? It looked odd to me. I’ll try your new suggestion, but I don’t see how harinezumi can help if !boot is not being read.

I’ll try your new suggestion, but I don’t see how harinezumi can help if !boot is not being read.

<minor problem sorted – we have power on the data, colleague is checking the phone supply.>

Harinezumi replaces the normal repeat sequence and continues with the next item in the list even if a failure has occured.
The boot you have is failing because something is wrong in the install.

I would clean out the Choices entries you copied down the tree, taking it back to a clean boot, and then run the harinezumi utility. Then look in the location given by the help file for a file called “bootlog”

If you’re using the 0.3 revision then you can specify the location of the log file with a -l $.bootlog after harinezumi in the harikick file:

echo “Running HariKick…”
WimpSlot -next 256K
FreePool
AddToRMA 768

<Obey$Dir>.harinezumi -l SCSI::$.Bootlog

@Rick Murray

Try putting a space between the slash and the filename, see if that makes it work, as the error (if typed correctly) looks like RISC OS is interpreting the “/” as part of the filename!?

Powering up from cold as usual it didn’t read !Boot and so no BootLog. On doing a Restart, I got an error as before but with the line
“Error: File ‘/’ not found (Error number &D6)".
:-(((
As suggested, at the command prompt, I typed in
“Run <Boot$Dir>.Utils.harikick”.
BB then went on to run !boot successfully and produce a BootLog file.
The BootLog file is long, but every line starts with "Okay: " except the last which says “Now handing over to Desktop environment…”.
So what does this prove? That it read the !boot is just down to the fact that I did a Restart as usual.
I am using harinezumi_0-03alpha (built Oct 7 2012).

Does anyone know what data, e.g, configuration data or settings, is lost after power off, but is retained through a Restart (so power maintained)?

David, could you try changing ‘/’ to ‘Run’. A long shot I know. I’m sure I’ve come across strange errors like this when tinkering with !Boot in earlier OS versions.

The error you are seeing shows !Boot is being read. But is failing for some obscure reason.

Andrew: “David, could you try changing ‘/’ to ‘Run’. A long shot I know. I’m sure I’ve come across strange errors like this when tinkering with !Boot in earlier OS versions.”

Or even:

obey -c <boot$dir>.utils.harikick actually. The Run version doesn’t work.
AND by mistyping the <boot$dir>. as /<boot$dir>. I can reproduce the exact error David quotes.

Which you will note is what I have in my “Run” file.
I hadn’t noticed Ricks “/” entry before as I was editing with a flip between views on the first version and accidentally did the “obey -c” (which works) thereafter I did it from memory.

@Andrew Daniel

The error you are seeing shows !Boot is being read. But is failing for some obscure reason.

There is no evidence to me that Boot is being read when BB is powered up from Cold. Although I don’t get the error message saying something like “!Boot has not been run …”, when I click select on the USB stick I then get such a message. Read my post agsin. Yes, it reads boot if I do a Restart, so not from cold.

Hmmm very puzzling David. What happens if there is no !Boot present? I wonder if it some kind of timing issue?

obey -c <boot$dir>.utils.harikick actually. The Run version doesn’t work.
AND by mistyping the <boot$dir>. as /<boot$dir>. I can reproduce the exact error David quotes.

Eh?

Then in this case I feel there are some sort of inconsistences with RISC OS. The boot !Run file I quoted above ( here ), calls “harikick” with “/” – and on RPCEmu it works [just tried to be sure, but since I used that for developing, I knew it would anyway…] No error in transciption, I just cut’n’pasted it from the HostFS folder.

So it works on the emulator but not hardware?
How come?

Surely the behaviour of a Run action on an Obey file is to “obey” it? Err… it did come out your end typed as an Obey file, didn’t it?

Then in this case I feel there are some sort of inconsistences with RISC OS. The boot !Run file I quoted above (here), calls “harikick” with “/” – and on RPCEmu it works [just tried to be sure, but since I used that for developing, I knew it would anyway…] No error in transciption, I just cut’n’pasted it from the HostFS folder.

Hmmm, guess where the majority of my tests of Davids version were done yesterday – RPCEmu.
Same behaviour on beagle-xm.
However, I’ve just tested and specifically instructing the system to do an Obey (with or without the -c (cache) switch) works even if the file is filetyped “data” but harikick filetyped as data and called using /<boot$Dir> version fails with the error quoted.
I suggest the Help file instructions be changed to the Obey version to cover the possibility that the user has a mis-typed harikick file. Quite why it would be is open to speculation.

I think all this talk of Obey vs / and of adding logging to the boot are missing Dave’s real problem – it is not even trying to run !Boot when first switched on.

This suggest to me some sort of timing issue. Maybe the USB stick is too slow to initialise so RISC OS doesn’t even see it as an available boot device? On a restart, the stick is already up and running so it boots normally.

We will test this at ROUGOL tonight, using Dave’s USB stick on my BB-xM, and my USB stick on Dave’s BB. Hopefully that will narrow down the problem a bit more.

(Plug – Exciting talk at ROUGOL tonight, hear how RISC OS was created from the man who led the development team!)

This is a bit of an odd issue to run into, because even if the USB stick isn’t ready on startup the machine should sit and wait until it is ready. So either RISC OS is deciding not to run the boot sequence (e.g. it thinks shift was held down) or it starts to run it but fails almost immediately (perhaps due to the stick being detected but being not quite ready for action). When I get a chance I’ll try putting together a ROM image which will be able to log what’s happening.

I suggest the Help file instructions be changed to the Obey version

I’ll do this for the next version; however it is worth asking if “harikick” fails due to being untyped, wouldn’t the application itself suffer likewise?

I’ll do this for the next version; however it is worth asking if “harikick” fails due to being untyped, wouldn’t the application itself suffer likewise?

Just tested on RPCEmu (which I suspect you have too,now) and the answer is yes filetyping the application as data breaks things (as expected).

Perhaps the install should be a self extract to put properly filetyped obey and application files into !Boot.Utils and echo the help instruction to alter the “Run” appropriately. However, the idea was to add this as a facility in the standard ROM/Boot so that people had a decent diagnostic no matter what happens.

@ Bryan

This suggest to me some sort of timing issue. Maybe the USB stick is too slow to initialise so RISC OS doesn’t even see it as an available boot device? On a restart, the stick is already up and running so it boots normally.
We will test this at ROUGOL tonight, using Dave’s USB stick on my BB-xM, and my USB stick on Dave’s BB. Hopefully that will narrow down the problem a bit more.

This test on Bryan’s BB-xM using my USB stick stuck directly into the BB-xM and with his micro SD card resulted in a successful boot to Desktop.
Also, at ROUGOL, we stuck my USB stick directly into my BB (not BB-xM, I shouldn’t need to keep saying this, but people don’t read the posts carefully) with my SD card. It booted to the desktop, correctly.
Both tests used my power supply unit, but a different one to the one I had been using at home.
At home I have had a successful boot to desktop from cold with a different power supply unit, a different 7-port USB hub and using a different mains socket. So it seems probable that the problem is a hardware one and the likely candidate is one of these, but it could also be due to the BB being sensitive to timing issues.

@Jeffrey Lee

When I get a chance I’ll try putting together a ROM image which will be able to log what’s happening.

This would be very welcome, just what’s needed. I don’t think we have ever had the ability to log what happens before !Boot is read on any RISC OS computer?

I don’t think we have ever had the ability to log what happens before !Boot is read on any RISC OS computer?

By necessity, RISC OS probes the keyboard at start-up (CMOS clear, etc).
Perhaps it could be added that starting with Alt held down will write information to the screen (like the list of modules you see) and attempt to spit out same to the serial port?