Re: Moving forward with sh2/nommu

[Rich Felker <dalias@libc.org>]

On Fri, Jun 12, 2015 at 01:08:05PM +0900, Yoshinori Sato wrote:
> > > >> 4. Syscall trap numbers differ on SH2 vs SH3/4. Presumably the reason
> > > >>    is that these two SH2A hardware traps overlap with the syscall
> > > >>    range used by SH3/4 ABI:
> > > > 
> > > > I haven't patched this yet. I'd like to use 31 (0x1f) as the new
> > > > universal SH syscall trap number, instead of 22. More details on the
> > > > reasons later.
> > > 
> > > I've cc'd Yoshinori Sato (who did most of the historical sh2 work) and
> > > Shumpei Kawasaki (the original superh architect). They'll probably have
> > > an opinion on your "more reasons" for changing sh2 system call numbers
> > > to match sh4.
> 
> It histrical reason.
> SH3/4 is assigned #0x10 to #0x17 for system call entry.
> But SH2A system using this vector.
> So we moved to #0x20 to #0x27 for SH2A.
> (SH2A specification is #0x20 to #0x3f allocated for user application.)
> 
> And SH2 port is based on SH2A port.
> It have same systemcall interface.
> 
> > Thank you. I'd really like to make progress at least on the matter of
> > determining if this is feasible. I now have a new musl/sh2 patch that
> > simply uses "trapa #31" unconditionally, and it's a lot
> > simpler/cleaner and working on my patched kernel. The big question is
> > just whether this is an unacceptable constraint on hardware.
> 
> SH2A reserved system for vector 31.
> But not assigned now.
> I think no problem.

Thank you for the feedback. This sounds promising.

We still need whoever ends up being the new kernel maintainer for SH
to be okay with adding trap 31 syscall support for sh2 and declaring
it supported/stable for sh3/4 too, but at least it looks like there
arent technical problems for doing this.

Rich