Alex Bennée writes: > 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 >
Thank you for the detailed feedback. My initial goal is intentionally much smaller than full smartphone emulation. I mainly want to establish a minimal MSM7K machine model capable of early Linux/Android boot and serial console output. I agree that a complete emulation of commercial devices would require significant long-term work, especially for multimedia and modem-related hardware. Regarding experience: - I have been studying QEMU internals and ARM board models - I have experience with low-level firmware/kernel analysis - I have also been working with vendor kernel sources and older Android boot chains For the initial devices: - ARM1136 support already existing in QEMU simplifies the CPU side - Some peripherals appear to be Qualcomm-specific rather than standard ARM PrimeCell IP blocks, although I am still verifying this through downstream kernel sources and available documentation My current plan is roughly: 1. Minimal machine definition 2. UART support 3. Interrupt/timer implementation 4. NAND boot path 5. Linux kernel boot to serial console I also appreciate the comments regarding: - record/replay compatibility - maintainability expectations - testing and documentation - avoiding legacy API patterns I intend to keep the implementation incremental and localized as much as possible. Thanks again for the guidance and references.
