Internal Error Nos. &800000X

Dave

There are all sorts of people who try to help on this forum across the “expertise” spectrum and I by no means class myself in the top half of that mix.

I guess I was trying to point out that the Language setting didn’t give that error here with the same setting you had and thus perhaps not relevant to your issue. However the fact that you booted in to a desktop that could not be configured when you set it to 10 (Desktop) did point to an issue with your !Boot set up/configuration and hence why I also mentioned checking your widget.

Hopefully you have a working BB and RISC OS now.

I have checked the widget and it wasn’t loose and would have been surprised if it was.
I am still getting the problem of “No Boot Application has been run on startup ….”. If I do a shutdown followed by clicking on the Restart button, then it runs !Boot.
In the list given by *Status is a line “Ignore 10” immediately preceding the line “Language 10”. Does anyone know what the Ignore setting does? Is it relevant?

Ignore 10 is not relevant.
Back in the dark ol’ dusty days of yore when printers couldn’t tell £ from #, another lurking gotcha was what sequence to send for a “newline”, because technically a newline is two characters (carriage return, then line feed; hence the acronym CRLF). However, printers being somewhat bloody-minded had their own specific ideas and frequently the CR (ASCII 13) would suffice and the LF (ASCII 10) would need to be suppressed otherwise output would be double-spaced. Hence, IGNORE 10 (instructs RISC OS to “eat” all 10s to the printer port). This is for raw printing, I believe the printer driver does its own thing here.

Amusingly, the CRLF lives on in the line endings in DOS/Windows files despite the fact that two bytes aren’t needed to mark “end of line”…

Thanks for the explanation of Ignore 10, it’s quite interesting.
I wonder whether my problem is hardware related as sometimes powering up from scratch does run !Boot; but this seems to happen only when I have used BB recently, so it might be because BB is warm. I have had a similar problem with failure during bootup to “contact the DHCP server for etherUSB interface”, but it establishes contact after clicking on the Retry button or if BB has recently been used. My BB is not a BB-xM and so BB uses a USB-ethernet adaptor.
Using Scroll Lock on the keyboard, I have managed to read some of the text appearing on screen prior to !Boot being run and amongst the text are the following error lines.
“error: No ‘Econet’ installed” (appears several times)
“error: RAM disc size too small”
“error: AUN not configured”
I have not yet configured networking as I wanted to have a !Boot as close as possible to the one downloaded from ROOL on 22/9/12. All I have added is some extra MDFs and configured for a 1360 × 768 screen mode plus some settings for some patience games in !Boot.Choices (that are not run or booted at bootup). Apart from the few files affected by this, the only other file with a date after 22/9/12 is ScrnSetup which is a one-liner, “Unset ScrSaver$Dir”.
Further, I gave different names to all the other 3 directories that the system looks at on booting, so that just the 3 that came with the ROOL HardDisc4 are seen at bootup.

I wonder whether my problem is hardware related

That is a possibility, though the thought that came to mind first was that maybe something is initialising but isn’t quite ready in time for the first boot?

It’s a bit of a shot in the dark really, we’d need to know why the machine is failing to run !Boot, but I suspect if a reason is being given (“Drive not ready” or whatever) it might flicker away before you’ve had a chance to read it.

Here’s the thing – when RISC OS starts, it may or may not list the modules as they are scanned/loaded/init’d (I think 5.19 does and 5.18 doesn’t?). Then the screen will go black.

Then you’ll see something like:
RISC OS 512Mb
ARM Cortex-A8
<something else here, I forget>

Just below this will be what you are looking for. You see, with a normal boot you’ll get the stuff about toolbox modules and then a running résumé of the predesk stuff as it gets loaded. But if boot fails, you’ll probably see an error here instead.

Using Scroll Lock on the keyboard, I have managed to read some of the text appearing on screen

Try holding Ctrl until some text appears, then hit Ctrl and Shift to pause output, then let go of Shift only for the next line.
[Ctrl does line advance in slo-mo; Ctrl+Shift does a scroll lock … you just gotta be careful not to be holding Shift when RISC OS is deciding whether or not to run !Boot (as a Shift-Boot means to skip !Boot ;-) ).

