[J-core] qemu support

[Rob Landley]

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?

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.)

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...)

(Remind me to poke Jeff & Jen about when the last sh4 patent expires so
we know when we can open the j4 can of worms...)

>> 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.

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?

>>> 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

Rich: do you want to edit the website to add a "references" page, or
should I? :)

(When we get the github account set up, remind me to put the website git
repository on it so we can take pull requests for website changes. :)

> 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.

We should try to get permission to host and update local copies on
j-core.org.

Rob