-
Notifications
You must be signed in to change notification settings - Fork 1
/
README-OR1K
124 lines (94 loc) · 4.29 KB
/
README-OR1K
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
or1k binutils port README
=========================
After several years of the OpenRISC 1000 (or1k) binutils port being in a state
of semi-completeness the time has come for it to get organised.
What was in the binutils release as of version 2.22 was two targets, openrisc
and or32.
The openrisc target was a CGEN-based version that was, as far as I could tell,
not complete and not used. The or32 target was a strangely-named port for
32-bit or1k implementations.
As neither of these were adequate solutions, this "new" port aims to right the
wrongs and provide a single, coherent OpenRISC 1000 binutils implementation.
For arguments against the previous tool chain triplet naming (or32-*-*) see
this post on OpenCores: http://opencores.org/forum,OpenRISC,0,3478
* Building
==========
Just make a build directory and an install directory and away you go:
$ mkdir ../bld-binutils && cd ../bld-binutils
$ sudo mkdir /opt/or1k-toolchain && sudo chmod a+rwx /opt/or1k-toolchain
$ ../binutils/configure --target=or1k-elf --prefix=/opt/or1k-toolchain
$ make
$ make install
This will just give you the assembler and other basics.
* Regenerating CGEN input
=========================
The files generated by CGEN go in the opcodes/ directory and are all prefixed
with "or1k-".
Regenerating these, if developing the CGEN description files can be done in one
of two ways.
Method 1:
=========
There's a shell script in the binutils/opcodes directory which knows how to run
CGEN and regenerate what it needs. We can call it with "run-cgen-all" if the
cgen path is plumbed into the binutils directory, but I've found that to be
problematic (see method 2). We can, instead, call it directly with what it
needs to regenerate the CGEN-dervied files.
Note: the following approach is best if developing/hacking the .cpu files in
CGEN and wanting to quickly regenerate the opcodes source.
Go into the binutils/opcodes source directory (ie. not where you're running
"make from") and do the following:
1. Make the cgen.sh script executable
$ chmod +x cgen.sh
2. Run it with the appropriate paths. I have my CGEN source under $HOME/git/cgen
so change that as required.
$ ./cgen.sh opcodes `pwd` \
"guile -l $HOME/git/cgen/src/cgen/guile.scm -s" \
$HOME/git/cgen/src/cgen "-v" or1k or1k \
$HOME/git/cgen/src/cgen/cpu/or1k.cpu \
$HOME/git/cgen/src/cgen/cpu/or1k.opc "" opinst
Remember, if using the "make run-cgen-all" method, as below, it uses the .cpu
files in the binutils/cpu source directory, so those will have to be updated
with the modified ones from the cgen directory if switching to that method.
Method 2:
=========
1. Link the cgen directory into the git checkout's directory, so it's along
side binutils/ opcodes/ etc.
$ ln -s ~/path/to/cgen cgen
2. Create a directory to build binutils in, so something like :
$ cd ../
$ mkdir bld-binutils && cd bld-binutils
3. Configure binutils to build for or1k
$ ../binutils-or1k/configure --target=or1k-elf
4. Make the opcodes build directory appear
$ make configure-opcodes
$ cd opcodes
5. Edit "Makefile" so that the CGEN_CPUS variable just has "or1k" in it (or
don't, but this saves time)
6. Kick off the scripts to create the new or1k files.
$ make run-cgen-all
You should see something like:
Canonicalizing instruction semantics ...
Done canonicalization.
Analyzing instruction set ...
Performing sanity checks ...
Done analysis.
Generating or1k-desc.h ...
Generating or1k-desc.c ...
Generating or1k-opc.h ...
Generating or1k-opc.c ...
Generating or1k-ibld.in ...
Generating or1k-asm.in ...
Generating or1k-dis.in ...
Generating or1k-opinst.c ...
touch stamp-or1k
Then you are done.
Annoyingly, if you plan on building everything in binutils, you have to unlink
the cgen directory out of the binutils source directory otherwise it will break
halfway through the compile as it tries to do a configure and make in cgen.
Maybe I'm doing something wrong, though...
It is possible to manually re-generate these or1k-* files, though, using
the script binutils/opcodes/cgen.sh and it's likely this is the easier way to
do it, but this longer way is how I do it for now.
TODO: gas testsuite and confirm the CGEN port is correct
Julius Baxter, January 2012