[J-core] qemu support

[Rich Felker]

On Tue, Apr 26, 2016 at 06:50:26PM -0500, Rob Landley wrote:
> On 04/26/2016 12:05 PM, Rich Felker wrote:
> > 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.
> 
> Rich: you got j2 userspace running under qemu already, didn't you?
> (Using an sh4 kernel to run fdpic binaries.) You emailed me the glue
> magic you used to get that running once, but I don't think I ever put it
> on the website. Could you repost it here?

First, app-level: qemu-sh4eb mostly runs FDPIC j2 binaries out of the
box, except that it lacks the right signal-handling support for FDPIC
(treating the signal handler pointer as a function descriptor rather
than a code address) so programs that use signal handlers crash badly.
There's experimental SH-FDPIC support in qemu already, but it's not
enabled; I had to hack some macros and add some code to enable it. But
the code that's already there is really not needed except for testing
the FDPIC crt1/ldso entry point code, since FDPIC binaries run fine
loaded as plain ELF. I can dig up and post my patches for this. The
important part of my patches, though, is making signal handling work
right, and that's trivial.

qemu-system-sh4eb can also be used to run a FDPIC j2 userspace. There
are no hacks needed to make this work; you just need to be able to
build a big-endian kernel for the board qemu emulates (the
configuration in Aboriginal Linux, switched to big endian). One issue
we ran into before was with the init process, but it works correctly
if your initramfs has a /init script that mounts devtmpfs, opens the
console to it, and execs /sbin/init. None of this is specific to sh;
it's just that the kernel doesn't like using initramfs as the "main
filesystem" unless you provide such a bootstrapping /init.

> Running a j2 _kernel_ under qemu, and getting qemu to emulate a numato
> board and consider sh3/sh4 instructions "illegal" when emulating j2, is
> a separate issue. (And a much more intrusive change to qemu. In theory
> we could even add Mimasv2 and Turtle board emulations without teaching
> qemu about device tree, in practice that's not the approach we want to
> take.)

If it's easy to do, this might be a good temporary measure to allow
further qemu/j2 development to proceed. It could be switched to DT
later.

> Also, in theory we could get a native-ish toolchain running on
> qemu-system-sh4, using an sh4 hosted toolchain that produces j2 fdpic
> binaries as output. (About like doing a 32 bit build on a 64 bit
> machine, the result runs but running doesn't guarantee you did it right...)

In theory you can also do native compiles on j2. I almost got it
working but I botched the target options resulting in a mismatching
ABI (I think I left out --enable-fdpic) and I didn't get around to
redoing the build. But it got all the way to linking before it errored
out, so I'm pretty sure it will work.

> I've spoken to the qemu guys at ELC several times over the years. They
> were working on this back in 2010. I was trying to poke them to do more:
> 
> http://elinux.org/CELF_Project_Proposal/Add_Device_Tree_emulation_support_to_QEMU
> 
> I don't know about the current status of this, but asking on the qemu
> mailing list might get a reply?

Thanks for digging this up. Yes, asking there seems like a good idea.

> > 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
> 
> Rich: do you want to edit the website to add a "references" page, or
> should I? :)

Go ahead if you can. The state of the website keeps making me want to
redesign the whole thing whenever I touch it, but I have more pressing
things to be doing...

Rich