gustavo menezes <[email protected]> writes:
> Hello,
>
> I am interested in developing initial support for the Qualcomm MSM7201A
> SoC family in QEMU.
>
> The goal is to emulate early Qualcomm MSM7K-based smartphones such as
> the HTC Dream / T-Mobile G1 and related Windows Mobile devices.
That sounds like quite a lot of work for one person. Have you done much
device modelling or reverse engineering before?
>
> Initial targets would include:
> - ARM1136 core support integration
We already have at least one board that uses this so that is done.
> - UART
> - Interrupt controller
> - Timers
Are these all Arm IP blocks or something QC specific?
> - NAND flash controller
> - Minimal Linux/Android boot capability
While Android can boot on QEMU (specifically the Cuttlefish Android
target) you may need to model/stub a lot of devices to get through the
boot of an unmodified image.
> Longer term goals may include:
> - LCD/framebuffer support
> - Audio
> - Modem/DSP stubs
> - Power management
> - Windows Mobile compatibility
>
> Potential use cases:
> - Preservation of early smartphone platforms
> - Android historical research
> - Embedded Linux development
> - Reverse engineering research
For reverse engineering you should ensure any devices you model work
appropriately with record/replay.
>
> I would appreciate feedback regarding:
> - Existing related efforts
There are a number of downstream forks of QEMU that model various things
including at least one that claims to emulate a full iPhone so such
things are possible. However most of the upstream models are either
aimed at virtualisation, model various developer/reference boards and a
large number of system controller boards.
> - Preferred machine model structure
I'll leave that for others - however the general advice is to be wary of
copying and pasting for older models which often use old/legacy APIs and
haven't bee converted.
> - Maintainership expectations
No one is expecting full security support for random board models (see
security.rst) however neither are drive-by code dumps particularly
useful to the project. Orphaned sections of code are liable to
eventually get removed especially if there is little evidence of it
being useful to people. You should be prepared to at least field bug
reports and review incoming patches even if the patches are eventually
merged through some higher level maintainer tree.
> - Upstream acceptance concerns
All code added to QEMU adds some degree to the maintenance burden. As
code is likely to be re-factored by many people the most useful thing to
address are:
- Good comments and references to source documents of what behaviour
should be
- Testing, having some way to ensure functionality doesn't bit rot
- Try and keep changes localised - QEMU is pretty modular but if you
need to make changes to wider code expect to justify it.
Plus all the usual things about project coding and commit style and what
developer focused documentation we have:
https://qemu.readthedocs.io/en/master/devel/index.html
>
> Thanks
--
Alex Bennée
Virtualisation Tech Lead @ Linaro
