qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 6461d7: fsl-imx6: Swap Ethernet interrupt def


From: GitHub
Subject: [Qemu-commits] [qemu/qemu] 6461d7: fsl-imx6: Swap Ethernet interrupt defines
Date: Tue, 20 Mar 2018 02:50:13 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 6461d7e2678fe4a71c257da85136c0e776dfd94c
      
https://github.com/qemu/qemu/commit/6461d7e2678fe4a71c257da85136c0e776dfd94c
  Author: Guenter Roeck <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/net/imx_fec.c
    M include/hw/arm/fsl-imx6.h

  Log Message:
  -----------
  fsl-imx6: Swap Ethernet interrupt defines

The sabrelite machine model used by qemu-system-arm is based on the
Freescale/NXP i.MX6Q processor. This SoC has an on-board ethernet
controller which is supported in QEMU using the imx_fec.c module
(actually called imx.enet for this model.)

The include/hw/arm/fsm-imx6.h file defines the interrupt vectors for the
imx.enet device like this:

 #define FSL_IMX6_ENET_MAC_1588_IRQ 118
 #define FSL_IMX6_ENET_MAC_IRQ 119

According to https://www.nxp.com/docs/en/reference-manual/IMX6DQRM.pdf,
page 225, in Table 3-1. ARM Cortex A9 domain interrupt summary,
interrupts are as follows.

150 ENET MAC 0 IRQ
151 ENET MAC 0 1588 Timer interrupt

where

150 - 32 == 118
151 - 32 == 119

In other words, the vector definitions in the fsl-imx6.h file are reversed.

Fixing the interrupts alone causes problems with older Linux kernels:
The Ethernet interface will fail to probe with Linux v4.9 and earlier.
Linux v4.1 and earlier will crash due to a bug in Ethernet driver probe
error handling. This is a Linux kernel problem, not a qemu problem:
the Linux kernel only worked by accident since it requested both interrupts.

For backward compatibility, generate the Ethernet interrupt on both interrupt
lines. This was shown to work from all Linux kernel releases starting with
v3.16.

Link: https://bugs.launchpad.net/qemu/+bug/1753309
Signed-off-by: Guenter Roeck <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 68cbecfdd7afbfdf9cb06a87a2a297e8a6add7d7
      
https://github.com/qemu/qemu/commit/68cbecfdd7afbfdf9cb06a87a2a297e8a6add7d7
  Author: Wei Huang <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M dump.c

  Log Message:
  -----------
  dump: Update correct kdump phys_base field for AArch64

For guest kernel that supports KASLR, the load address can change every
time when guest VM runs. To find the physical base address correctly,
current QEMU dump searches VMCOREINFO for the string "NUMBER(phys_base)=".
However this string pattern is only available on x86_64. AArch64 uses a
different field, called "NUMBER(PHYS_OFFSET)=". This patch makes sure
QEMU dump uses the correct string on AArch64.

Signed-off-by: Wei Huang <address@hidden>
Reviewed-by: Marc-André Lureau <address@hidden>
Message-id: address@hidden
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 824e4a12f3de76d3efb3229027a04c1fd69244d5
      
https://github.com/qemu/qemu/commit/824e4a12f3de76d3efb3229027a04c1fd69244d5
  Author: Andrey Smirnov <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/char/imx_serial.c

  Log Message:
  -----------
  char: i.MX: Simplify imx_update()

Code of imx_update() is slightly confusing since the "flags" variable
doesn't really corespond to anything in real hardware and server as a
kitchensink accumulating events normally reported via USR1 and USR2
registers.

Change the code to explicitly evaluate state of interrupts reported
via USR1 and USR2 against corresponding masking bits and use the to
detemine if IRQ line should be asserted or not.

NOTE: Check for UTS1_TXEMPTY being set has been dropped for two
reasons:

    1. Emulation code implements a single character FIFO, so this flag
       will always be set since characters are trasmitted as a part of
       the code emulating "push" into the FIFO

    2. imx_update() is really just a function doing ORing and maksing
       of reported events, so checking for UTS1_TXEMPTY should happen,
       if it's ever really needed should probably happen outside of
       it.

Cc: address@hidden
Cc: address@hidden
Cc: Bill Paul <address@hidden>
Cc: Peter Maydell <address@hidden>
Signed-off-by: Andrey Smirnov <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 46d3fb634cb0e44c6cf0ed3a996d6996f3818c2d
      
https://github.com/qemu/qemu/commit/46d3fb634cb0e44c6cf0ed3a996d6996f3818c2d
  Author: Andrey Smirnov <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/char/imx_serial.c
    M include/hw/char/imx_serial.h

  Log Message:
  -----------
  char: i.MX: Add support for "TX complete" interrupt

Add support for "TX complete"/TXDC interrupt generate by real HW since
it is needed to support guests other than Linux.

Based on the patch by Bill Paul as found here:
https://bugs.launchpad.net/qemu/+bug/1753314

