On Thu, Aug 26, 2021 at 06:59:25AM +0000, Sarah wrote: > On Wednesday, 25 August 2021, 23:36:53 BST, Theo Markettos > <t...@markettos.org.uk> wrote: > > >Changing RISC OS to use the documented interface for USB power control, > >which is the one I found, is a small change. The timer issue is a more > >substantial roadblock, and that's a hard peripheral that QEMU doesn't > >implement because other OSes use the ARM's own timer instead. > > So why is RO different to everyone else?
The timer issue is a more complicated one. Essentially RISC OS assumes timers work just the same as they did on the Archimedes. There's one timer, you configure it to give you an interrupt at 100Hz, job done. So what happens when someone ports RISC OS to a new platform is they scour the datasheet for a timer that behaves just like the one in the IOC on the Archimedes (and RiscPC). And that's what happened on the Pi - there's a timer that's specific to the Pi SoC. That approach is running out of road. It made sense in a world of an 8MHz/4MIPS CPU, where you got 40,000 instructions between interrupts. Now CPUs are 2GHz it's less good to have a 100Hz timer with 20 million instructions between interrupts. Lots of I/O things depend on microsecond timing, for example. Nowadays you want multiple sources of arbitrary different time granularity too, and be able to read the timer counter without consistency risks. Every Arm core has a timer block as part of the core, which means it doesn't depend on the hardware the SoC vendor decided to slap around it. So you don't need to worry about writing a timer implementation for every single SoC. Unfortunately the timers have changed between generations, so an ARM11 timer is different from a Cortex A53 timer, so you need a handful of drivers for those. Also, cores are subject to powersaving - you need to adjust if the core that is clocking the timer gets downclocked from 2GHz to 857MHz to save power. Linux, FreeBSD, etc have modern timer subsystems that use the Arm core's timers, with code to implement generic timers on top of what the hardware provides, with drivers for the various Arm cores. Therefore QEMU doesn't implement the Pi-SoC timer because no other OS uses it - if you select the raspi2 emulation you get a Cortex A7 CPU and its timers, if you select raspi4 you get a Cortex A72 with timers. You can boot quite happily on a new SoC with a Cortex A72 without any tailoring the new hardware, because you're using generic timer (and interrupt controller and UART) drivers. RISC OS doesn't do any of this, it just clings to the idea that a single 100Hz timer is good enough - and it isn't in this day and age. So in this space it's not wrong to say QEMU should implement the Pi-specific timer - it would make QEMU's implementation more complete. But, all things being equal, instead of investing the effort in distributing a fork of QEMU, looking at the bigger picture it could make more sense to invest effort in modernising RISC OS' use of timers, which would make it easier to port to new platforms and down the line improve the performance and capability of RISC OS on all platforms. Making it less weird and work more like other OSes, in an area that doesn't have any benefits to being different, makes it easier to work with down the line - booting on emulators or on new silicon. But all things aren't equal, so it really depends on who has time and skills and what they want to work on. > Bending your side to meet the quirks of a current inaccurate > implementation of something else leaves you screwed if said other side > becomes more accurate. Which is quite likely to happen; QEMU is aiming to > emulate a Pi, not "something like a Pi", and they are quite likely to make > changes to bring their emulation closer to a real Pi. At which point RO > has _more_ costs having to readjust. In systems typically there is 'core' behaviour, that is the well trodden path that every platform uses regularly. And then there are the depths of the weeds, where they rarely go. RISC OS exercises unusual parts of the weeds that others don't. You can fix the emulator's implementation of the weeds, or you can make RISC OS more mainstream and less surprising. In this instance I see more benefit to modernising RISC OS to make it more mainstream (in this particular area) than I do than in improving the weedy parts of the emulation, not that that is a bad goal of itself. > If you just want something for virtualisation that doesn't want to look > like a Pi, QEMU has the 'virt' platform for that, and there's no reason RO > couldn't port to that. Porting specifically to "the current state of the > Pi emulation" rather than fixing the problematic elements of said Pi > emulation is just asking for trouble. Agreed, but the 'virt' platform would require the timer modernisation above. I'd suggest it's better to invest in that kind of modernisation rather the improving a specific implementation of a specific emulator. Theo _______________________________________________ RPCEmu mailing list RPCEmu@riscos.info http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
