[Top][All Lists]

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

Re: [Qemu-devel] [PATCH v1 5/5] hw/arm: Add the Netduino Plus 2

From: Alistair
Subject: Re: [Qemu-devel] [PATCH v1 5/5] hw/arm: Add the Netduino Plus 2
Date: Sat, 04 May 2019 00:25:56 -0400
User-agent: Cyrus-JMAP/3.1.6-449-gfb3fc5a-fmstable-20190430v1

On Thu, May 2, 2019, at 3:06 AM, Peter Maydell wrote:
> On Tue, 30 Apr 2019 at 21:29, Alistair Francis <address@hidden> wrote:
> >
> > On Tue, Apr 30, 2019 at 9:02 AM Peter Maydell <address@hidden> wrote:
> > > Can you explain the purpose of the reset code? None of the other
> > > v7m boards seem to need to do a manual qemu_register_reset().
> >
> > The reset code allows the machine to work with the -kernel option.
> > Without the reset override using -kernel results in the guest starting
> > at the wrong address. We can use the -device loader option without the
> > reset code though.
> That sounds in line with how -kernel works on the other armv7m
> boards -- the expectation is that your image file includes a
> full vector table and the CPU will read the PC and SP from it
> when it resets. If you want "honour the entry point" you can
> use -device loader, as you say.
> Ignoring the entry point for -kernel ELF files is certainly
> a bit confusing, but I think if we want to change this we should
> do it globally, rather than having one board which behaves
> differently to the rest. Changing it does have some awkwardness:

Hmm... That is a good point. It is confusing having something just for one 
board. I'll drop this part and we can re-evaluate later.

> * possibility of breaking previously working images

I have no way to test the other boards, so this might be difficult to change.

> * we can get the initial PC from the ELF entrypoint, but if
>  we do this what do we do about the initial SP value ?

Not sure about this one either. I'm guessing it changes between the different M 


> thanks
> -- PMM

reply via email to

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