Cc: address@hidden
Cc: address@hidden
Cc: Bill Paul <address@hidden>
Cc: Peter Maydell <address@hidden>
Signed-off-by: Bill Paul <address@hidden>
Signed-off-by: Andrey Smirnov <address@hidden>
Message-id: address@hidden
Reviewed-by: Peter Maydell <address@hidden>
Signed-off-by: Peter Maydell <address@hidden>


  Commit: 01e02f5aa74315f81b62872a50fe1b3e96dd00df
      
https://github.com/qemu/qemu/commit/01e02f5aa74315f81b62872a50fe1b3e96dd00df
  Author: Peter Maydell <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/arm/raspi.c

  Log Message:
  -----------
  hw/arm/raspi: Don't do board-setup or secure-boot for raspi3

For the rpi1 and 2 we want to boot the Linux kernel via some
custom setup code that makes sure that the SMC instruction
acts as a no-op, because it's used for cache maintenance.
The rpi3 boots AArch64 kernels, which don't need SMC for
cache maintenance and always expect to be booted non-secure.
Don't fill in the aarch32-specific parts of the binfo struct.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Andrew Baumann <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden


  Commit: 43118f4351c1c430aa5c32aed80dcfe0b525a1f0
      
https://github.com/qemu/qemu/commit/43118f4351c1c430aa5c32aed80dcfe0b525a1f0
  Author: Peter Maydell <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/arm/boot.c

  Log Message:
  -----------
  hw/arm/boot: assert that secure_boot and secure_board_setup are false for 
AArch64

Add some assertions that if we're about to boot an AArch64 kernel,
the board code has not mistakenly set either secure_boot or
secure_board_setup. It doesn't make sense to set secure_boot,
because all AArch64 kernels must be booted in non-secure mode.

It might in theory make sense to set secure_board_setup, but
we don't currently support that, because only the AArch32
bootloader[] code calls this hook; bootloader_aarch64[] does not.
Since we don't have a current need for this functionality, just
assert that we don't try to use it. If it's needed we'll add
it later.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden


  Commit: bda816f08abde5b1681b4e3ba55e42871dad96fc
      
https://github.com/qemu/qemu/commit/bda816f08abde5b1681b4e3ba55e42871dad96fc
  Author: Peter Maydell <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/arm/boot.c

  Log Message:
  -----------
  hw/arm/boot: If booting a kernel in EL2, set SCR_EL3.HCE

If we're directly booting a Linux kernel and the CPU supports both
EL3 and EL2, we start the kernel in EL2, as it expects. We must also
set the SCR_EL3.HCE bit in this situation, so that the HVC
instruction is enabled rather than UNDEFing. Otherwise at least some
kernels will panic when trying to initialize KVM in the guest.

Signed-off-by: Peter Maydell <address@hidden>
Message-id: address@hidden


  Commit: 3d260cf3c6375c641106c71dd6cf9b638b73847b
      
https://github.com/qemu/qemu/commit/3d260cf3c6375c641106c71dd6cf9b638b73847b
  Author: Peter Maydell <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/arm/bcm2836.c

  Log Message:
  -----------
  hw/arm/bcm2386: Fix parent type of bcm2386

The TypeInfo and state struct for bcm2386 disagree about what the
parent class is -- the TypeInfo says it's TYPE_SYS_BUS_DEVICE,
but the BCM2386State struct only defines the parent_obj field
as DeviceState. This would have caused problems if anything
actually tried to treat the object as a TYPE_SYS_BUS_DEVICE.
Fix the TypeInfo to use TYPE_DEVICE as the parent, since we don't
need any of the additional functionality TYPE_SYS_BUS_DEVICE
provides.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Andrew Baumann <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden


  Commit: 926dcdf073a2f9cf8f8d4d71b35110544dae2b40
      
https://github.com/qemu/qemu/commit/926dcdf073a2f9cf8f8d4d71b35110544dae2b40
  Author: Peter Maydell <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/arm/bcm2836.c
    M hw/arm/raspi.c
    M include/hw/arm/bcm2836.h

  Log Message:
  -----------
  hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283x

Our BCM2836 type is really a generic one that can be any of
the bcm283x family. Rename it accordingly. We change only
the names which are visible via the header file to the
rest of the QEMU code, leaving private function names
in bcm2836.c as they are.

This is a preliminary to making bcm283x be an abstract
parent class to specific types for the bcm2836 and bcm2837.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Andrew Baumann <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden


  Commit: 0fd74f03ed7e8c95279a9af2b684dd65713ca03f
      
https://github.com/qemu/qemu/commit/0fd74f03ed7e8c95279a9af2b684dd65713ca03f
  Author: Peter Maydell <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/arm/bcm2836.c
    M hw/arm/raspi.c
    M include/hw/arm/bcm2836.h

  Log Message:
  -----------
  hw/arm/bcm2836: Create proper bcm2837 device

The bcm2837 is pretty similar to the bcm2836, but it does have
some differences. Notably, the MPIDR affinity aff1 values it
sets for the CPUs are 0x0, rather than the 0xf that the bcm2836
uses, and if this is wrong Linux will not boot.

