Re: [linuxsh-dev] SH5 kernel

[Paul M. <le...@Ch...>]

On Wed, Feb 27, 2002 at 11:54:02PM +0000, Stuart Menefy wrote:
> Following the release of an SH5 compiler and associated tools last week,
> I pleased to be able to say that we are also almost ready to release
> an SH5 Linux kernel.
>=20
Good to hear. Any idea when the SH8000's will be readily available?

Speaking of the kernel, what's the status of your guys kgdb work? Are there
only SH5 specific hacks and stubs in your tree?

> This work has been going for some time, in another group within ST, but
> it is only now that the tools are available, and the architecture is
> public, that we are able to release it.
>=20
Does this mean that any code that was developed using the NDA'd documentati=
on
can be pushed into CVS now? Also, are there any updates to the documentatio=
n?
If so, are these available without NDA?

> I say almost ready, because there are some last minute details to tidy
> up, but mainly because I'd like to get people's suggestions on where we
> should be putting this.
>=20
Since you're looking for comments and suggestions on how the source tree is
done presently, is there some place where we can take a look at the tree the
way it is now, so that more accurate feedback can be offered?

> First a bit of background:
>=20
> As far as a kernel is concerned, SH5 is not a variant of the current SH
> architecture, in the way that SH3 and SH4 are. It is a 64 bit processor,
> with more and wider registers, different caches, MMU, interrupt controller
> etc.
>=20
> The CPU supports two instruction sets, the new instruction set
> (called SH-Media) gives access to all the new facilities of the machine,
> however it also supports a second instruction set (SH-Compact) which
> is a subset of the SH4 instruction set, sufficient to support native
> execution of SH4 _user_ _mode_ binaries. This means that a new kernel
> must, at least in part, be written in SH-Media instructions. It could
> also use SH-Compact if desired, but we've chosen not to do this at the
> moment. And yes, Linux could support the native execution of SH4 binaries
> if somebody felt like doing the necessary work in the kernel.
>=20
I suppose the use of SH-Media extensively makes the most sense for the init=
ial
port, but in the long run, doing as much as possibly in SH-Compact would
probably be faster and cut down on the overall object/resultant kernel size=
 ..
especially considering the differences in instruction sizes (and with -g
turned on, saving as much space as possible is always a plus..). While this
may not be worth thinking about right now, it still seems like something wo=
rth
looking into in the future..

> So for this reason we decided not to merge the SH5 code with the current
> SH3/4 kernel. We have created a new architecture called "sh5" in the kern=
el
> source code, which is completely separate from the current "sh"
> architecture. However it does share device drivers with the other SH
> devices, such as the SCIF.
>=20
> It could have been called sh64, but we decided against that as it
> is not really a 64 bit port - pointers and longs are still 32 bits.
> A full 64 bit port is still a possibility for the future.
>=20
I'm not so sure that this is a good idea.. in the tradition of architecture
naming schemes under linux things always follow the arch/arch64 approach.
If the system is capable of sanely mapping things to 64-bit addresses witho=
ut
the system choking, then the arch64 thing seems to make more sense. If on t=
he
other hand, the system has issues with this, then it doesn't have much place
in an arch64-type layout. From your indication of pointers being 32 bits, t=
his
would certainly seem to indicate that it's not ready for an sh64 convention.

On the other hand, adding "sh5" completely goes against the natural order of
things and should try to be avoided as vigorously as possible. While the SH5
might not follow typical SH3/4 convention, that hardly warrants the creation
of a new arch directory. Under MIPS, many systems have completely different
caches, MMU's, TLB handling, etc, etc. all of these things are dealt with i=
n a
rather sane fashion -- of which I'm trying to achieve the same goal with the
SH tree for 2.5, though I'm still working on restructuring things.

As long as the majority of things are done in SH-Compact, changes to things
like entry.S should be rather minimalistic.. but it's hard to determine what
the severity of the changes are without having any code to look at.

> Work on this port started some time ago, and hasn't kept track with
> current kernel developments. So the port is still based on a 2.4.0-test4
> kernel. One of the things we want to do in the not too distant future is
> upgrade to a more recent tree, but I'd rather release now and get
> people looking at it than wait any longer.
>=20
Agreed, this seems like the best possible course of action.

> So, the proposal:
>=20
> I'd like to get this code checked into a CVS repository on SourceForge
> as soon as possible. There are already several groups here who want
> access to the sources, so this is easier than just putting it up for
> FTP somewhere. Plus it allows other developers to join in as things
> develop.
>=20
> At the moment I think it may be better to create a new SourceForge
> project for this, rather than use the current LinuxSH one.
>=20
> This is mainly:
>  - to try and reduce confusion - a lot of the current web content is not
>    applicable to SH5, and adding qualifying statements would make it
>    messy.

A lot of the LinuxSH website is out of date and needing to be revamped the =
way
it is. While it might not presently be the best place to discuss SH5, it
certainly should be. If someone had the time to spend on cleaning up the
website, that'd seem to be the best solution. Any volunteers?

>  - the kernel is currently only of interest to kernel hackers, its
>    not ready for general consumption.

The 2.5 restructuring tree for the LinuxSH isn't suitable for mere mortals
either, and shouldn't even be approached by anyone other then kernel hacker=
s.
Yet it sits in CVS just fine.=20

>  - because the current SH5 code is based around the old kernel, and is
>    still fairly immature, it doesn't make sense to put it in the
>    "linux" directory in CVS. It could go in a separate directory in
>    CVS though.

In my opinion, there isn't enough reason to divide this stuff out into a
completely seperate project.. putting SH5 under its own module for the time
being would be fine, but it would be nice to forward port this stuff to
current 2.4, and merge it into the 2.4 branch of the drop-in tree, where it
can then be used by everybody and the other module could be removed in its
entirety.

If there's interest in this, I'd have no problems taking care of updating t=
he
SH5 tree and merging it into the existing drop-in, if there are no other
takers.

>  - things are still very changable. Its quite possible major
>    restructuring may still happen (renaming the architacture for example!=
),
>    and we don't know at the moment how things will turn out.

I'd say concentrate on stable changes under the 2.4 branch if that's where
this ends up going.. or just leave it in HEAD.. I'd prefer if  major
restructuring would  be postponed until I'm done with the 2.5 restructuring=
 of
the tree, otherwise we might end up duplicating efforts. Plus, it should ma=
ke
assimilating SH5 in a sane fashion a lot easier..

> and then at some point in the future when the kernel is more mature,
> and we know better what it will look like, we can think about merging
> it into the LinuxSH project.
>=20
If you start maintaining it independantly of the LinuxSH project from the
beginning, it's just going to be more of a nuisance when you try and do the
merge later. At present, the code is in its infancy, things can still be
changed, etc, etc. with these things in mind, it's the best time to merge t=
his
into the LinuxSH project and beat it into submission..

Either way.. lets have a look at the tree first, and then we can figure out
what the best course of action might be. Or if anyone else has any similar
insight on the matter, that could be helpful too.

Regards,

--=20
Paul Mundt <le...@ch...>