hw-cpu-openrisc

hw-cpu-openrisc

[Robert Cragie]

I would like to create a 'hw-cpu-openrisc' CPU component. I have some ideas
about what to do, however I would be very grateful if someone could give me
some definite pointers and an indication of how much effort it would take. I
see the openrisc architecture is there in bfd and cgen already, so that's a
start...

TIA

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________

Re: hw-cpu-openrisc

[Frank Ch. Eigler]

"Robert Cragie"  wrote:

> I would like to create a 'hw-cpu-openrisc' CPU component. I have
> some ideas about what to do [...]

The work includes ...
- adding sid configury for the openrisc target; see sid/config/sidtargets.m4;
  will need autoconf/automake runs throughout
- adding sid configuration file generator pieces to sid/bsp/configrun-sid
- populating sid/component/cgen-cpu/openrisc, mostly with cgen-generated files,
  plus one or two hand-written ones; the m32r target is amongst the simplest to
  use as a base
- testing, perhaps as a dejagnu "baseboard"

With a cgen model already done, this part can be done in days or weeks
or more, depending on details, acquaintance with configury hacking,
and other factors.


- FChE

RE: hw-cpu-openrisc

[Robert Cragie]

I'm having a go at piecing the jigsaw together...

> The work includes ...
> - adding sid configury for the openrisc target; see
> sid/config/sidtargets.m4;

Will something like this be sufficient?

Index: sidtargets.m4
===================================================================
RCS file: /cvs/src/src/sid/config/sidtargets.m4,v
retrieving revision 1.4
diff -r1.4 sidtargets.m4
43a44
> sidtarget_openrisc=$sidtarget_default
56a58
>       openrisc*) sidtarget_openrisc=1 ;;
70a73
>   ${sidtarget_openrisc}) ;;
104a108,112
>
> AC_MSG_CHECKING(OpenRISC family support)
> AC_SUBST(sidtarget_openrisc)
> AM_CONDITIONAL(SIDTARGET_OPENRISC,[test "x$sidtarget_openrisc" = x1])
> AC_MSG_RESULT($sidtarget_openrisc)#

>   will need autoconf/automake runs throughout

So how do I do this exactly? I don't know much about these utilities, I'm
afraid. I did 'autoconf' and 'automake' at the top but it didn't seem to
make much difference to any of the files. If I need to go and read up about
these utilities before trying to do anything else, let me know :-)

> - adding sid configuration file generator pieces to sid/bsp/configrun-sid

Again, I think I can see what to do here, assuming I don't want any 'boards'
just yet. Would something like this do?

Index: configrun-sid.in
===================================================================
RCS file: /cvs/src/src/sid/bsp/configrun-sid.in,v
retrieving revision 1.34
diff -r1.34 configrun-sid.in
19a20
> 		 "openrisc" => "hw-cpu-openrisc/d",
25a27
> 		      "openrisc" => "-EB",
34a37
> 		   "openrisc" => "sw-gloss-openrisc/libgloss",
43a47
> 		   "openrisc" => "0x00000000,0x00800000",

> - populating sid/component/cgen-cpu/openrisc, mostly with
> cgen-generated files,
>   plus one or two hand-written ones; the m32r target is amongst
> the simplest to
>   use as a base

This is where I'm getting a little bit unstuck. Looking at the m32r
subdirectory, I can see the m32r-decode.cxx etc. files which all say they
are automatically generated by CGEN. But how did they get here? Are they
created somewhere else by an additional step then copied in? Again, I can
see in CGEN there are the sid-xxx.scm files which I presume are extra to the
normal CGEN release - do these build the 'extra bits' needed for SID? There
doesn't seem to be much about it in the documentation - how do you build
this?

I presume the additional hand-written files are needed to implement the sid
interfaces.

> - testing, perhaps as a dejagnu "baseboard"

Not even close :-)

I would really like to have a go at doing this, but I'm finding it hard
going with lack of documentation at the SID level and a huge directory tree.
Any more help would be really appreciated - even if it's to say 'get fully
acquainted with the GNU way of doing things first'. Then at least I know
what I'm up against.

Robert Cragie, Design Engineer
_______________________________________________________________
Jennic Ltd, Furnival Street, Sheffield, S1 4QT,  UK
http://www.jennic.com  Tel: +44 (0) 114 281 2655
_______________________________________________________________

Re: hw-cpu-openrisc

[Frank Ch. Eigler]

"Robert Cragie" <rcc@jennic.com> writes:

> I'm having a go at piecing the jigsaw together...

Good.


> > The work includes ...
> > - adding sid configury for the openrisc target; see
> > sid/config/sidtargets.m4;
> 
> Will something like this be sufficient?
> 
> Index: sidtargets.m4
> ===================================================================
> [...]

Looks good.

> >   will need autoconf/automake runs throughout
> 
> So how do I do this exactly? I don't know much about these utilities, I'm
> afraid. [...]

You really need to bite the bullet and figure out a bit about how they
work.  The basics can be accomplished by configuring the sid build
tree (only) with --enable-maintainer-mode, putting the
sources.redhat.com binutils "official" version of autoconf etc. into
your $PATH, touching all the configure.in, Makefile.am files, and
running a build.  If you do a grep over configure*/Makefile* files in
the source tree, you'll see the lots of places where these sidtarget*
type configury bits show up.


> > - adding sid configuration file generator pieces to sid/bsp/configrun-sid
> 
> Again, I think I can see what to do here, assuming I don't want any 'boards'
> just yet. Would something like this do?
> [...]

Yup, except that if there exists a typical libgloss/newlib port for
openrisc, you can likely go for the plain generic gloss model instead
of requiring an openrisc-specific one.


> [...]
> > - populating sid/component/cgen-cpu/openrisc [...]
> 
> This is where I'm getting a little bit unstuck. Looking at the m32r
> subdirectory, I can see the m32r-decode.cxx etc. files which all say they
> are automatically generated by CGEN. But how did they get here?  [...]

Each per-cpu Makefile includes commands that run cgen so that the
sid-targeted simulation kernel is emitted in the source directory.


> I presume the additional hand-written files are needed to implement
> the sid interfaces.

Right.  It is important to start small and handle only the basic
cases.


> [...]  I would really like to have a go at doing this, but I'm
> finding it hard going with lack of documentation at the SID level
> and a huge directory tree.  [...]

It's hard to come up with a full recipe.  We've all learned by being
talked through the process or figuring it out alone. :-)  As soon as
something almost builds/works, the missing bits become pretty obvious.


- FChE