[RFC] Add initial Qualcomm MSM7201A platform emulation

[RFC] Add initial Qualcomm MSM7201A platform emulation

[gustavo menezes]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

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.

Initial targets would include:
- ARM1136 core support integration
- UART
- Interrupt controller
- Timers
- NAND flash controller
- Minimal Linux/Android boot capability

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

I would appreciate feedback regarding:
- Existing related efforts
- Preferred machine model structure
- Maintainership expectations
- Upstream acceptance concerns

Thanks

[-- Attachment #2: Type: text/html, Size: 999 bytes --]

Re: [RFC] Add initial Qualcomm MSM7201A platform emulation

[Alex Bennée]

gustavo menezes <gumenezes2019@gmail.com> 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

Re: [RFC] Add initial Qualcomm MSM7201A platform emulation

[gustavo menezes]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1667 bytes --]

Re: [RFC] Add initial Qualcomm MSM7201A platform emulation

[gustavo menezes]

[-- Attachment #1: Type: text/plain, Size: 4974 bytes --]

Alex Bennée writes:

> gustavo menezes <gumenezes2019@gmail.com> 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.

[-- Attachment #2: Type: text/html, Size: 5889 bytes --]