On Wed, Sep 11, 2019, at 11:49 AM, Peter Maydell wrote: > On Fri, 6 Sep 2019 at 07:10, Alistair Francis <alist...@alistair23.me> wrote: > > > > > > Now that the Arm-M4 CPU has been added to QEMU we can add the Netduino > > Plus 2 machine. This is very similar to the STM32F205 and Netduino 2 SoC > > and machine. > > > > v4: > > - Rebase on master > > v3: > > - Remove custom reset handler > > - Add init-entry and init-sp properties > > - Rebase on master (including Kconfig changes) > > v2: > > - Reorder patchset > > - Return the kernel entry point instead of using a pointer > > - Address Peter's comments > > > > > > Alistair Francis (6): > > armv7m: Allow entry information to be returned > > target/arm: Allow setting M mode entry and sp > > hw/misc: Add the STM32F4xx Sysconfig device > > hw/misc: Add the STM32F4xx EXTI device > > hw/arm: Add the STM32F4xx SoC > > hw/arm: Add the Netduino Plus 2 > > What are the changes for setting initial SP and PC for?
If it's not set the the guest code jumps into some broken address and crashes at boot. > Why is this SoC special? Is it different from the > stm32f205 SoC we model already? >From memory the STM32F205 might have the same issue. It just wasn't a big >problem as my STM32F2xx tests were targeting QEMU while the STM32F4xx isn't. > > I'm not in general a fan of individual board models having > their own custom behaviour for -kernel. The inconsistencies > between architectures and between A- and M- profile are > awkward enough as it is... I do see it as a pain as well, but I'm not sure what else to do to fix it. Alistair > > thanks > -- PMM > >
