Re: [Qemu-devel] [RESEND PATCH v7 0/3] Initial i.MX7 support

[Guenter Roeck]

On Mon, Mar 05, 2018 at 07:50:23AM -0800, Andrey Smirnov wrote:
> On Mon, Mar 5, 2018 at 7:31 AM, Peter Maydell  
> wrote:
> > On 5 March 2018 at 06:12, Andrey Smirnov  wrote:
> >> RESEND due to botched original v7 submission (patch 1/3 broken)
> >>
> >> Hi everyone,
> >>
> >> This v7 of the patch series containing the work that I've done in
> >> order to enable support for i.MX7 emulation in QEMU.
> >
> > Thanks; applied to target-arm.next.
> >
> > By the way there were a couple of i.MX bug reports this weekend:
> > https://bugs.launchpad.net/qemu/+bug/1753314  (about the UART)
> 
> Sure, might not be able to look at it immediately but I'll give it a
> spin by the end of this week.
> 
> > https://bugs.launchpad.net/qemu/+bug/1753309  (about ethernet)
> >
> 
> Peter:
> 
> Ha! This is a rather amusing coincidence since I was just talking
> about this exact bug with Guenter Roeck (added to this thread), who
> was going to submit a patch to fix it.
> 
> Guenter:
> 
> Sorry for just randomly pulling you into this seemingly random
> discussion, but I though this additional context would be helpful to
> you.
> 
I just updated https://bugs.launchpad.net/qemu/+bug/1753309 with my
observations. As it turns out, the Ethernet interface on older kernels
(4.9 and older) only works with the current version of qemu. It is
possible to fix the problem by applying upstream commit 4c8777892e80b
to v4.9 and older kernels. However, I don't know if the problem is also
seen with real hardware, or if there is some other problem lurking
somewhere in qemu.

Guenter

Re: [Qemu-devel] [RESEND PATCH v7 0/3] Initial i.MX7 support

[Andrey Smirnov]

On Mon, Mar 5, 2018 at 7:31 AM, Peter Maydell  wrote:
> On 5 March 2018 at 06:12, Andrey Smirnov  wrote:
>> RESEND due to botched original v7 submission (patch 1/3 broken)
>>
>> Hi everyone,
>>
>> This v7 of the patch series containing the work that I've done in
>> order to enable support for i.MX7 emulation in QEMU.
>
> Thanks; applied to target-arm.next.
>
> By the way there were a couple of i.MX bug reports this weekend:
> https://bugs.launchpad.net/qemu/+bug/1753314  (about the UART)

Sure, might not be able to look at it immediately but I'll give it a
spin by the end of this week.

> https://bugs.launchpad.net/qemu/+bug/1753309  (about ethernet)
>

Peter:

Ha! This is a rather amusing coincidence since I was just talking
about this exact bug with Guenter Roeck (added to this thread), who
was going to submit a patch to fix it.

Guenter:

Sorry for just randomly pulling you into this seemingly random
discussion, but I though this additional context would be helpful to
you.

Thanks,
Andrey Smirnov

Re: [Qemu-devel] [RESEND PATCH v7 0/3] Initial i.MX7 support

[Peter Maydell]

On 5 March 2018 at 06:12, Andrey Smirnov  wrote:
> RESEND due to botched original v7 submission (patch 1/3 broken)
>
> Hi everyone,
>
> This v7 of the patch series containing the work that I've done in
> order to enable support for i.MX7 emulation in QEMU.

Thanks; applied to target-arm.next.

By the way there were a couple of i.MX bug reports this weekend:
https://bugs.launchpad.net/qemu/+bug/1753314  (about the UART)
https://bugs.launchpad.net/qemu/+bug/1753309  (about ethernet)

Are you interested in having a look at them?

thanks
-- PMM

[Qemu-devel] [RESEND PATCH v7 0/3] Initial i.MX7 support

[Andrey Smirnov]

RESEND due to botched original v7 submission (patch 1/3 broken)

Hi everyone,

This v7 of the patch series containing the work that I've done in
order to enable support for i.MX7 emulation in QEMU.

As the one before last commit in the series states the supported i.MX7
features are:

