* the INITSVTOR* registers before powering up the CPUs in any case,
* so the hardware's default value doesn't matter. QEMU doesn't emulate
* the control processor, so instead we behave in the way that the
- * firmware does. All boards currently known about have firmware that
- * sets the INITSVTOR0 and INITSVTOR1 registers to 0x10000000, like the
- * IoTKit default. We can make this more configurable if necessary.
+ * firmware does. The initial value is configurable by the board code
+ * to match whatever its firmware does.
*/
- qdev_prop_set_uint32(cpudev, "init-svtor", 0x10000000);
+ qdev_prop_set_uint32(cpudev, "init-svtor", s->init_svtor);
/*
* Start all CPUs except CPU0 powered down. In real hardware it is
* a configurable property of the SSE-200 which CPUs start powered up
DEFINE_PROP_UINT32("EXP_NUMIRQ", ARMSSE, exp_numirq, 64),
DEFINE_PROP_UINT32("MAINCLK", ARMSSE, mainclk_frq, 0),
DEFINE_PROP_UINT32("SRAM_ADDR_WIDTH", ARMSSE, sram_addr_width, 15),
+ DEFINE_PROP_UINT32("init-svtor", ARMSSE, init_svtor, 0x10000000),
DEFINE_PROP_END_OF_LIST()
};
* if necessary.)
* + QOM property "SRAM_ADDR_WIDTH" sets the number of bits used for the
* address of each SRAM bank (and thus the total amount of internal SRAM)
+ * + QOM property "init-svtor" sets the initial value of the CPU SVTOR register
+ * (where it expects to load the PC and SP from the vector table on reset)
* + Named GPIO inputs "EXP_IRQ" 0..n are the expansion interrupts for CPU 0,
* which are wired to its NVIC lines 32 .. n+32
* + Named GPIO inputs "EXP_CPU1_IRQ" 0..n are the expansion interrupts for
uint32_t exp_numirq;
uint32_t mainclk_frq;
uint32_t sram_addr_width;
+ uint32_t init_svtor;
} ARMSSE;
typedef struct ARMSSEInfo ARMSSEInfo;