Upgrade from 5.18 to 5.19

Hi all

I’ve just upgraded from 5.18 to 5.19 and I’m now getting a number of errors when booting.

“error: RAM disc size too small”
“error: Joystick IO controller missing”
“error: No ‘Econet’ installed
“Error: DataAbort:Abort on data transfer at &FC01767C (Error Number &80000002)

My !Boot file is on HostFS which I can no longer access.

What am I doing wrong?

Best regards

fyl

There isn’t a 5.18 for IOMD (which RPCEmu is emulating), which is initially puzzling. I’ll assume that’s a typo.

The first 3 errors are OK to ignore, they are just modules stating the reason for which they are going dormant.

The last one is the show stopper, and would typically be caused by a 26 bit application in your boot sequence, but I could be wrong.

Got the same error here with the latest build. Everything’s fine with the 10th April build (and earlier) though, and my !Boot hadn’t changed between updating, so it’s not that.

I’ve just downloaded it and see there was some rather heavy editing of the actual output.

The data abort is 1 line after “init mod MbufManager”, hmm, I changed that yesterday to make it StrongARM safe, but looks like I may have broken it in the process!

If you’re not using networking you can just do

*UNPLUG MbufManager

Turns out I was actually upgrading from an earlier version of 5.19. So it’s an issue with the current version of 5.19.

Sprow: It doesn’t begin to load the boot sequence. As I said, my !Boot is on HostFS, which it can’t access.

Confirming that unplugging MbufManager works – looks like that’s the problem. :)

Yes, works here too with MbufManager unplugged.

At least I now get a consistent non-startup. :-)

That’s true, actually. Pressing reset now gets to the keyboard lamps flashing twice then hanging and behaves the same each time. All the LEDs on the BB come on too.

The data abort is 1 line after “init mod MbufManager”, hmm, I changed that yesterday to make it StrongARM safe, but looks like I may have broken it in the process!

Not sure if you’ve had a chance to look into it yet, but it looks like some crucial LDM’s in the module initialisation code have been swapped for LDR’s, so it only pops the return address off of the stack instead of the full stack frame.

LDM’s in the module initialisation code have been swapped for LDR’s

Yeah. Internally the sources are “interesting” and I’d not spotted a subtlety of one of its macros.

I’ve submitted a change to ROOL to put in the closed sources, but for now I’ve just outdated the binary from public CVS so it’ll go back to the other version.