On Wed, Aug 25, 2021 at 02:38:16PM +0000, Sarah wrote:
> On Wednesday, 25 August 2021, 14:20:47 BST, Theo Markettos <theo@markettos.org.uk> wrote:
>
> >RISC OS currently uses some undocumented firmware interfaces
>
> Please tell me this is a joke. That code needs to come out ASAP, and
> should never have been checked in.
It's not a joke, it's because the RISC OS port and the firmware have
co-evolved. Originally there were no documented firmware interfaces,
because there was no documentation - there were simply emails to the
firmware developers. Later on some bits got documented, but it turned out
not the ones RISC OS implemented.
(This is how a lot of stuff gets developed, when the software and hardware
teams are working together you can save a lot on documentation when you can
just go and ask, or go look at the chip design source code. Which are
things people outside the company don't have access to, but then don't need
to according to the target market)
> The best approach I can see at this point, is to fork QEMU, fix the
> firmware simulation at the FW version RO5 is using (I'm assuming the
> binary blob for this is loaded by RO; if not you've got some issues in
> general anyway), and add the convenience features like HostFS. Then
> feedback any relevant changes/fixes to mainline and let them go up
> whatever upstreaming process is in use there at their leisure.
The firmware is loaded before the OS boots, so you don't get to control what
firmware you're running on. On Pi 0-3 the GPU firmware boots first and
brings up the ARM later on; Pi 4 has more of a traditional boot process that
involve the firmware being an ARM 'BIOS' to load up the OS.
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.
But I raise this as more of a philosophical point: modern systems are
complex and change over time - they are not fixed at a point in the past
like older hardware was. Emulating them therefore may need a different
approach. Particularly when you can bend both sides to meet each other,
it's then a question of which side is easier to bend, and which incurs you
the least costs.
> This would give you a reasonable emulation of a more modern platform more
> suitable for new software, and is a hell of a lot better than the idea of
> forking RPCemu (since the relevant changes would never be mainlined) to
> weld in ARMv7 and the like.
I agree: RPCEmu is designed to be a fixed emulation of a fixed piece of
hardware from a historical period. If what you want is a way to run modern
RISC OS on modern hardware, there are other ways to go about it.
Theo
_______________________________________________
RPCEmu mailing list
RPCEmu@riscos.info
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
No comments:
Post a Comment