qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v5 2/2] Add Nios II semihosting support.


From: Peter Maydell
Subject: Re: [Qemu-devel] [PATCH v5 2/2] Add Nios II semihosting support.
Date: Fri, 8 Mar 2019 18:21:58 +0000

On Fri, 8 Mar 2019 at 17:01, Sandra Loosemore <address@hidden> wrote:
>
> On 3/8/19 9:04 AM, Peter Maydell wrote:
> > Thanks. So who "owns" this ABI (ie has the authority to change
> > it and should be the end documenting it)? How many projects or
> > bits of software are implementing either end of it?
>
> Going back in ancient history, I implemented the m68k version in
> libgloss in 2006 to support a hardware debug stub that CodeSourcery was
> also providing at that time.  We later moved the runtime side of it into
> target-agnostic code in an internal library, so when it came time to do
> a similar JTAG debug stub for bare-metal Nios II hardware testing in
> 2012, we re-used our existing code for both library and debug stub.
> Later Altera implemented the same protocol in some proprietary
> simulators they provided to us, and more recently we wrote these patches
> to add it to QEMU.  We've shifted away from hardware testing and no
> longer use the original debug stub now.
>
> > If we decide that QEMU owns the spec we can put the documentation
> > into docs/specs/.
>
> Making QEMU the "owner" of the ABI seems a little peculiar to me since
> it is only one client among several, and is a latecomer too.  I think
> libgloss would make a little more sense.  OTOH, I have no problem with
> making the documentation part of QEMU.

Thanks for the backstory. I agree that if QEMU is just one of
multiple implementations then it's not a great place to
hold the specification. Either libgloss, or I suppose in
theory Altera as the owner of the architecture could bless
the specification and host it...

-- PMM



reply via email to

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