“error: No ‘Econet’ installed” (appears several times)
“error: RAM disc size too small”
“error: AUN not configured”

The first is normal – you don’t have Econet. It’ll be Econet, NetFiler, and NetFS aborting on initialise (because these modules “go away” on non-networked machines).

The next… Don’t have a recollection of this one. It is possible (although perhaps slightly braindead, ho ho) if RAMFS starts up and gives this message in the configured RAMdisc size is zero.

Finally, AUN not configured is……..probably because AUN hasn’t been configured. At a wild guess. But I may be wrong. (^_^)

Okay.
The thing we’ll need to know is the bit that looks like this:

RISC OS 512Mb
ARM Cortex-A8
[something]

When the !Boot fails, what messages appear just below? This should give an indication of what is happening.

TIP! Possibly the simplest way to do this without needing to fiddle with keypresses or bionic vision is to just point a video camera at the screen. Don’t have a video camera? Any Smartphone (Android, iThingy, Bada…) or featurephone made in the last five years with a non-crap resolution (say, 640×480 as a minimum) ought to work. Then copy the file to a PC and frame-step to the important part. If you can’t do that or don’t fancy taking time to figure it out, drop the video onto YouTube as an unlisted video and paste the URL here. I can pull the video and step through it. Just, you know, play it back on the phone once to make sure it is readable and not blurry or such.

I wonder whether my problem is hardware related as sometimes powering up from scratch does run !Boot; but this seems to happen only when I have used BB recently, so it might be because BB is warm. I have had a similar problem with failure during bootup to “contact the DHCP server for etherUSB interface”, but it establishes contact after clicking on the Retry button or if BB has recently been used. My BB is not a BB-xM and so BB uses a USB-ethernet adaptor.

Q1. What style of power supply do you have?