* up to 2 Cortex A9 cores (SMP works with PSCI)
* A7 MPCORE (identical to A15 MPCORE)
* 4 GPTs modules
* 7 GPIO controllers
* 2 IOMUXC controllers
* 1 CCM module
* 1 SVNS module
* 1 SRC module
* 1 GPCv2 controller
* 4 eCSPI controllers
* 4 I2C controllers
* 7 i.MX UART controllers
* 2 FlexCAN controllers
* 2 Ethernet controllers (FEC)
* 3 SD controllers (USDHC)
* 4 WDT modules
* 1 SDMA module
* 1 GPR module
* 2 USBMISC modules
* 2 ADC modules
* 1 PCIe controller
* 3 USB controllers
* 1 LCD controller
* 1 ARMv7 DAP IP block

Feedback is welcome!

Changes since [v6]:

- Removed reference to "is_express"

- All endiannes in Designware PCI implementation is now specified
  as little-endian

- Patchset rebase on latest master
  (136c67e07869227b21b3f627316e03679ce7b738)


Changes since [v5]:

- Rebase patchest on top of latest QEMU master, so now the
  patchset is down to three patches

- Reverted the change to use pci_data_* functions becuase the
  patch supporting this change was causing trouble

- Fixed endiannes of MSI and configuration space accessors to be
  LITTLE_ENDIAN

Changes since [v4]:

- Rebase patchest on top of latest QEMU master

- Reworked PCIE emulation code to create MemoryRegions
  only once

- Fixed incorrect usages of PCI instead of PCIE

- Fixed device class reported by PCIE bridge

- Added patch to make pci_data_read() and pci_data_write() usable
  for PCIE devices as well

- Converted PCIE code to use pci_data_read() and pci_data_write()

- Added VMStateDescription code for PCIE

- Collected Reviewed-by tag from Philippe

Changes since [v3]:

- Changes to FEC were split into a separate set and merged to master

- Patchest is rebased on latest master

- Converted to use PSCI DT fixup code that is shared with virt
  platform (now relocated to live in arm/boot.c)

- Large number of dummy block were converted to use
  create_unimplemented_device() as opposed to its own dedicated
  type

- Incorporated varios small feedback items

- Collected Reviewed-by tags from Peter

Changes since [v2]:

- Added stubs for more blocks that were causing memory
  transactions when booting Linux guest as were revealed by
  additional testing of the patchest

- Added proper USB emulation code, so now it should be possible to
  emulated guest's USB bus

Changes since [v1]:

- Patchset no longer relies on "ignore_memory_transaction_failures = false"
  for its functionality

- As a consequnce of implementing the above a number of patches
  implementing dummy IP block emulation as well as PCIe emulation
  patches that I alluded to in [v1] are now included in this patch
  series

- "has_el3" property is no longer being set to "false" as a part
  of intialization of A7 CPU. I couldn't reproduce the issues that
  I thought I was having, so I just dropped that code.

- A number of smaller feedback items from Peter and other has been
  incorporated into the patches.


Thanks,
Andrey Smirnov

[v6] https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg03587.html
[v5] https://lists.gnu.org/archive/html/qemu-devel/2018-02/msg01558.html
[v4] https://lists.gnu.org/archive/html/qemu-devel/2018-01/msg03264.html
[v3] https://lists.gnu.org/archive/html/qemu-devel/2017-11/msg04236.html
[v2] https://lists.gnu.org/archive/html/qemu-devel/2017-10/msg05516.html
[v1] https://lists.gnu.org/archive/html/qemu-devel/2017-09/msg04770.html

Andrey Smirnov (3):
  pci: Add support for Designware IP block
  i.MX: Add i.MX7 SOC implementation.
  Implement support for i.MX7 Sabre board

 default-configs/arm-softmmu.mak  |   3 +
 include/hw/arm/fsl-imx7.h| 222 
 include/hw/pci-host/designware.h | 102 ++
 include/hw/pci/pci_ids.h |   2 +
 hw/arm/fsl-imx7.c| 580 ++
 hw/arm/mcimx7d-sabre.c   |  90 +
 hw/pci-host/designware.c | 754 +++
 hw/arm/Makefile.objs |   3 +
 hw/pci-host/Makefile.objs|   2 +
 9 files changed, 1758 insertions(+)
 create mode 100644 include/hw/arm/fsl-imx7.h
 create mode 100644 include/hw/pci-host/designware.h
 create mode 100644 hw/arm/fsl-imx7.c
 create mode 100644 hw/arm/mcimx7d-sabre.c
 create mode 100644 hw/pci-host/designware.c

-- 
2.14.3