Rather than trying to have one device with properties that
configure it differently for the two cases, create two
separate QOM devices for the two SoCs. We use the same approach
as hw/arm/aspeed_soc.c and share code and have a data table
that might differ per-SoC. For the moment the two types don't
actually have different behaviour.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden


  Commit: 1bcb4d16bb0b4ad2fdde8802ccd0598cdf020fc7
      
https://github.com/qemu/qemu/commit/1bcb4d16bb0b4ad2fdde8802ccd0598cdf020fc7
  Author: Peter Maydell <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/arm/bcm2836.c

  Log Message:
  -----------
  hw/arm/bcm2836: Use correct affinity values for BCM2837

The BCM2837 sets the Aff1 field of the MPIDR affinity values for the
CPUs to 0, whereas the BCM2836 uses 0xf. Set this correctly, as it
is required for Linux to boot.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Andrew Baumann <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden


  Commit: 210f47840dd62dcdb6ee87b2c6062f322f7e0363
      
https://github.com/qemu/qemu/commit/210f47840dd62dcdb6ee87b2c6062f322f7e0363
  Author: Peter Maydell <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/arm/bcm2836.c
    M hw/arm/raspi.c

  Log Message:
  -----------
  hw/arm/bcm2836: Hardcode correct CPU type

Now we have separate types for BCM2386 and BCM2387, we might as well
just hard-code the CPU type they use rather than having it passed
through as an object property. This then lets us put the initialization
of the CPU object in init rather than realize.

Note that this change means that it's no longer possible on
the command line to use -cpu to ask for a different kind of
CPU than the SoC supports. This was never a supported thing to
do anyway; we were just not sanity-checking the command line.

This does require us to only build the bcm2837 object on
TARGET_AARCH64 configs, since otherwise it won't instantiate
due to the missing cortex-a53 device and "make check" will fail.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Andrew Baumann <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden


  Commit: ff72cb6b46b95bb530787add5277c211af3d31c6
      
https://github.com/qemu/qemu/commit/ff72cb6b46b95bb530787add5277c211af3d31c6
  Author: Peter Maydell <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M hw/arm/raspi.c

  Log Message:
  -----------
  hw/arm/raspi: Provide spin-loop code for AArch64 CPUs

The raspi3 has AArch64 CPUs, which means that our smpboot
code for keeping the secondary CPUs in a pen needs to have
a version for A64 as well as A32. Without this, the
secondary CPUs go into an infinite loop of taking undefined
instruction exceptions.

Signed-off-by: Peter Maydell <address@hidden>
Reviewed-by: Philippe Mathieu-Daudé <address@hidden>
Message-id: address@hidden


  Commit: c26ef39204f3200efe89470f6b21ac783edadd29
      
https://github.com/qemu/qemu/commit/c26ef39204f3200efe89470f6b21ac783edadd29
  Author: Peter Maydell <address@hidden>
  Date:   2018-03-19 (Mon, 19 Mar 2018)

  Changed paths:
    M dump.c
    M hw/arm/bcm2836.c
    M hw/arm/boot.c
    M hw/arm/raspi.c
    M hw/char/imx_serial.c
    M hw/net/imx_fec.c
    M include/hw/arm/bcm2836.h
    M include/hw/arm/fsl-imx6.h
    M include/hw/char/imx_serial.h

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20180319' 
into staging

target-arm queue:
 * fsl-imx6: Fix incorrect Ethernet interrupt defines
 * dump: Update correct kdump phys_base field for AArch64
 * char: i.MX: Add support for "TX complete" interrupt
 * bcm2836/raspi: Fix various bugs resulting in panics trying
   to boot a Debian Linux kernel on raspi3

# gpg: Signature made Mon 19 Mar 2018 18:30:33 GMT
# gpg:                using RSA key 3C2525ED14360CDE
# gpg: Good signature from "Peter Maydell <address@hidden>"
# gpg:                 aka "Peter Maydell <address@hidden>"
# gpg:                 aka "Peter Maydell <address@hidden>"
# Primary key fingerprint: E1A5 C593 CD41 9DE2 8E83  15CF 3C25 25ED 1436 0CDE

* remotes/pmaydell/tags/pull-target-arm-20180319:
  hw/arm/raspi: Provide spin-loop code for AArch64 CPUs
  hw/arm/bcm2836: Hardcode correct CPU type
  hw/arm/bcm2836: Use correct affinity values for BCM2837
  hw/arm/bcm2836: Create proper bcm2837 device
  hw/arm/bcm2836: Rename bcm2836 type/struct to bcm283x
  hw/arm/bcm2386: Fix parent type of bcm2386
  hw/arm/boot: If booting a kernel in EL2, set SCR_EL3.HCE
  hw/arm/boot: assert that secure_boot and secure_board_setup are false for 
AArch64
  hw/arm/raspi: Don't do board-setup or secure-boot for raspi3
  char: i.MX: Add support for "TX complete" interrupt
  char: i.MX: Simplify imx_update()
  dump: Update correct kdump phys_base field for AArch64
  fsl-imx6: Swap Ethernet interrupt defines

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/2c8cfc0b52b5...c26ef39204f3

reply via email to

[Prev in Thread] Current Thread [Next in Thread]