hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
/*
|
|
|
|
* MIPS Boston development board emulation.
|
|
|
|
*
|
|
|
|
* Copyright (c) 2016 Imagination Technologies
|
|
|
|
*
|
|
|
|
* This library is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU Lesser General Public
|
|
|
|
* License as published by the Free Software Foundation; either
|
|
|
|
* version 2 of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This library is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
* Lesser General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU Lesser General Public
|
|
|
|
* License along with this library; if not, see <http://www.gnu.org/licenses/>.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "qemu/osdep.h"
|
2018-06-25 12:41:58 +00:00
|
|
|
#include "qemu/units.h"
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
#include "exec/address-spaces.h"
|
|
|
|
#include "hw/boards.h"
|
|
|
|
#include "hw/char/serial.h"
|
|
|
|
#include "hw/ide/pci.h"
|
|
|
|
#include "hw/ide/ahci.h"
|
|
|
|
#include "hw/loader.h"
|
|
|
|
#include "hw/loader-fit.h"
|
|
|
|
#include "hw/mips/cps.h"
|
|
|
|
#include "hw/mips/cpudevs.h"
|
|
|
|
#include "hw/pci-host/xilinx-pcie.h"
|
2019-08-12 05:23:51 +00:00
|
|
|
#include "hw/qdev-properties.h"
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
#include "qapi/error.h"
|
|
|
|
#include "qemu/error-report.h"
|
|
|
|
#include "qemu/log.h"
|
2017-01-26 13:19:46 +00:00
|
|
|
#include "chardev/char.h"
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
#include "sysemu/device_tree.h"
|
|
|
|
#include "sysemu/sysemu.h"
|
|
|
|
#include "sysemu/qtest.h"
|
2019-08-12 05:23:59 +00:00
|
|
|
#include "sysemu/runstate.h"
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
#include <libfdt.h>
|
|
|
|
|
|
|
|
#define TYPE_MIPS_BOSTON "mips-boston"
|
|
|
|
#define BOSTON(obj) OBJECT_CHECK(BostonState, (obj), TYPE_MIPS_BOSTON)
|
|
|
|
|
|
|
|
typedef struct {
|
|
|
|
SysBusDevice parent_obj;
|
|
|
|
|
|
|
|
MachineState *mach;
|
2019-05-07 16:34:09 +00:00
|
|
|
MIPSCPSState cps;
|
2019-10-23 15:50:06 +00:00
|
|
|
SerialMM *uart;
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
CharBackend lcd_display;
|
|
|
|
char lcd_content[8];
|
|
|
|
bool lcd_inited;
|
|
|
|
|
|
|
|
hwaddr kernel_entry;
|
|
|
|
hwaddr fdt_base;
|
|
|
|
} BostonState;
|
|
|
|
|
|
|
|
enum boston_plat_reg {
|
|
|
|
PLAT_FPGA_BUILD = 0x00,
|
|
|
|
PLAT_CORE_CL = 0x04,
|
|
|
|
PLAT_WRAPPER_CL = 0x08,
|
|
|
|
PLAT_SYSCLK_STATUS = 0x0c,
|
|
|
|
PLAT_SOFTRST_CTL = 0x10,
|
|
|
|
#define PLAT_SOFTRST_CTL_SYSRESET (1 << 4)
|
|
|
|
PLAT_DDR3_STATUS = 0x14,
|
|
|
|
#define PLAT_DDR3_STATUS_LOCKED (1 << 0)
|
|
|
|
#define PLAT_DDR3_STATUS_CALIBRATED (1 << 2)
|
|
|
|
PLAT_PCIE_STATUS = 0x18,
|
|
|
|
#define PLAT_PCIE_STATUS_PCIE0_LOCKED (1 << 0)
|
|
|
|
#define PLAT_PCIE_STATUS_PCIE1_LOCKED (1 << 8)
|
|
|
|
#define PLAT_PCIE_STATUS_PCIE2_LOCKED (1 << 16)
|
|
|
|
PLAT_FLASH_CTL = 0x1c,
|
|
|
|
PLAT_SPARE0 = 0x20,
|
|
|
|
PLAT_SPARE1 = 0x24,
|
|
|
|
PLAT_SPARE2 = 0x28,
|
|
|
|
PLAT_SPARE3 = 0x2c,
|
|
|
|
PLAT_MMCM_DIV = 0x30,
|
|
|
|
#define PLAT_MMCM_DIV_CLK0DIV_SHIFT 0
|
|
|
|
#define PLAT_MMCM_DIV_INPUT_SHIFT 8
|
|
|
|
#define PLAT_MMCM_DIV_MUL_SHIFT 16
|
|
|
|
#define PLAT_MMCM_DIV_CLK1DIV_SHIFT 24
|
|
|
|
PLAT_BUILD_CFG = 0x34,
|
|
|
|
#define PLAT_BUILD_CFG_IOCU_EN (1 << 0)
|
|
|
|
#define PLAT_BUILD_CFG_PCIE0_EN (1 << 1)
|
|
|
|
#define PLAT_BUILD_CFG_PCIE1_EN (1 << 2)
|
|
|
|
#define PLAT_BUILD_CFG_PCIE2_EN (1 << 3)
|
|
|
|
PLAT_DDR_CFG = 0x38,
|
|
|
|
#define PLAT_DDR_CFG_SIZE (0xf << 0)
|
|
|
|
#define PLAT_DDR_CFG_MHZ (0xfff << 4)
|
|
|
|
PLAT_NOC_PCIE0_ADDR = 0x3c,
|
|
|
|
PLAT_NOC_PCIE1_ADDR = 0x40,
|
|
|
|
PLAT_NOC_PCIE2_ADDR = 0x44,
|
|
|
|
PLAT_SYS_CTL = 0x48,
|
|
|
|
};
|
|
|
|
|
chardev: Use QEMUChrEvent enum in IOEventHandler typedef
The Chardev events are listed in the QEMUChrEvent enum.
By using the enum in the IOEventHandler typedef we:
- make the IOEventHandler type more explicit (this handler
process out-of-band information, while the IOReadHandler
is in-band),
- help static code analyzers.
This patch was produced with the following spatch script:
@match@
expression backend, opaque, context, set_open;
identifier fd_can_read, fd_read, fd_event, be_change;
@@
qemu_chr_fe_set_handlers(backend, fd_can_read, fd_read, fd_event,
be_change, opaque, context, set_open);
@depends on match@
identifier opaque, event;
identifier match.fd_event;
@@
static
-void fd_event(void *opaque, int event)
+void fd_event(void *opaque, QEMUChrEvent event)
{
...
}
Then the typedef was modified manually in
include/chardev/char-fe.h.
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Acked-by: Corey Minyard <cminyard@mvista.com>
Acked-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Message-Id: <20191218172009.8868-15-philmd@redhat.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2019-12-18 17:20:09 +00:00
|
|
|
static void boston_lcd_event(void *opaque, QEMUChrEvent event)
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
{
|
|
|
|
BostonState *s = opaque;
|
|
|
|
if (event == CHR_EVENT_OPENED && !s->lcd_inited) {
|
|
|
|
qemu_chr_fe_printf(&s->lcd_display, " ");
|
|
|
|
s->lcd_inited = true;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static uint64_t boston_lcd_read(void *opaque, hwaddr addr,
|
|
|
|
unsigned size)
|
|
|
|
{
|
|
|
|
BostonState *s = opaque;
|
|
|
|
uint64_t val = 0;
|
|
|
|
|
|
|
|
switch (size) {
|
|
|
|
case 8:
|
|
|
|
val |= (uint64_t)s->lcd_content[(addr + 7) & 0x7] << 56;
|
|
|
|
val |= (uint64_t)s->lcd_content[(addr + 6) & 0x7] << 48;
|
|
|
|
val |= (uint64_t)s->lcd_content[(addr + 5) & 0x7] << 40;
|
|
|
|
val |= (uint64_t)s->lcd_content[(addr + 4) & 0x7] << 32;
|
|
|
|
/* fall through */
|
|
|
|
case 4:
|
|
|
|
val |= (uint64_t)s->lcd_content[(addr + 3) & 0x7] << 24;
|
|
|
|
val |= (uint64_t)s->lcd_content[(addr + 2) & 0x7] << 16;
|
|
|
|
/* fall through */
|
|
|
|
case 2:
|
|
|
|
val |= (uint64_t)s->lcd_content[(addr + 1) & 0x7] << 8;
|
|
|
|
/* fall through */
|
|
|
|
case 1:
|
|
|
|
val |= (uint64_t)s->lcd_content[(addr + 0) & 0x7];
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
return val;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void boston_lcd_write(void *opaque, hwaddr addr,
|
|
|
|
uint64_t val, unsigned size)
|
|
|
|
{
|
|
|
|
BostonState *s = opaque;
|
|
|
|
|
|
|
|
switch (size) {
|
|
|
|
case 8:
|
|
|
|
s->lcd_content[(addr + 7) & 0x7] = val >> 56;
|
|
|
|
s->lcd_content[(addr + 6) & 0x7] = val >> 48;
|
|
|
|
s->lcd_content[(addr + 5) & 0x7] = val >> 40;
|
|
|
|
s->lcd_content[(addr + 4) & 0x7] = val >> 32;
|
|
|
|
/* fall through */
|
|
|
|
case 4:
|
|
|
|
s->lcd_content[(addr + 3) & 0x7] = val >> 24;
|
|
|
|
s->lcd_content[(addr + 2) & 0x7] = val >> 16;
|
|
|
|
/* fall through */
|
|
|
|
case 2:
|
|
|
|
s->lcd_content[(addr + 1) & 0x7] = val >> 8;
|
|
|
|
/* fall through */
|
|
|
|
case 1:
|
|
|
|
s->lcd_content[(addr + 0) & 0x7] = val;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
qemu_chr_fe_printf(&s->lcd_display,
|
|
|
|
"\r%-8.8s", s->lcd_content);
|
|
|
|
}
|
|
|
|
|
|
|
|
static const MemoryRegionOps boston_lcd_ops = {
|
|
|
|
.read = boston_lcd_read,
|
|
|
|
.write = boston_lcd_write,
|
|
|
|
.endianness = DEVICE_NATIVE_ENDIAN,
|
|
|
|
};
|
|
|
|
|
|
|
|
static uint64_t boston_platreg_read(void *opaque, hwaddr addr,
|
|
|
|
unsigned size)
|
|
|
|
{
|
|
|
|
BostonState *s = opaque;
|
|
|
|
uint32_t gic_freq, val;
|
|
|
|
|
|
|
|
if (size != 4) {
|
2018-06-08 12:15:33 +00:00
|
|
|
qemu_log_mask(LOG_UNIMP, "%uB platform register read\n", size);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (addr & 0xffff) {
|
|
|
|
case PLAT_FPGA_BUILD:
|
|
|
|
case PLAT_CORE_CL:
|
|
|
|
case PLAT_WRAPPER_CL:
|
|
|
|
return 0;
|
|
|
|
case PLAT_DDR3_STATUS:
|
|
|
|
return PLAT_DDR3_STATUS_LOCKED | PLAT_DDR3_STATUS_CALIBRATED;
|
|
|
|
case PLAT_MMCM_DIV:
|
2019-05-07 16:34:09 +00:00
|
|
|
gic_freq = mips_gictimer_get_freq(s->cps.gic.gic_timer) / 1000000;
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
val = gic_freq << PLAT_MMCM_DIV_INPUT_SHIFT;
|
|
|
|
val |= 1 << PLAT_MMCM_DIV_MUL_SHIFT;
|
|
|
|
val |= 1 << PLAT_MMCM_DIV_CLK0DIV_SHIFT;
|
|
|
|
val |= 1 << PLAT_MMCM_DIV_CLK1DIV_SHIFT;
|
|
|
|
return val;
|
|
|
|
case PLAT_BUILD_CFG:
|
|
|
|
val = PLAT_BUILD_CFG_PCIE0_EN;
|
|
|
|
val |= PLAT_BUILD_CFG_PCIE1_EN;
|
|
|
|
val |= PLAT_BUILD_CFG_PCIE2_EN;
|
|
|
|
return val;
|
|
|
|
case PLAT_DDR_CFG:
|
2018-06-25 12:41:57 +00:00
|
|
|
val = s->mach->ram_size / GiB;
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
assert(!(val & ~PLAT_DDR_CFG_SIZE));
|
|
|
|
val |= PLAT_DDR_CFG_MHZ;
|
|
|
|
return val;
|
|
|
|
default:
|
2018-06-08 12:15:33 +00:00
|
|
|
qemu_log_mask(LOG_UNIMP, "Read platform register 0x%" HWADDR_PRIx "\n",
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
addr & 0xffff);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void boston_platreg_write(void *opaque, hwaddr addr,
|
|
|
|
uint64_t val, unsigned size)
|
|
|
|
{
|
|
|
|
if (size != 4) {
|
2018-06-08 12:15:33 +00:00
|
|
|
qemu_log_mask(LOG_UNIMP, "%uB platform register write\n", size);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (addr & 0xffff) {
|
|
|
|
case PLAT_FPGA_BUILD:
|
|
|
|
case PLAT_CORE_CL:
|
|
|
|
case PLAT_WRAPPER_CL:
|
|
|
|
case PLAT_DDR3_STATUS:
|
|
|
|
case PLAT_PCIE_STATUS:
|
|
|
|
case PLAT_MMCM_DIV:
|
|
|
|
case PLAT_BUILD_CFG:
|
|
|
|
case PLAT_DDR_CFG:
|
|
|
|
/* read only */
|
|
|
|
break;
|
|
|
|
case PLAT_SOFTRST_CTL:
|
|
|
|
if (val & PLAT_SOFTRST_CTL_SYSRESET) {
|
2017-05-15 21:41:13 +00:00
|
|
|
qemu_system_reset_request(SHUTDOWN_CAUSE_GUEST_RESET);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
qemu_log_mask(LOG_UNIMP, "Write platform register 0x%" HWADDR_PRIx
|
2018-06-08 12:15:33 +00:00
|
|
|
" = 0x%" PRIx64 "\n", addr & 0xffff, val);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static const MemoryRegionOps boston_platreg_ops = {
|
|
|
|
.read = boston_platreg_read,
|
|
|
|
.write = boston_platreg_write,
|
|
|
|
.endianness = DEVICE_NATIVE_ENDIAN,
|
|
|
|
};
|
|
|
|
|
|
|
|
static const TypeInfo boston_device = {
|
|
|
|
.name = TYPE_MIPS_BOSTON,
|
|
|
|
.parent = TYPE_SYS_BUS_DEVICE,
|
|
|
|
.instance_size = sizeof(BostonState),
|
|
|
|
};
|
|
|
|
|
|
|
|
static void boston_register_types(void)
|
|
|
|
{
|
|
|
|
type_register_static(&boston_device);
|
|
|
|
}
|
|
|
|
type_init(boston_register_types)
|
|
|
|
|
|
|
|
static void gen_firmware(uint32_t *p, hwaddr kernel_entry, hwaddr fdt_addr,
|
|
|
|
bool is_64b)
|
|
|
|
{
|
|
|
|
const uint32_t cm_base = 0x16100000;
|
|
|
|
const uint32_t gic_base = 0x16120000;
|
|
|
|
const uint32_t cpc_base = 0x16200000;
|
|
|
|
|
|
|
|
/* Move CM GCRs */
|
|
|
|
if (is_64b) {
|
|
|
|
stl_p(p++, 0x40287803); /* dmfc0 $8, CMGCRBase */
|
|
|
|
stl_p(p++, 0x00084138); /* dsll $8, $8, 4 */
|
|
|
|
} else {
|
|
|
|
stl_p(p++, 0x40087803); /* mfc0 $8, CMGCRBase */
|
|
|
|
stl_p(p++, 0x00084100); /* sll $8, $8, 4 */
|
|
|
|
}
|
|
|
|
stl_p(p++, 0x3c09a000); /* lui $9, 0xa000 */
|
|
|
|
stl_p(p++, 0x01094025); /* or $8, $9 */
|
|
|
|
stl_p(p++, 0x3c0a0000 | (cm_base >> 16)); /* lui $10, cm_base >> 16 */
|
|
|
|
if (is_64b) {
|
|
|
|
stl_p(p++, 0xfd0a0008); /* sd $10, 0x8($8) */
|
|
|
|
} else {
|
|
|
|
stl_p(p++, 0xad0a0008); /* sw $10, 0x8($8) */
|
|
|
|
}
|
|
|
|
stl_p(p++, 0x012a4025); /* or $8, $10 */
|
|
|
|
|
|
|
|
/* Move & enable GIC GCRs */
|
|
|
|
stl_p(p++, 0x3c090000 | (gic_base >> 16)); /* lui $9, gic_base >> 16 */
|
|
|
|
stl_p(p++, 0x35290001); /* ori $9, 0x1 */
|
|
|
|
if (is_64b) {
|
|
|
|
stl_p(p++, 0xfd090080); /* sd $9, 0x80($8) */
|
|
|
|
} else {
|
|
|
|
stl_p(p++, 0xad090080); /* sw $9, 0x80($8) */
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Move & enable CPC GCRs */
|
|
|
|
stl_p(p++, 0x3c090000 | (cpc_base >> 16)); /* lui $9, cpc_base >> 16 */
|
|
|
|
stl_p(p++, 0x35290001); /* ori $9, 0x1 */
|
|
|
|
if (is_64b) {
|
|
|
|
stl_p(p++, 0xfd090088); /* sd $9, 0x88($8) */
|
|
|
|
} else {
|
|
|
|
stl_p(p++, 0xad090088); /* sw $9, 0x88($8) */
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Setup argument registers to follow the UHI boot protocol:
|
|
|
|
*
|
|
|
|
* a0/$4 = -2
|
|
|
|
* a1/$5 = virtual address of FDT
|
|
|
|
* a2/$6 = 0
|
|
|
|
* a3/$7 = 0
|
|
|
|
*/
|
|
|
|
stl_p(p++, 0x2404fffe); /* li $4, -2 */
|
|
|
|
/* lui $5, hi(fdt_addr) */
|
|
|
|
stl_p(p++, 0x3c050000 | ((fdt_addr >> 16) & 0xffff));
|
|
|
|
if (fdt_addr & 0xffff) { /* ori $5, lo(fdt_addr) */
|
|
|
|
stl_p(p++, 0x34a50000 | (fdt_addr & 0xffff));
|
|
|
|
}
|
|
|
|
stl_p(p++, 0x34060000); /* li $6, 0 */
|
|
|
|
stl_p(p++, 0x34070000); /* li $7, 0 */
|
|
|
|
|
|
|
|
/* Load kernel entry address & jump to it */
|
|
|
|
/* lui $25, hi(kernel_entry) */
|
|
|
|
stl_p(p++, 0x3c190000 | ((kernel_entry >> 16) & 0xffff));
|
|
|
|
/* ori $25, lo(kernel_entry) */
|
|
|
|
stl_p(p++, 0x37390000 | (kernel_entry & 0xffff));
|
|
|
|
stl_p(p++, 0x03200009); /* jr $25 */
|
|
|
|
}
|
|
|
|
|
|
|
|
static const void *boston_fdt_filter(void *opaque, const void *fdt_orig,
|
|
|
|
const void *match_data, hwaddr *load_addr)
|
|
|
|
{
|
|
|
|
BostonState *s = BOSTON(opaque);
|
|
|
|
MachineState *machine = s->mach;
|
|
|
|
const char *cmdline;
|
|
|
|
int err;
|
|
|
|
void *fdt;
|
|
|
|
size_t fdt_sz, ram_low_sz, ram_high_sz;
|
|
|
|
|
|
|
|
fdt_sz = fdt_totalsize(fdt_orig) * 2;
|
|
|
|
fdt = g_malloc0(fdt_sz);
|
|
|
|
|
|
|
|
err = fdt_open_into(fdt_orig, fdt, fdt_sz);
|
|
|
|
if (err) {
|
|
|
|
fprintf(stderr, "unable to open FDT\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
cmdline = (machine->kernel_cmdline && machine->kernel_cmdline[0])
|
|
|
|
? machine->kernel_cmdline : " ";
|
|
|
|
err = qemu_fdt_setprop_string(fdt, "/chosen", "bootargs", cmdline);
|
|
|
|
if (err < 0) {
|
|
|
|
fprintf(stderr, "couldn't set /chosen/bootargs\n");
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2018-06-25 12:41:57 +00:00
|
|
|
ram_low_sz = MIN(256 * MiB, machine->ram_size);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
ram_high_sz = machine->ram_size - ram_low_sz;
|
|
|
|
qemu_fdt_setprop_sized_cells(fdt, "/memory@0", "reg",
|
|
|
|
1, 0x00000000, 1, ram_low_sz,
|
|
|
|
1, 0x90000000, 1, ram_high_sz);
|
|
|
|
|
|
|
|
fdt = g_realloc(fdt, fdt_totalsize(fdt));
|
|
|
|
qemu_fdt_dumpdtb(fdt, fdt_sz);
|
|
|
|
|
|
|
|
s->fdt_base = *load_addr;
|
|
|
|
|
|
|
|
return fdt;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const void *boston_kernel_filter(void *opaque, const void *kernel,
|
|
|
|
hwaddr *load_addr, hwaddr *entry_addr)
|
|
|
|
{
|
|
|
|
BostonState *s = BOSTON(opaque);
|
|
|
|
|
|
|
|
s->kernel_entry = *entry_addr;
|
|
|
|
|
|
|
|
return kernel;
|
|
|
|
}
|
|
|
|
|
|
|
|
static const struct fit_loader_match boston_matches[] = {
|
|
|
|
{ "img,boston" },
|
|
|
|
{ NULL },
|
|
|
|
};
|
|
|
|
|
|
|
|
static const struct fit_loader boston_fit_loader = {
|
|
|
|
.matches = boston_matches,
|
|
|
|
.addr_to_phys = cpu_mips_kseg0_to_phys,
|
|
|
|
.fdt_filter = boston_fdt_filter,
|
|
|
|
.kernel_filter = boston_kernel_filter,
|
|
|
|
};
|
|
|
|
|
|
|
|
static inline XilinxPCIEHost *
|
|
|
|
xilinx_pcie_init(MemoryRegion *sys_mem, uint32_t bus_nr,
|
|
|
|
hwaddr cfg_base, uint64_t cfg_size,
|
|
|
|
hwaddr mmio_base, uint64_t mmio_size,
|
|
|
|
qemu_irq irq, bool link_up)
|
|
|
|
{
|
|
|
|
DeviceState *dev;
|
|
|
|
MemoryRegion *cfg, *mmio;
|
|
|
|
|
|
|
|
dev = qdev_create(NULL, TYPE_XILINX_PCIE_HOST);
|
|
|
|
|
|
|
|
qdev_prop_set_uint32(dev, "bus_nr", bus_nr);
|
|
|
|
qdev_prop_set_uint64(dev, "cfg_base", cfg_base);
|
|
|
|
qdev_prop_set_uint64(dev, "cfg_size", cfg_size);
|
|
|
|
qdev_prop_set_uint64(dev, "mmio_base", mmio_base);
|
|
|
|
qdev_prop_set_uint64(dev, "mmio_size", mmio_size);
|
|
|
|
qdev_prop_set_bit(dev, "link_up", link_up);
|
|
|
|
|
|
|
|
qdev_init_nofail(dev);
|
|
|
|
|
|
|
|
cfg = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 0);
|
|
|
|
memory_region_add_subregion_overlap(sys_mem, cfg_base, cfg, 0);
|
|
|
|
|
|
|
|
mmio = sysbus_mmio_get_region(SYS_BUS_DEVICE(dev), 1);
|
|
|
|
memory_region_add_subregion_overlap(sys_mem, 0, mmio, 0);
|
|
|
|
|
|
|
|
qdev_connect_gpio_out_named(dev, "interrupt_out", 0, irq);
|
|
|
|
|
|
|
|
return XILINX_PCIE_HOST(dev);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void boston_mach_init(MachineState *machine)
|
|
|
|
{
|
|
|
|
DeviceState *dev;
|
|
|
|
BostonState *s;
|
|
|
|
Error *err = NULL;
|
2020-02-19 16:09:24 +00:00
|
|
|
MemoryRegion *flash, *ddr_low_alias, *lcd, *platreg;
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
MemoryRegion *sys_mem = get_system_memory();
|
|
|
|
XilinxPCIEHost *pcie2;
|
|
|
|
PCIDevice *ahci;
|
|
|
|
DriveInfo *hd[6];
|
|
|
|
Chardev *chr;
|
|
|
|
int fw_size, fit_err;
|
|
|
|
bool is_64b;
|
|
|
|
|
2018-06-25 12:41:57 +00:00
|
|
|
if ((machine->ram_size % GiB) ||
|
|
|
|
(machine->ram_size > (2 * GiB))) {
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
error_report("Memory size must be 1GB or 2GB");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
dev = qdev_create(NULL, TYPE_MIPS_BOSTON);
|
|
|
|
qdev_init_nofail(dev);
|
|
|
|
|
|
|
|
s = BOSTON(dev);
|
|
|
|
s->mach = machine;
|
|
|
|
|
2017-10-05 13:51:10 +00:00
|
|
|
if (!cpu_supports_cps_smp(machine->cpu_type)) {
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
error_report("Boston requires CPUs which support CPS");
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2017-10-05 13:51:10 +00:00
|
|
|
is_64b = cpu_supports_isa(machine->cpu_type, ISA_MIPS64);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
hw/mips: Use object_initialize_child for correct reference counting
As explained in commit aff39be0ed97:
Both functions, object_initialize() and object_property_add_child()
increase the reference counter of the new object, so one of the
references has to be dropped afterwards to get the reference
counting right. Otherwise the child object will not be properly
cleaned up when the parent gets destroyed.
Thus let's use now object_initialize_child() instead to get the
reference counting here right.
This patch was generated using the following Coccinelle script:
@use_sysbus_init_child_obj_missing_parent@
expression child_ptr;
expression child_type;
expression child_size;
@@
- object_initialize(child_ptr, child_size, child_type);
...
- qdev_set_parent_bus(DEVICE(child_ptr), sysbus_get_default());
...
?- object_unref(OBJECT(child_ptr));
+ sysbus_init_child_obj(OBJECT(PARENT_OBJ), "CHILD_NAME", child_ptr,
+ child_size, child_type);
We let the Malta/Boston machines adopt the CPS child, and similarly
the CPS adopts the ITU/CPC/GIC/GCR children.
While the object_initialize() function doesn't take an
'Error *errp' argument, the object_initialize_child() does.
Since this code is used when a machine is created (and is not
yet running), we deliberately choose to use the &error_abort
argument instead of ignoring errors if an object creation failed.
This choice also matches when using sysbus_init_child_obj(),
since its code is:
void sysbus_init_child_obj(Object *parent,
const char *childname, void *child,
size_t childsize, const char *childtype)
{
object_initialize_child(parent, childname, child, childsize,
childtype, &error_abort, NULL);
qdev_set_parent_bus(DEVICE(child), sysbus_get_default());
}
Suggested-by: Eduardo Habkost <ehabkost@redhat.com>
Inspired-by: Thomas Huth <thuth@redhat.com>
Signed-off-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20190507163416.24647-11-philmd@redhat.com>
Reviewed-by: Paolo Bonzini <pbonzini@redhat.com>
Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2019-05-07 16:34:10 +00:00
|
|
|
sysbus_init_child_obj(OBJECT(machine), "cps", OBJECT(&s->cps),
|
|
|
|
sizeof(s->cps), TYPE_MIPS_CPS);
|
2019-05-07 16:34:09 +00:00
|
|
|
object_property_set_str(OBJECT(&s->cps), machine->cpu_type, "cpu-type",
|
2017-10-05 13:51:10 +00:00
|
|
|
&err);
|
2019-05-18 20:54:27 +00:00
|
|
|
object_property_set_int(OBJECT(&s->cps), machine->smp.cpus, "num-vp", &err);
|
2019-05-07 16:34:09 +00:00
|
|
|
object_property_set_bool(OBJECT(&s->cps), true, "realized", &err);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
if (err != NULL) {
|
|
|
|
error_report("%s", error_get_pretty(err));
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
2019-05-07 16:34:09 +00:00
|
|
|
sysbus_mmio_map_overlap(SYS_BUS_DEVICE(&s->cps), 0, 0, 1);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
flash = g_new(MemoryRegion, 1);
|
2018-06-25 12:41:57 +00:00
|
|
|
memory_region_init_rom(flash, NULL, "boston.flash", 128 * MiB, &err);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
memory_region_add_subregion_overlap(sys_mem, 0x18000000, flash, 0);
|
|
|
|
|
2020-02-19 16:09:24 +00:00
|
|
|
memory_region_add_subregion_overlap(sys_mem, 0x80000000, machine->ram, 0);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
ddr_low_alias = g_new(MemoryRegion, 1);
|
|
|
|
memory_region_init_alias(ddr_low_alias, NULL, "boston_low.ddr",
|
2020-02-19 16:09:24 +00:00
|
|
|
machine->ram, 0,
|
|
|
|
MIN(machine->ram_size, (256 * MiB)));
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
memory_region_add_subregion_overlap(sys_mem, 0, ddr_low_alias, 0);
|
|
|
|
|
|
|
|
xilinx_pcie_init(sys_mem, 0,
|
2018-06-25 12:41:57 +00:00
|
|
|
0x10000000, 32 * MiB,
|
|
|
|
0x40000000, 1 * GiB,
|
2019-05-07 16:34:09 +00:00
|
|
|
get_cps_irq(&s->cps, 2), false);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
xilinx_pcie_init(sys_mem, 1,
|
2018-06-25 12:41:57 +00:00
|
|
|
0x12000000, 32 * MiB,
|
|
|
|
0x20000000, 512 * MiB,
|
2019-05-07 16:34:09 +00:00
|
|
|
get_cps_irq(&s->cps, 1), false);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
pcie2 = xilinx_pcie_init(sys_mem, 2,
|
2018-06-25 12:41:57 +00:00
|
|
|
0x14000000, 32 * MiB,
|
|
|
|
0x16000000, 1 * MiB,
|
2019-05-07 16:34:09 +00:00
|
|
|
get_cps_irq(&s->cps, 0), true);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
platreg = g_new(MemoryRegion, 1);
|
|
|
|
memory_region_init_io(platreg, NULL, &boston_platreg_ops, s,
|
|
|
|
"boston-platregs", 0x1000);
|
|
|
|
memory_region_add_subregion_overlap(sys_mem, 0x17ffd000, platreg, 0);
|
|
|
|
|
|
|
|
s->uart = serial_mm_init(sys_mem, 0x17ffe000, 2,
|
2019-05-07 16:34:09 +00:00
|
|
|
get_cps_irq(&s->cps, 3), 10000000,
|
2018-04-20 14:52:43 +00:00
|
|
|
serial_hd(0), DEVICE_NATIVE_ENDIAN);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
lcd = g_new(MemoryRegion, 1);
|
|
|
|
memory_region_init_io(lcd, NULL, &boston_lcd_ops, s, "boston-lcd", 0x8);
|
|
|
|
memory_region_add_subregion_overlap(sys_mem, 0x17fff000, lcd, 0);
|
|
|
|
|
2019-02-13 13:18:13 +00:00
|
|
|
chr = qemu_chr_new("lcd", "vc:320x240", NULL);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
qemu_chr_fe_init(&s->lcd_display, chr, NULL);
|
|
|
|
qemu_chr_fe_set_handlers(&s->lcd_display, NULL, NULL,
|
2017-07-06 12:08:49 +00:00
|
|
|
boston_lcd_event, NULL, s, NULL, true);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
|
|
|
|
ahci = pci_create_simple_multifunction(&PCI_BRIDGE(&pcie2->root)->sec_bus,
|
|
|
|
PCI_DEVFN(0, 0),
|
|
|
|
true, TYPE_ICH9_AHCI);
|
2017-07-18 15:47:56 +00:00
|
|
|
g_assert(ARRAY_SIZE(hd) == ahci_get_num_ports(ahci));
|
|
|
|
ide_drive_get(hd, ahci_get_num_ports(ahci));
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
ahci_ide_create_devs(ahci, hd);
|
|
|
|
|
|
|
|
if (machine->firmware) {
|
|
|
|
fw_size = load_image_targphys(machine->firmware,
|
2018-06-25 12:41:57 +00:00
|
|
|
0x1fc00000, 4 * MiB);
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
if (fw_size == -1) {
|
2019-04-17 19:06:30 +00:00
|
|
|
error_report("unable to load firmware image '%s'",
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
machine->firmware);
|
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
} else if (machine->kernel_filename) {
|
|
|
|
fit_err = load_fit(&boston_fit_loader, machine->kernel_filename, s);
|
|
|
|
if (fit_err) {
|
2019-04-17 19:06:30 +00:00
|
|
|
error_report("unable to load FIT image");
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
|
|
|
|
gen_firmware(memory_region_get_ram_ptr(flash) + 0x7c00000,
|
|
|
|
s->kernel_entry, s->fdt_base, is_64b);
|
|
|
|
} else if (!qtest_enabled()) {
|
2019-04-17 19:06:30 +00:00
|
|
|
error_report("Please provide either a -kernel or -bios argument");
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
exit(1);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void boston_mach_class_init(MachineClass *mc)
|
|
|
|
{
|
|
|
|
mc->desc = "MIPS Boston";
|
|
|
|
mc->init = boston_mach_init;
|
|
|
|
mc->block_default_type = IF_IDE;
|
2018-06-25 12:41:57 +00:00
|
|
|
mc->default_ram_size = 1 * GiB;
|
2020-02-19 16:09:24 +00:00
|
|
|
mc->default_ram_id = "boston.ddr";
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
mc->max_cpus = 16;
|
2017-10-05 13:51:10 +00:00
|
|
|
mc->default_cpu_type = MIPS_CPU_TYPE_NAME("I6400");
|
hw/mips: MIPS Boston board support
Introduce support for emulating the MIPS Boston development board. The
Boston board is built around an FPGA & 3 PCIe controllers, one of which
is connected to an Intel EG20T Platform Controller Hub. It is used
during the development & debug of new CPUs and the software intended to
run on them, and is essentially the successor to the older MIPS Malta
board.
This patch does not implement the EG20T, instead connecting an already
supported ICH-9 AHCI controller. Whilst this isn't accurate it's enough
for typical stock Boston software (eg. Linux kernels) to work with hard
disks given that both the ICH-9 & EG20T implement the AHCI
specification.
Boston boards typically boot kernels in the FIT image format, and this
patch will treat kernels provided to QEMU as such. When loading a kernel
directly, the board code will generate minimal firmware much as the
Malta board code does. This firmware will set up the CM, CPC & GIC
register base addresses then set argument registers & jump to the kernel
entry point. Alternatively, bootloader code may be loaded using the bios
argument in which case no firmware will be generated & execution will
proceed from the start of the boot code at the default MIPS boot
exception vector (offset 0x1fc00000 into (c)kseg1).
Currently real Boston boards are always used with FPGA bitfiles that
include a Global Interrupt Controller (GIC), so the interrupt
configuration is only defined for such cases. Therefore the board will
only allow use of CPUs which implement the CPS components, including the
GIC, and will otherwise exit with a message.
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Reviewed-by: Yongbok Kim <yongbok.kim@imgtec.com>
[yongbok.kim@imgtec.com:
isolated boston machine support for mips64el.
updated for recent Chardev changes.
ignore missing bios/kernel for qtest.
added default -drive to if=ide explicitly.
changed default memory size into 1G due to make check failure
on 32-bit hosts]
Signed-off-by: Yongbok Kim <yongbok.kim@imgtec.com>
2016-09-08 14:51:58 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
DEFINE_MACHINE("boston", boston_mach_class_init)
|