5.15 IOMD on RPCEmu

As of version 0.8.4 it’s possible to use the IOMD HAL build on RPCEmu Spoon Edition on Windows and Linux.

http://www.marutan.net/rpcemuspoon/

However it has many limitations, which mostly match its performance on real hardware. Please see this link for more details.

http://www.marutan.net/rpcemuspoon/ro5.html

I hope this might assist in further testing and development.

Peter

[Edits for the more obvious spelling mistakes]

Any idea if there will be updates to get it running with disk and VRAM?

best regards,

Jan Rinze.

Any idea if there will be updates to get it running with disk and VRAM?

That rather depends on whether anyone has the time, skill and inclination to add it. It was me that got the build as far as it currently is, but there are 101 other things I could be doing for ROOL and this isn’t high on my personal priority list.

Maybe if Hostfs is patched for RO 5.15 then disk would not be such a problem. Can RO 5.15 load podules? Also it would be nice if RAM gets properly recognised.

Any clue on who is looking into that a.t.m.? RO 5.15 in RPCemu would enable a huge amount of RiscOS users to get involved.

best regards,

Jan Rinze.

Any clue on who is looking into that a.t.m.?

I don’t think anyone’s working on it at the moment.

In case you were wondering, I’m not working on 5.15 for IOMD, it’s a different skill set to working on RPCEmu. RPCEmu has more than enough issues and improvements to keep me occupied almost indefinitely, it also already runs 14 other versions of riscos.

However, as HostFS does work with 5.15, just cannot boot from it, due to the NVRAM not being saved in the 5.15 OS. As such the priority for anyone who wants to have a look at it would probably be the the NVRAM as that is the only thing blocking an emulated usable system (albeit with low memory).

Is there documentation about the settings so that people can change it by them selves? like the RAM constraints? Also the place where it loads its default cmos settings?

I’d just like to point out that it’s a bug somewhere in the IOMD HAL that’s causing the NVRAM problem – it’s not supposed to reset NVRAM to the defaults on every boot. The hardware (obviously) exists, and the same behaviour is observed on real hardware.

I can also point out that the hardware NVRAM is successfully being written with the default values (as can be observed when you go back to the underlying OS) – so it’s something about reading back the settings or the checksumming that’s broken.

Ben, I saw that LoadCMOS of a recently saved cmos by SaveCMOS fails on the beagleboard. Could this be related? if SaveCMOS writes bogus data to a file the LoadCMOS will correctly report an error on the cmos file. I will have to try this on RPCemu and see if there it has the same problem.

I’m not sure without checking if Beagle has NVRAM - or maybe it’s a RevC3 thing? In any case, NVRAM works fine on Iyonix, so it points to a problem in each of the IOMD and OMAP3 HALs.

I’d wager that LoadCMOS failing on a beagleboard is an ARMv6/v7 related bug rather than a bug in the HAL, since at the moment there’s no CMOS support in the HAL.

As far as I’m aware there’s no NVRAM/CMOS/etc. hardware in any beagleboard version, so when CMOS support does get implemented it will most likely be via saving to NAND.

Just had a quick look at the IOMD NVRAM code. Here it isn’t:

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/HAL/IOMD/s/NVRAM?rev=1.3

Can someone explain how the HAL deals with IIC devices? Here HAL_NVMemoryRead and HAL_NVMemoryWrite return without doing anything.

I notice that the Tungsten HAL just NullEntry for these in the HAL table, and has no HAL_NVMemoryRead/Write functions of its own. Does that mean the HAL will assume that an IIC device is connected and use that rather than the specific calls? The IOMD HAL calls the functions, but they don’t do anything. So perhaps they should be set to NullEntry and then the default IIC driver will be used?

Does reading the CMOS clock work on the A7000 RO5.15? If so, there’s obviously some reading of the clock/RAM chip working. But I wonder if some parts of the OS are doing IIC directly, or through the HAL IIC, but not using the HAL_NVMemoryRead/Write calls.

Is IIC still bit-banged on Iyonix hardware? The code for IIC_Control seems to suggest it.

[some time later]

Ah, found the HAL NVRAM documentation

Since the HAL doesn’t set NVMemoryFlag_HAL (wanting to use HAL_NVMemoryRead/Write) IIC should be used by i2cutils and that code looks OK. So I’m a bit puzzled…

The next question is: the IIC code obviously works on Iyonix, so what’s different between IOMD and Tungsten HALs? One other thing I can spot is this:

 HAL_NVMemoryType
       MOV     a1, #NVMemoryFlag_IIC
        ORR     a1, a1, #NVMemoryFlag_LowRead+NVMemoryFlag_LowWrite
        MOV     pc, lr

HAL_NVMemoryType
        LDR     R0, =NVMemoryFlag_MaybeIIC :OR: NVMemoryFlag_ProtectAtEnd
        MOV     pc, lr

MaybeIIC involves some probing of the possible CMOS chips – since we know what the IOMD machines have (a PCF8583 at IIC address &A0 for RPC/A7000 anyway – not sure about RiscStations, Micos etc – and NCs may well have something else) we don’t need to probe. So perhaps setting this to NVMemoryFlag_IIC would do the trick.

(I don’t have a working build system nor an A7000 to test, I’m afraid)

Another potential issue in NVRAM, though it might be worked around elsewhere.

HAL_NVMemorySize MOV R0, #256

For PCF8583 that’s not correct, there’s only 240 bytes of CMOS, the first 16 bytes or for reading/writing the RTC.

http://home.marutan.net/arcemdocs/PCF8583_5.pdf

So possibly, writing to much data to the wrong address.

Then when the checksum is checked, the time has always changed in the first 16 bytes so the checksum is always invalid and RO resets it to the defaults?

Also, once again I’ve not got a build env setup to test this :(