[J-core] qemu support

[Rich Felker]

On Tue, Apr 26, 2016 at 12:44:43PM -0400, Christopher Friedt wrote:
> Hi Rich,
> 
> Thanks for getting back to me.
> 
> Qemu is a pretty invaluable tool for getting people hacking on a new
> architecture, if only because it lowers the barrier to entry in terms
> of cost. Plus, it's sometimes a bit more convenient :-)

I agree completely. <3 qemu for getting started on new archs.

> On Tue, Apr 26, 2016 at 12:23 PM, Rich Felker <dalias at libc.org> wrote:
> > On Tue, Apr 26, 2016 at 08:15:58AM -0400, Christopher Friedt wrote:
> >> Hi List,
> >>
> >> just out of curiosity, has anyone started working on Qemu support for
> >> j2 and e.g. the Numato board?
> >
> > No. It's something on my medium to long term agenda, but if somebody
> > else wants to try sooner that would be great. I think it would make
> > sense to start by converting qemu's sh support over to taking as input
> > a device tree for the hardware to emulate rather than hard-coding a
> > fixed board, but you could get by without this step.
> 
> Device Tree support would benefit not just sh or j2 but most
> architectures in Qemu. I'm not even aware if DT support is available
> currently for any arch in Qemu (PPC?). It would probably be best to
> defer that, if that's the case, and then handle it for all machine
> types.

I kind of thought at least one arch had something like this already,
but if so it's probably done in a hackish arch-specific way rather
than as a general framework.

> > The minimal change needed to run j2/sh2 bare-metal/kernel code (vs sh4
> > code) is that the trap/interrupt mechanism has to jump to _code_ in
> > the trap vector table rather than loading an address from the table.
> 
> Hmm... Is that specific to Qemu? Otherwise, maybe I'm unfamiliar with
> the j2 / sh2 interrupt mechanism.

It's a difference between sh2 and sh3+. See the full ISA reference
manuals or the summary here:

http://shared-ptr.com/sh_insns.htm

Actually I think I said it backwards. On sh1/sh2/j2, interrupts/traps
load an address from (VBR+trapno*4) and jump to it. On sh3/sh4, they
branch to VBR+0x100 with trapno*4 in a special TRA register. The way
registers are saved/restored also differ.

(Note that it seems easy for software running on sh4 that wants the
sh2 behavior to get it just by appending some code after the last VBR
table entry that converts the saved register state then jumps to
VBR+TRA. But of course qemu can't do it that way because it can't
clobber the memory at VBR+0x100.)

> Do you know of a decent document describing the SuperH ISA and core model?

The above ISA summary is great but here are the original official
docs.

SH-1/2:
http://documentation.renesas.com/doc/products/mpumcu/rej09b0171_superh.pdf

SH-4:
http://documentation.renesas.com/doc/products/mpumcu/rej09b0318_sh_4sm.pdf

Here's the SH-FDPIC ABI doc (one mistake to be aware of: the meaning
of the EF_SH_PIC flag is inverted vs what the document says):
http://sourcery.mentor.com/public/docs/sh-fdpic/sh-fdpic-abi.txt

And some additional ABI documents:
http://www2.st.com/content/ccc/resource/technical/document/reference_manual/37/ad/a9/94/a1/8d/43/a1/CD17839242.pdf/files/CD17839242.pdf/jcr:content/translations/en.CD17839242.pdf
http://www.kpitgnutools.com/manuals/SH-ABI-Specification.html
https://www.uclibc.org/docs/psABI-sh.txt

There may be some minor inconsistencies in some of them vs what's
actually used in practice. If you run into anything that seems
questionable, just ask and I'll check it against actual existing
practice.

> > Aside from that, support for the j2 cas.l (compare and swap)
> > instruction should be added, and instructions not available on j2
> > (i.e. all insns new on sh3+ except the barrel shifter) should be made
> > to trap so that code that can't actually run on the real hardware gets
> > caught.
> 
> Right - there is a -cpu argument that could be used to allow /
> disallow certain instructions.

Indeed.

Rich