New IOMD softload

I’ve uploaded a new IOMD softload to my site which has the following improvements:

• Rewritten RAM detection/setup code. I’m hoping this will fix all the issues people have been having with it not booting on their machines.
• Implemented HAL_Reset, so that ctrl-break and other software resets will work
• Added code to do the keyboard scan at boot
• Implemented a couple of other missing HAL functions – HAL_MonitorLeadID (for automatic monitor type detection, should work about as well as it does in 3.x/4.x) and HAL_PhysInfo (required for OS_Memory 6/7)
• Fixed Sound_Enable sometimes corrupting registers. Unfortunately this doesn’t seem to be the cause of the Maestro crash, so there’s still at least one sound-related bug lurking.

Grab the softload over here: http://www.phlamethrower.co.uk/misc2/IOMDHALDev.zip

Also included in the archive is an improved version of the softload tool. The only new feature that regular users might be interested in is the ‘-dummyrun’ option, which is useful if you need to get a look at the debug output that’s produced before it boots the new ROM (it causes the tool to exit just short of starting the new ROM).

There’s also a ‘PhysRAM’ basic file in the archive; if any Kinetic users could run it and report back here with the values it prints out then that should allow us to add Kinetic softload support to the ROM.

With any luck the official 5.18 release will be out soon and it’ll be safe for me to check all these changes into CVS.

Nice work! Sounds promising. Will this have some benefits for RPCemu RO5 users?

I think everything on that list will help RPCEmu users, except the rewritten RAM detection (the old code seemed to work OK) and the monitor detection (not really sure what monitor type, if any, RPCEmu will emulate)

I’ve found the cause of the Maestro crash. SoundControl has the following code in its SWI handler:

PHPSEI R14,R0
Pull R0

After macro expansion, this becomes:

MRS R14,CPSR
TST R14,#&80
ORRREQ R0,R14,#&80
MSREQ CPSR_c,R0
LDR R0,[R13],#4

Which is the perfect code sequence to trigger the StrongARM MSR bug and cause the LDR to be executed twice, popping two items off the stack instead of one. Now I just have to decide how best to fix it – the PHPSEI macro is defined in Hdr:CPU.Generic32, which contains lots of other macros which can be made to perform conditional MSR’s. I think I’ll go with the following approach:

• Make the ‘mymsr’ macro emit a warning (or even an error?) if it’s asked to produce a conditional MSR CPSR_c (and the code is being compiled for ARMv4).
• Add a flag to mymsr to allow suppression of the warning (for code that knows what it’s doing)
• Modify all the macros which rely on mymsr (or ones which use MSR directly) to ensure they produce safe code when compiling for ARMv4
• Rebuild the disc image & IOMD ROM to check for any bits which trigger the warning, and fix/suppress as appropriate

Since objasm doesn’t seem to produce a warning for the code (something ROOL could add, pretty please?) I’m thinking that adding the warning/error to mymsr is our best defence against the conditional MSR bug. Anyone else have any ideas?

our best defence against the conditional MSR bug

Blunt axe solution: emit a NOP after conditional MSR in mymsr?

tst r14,#&80
bne jmp
orr r0,r14,#&80
msr cpsr_c,r0
.jmp
ldr r0,[r13],#4

tst r14,#&80
orreq r0,r14,#&80
movne pc,pc
msr cpsr_c,r0
ldr r0,[r13],#4

tst r14,#&80
orreq r0,r14,#&80
movne r0,r14
msr cpsr_c,r0
ldr r0,[r13],#4

Colin: All perfectly valid solutions, but I think for performance reasons it’s better to have a NOP (or some other safe instruction) after the MSR rather than add a branch or make the MSR unconditional.

A search through the ROM disassembly revealed a handful of dangerous MSRs which still needed fixing, including three in MbufManager (aka MManager in CVS). Since this is still closed source I’ll have to leave it to ROOL to fix these (although if push comes to shove it looks like I could just reorder a couple of instructions in the binary):

• MSREQ CPSR_c,R3 at offset 1260
• MSREQ CPSR_c,R3 at offset 12D4
• MSREQ CPSR_c,R3 at offset 1350

Once I’ve checked the disc image I think I should be OK to check in these MSR fixes (except those MbufManager ones).

Did anyone get a chance to try this softload? All the changes are now in CVS, so you can’t blame me (much) if you find it doesn’t work!

I’ve not got a system I could usefully test it on – assuming you mean the IOMD softload, unless RPCemu with 5.17 would do?

The main thing I’m interested in getting tested is the RAM setup/detection. Although some of it’s been run through a testbed, there’s a fair amount which hasn’t, so it wouldn’t surprise me if there are one or two situations in which it will fail.

I’ve already tested it under RPCEmu, so it would be testing with real IOMD machines that I’m most interested in.

I think Sprow has a working RiscPC… ;)

Hmm, OK. Maybe you can check in a StrongARM-safe version of MbufManager then? :) (see the list of MSR’s a few posts up – the code needs tweaking so it won’t fail badly when the StrongARM conditional MSR bug is triggered)

Sprow has a working RiscPC

ROM of 27-Feb-12 loaded just fine (previously I’ve never managed to get the softload tool to work), detected 65MB of RAM (64 in a single SIMM, then 1 of VRAM) and booted into the desktop just fine.

