RISC OS Module Addresses Change Every Reboot

I’m still working on 32-bitting !ARM_Debug, and have reached the point where I can use !ARM_Debug to debug itself :-)

However, every time I reset/reboot my RPi1 (I’m using the latest RO5 release), the modules that I’m using have a slightly different base address. This is a real pain.

Q. Is there any easy way I can ensure that modules always have the same base address each time I reboot my RPi1 with RO5 ?

I’ve tried disconnecting/disabling the networking and removing USB sticks etc., but nothing seems to make any difference. My expectation is that the memory map should be identical each time I reboot, assuming that the RPi1 and RISC OS conditions are also identical for each reboot. RISCOS is not multi-processor or ‘proper’ multi-tasking.

Which part of the RO5 operating system is allocating the RAM slightly differently on each reboot – or is there a random number generator embedded in the code ;-) ?

Ralph

p.s. The RISC PC with RO3.7 usually always allocates the same RAM addresses to modules that are defined in the boot structure.

OS_Module,18,ModuleName will return the base address in R3. Can you use that to get the address instead of assuming it is fixed?

My expectation is that the memory map should be identical each time I reboot

Only if the conditions are EXACTLY identical. Remember lots of stuff make small memory claims in the RMA, so if anything is just a fraction different (like a request, say, NetTime or whatever takes a little longer) this could lead to the claims being in a different order and possible gaps as blocks are freed and reallocated.

Never assume anything is in a fixed location in the RMA (even in ROM, different video modules and build options and changes to the code itself will cause stuff to shift from one machine type and ROM image to another).

As said above, use the lookup to get the module’s address.

Never assume anything is in a fixed location in the RMA

I thought the operative word was indicated by the first letter in the TLA ==> Relocatable

What?!
You mean it doesn’t stand for Random Memory Allocations ?

🤣

Random Memory Allocations

It scatters things across random bits of memory? That’s got to be awkward finding all the bits

Q. Is there any easy way I can ensure that modules always have the same base address each time I reboot my RPi1 with RO5 ?

To answer your specific questions…

No, you can’t.

Which part of the RO5 operating system is allocating the RAM slightly differently on each reboot – or is there a random number generator embedded in the code ;-) ?

Lots of the OS could be doing this, even for ROM modules. Timings of startup may mean that ticker events happen in a different order or at different points in the system execution. Devices within the system might respond with slightly different timings – There are many devices in the system which need to be enumerated and accessed, some of which may take longer or shorter times to initialise or respond, which may perturb the system’s startup. Devices may themselves generate interrupts that change the behaviour – sometimes in big ways.

RISC OS 3.7 is a lot simpler and does not include – in particular – USB devices, monitor detection or network autoconfiguration. Both of these things may generate interrupts as data is received. The biggest of these is network autoconfiguration, which (depending on when packets are received) may cause other parts of the system to come alive and begin operation. That doesn’t mean that removing USB devices and network cables will help you – there are generally internal USB devices in the system such as hubs and built-in devices which will still affect things.

Thanks everyone – but especially to Charles for his detailed response. Looks like trying to get some RO5 modules to load at the same address on successive reboots is never going to happen.

I’ll continue to use a pad of paper to write down all the soft break memory addresses in advance, each time I set up a copy of !ARM_Debug to debug itself.

Ralph

If you get the base address as suggested by OS_Module,18, then you can use offsets into the ARM_debug module for debugging locations. The offsets will only change when you change the module! Any errors should also be reported as offsets in the module.