Q2. If the failure occurs more often when the unit is warm try cooling the USB hub chip (just inboard from the USB ports.
On my -xM the chip tends to be the warmest on board.

One test you might be able to try is connecting the USB port that normally houses your memory stick holding the !Boot to apowered USB hub and connecting the memory stick to that as it may be a limit on the available power to your USB devices.

@Rick Murray
There isn’t a smart phone or video camera in the house, except on my EeePC Netbook — I could try that.
After the 3 lines
RISC OS 5.12Mb
ARM Cortex-A8
Acorn SCSIFS,
I get the Reporter message in red.

This seems to be right as I have installed Martin Avison’s Reporter to report what happens during !Boot and that is what I get on my Iyonix where I have Reporter installed. But, of course, if it has got this far !Boot has started. I don’t think there are any lines after those first three that you mention other than ones after !Boot has started (running the Obey files in Choices.Boot.Predesk). I have tried using CTRL and Shift to read the text and don’t see anything more than this.
I get three error messages from Reporter (red lines):
“Filing System or path BootFX: not present”
“File ‘VIDCBandwidthLimit’ not found” and
“File ‘BootResources:Configure.Monitors.BeagleBoard.!Sprites’ not found”.
The first is in the context of !Boot.Utils.BootRun, the second in the context of Choices.Boot.PreDesk.Configure.!Run and the third in !Boot.Resources.Configure.Monitors.

@Steve Pampling
The power supply is a Switched Mode AC to DC Adaptor from Maplins set at 5v with output of 5amps (at this voltage).
Wrong way round: The failure to run !Boot occurs when BB is cold, unlikely when BB is warm (= just been used).

One test you might be able to try is connecting the USB port that normally houses your memory stick holding the !Boot to apowered USB hub and connecting the memory stick to that as it may be a limit on the available power to your USB devices.

I don’t know what you mean by this. I am using just one USB memory stick which has !Boot on and the other directories, and the USB hub is powered. As I said earlier in the thread, my BB is not an xM model and has just one USB port.

Greetings Comrades in ARMS!

My Panda has once again given the dreaded message on booting:
“Error: Internal error: abort on data transfer at &FC12D64C (Error number &80000002)”
followed on the next line by *X , where X is a ‘funny’ character that you see only in binaries.
Panda got as far as loading !Reporter at the beginning of !Boot and even ran the connection to LAN via DHCP.
OK, Theo, I have remmbered this time to look up, in this thread, what this error means. :-)
Despite configuring !reporter to record bootlogging with bootlog = on, nothing was saved to the ReportLog file in !Reporter. :-(
Anyway, after trying various things for a bit hoping to find where the error was, I decided to apply what worked before (despite loads of suggestions that got Panda nowhere): Copy into the bootloader partition a fresh version of the RISC OS ROM.
Shock, horror, there is no OMAP4 ROM in the ROMs downlaod section! Where has it gone?
So I make do with the same version of OMAP4 dated 22/09/2013 (V5.21) that was on the SD card. Hey Presto, Panda boots up to desktop, but with a (different) error that I have seen before and can be cancelled without any ensuing problems.
Now, using Verma, I see that the address &FC12D64C is between the address of WindowManager and the (greater) address of TaskManager. So there was something wrong with WindowManager?
(The ReportLog file is still empty.)
Wierd or What?

Despite configuring !reporter to record bootlogging with bootlog = on, nothing was saved to the ReportLog file in !Reporter.

I am not sure exactly what you have set: I assume you have set ‘Start Reporter in Boot.!Run’, but I am not sure if you have ticked ‘Logging’ in the BootLog tab, or what your <ReportLog$Path> is set to. When it did boot, was anything displayed from boot in the Reporter window? If you tick ‘Logging’ in the Desktop tab, and re-start Reporter, do you see anything in the ReportLog file then? (Incidentally, the next version should be easier to set up in this area).

@Martin
I did tick Logging in the Boot section of Reporter Customisation (BootLog section has no option to tick Logging). The reply to *show ReportLog$Path is SDFS::HardDisc0.$.Utilities.!Reporter . Actually, this is what I did after I got Panda to boot up correctly. All I could do when it wasn’t completing boot was manually alter the setting to LogOn=1 in the !Config.Confix file (with the SD card in a card reader on my Iyonix). I have just noticed that there are 2 places in this file with line LogOn=X , where X can be 0 or 1. I only altered it in the paragraph beginning [command]. But no matter, I have that Logging button ticked and the ReportLog file is empty.
I have tried this on the Iyonix and it works. So I must be ‘ticking the right boxes’.
To answer your other questions, the Reporter window is working as usual and, no, there is nothing in the ReportLog file. I haven’t tried ticking Logging in the Desktop section, but this is not ticked on the Iyonix either.

I suspect that the log open is failing for some reason. I am not familiar with the Panda setup, but presumably SDFS is in ROM, and HardDisc0 is the boot disc? Please can you delete the log file, then try *ReportLogOn then *ReportLogOff and see if that creates and writes to the log file. Perhaps email me the results?

Shock, horror, there is no OMAP4 ROM in the ROMs downlaod section! Where has it gone?

Not there again today, neither is there a trace of it. Does this mean that the OMAP3 ROM should now be used on the Pandaboard and it just self-tests for the right hardware? That seems the most obvious conclusion but I haven’t had time to try it yet.

I have the 5.21 ROM dated 20 oct 2013 running on my Panda.
Seems that is the last one that was available on the website.
Will OMAP4 support be continued?

OMAP4 ROMs being missing from the website is probably just a temporary glitch. I’ll send ROOL a mail about it to make sure they’re aware of the problem.

Good to know :-)
I already recompiled a new RO 5.21 from sources. 5.21 seems a little less stable, could be my setup though.

OMAP4 ROMs being missing from the website is probably just a temporary glitch. I’ll send ROOL a mail about it to make sure they’re aware of the problem.

Indeed. We had a query relating to licensing and decided the best option was to temporarily take down the OMAP4 build. Sorry. :( It’s pretty trivial so we hope normal service will be restored in the next few days (although attending the London Show means we can’t sort it out before next week).