Numbers in task manager all seemed to add up, allowing for the 4MB lost to the softload.

Sounds good.

previously I’ve never managed to get the softload tool to work

Judging by the ROM date you must be using ROOL’s one – in which case that will have contained an older version of the softload tool. So either I fixed the problems you were having with the softload tool a while ago, or some/all of your problems were being caused by the old HAL code.

Anyway, I’ve now checked in updated softload binaries, so tomorrows ROMs should work even better.

so tomorrows ROMs should work even better.

That softload tool now reports “softload failed; out of memory”, however if I let the boot sequence complete normally then go and run !!Softload manually it works as before. Presumably that’s something simple like the free pool isn’t big enough?

I fixed the problems you were having with the softload tool a while ago

You did, I just forgot to retest.

Presumably that’s something simple like the free pool isn’t big enough?

Yes, that’s probably it. I’m a bit surrpised though; the memory usage shouldn’t be much higher than before. However, I will need to change it to allocate the decompression workspace from somewhere else.

Did anyone get a chance to try this softload? All the changes are now in CVS, so you can’t blame me (much) if you find it doesn’t work!

I tried the !!Softload on my RiscPc 3.7 and it wanted a newer SharedClibrary.
I copied the Iyonix module to ShareCLib and it loaded but get "abort on data transfer at &022B48F0’ then.
Machine is 128MB Strongarm with or without viewfinder. For some reason when I pull the viewfinder, I loose the network, but that doesn’t matter for this exercise.
I just realised that I used the ROOL download, rather that Jeffreys,
-will update shortly
OK, same deal except at &024BBC70
The extra basic program errors with ‘Unknown OS_ReadSysInfo Call’
Seems like the IOMD softload is assuming RO4? even the archive name is a long filename.

Ron M.

That softload tool now reports “softload failed; out of memory”, however if I let the boot sequence complete normally then go and run !!Softload manually it works as before. Presumably that’s something simple like the free pool isn’t big enough?

It looks like there are three potential causes of this:

• The first is that SCL can’t/won’t resize the application slot if the wimp isn’t active. As a workaround for this I’ve made it so that all the temporary allocations now come from the RMA (the temporary allocations could be anything up to 512K, since the tool now knows how to use the physical memory map returned by OS_Memory 6/7 to find where the hard ROM is hiding)
• However there was also a bug that caused it to load the entire ROM when it was only interested in the footer, so it was claiming significantly more temporary memory than it should have been (and that also explains why I’d noticed that the tool had become significantly slower since my changes!)
• And the final possibility is that something’s swallowed the free pool. On my Risc PC I found that softloading a new version of the Wimp within PreDesk caused most of the memory allocated to the free pool to simply vanish – instead of being returned to the application slot it went away altogether and wasn’t showing up in any dynamic areas. If you enter the desktop or know a safe slot size to specify in a *wimpslot command you can get the memory back again, but using the standard utilities available in 3.6/3.7 (AppSpace, FreePool, etc.) there doesn’t seem to be any surefire way to recover it before running the softload tool. Perhaps we need to write a utility which will find the lost memory and move it back into the free pool.

I copied the Iyonix module to ShareCLib and it loaded but get "abort on data transfer at &022B48F0’ then.

You don’t want to use the Iyonix version on a 26bit OS. Try the version in the “System resources” archive from this page

The extra basic program errors with ‘Unknown OS_ReadSysInfo Call’
Seems like the IOMD softload is assuming RO4? even the archive name is a long filename.

Not exactly. I’m only interested in the output of the PhysRam program when a Kinetic user runs it. And since you’d need RISC OS 4 to be using a Kinetic card, there wasn’t much point making sure the program works on 3.×.

I’ve updated the archive on my site to contain a copy of the latest softload tool and a newer ROM. So you can give that one ago, or wait for the latest ROOL ones in the morning (which should be pretty much the same as my one).

So you can give that one ago, or wait for the latest ROOL ones in the morning

Yup – that softload tool runs fine with 29-Feb-2012 IOMD ROM.

I upgraded the !System Rebooted/Powered Down a few times but still got
RISC OS 130MB
SA-110 Processor
Acorn ADFS
Error: Internal error: abort on data transfer at x00008D60 (Error number &80000002)
After a page of the initialising. Any ideas?
RiscPC 3.7 SA and podules.
Just letting you know, I don’t think I can use it seriously until networking can work.
Ron M.

That’ll most likely be a !Boot sequence issue. Hopefully by the time we have networking drivers sorted out we’ll also have a RISC OS 5 boot sequence which can easily be merged with peoples existing 3.x/4.x !Boot.

But the important thing for now is that the ROM image seems to be working OK on your machine.

Hopefully by the time we have networking drivers sorted out we’ll also have a RISC OS 5 boot sequence which can easily be merged with peoples existing 3.x/4.x !Boot.

Is a resourcesfs live version viable? (Obviously unlikely to be much good on machines with under 64M RAM)

Yes, it’s viable.

> Is a resourcesfs live version viable?
Yes, it’s viable.

Could I request it, please? (I’d like to try it on the local club RPC)

Do you still need your test prog run on more Kinetics?