diff options
| author | Mike Frysinger <vapier@gentoo.org> | 2022-02-14 21:25:49 -0500 |
|---|---|---|
| committer | Corinna Vinschen <vinschen@redhat.com> | 2022-02-17 13:06:50 +0100 |
| commit | 664d7f014a5dedb99cc8679c9557e20fc2015227 (patch) | |
| tree | 97e3ae9d3753f8f678ea52b780e70f0ae42a92e6 /libgloss.html | |
| parent | switch to https:// for many sites (diff) | |
add libgloss manual from current git
Diffstat (limited to 'libgloss.html')
| -rw-r--r-- | libgloss.html | 2352 |
1 files changed, 2352 insertions, 0 deletions
diff --git a/libgloss.html b/libgloss.html new file mode 100644 index 0000000..b8b63df --- /dev/null +++ b/libgloss.html | |||
| @@ -0,0 +1,2352 @@ | |||
| 1 | <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> | ||
| 2 | <html> | ||
| 3 | <!-- Created by GNU Texinfo 6.8, https://www.gnu.org/software/texinfo/ --> | ||
| 4 | <head> | ||
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> | ||
| 6 | <title>Embed with GNU</title> | ||
| 7 | |||
| 8 | <meta name="description" content="Embed with GNU"> | ||
| 9 | <meta name="keywords" content="Embed with GNU"> | ||
| 10 | <meta name="resource-type" content="document"> | ||
| 11 | <meta name="distribution" content="global"> | ||
| 12 | <meta name="Generator" content="makeinfo"> | ||
| 13 | <meta name="viewport" content="width=device-width,initial-scale=1"> | ||
| 14 | |||
| 15 | <link href="#Top" rel="start" title="Top"> | ||
| 16 | <link href="#SEC_Contents" rel="contents" title="Table of Contents"> | ||
| 17 | <link href="#Libgloss" rel="next" title="Libgloss"> | ||
| 18 | <style type="text/css"> | ||
| 19 | <!-- | ||
| 20 | a.copiable-anchor {visibility: hidden; text-decoration: none; line-height: 0em} | ||
| 21 | a.summary-letter {text-decoration: none} | ||
| 22 | blockquote.indentedblock {margin-right: 0em} | ||
| 23 | div.display {margin-left: 3.2em} | ||
| 24 | div.example {margin-left: 3.2em} | ||
| 25 | kbd {font-style: oblique} | ||
| 26 | pre.display {font-family: inherit} | ||
| 27 | pre.format {font-family: inherit} | ||
| 28 | pre.menu-comment {font-family: serif} | ||
| 29 | pre.menu-preformatted {font-family: serif} | ||
| 30 | span.nolinebreak {white-space: nowrap} | ||
| 31 | span.roman {font-family: initial; font-weight: normal} | ||
| 32 | span.sansserif {font-family: sans-serif; font-weight: normal} | ||
| 33 | span:hover a.copiable-anchor {visibility: visible} | ||
| 34 | ul.no-bullet {list-style: none} | ||
| 35 | --> | ||
| 36 | </style> | ||
| 37 | |||
| 38 | |||
| 39 | </head> | ||
| 40 | |||
| 41 | <body lang="en"> | ||
| 42 | <h1 class="settitle" align="center">Embed with GNU</h1> | ||
| 43 | |||
| 44 | |||
| 45 | |||
| 46 | |||
| 47 | <p>Copyright (c) 1993, 1994, 1995 Cygnus Support | ||
| 48 | </p> | ||
| 49 | <p>Permission is granted to make and distribute verbatim copies of | ||
| 50 | this manual provided the copyright notice and this permission notice | ||
| 51 | are preserved on all copies. | ||
| 52 | </p> | ||
| 53 | <p>Permission is granted to copy and distribute modified versions of this | ||
| 54 | manual under the conditions for verbatim copying, provided also that | ||
| 55 | the entire resulting derived work is distributed under the terms of a | ||
| 56 | permission notice identical to this one. | ||
| 57 | </p> | ||
| 58 | <p>Permission is granted to copy and distribute translations of this manual | ||
| 59 | into another language, under the above conditions for modified versions. | ||
| 60 | </p> | ||
| 61 | <div class="top" id="Top"> | ||
| 62 | <div class="header"> | ||
| 63 | <p> | ||
| 64 | Next: <a href="#Libgloss" accesskey="n" rel="next">Libgloss</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 65 | </div> | ||
| 66 | <span id="Embed-with-GNU"></span><h1 class="top">Embed with GNU</h1> | ||
| 67 | |||
| 68 | <p><strong>Rough Draft</strong> | ||
| 69 | </p> | ||
| 70 | <p>The goal of this document is to gather all the information needed to | ||
| 71 | port the GNU tools to a new embedded target in one place. This will | ||
| 72 | duplicate some info found in the other manual for the GNU tools, but | ||
| 73 | this should be all you’ll need. | ||
| 74 | </p> | ||
| 75 | |||
| 76 | <div class="Contents_element" id="SEC_Contents"> | ||
| 77 | <h2 class="contents-heading">Table of Contents</h2> | ||
| 78 | |||
| 79 | <div class="contents"> | ||
| 80 | |||
| 81 | <ul class="no-bullet"> | ||
| 82 | <li><a id="toc-Libgloss-1" href="#Libgloss">1 Libgloss</a> | ||
| 83 | <ul class="no-bullet"> | ||
| 84 | <li><a id="toc-Supported-Targets" href="#Supported-targets">1.1 Supported Targets</a> | ||
| 85 | <ul class="no-bullet"> | ||
| 86 | <li><a id="toc-Sparclite-Targets-Supported" href="#Sparclite">1.1.1 Sparclite Targets Supported</a></li> | ||
| 87 | <li><a id="toc-Motorola-CPU32-Targets-supported" href="#CPU32">1.1.2 Motorola CPU32 Targets supported</a></li> | ||
| 88 | <li><a id="toc-Mips-core-Targets-Supported" href="#Mips">1.1.3 Mips core Targets Supported</a></li> | ||
| 89 | <li><a id="toc-PA_002dRISC-Targets-Supported" href="#PA_002dRISC">1.1.4 PA-RISC Targets Supported</a></li> | ||
| 90 | </ul></li> | ||
| 91 | <li><a id="toc-Configuring-and-building-libgloss_002e" href="#Building-libgloss">1.2 Configuring and building libgloss.</a></li> | ||
| 92 | <li><a id="toc-Adding-Support-for-a-New-Board" href="#Board-support">1.3 Adding Support for a New Board</a></li> | ||
| 93 | </ul></li> | ||
| 94 | <li><a id="toc-Porting-GCC" href="#GCC">2 Porting GCC</a> | ||
| 95 | <ul class="no-bullet"> | ||
| 96 | <li><a id="toc-Compilation-passes" href="#Overview">2.1 Compilation passes</a></li> | ||
| 97 | </ul></li> | ||
| 98 | <li><a id="toc-Porting-newlib" href="#Libraries">3 Porting newlib</a> | ||
| 99 | <ul class="no-bullet"> | ||
| 100 | <li><a id="toc-Crt0_002c-the-main-startup-file" href="#Crt0">3.1 Crt0, the main startup file</a></li> | ||
| 101 | <li><a id="toc-Linker-scripts-for-memory-management" href="#Linker-Scripts">3.2 Linker scripts for memory management</a></li> | ||
| 102 | <li><a id="toc-What-to-do-when-you-have-a-binary-image" href="#What-to-do-now">3.3 What to do when you have a binary image</a></li> | ||
| 103 | <li><a id="toc-Libraries-1" href="#Libc">3.4 Libraries</a> | ||
| 104 | <ul class="no-bullet"> | ||
| 105 | <li><a id="toc-Making-I_002fO-work" href="#I_002fO-Support">3.4.1 Making I/O work</a></li> | ||
| 106 | <li><a id="toc-Routines-for-dynamic-memory-allocation" href="#Memory-Support">3.4.2 Routines for dynamic memory allocation</a></li> | ||
| 107 | <li><a id="toc-Misc-support-routines" href="#Misc-Support">3.4.3 Misc support routines</a></li> | ||
| 108 | <li><a id="toc-Useful-debugging-functions" href="#Debugging">3.4.4 Useful debugging functions</a></li> | ||
| 109 | </ul></li> | ||
| 110 | </ul></li> | ||
| 111 | <li><a id="toc-Writing-a-new-GDB-backend" href="#GDB">4 Writing a new GDB backend</a> | ||
| 112 | <ul class="no-bullet"> | ||
| 113 | <li><a id="toc-The-standard-remote-protocol" href="#GNU-remote-protocol">4.1 The standard remote protocol</a></li> | ||
| 114 | <li><a id="toc-A-linked-in-exception-handler" href="#Exception-handler">4.2 A linked in exception handler</a></li> | ||
| 115 | <li><a id="toc-Using-a-ROM-monitor-as-a-backend" href="#ROM-monitors">4.3 Using a ROM monitor as a backend</a></li> | ||
| 116 | <li><a id="toc-Adding-support-for-new-protocols" href="#Other-remote-protocols">4.4 Adding support for new protocols</a></li> | ||
| 117 | </ul></li> | ||
| 118 | <li><a id="toc-Code-Listings-1" href="#Code-Listings">Appendix A Code Listings</a> | ||
| 119 | <ul class="no-bullet"> | ||
| 120 | <li><a id="toc-Linker-script-for-the-IDP-board" href="#idp_002eld">A.1 Linker script for the IDP board</a></li> | ||
| 121 | <li><a id="toc-crt0_002eS-_002d-The-startup-file" href="#crt0_002eS">A.2 crt0.S - The startup file</a></li> | ||
| 122 | <li><a id="toc-C-based-_0022glue_0022-code_002e" href="#glue_002ec">A.3 C based "glue" code.</a></li> | ||
| 123 | <li><a id="toc-I_002fO-assembler-code-sample" href="#mvme_002eS">A.4 I/O assembler code sample</a></li> | ||
| 124 | <li><a id="toc-I_002fO-code-sample" href="#io_002ec">A.5 I/O code sample</a></li> | ||
| 125 | <li><a id="toc-Led-control-sample" href="#leds_002ec">A.6 Led control sample</a></li> | ||
| 126 | </ul></li> | ||
| 127 | </ul> | ||
| 128 | </div> | ||
| 129 | </div> | ||
| 130 | <hr> | ||
| 131 | <div class="chapter" id="Libgloss"> | ||
| 132 | <div class="header"> | ||
| 133 | <p> | ||
| 134 | Next: <a href="#GCC" accesskey="n" rel="next">Porting GCC</a>, Previous: <a href="#Top" accesskey="p" rel="prev">Embed with GNU</a>, Up: <a href="#Top" accesskey="u" rel="up">Embed with GNU</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 135 | </div> | ||
| 136 | <span id="Libgloss-1"></span><h2 class="chapter">1 Libgloss</h2> | ||
| 137 | <p>Libgloss is a library for all the details that usually get glossed over. | ||
| 138 | This library refers to things like startup code, and usually I/O support | ||
| 139 | for <code>gcc</code> and <code>C library</code>. The C library used through out | ||
| 140 | this manual is <code>newlib</code>. Newlib is a ANSI conforming C library | ||
| 141 | developed by Cygnus Support. Libgloss could easily be made to | ||
| 142 | support other C libraries, and it can be used standalone as well. The | ||
| 143 | standalone configuration is typically used when bringing up new | ||
| 144 | hardware, or on small systems. | ||
| 145 | </p> | ||
| 146 | <p>For a long time, these details were part of newlib. This approach worked | ||
| 147 | well when a complete tool chain only had to support one system. A tool | ||
| 148 | chain refers to the series of compiler passes required to produce a | ||
| 149 | binary file that will run on an embedded system. For C, the passes are | ||
| 150 | cpp, gcc, gas, ld. Cpp is the preprocessor, which process all the header | ||
| 151 | files and macros. Gcc is the compiler, which produces assembler from the | ||
| 152 | processed C files. Gas assembles the code into object files, and then ld | ||
| 153 | combines the object files and binds the code to addresses and produces | ||
| 154 | the final executable image. | ||
| 155 | </p> | ||
| 156 | <p>Most of the time a tool chain does only have to support one target | ||
| 157 | execution environment. An example of this would be a tool chain for the | ||
| 158 | AMD 29k processor family. All of the execution environments for this | ||
| 159 | processor have the same interface, the same memory map, and the same | ||
| 160 | I/O code. In this case all of the support code is under newlib/libc/sys. | ||
| 161 | Libgloss’s creation was forced initially because of the <code>cpu32</code> | ||
| 162 | processor family. There are many different execution environments for | ||
| 163 | this line, and they vary wildly. newlib itself has only a few | ||
| 164 | dependencies that it needs for each target. These are explained later in | ||
| 165 | this doc. The hardware dependent part of newlib was reorganized into a | ||
| 166 | separate directory structure within newlib called the stub dirs. It was | ||
| 167 | initially called this because most of the routines newlib needs for a | ||
| 168 | target were simple stubs that do nothing, but return a value to the | ||
| 169 | application. They only exist so the linker can produce a final | ||
| 170 | executable image. This work was done during the early part of 1993. | ||
| 171 | </p> | ||
| 172 | <p>After a while it became apparent that this approach of isolating the | ||
| 173 | hardware and systems files together made sense. Around this same time | ||
| 174 | the stub dirs were made to run standalone, mostly so it could also be | ||
| 175 | used to support GDB’s remote debugging needs. At this time it was | ||
| 176 | decided to move the stub dirs out of newlib and into it’s own separate | ||
| 177 | library so it could be used standalone, and be included in various other | ||
| 178 | GNU tools without having to bring in all of newlib, which is large. The | ||
| 179 | new library is called Libgloss, for Gnu Low-level OS support. | ||
| 180 | </p> | ||
| 181 | |||
| 182 | <ul class="section-toc"> | ||
| 183 | <li><a href="#Supported-targets" accesskey="1">Supported Targets</a></li> | ||
| 184 | <li><a href="#Building-libgloss" accesskey="2">Configuring and building libgloss.</a></li> | ||
| 185 | <li><a href="#Board-support" accesskey="3">Adding Support for a New Board</a></li> | ||
| 186 | </ul> | ||
| 187 | <hr> | ||
| 188 | <div class="section" id="Supported-targets"> | ||
| 189 | <div class="header"> | ||
| 190 | <p> | ||
| 191 | Next: <a href="#Building-libgloss" accesskey="n" rel="next">Configuring and building libgloss.</a>, Previous: <a href="#Libgloss" accesskey="p" rel="prev">Libgloss</a>, Up: <a href="#Libgloss" accesskey="u" rel="up">Libgloss</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 192 | </div> | ||
| 193 | <span id="Supported-Targets"></span><h3 class="section">1.1 Supported Targets</h3> | ||
| 194 | <p>Currently libgloss is being used for the following targets: | ||
| 195 | </p> | ||
| 196 | |||
| 197 | <ul class="section-toc"> | ||
| 198 | <li><a href="#Sparclite" accesskey="1">Sparclite Targets Supported</a></li> | ||
| 199 | <li><a href="#CPU32" accesskey="2">Motorola CPU32 Targets supported</a></li> | ||
| 200 | <li><a href="#Mips" accesskey="3">Mips core Targets Supported</a></li> | ||
| 201 | <li><a href="#PA_002dRISC" accesskey="4">PA-RISC Targets Supported</a></li> | ||
| 202 | </ul> | ||
| 203 | <hr> | ||
| 204 | <div class="subsection" id="Sparclite"> | ||
| 205 | <div class="header"> | ||
| 206 | <p> | ||
| 207 | Next: <a href="#CPU32" accesskey="n" rel="next">Motorola CPU32 Targets supported</a>, Up: <a href="#Supported-targets" accesskey="u" rel="up">Supported Targets</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 208 | </div> | ||
| 209 | <span id="Sparclite-Targets-Supported"></span><h4 class="subsection">1.1.1 Sparclite Targets Supported</h4> | ||
| 210 | <p>This is for the Fujitsu Sparclite family of processors. Currently this | ||
| 211 | covers the ex930, ex931, ex932, ex933, and the ex934. In addition to the | ||
| 212 | I/O code a startup file, this has a GDB debug-stub that gets linked into | ||
| 213 | your application. This is an exception handler style debug stub. For | ||
| 214 | more info, see the section on Porting GDB. <a href="#GDB">Porting GDB</a>. | ||
| 215 | </p> | ||
| 216 | <p>The Fujitsu eval boards use a host based terminal program to load and | ||
| 217 | execute programs on the target. This program, <code>pciuh</code> is relatively | ||
| 218 | new (in 1994) and it replaced the previous ROM monitor which had the | ||
| 219 | shell in the ROM. GDB uses the the GDB remote protocol, the relevant | ||
| 220 | source files from the gdb sources are remote-sparcl.c. The debug stub is | ||
| 221 | part of libgloss and is called sparcl-stub.c. | ||
| 222 | </p> | ||
| 223 | <hr> | ||
| 224 | </div> | ||
| 225 | <div class="subsection" id="CPU32"> | ||
| 226 | <div class="header"> | ||
| 227 | <p> | ||
| 228 | Next: <a href="#Mips" accesskey="n" rel="next">Mips core Targets Supported</a>, Previous: <a href="#Sparclite" accesskey="p" rel="prev">Sparclite Targets Supported</a>, Up: <a href="#Supported-targets" accesskey="u" rel="up">Supported Targets</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 229 | </div> | ||
| 230 | <span id="Motorola-CPU32-Targets-supported"></span><h4 class="subsection">1.1.2 Motorola CPU32 Targets supported</h4> | ||
| 231 | <p>This refers to Motorola’s m68k based CPU32 processor family. The crt0.S | ||
| 232 | startup file should be usable with any target environment, and it’s | ||
| 233 | mostly just the I/O code and linker scripts that vary. Currently there | ||
| 234 | is support for the Motorola MVME line of 6U VME boards and IDP | ||
| 235 | line of eval boards. All of the | ||
| 236 | Motorola VME boards run <code>Bug</code>, a ROM based debug monitor. | ||
| 237 | This monitor has the feature of using user level traps to do I/O, so | ||
| 238 | this code should be portable to other MVME boards with little if any | ||
| 239 | change. The startup file also can remain unchanged. About the only thing | ||
| 240 | that varies is the address for where the text section begins. This can | ||
| 241 | be accomplished either in the linker script, or on the command line | ||
| 242 | using the ‘<samp>-Ttext [address]</samp>’. | ||
| 243 | </p> | ||
| 244 | <p>There is also support for the <code>rom68k</code> monitor as shipped on | ||
| 245 | Motorola’s IDP eval board line. This code should be portable across the | ||
| 246 | range of CPU’s the board supports. There is also GDB support for this | ||
| 247 | target environment in the GDB source tree. The relevant files are | ||
| 248 | gdb/monitor.c, monitor.h, and rom58k-rom.c. The usage of these files is | ||
| 249 | discussed in the GDB section. | ||
| 250 | </p> | ||
| 251 | <hr> | ||
| 252 | </div> | ||
| 253 | <div class="subsection" id="Mips"> | ||
| 254 | <div class="header"> | ||
| 255 | <p> | ||
| 256 | Next: <a href="#PA_002dRISC" accesskey="n" rel="next">PA-RISC Targets Supported</a>, Previous: <a href="#CPU32" accesskey="p" rel="prev">Motorola CPU32 Targets supported</a>, Up: <a href="#Supported-targets" accesskey="u" rel="up">Supported Targets</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 257 | </div> | ||
| 258 | <span id="Mips-core-Targets-Supported"></span><h4 class="subsection">1.1.3 Mips core Targets Supported</h4> | ||
| 259 | <p>The Crt0 startup file should run on any mips target that doesn’t require | ||
| 260 | additional hardware initialization. The I/O code so far only supports a | ||
| 261 | custom LSI33k based RAID disk controller board. It should easy to | ||
| 262 | change to support the IDT line of eval boards. Currently the two | ||
| 263 | debugging protocols supported by GDB for mips targets is IDT’s mips | ||
| 264 | debug protocol, and a customized hybrid of the standard GDB remote | ||
| 265 | protocol and GDB’s standard ROM monitor support. Included here is the | ||
| 266 | debug stub for the hybrid monitor. This supports the LSI33k processor, | ||
| 267 | and only has support for the GDB protocol commands <code>g</code>, <code>G</code>, | ||
| 268 | <code>m</code>, <code>M</code>, which basically only supports the register and | ||
| 269 | memory reading and writing commands. This is part of libgloss and is | ||
| 270 | called lsi33k-stub.c. | ||
| 271 | </p> | ||
| 272 | <p>The crt0.S should also work on the IDT line of eval boards, but has only | ||
| 273 | been run on the LSI33k for now. There is no I/O support for the IDT eval | ||
| 274 | board at this time. The current I/O code is for a customized version of | ||
| 275 | LSI’s <code>pmon</code> ROM monitor. This uses entry points into the monitor, | ||
| 276 | and should easily port to other versions of the pmon monitor. Pmon is | ||
| 277 | distributed in source by LSI. | ||
| 278 | </p> | ||
| 279 | <hr> | ||
| 280 | </div> | ||
| 281 | <div class="subsection" id="PA_002dRISC"> | ||
| 282 | <div class="header"> | ||
| 283 | <p> | ||
| 284 | Previous: <a href="#Mips" accesskey="p" rel="prev">Mips core Targets Supported</a>, Up: <a href="#Supported-targets" accesskey="u" rel="up">Supported Targets</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 285 | </div> | ||
| 286 | <span id="PA_002dRISC-Targets-Supported"></span><h4 class="subsection">1.1.4 PA-RISC Targets Supported</h4> | ||
| 287 | <p>This supports the various boards manufactured by the HP-PRO consortium. | ||
| 288 | This is a group of companies all making variations on the PA-RISC | ||
| 289 | processor. Currently supported are ports to the WinBond ‘<samp>Cougar</samp>’ | ||
| 290 | board based around their w89k version of the PA. Also supported is the | ||
| 291 | Oki op50n processor. | ||
| 292 | </p> | ||
| 293 | <p>There is also included, but never built an unfinished port to the HP 743 | ||
| 294 | board. This board is the main CPU board for the HP700 line of industrial | ||
| 295 | computers. This target isn’t exactly an embedded system, in fact it’s | ||
| 296 | really only designed to load and run HP-UX. Still, the crt0.S and I/O | ||
| 297 | code are fully working. It is included mostly because their is a barely | ||
| 298 | functioning exception handler GDB debug stub, and I hope somebody could | ||
| 299 | use it. The other PRO targets all use GDB’s ability to talk to ROM | ||
| 300 | monitors directly, so it doesn’t need a debug stub. There is also a | ||
| 301 | utility that will produce a bootable file by HP’s ROM monitor. This is | ||
| 302 | all included in the hopes somebody else will finish it. :-) | ||
| 303 | </p> | ||
| 304 | <p>Both the WinBond board and the Oki board download srecords. The WinBond | ||
| 305 | board also has support for loading the SOM files as produced by the | ||
| 306 | native compiler on HP-UX. WinBond supplies a set of DOS programs that | ||
| 307 | will allow the loading of files via a bidirectional parallel port. This | ||
| 308 | has never been tested with the output of GNU SOM, as this manual is | ||
| 309 | mostly for Unix based systems. | ||
| 310 | </p> | ||
| 311 | <hr> | ||
| 312 | </div> | ||
| 313 | </div> | ||
| 314 | <div class="section" id="Building-libgloss"> | ||
| 315 | <div class="header"> | ||
| 316 | <p> | ||
| 317 | Next: <a href="#Board-support" accesskey="n" rel="next">Adding Support for a New Board</a>, Previous: <a href="#Supported-targets" accesskey="p" rel="prev">Supported Targets</a>, Up: <a href="#Libgloss" accesskey="u" rel="up">Libgloss</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 318 | </div> | ||
| 319 | <span id="Configuring-and-building-libgloss_002e"></span><h3 class="section">1.2 Configuring and building libgloss.</h3> | ||
| 320 | |||
| 321 | <p>Libgloss uses an autoconf based script to configure. Autoconf scripts | ||
| 322 | are portable shell scripts that are generated from a configure.in file. | ||
| 323 | Configure input scripts are based themselves on m4. Most configure | ||
| 324 | scripts run a series of tests to determine features the various | ||
| 325 | supported features of the target. For features that can’t be determined | ||
| 326 | by a feature test, a makefile fragment is merged in. The configure | ||
| 327 | process leaves creates a Makefile in the build directory. For libgloss, | ||
| 328 | there are only a few configure options of importance. These are –target | ||
| 329 | and –srcdir. | ||
| 330 | </p> | ||
| 331 | <p>Typically libgloss is built in a separate tree just for objects. In this | ||
| 332 | manner, it’s possible to have a single source tree, and multiple object | ||
| 333 | trees. If you only need to configure for a single target environment, | ||
| 334 | then you can configure in the source tree. The argument for –target is | ||
| 335 | a config string. It’s usually safest to use the full canonical opposed | ||
| 336 | to the target alias. So, to configure for a CPU32 (m68k) with a separate | ||
| 337 | source tree, use: | ||
| 338 | </p> | ||
| 339 | <div class="example"> | ||
| 340 | <pre class="example">../src/libgloss/configure --verbose --target m68k-coff | ||
| 341 | </pre></div> | ||
| 342 | |||
| 343 | <p>The configure script is in the source tree. When configure is invoked | ||
| 344 | it will determine it’s own source tree, so the –srcdir is would be | ||
| 345 | redundant here. | ||
| 346 | </p> | ||
| 347 | <p>Once libgloss is configured, <code>make</code> is sufficient to build it. The | ||
| 348 | default values for <code>Makefiles</code> are typically correct for all | ||
| 349 | supported systems. The test cases in the testsuite will also built | ||
| 350 | automatically as opposed to a <code>make check</code>, where test binaries | ||
| 351 | aren’t built till test time. This is mostly cause the libgloss | ||
| 352 | testsuites are the last thing built when building the entire GNU source | ||
| 353 | tree, so it’s a good test of all the other compilation passes. | ||
| 354 | </p> | ||
| 355 | <p>The default values for the Makefiles are set in the Makefile fragment | ||
| 356 | merged in during configuration. This fragment typically has rules like | ||
| 357 | </p> | ||
| 358 | <div class="example"> | ||
| 359 | <pre class="example">CC_FOR_TARGET = `if [ -f $${OBJROOT}/gcc/xgcc ] ; \ | ||
| 360 | then echo ${OBJROOT}/gcc/xgcc -B${OBJROOT}/gcc/ ; \ | ||
| 361 | else t='${program_transform_name}'; echo gcc | sed -e '' $$t ; fi` | ||
| 362 | </pre></div> | ||
| 363 | |||
| 364 | <p>Basically this is a runtime test to determine whether there are freshly | ||
| 365 | built executables for the other main passes of the GNU tools. If there | ||
| 366 | isn’t an executable built in the same object tree, then | ||
| 367 | <em>transformed</em>the generic tool name (like gcc) is transformed to the | ||
| 368 | name typically used in GNU cross compilers. The names are | ||
| 369 | typically based on the target’s canonical name, so if you’ve configured | ||
| 370 | for <code>m68k-coff</code> the transformed name is <code>m68k-coff-gcc</code> in | ||
| 371 | this case. If you install with aliases or rename the tools, this won’t | ||
| 372 | work, and it will always look for tools in the path. You can force the a | ||
| 373 | different name to work by reconfiguring with the | ||
| 374 | <code>--program-transform-name</code> option to configure. This option takes a | ||
| 375 | sed script like this <code>-e s,^,m68k-coff-,</code> which produces tools | ||
| 376 | using the standard names (at least here at Cygnus). | ||
| 377 | </p> | ||
| 378 | <p>The search for the other GNU development tools is exactly the same idea. | ||
| 379 | This technique gets messier when build options like <code>-msoft-float</code> | ||
| 380 | support are used. The Makefile fragments set the <code>MUTILIB</code> | ||
| 381 | variable, and if it is set, the search path is modified. If the linking | ||
| 382 | is done with an installed cross compiler, then none of this needs to be | ||
| 383 | used. This is done so libgloss will build automatically with a fresh, | ||
| 384 | and uninstalled object tree. It also makes it easier to debug the other | ||
| 385 | tools using libgloss’s test suites. | ||
| 386 | </p> | ||
| 387 | <hr> | ||
| 388 | </div> | ||
| 389 | <div class="section" id="Board-support"> | ||
| 390 | <div class="header"> | ||
| 391 | <p> | ||
| 392 | Previous: <a href="#Building-libgloss" accesskey="p" rel="prev">Configuring and building libgloss.</a>, Up: <a href="#Libgloss" accesskey="u" rel="up">Libgloss</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 393 | </div> | ||
| 394 | <span id="Adding-Support-for-a-New-Board"></span><h3 class="section">1.3 Adding Support for a New Board</h3> | ||
| 395 | |||
| 396 | <p>This section explains how to add support for a new board to libgloss. | ||
| 397 | In order to add support for a board, you must already have developed a | ||
| 398 | toolchain for the target architecture. | ||
| 399 | </p> | ||
| 400 | <p>All of the changes you will make will be in the subdirectory named | ||
| 401 | after the architecture used by your board. For example, if you are | ||
| 402 | developing support for a new ColdFire board, you will modify files in | ||
| 403 | the <samp>m68k</samp> subdirectory, as that subdirectory contains support | ||
| 404 | for all 68K devices, including architecture variants like ColdFire. | ||
| 405 | </p> | ||
| 406 | <p>In general, you will be adding three components: a <samp>crt0.S</samp> file | ||
| 407 | (see <a href="#Crt0">Crt0, the main startup file</a>), a linker script (see <a href="#Linker-Scripts">Linker scripts for memory management</a>), and a | ||
| 408 | hardware support library. Each should be prefixed with the name of | ||
| 409 | your board. For example, if you ard adding support for a new Surf | ||
| 410 | board, then you will be adding the assembly <samp>surf-crt0.S</samp> (which | ||
| 411 | will be assembled into <samp>surf-crt0.o</samp>), the linker script | ||
| 412 | <samp>surf.ld</samp>, and other C and assembly files which will be combined | ||
| 413 | into the hardware support library <samp>libsurf.a</samp>. | ||
| 414 | </p> | ||
| 415 | <p>You should modify <samp>Makefile.in</samp> to define new variables | ||
| 416 | corresponding to your board. Although there is some variation between | ||
| 417 | architectures, the general convention is to use the following format: | ||
| 418 | </p> | ||
| 419 | <div class="example"> | ||
| 420 | <pre class="example"># The name of the crt0.o file. | ||
| 421 | SURF_CRT0 = surf-crt0.o | ||
| 422 | # The name of the linker script. | ||
| 423 | SURF_SCRIPTS = surf.ld | ||
| 424 | # The name of the hardware support library. | ||
| 425 | SURF_BSP = libsurf.a | ||
| 426 | # The object files that make up the hardware support library. | ||
| 427 | SURF_OBJS = surf-file1.o surf-file2.o | ||
| 428 | # The name of the Makefile target to use for installation. | ||
| 429 | SURF_INSTALL = install-surf | ||
| 430 | </pre></div> | ||
| 431 | |||
| 432 | <p>Then, you should create the <code>${SURF_BSP}</code> and | ||
| 433 | <code>${SURF_INSTALL}</code> make targets. Add <code>${SURF_CRT0}</code> to | ||
| 434 | the dependencies for the <code>all</code> target and add | ||
| 435 | <code>${SURF_INSTALL}</code> to the dependencies for the <code>install</code> | ||
| 436 | target. Now, when libgloss is built and installed, support for your | ||
| 437 | BSP will be installed as well. | ||
| 438 | </p> | ||
| 439 | <hr> | ||
| 440 | </div> | ||
| 441 | </div> | ||
| 442 | <div class="chapter" id="GCC"> | ||
| 443 | <div class="header"> | ||
| 444 | <p> | ||
| 445 | Next: <a href="#Libraries" accesskey="n" rel="next">Porting newlib</a>, Previous: <a href="#Libgloss" accesskey="p" rel="prev">Libgloss</a>, Up: <a href="#Top" accesskey="u" rel="up">Embed with GNU</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 446 | </div> | ||
| 447 | <span id="Porting-GCC"></span><h2 class="chapter">2 Porting GCC</h2> | ||
| 448 | |||
| 449 | <p>Porting GCC requires two things, neither of which has anything to do | ||
| 450 | with GCC. If GCC already supports a processor type, then all the work in | ||
| 451 | porting GCC is really a linker issue. All GCC has to do is produce | ||
| 452 | assembler output in the proper syntax. Most of the work is done by the | ||
| 453 | linker, which is described elsewhere. | ||
| 454 | </p> | ||
| 455 | <p>Mostly all GCC does is format the command line for the linker pass. The | ||
| 456 | command line for GCC is set in the various config subdirectories of gcc. | ||
| 457 | The options of interest to us are <code>CPP_SPEC</code> and | ||
| 458 | <code>STARTFILE_SPEC</code>. CPP_SPEC sets the builtin defines for your | ||
| 459 | environment. If you support multiple environments with the same | ||
| 460 | processor, then OS specific defines will need to be elsewhere. | ||
| 461 | </p> | ||
| 462 | <p><code>STARTFILE_SPEC</code> | ||
| 463 | </p> | ||
| 464 | <p>Once you have linker support, GCC will be able to produce a fully linked | ||
| 465 | executable image. The only <em>part</em> of GCC that the linker wants is a | ||
| 466 | crt0.o, and a memory map. If you plan on running any programs that do | ||
| 467 | I/O of any kind, you’ll need to write support for the C library, which | ||
| 468 | is described elsewhere. | ||
| 469 | </p> | ||
| 470 | |||
| 471 | <ul class="section-toc"> | ||
| 472 | <li><a href="#Overview" accesskey="1">Compilation passes</a></li> | ||
| 473 | </ul> | ||
| 474 | <hr> | ||
| 475 | <div class="section" id="Overview"> | ||
| 476 | <div class="header"> | ||
| 477 | <p> | ||
| 478 | Next: <a href="#Options" accesskey="n" rel="next">Options</a>, Up: <a href="#GCC" accesskey="u" rel="up">Porting GCC</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 479 | </div> | ||
| 480 | <span id="Compilation-passes"></span><h3 class="section">2.1 Compilation passes</h3> | ||
| 481 | |||
| 482 | <p>GCC by itself only compiles the C or C++ code into assembler. Typically | ||
| 483 | GCC invokes all the passes required for you. These passes are cpp, cc1, | ||
| 484 | gas, ld. <code>cpp</code> is the C preprocessor. This will merge in the | ||
| 485 | include files, expand all macros definitions, and process all the | ||
| 486 | <code>#ifdef</code> sections. To see the output of ccp, invoke gcc with the | ||
| 487 | <code>-E</code> option, and the preprocessed file will be printed on the | ||
| 488 | stdout. cc1 is the actual compiler pass that produces the assembler for | ||
| 489 | the processed file. GCC is actually only a driver program for all the | ||
| 490 | compiler passes. It will format command line options for the other passes. | ||
| 491 | The usual command line GCC uses for the final link phase will have LD | ||
| 492 | link in the startup code and additional libraries by default. | ||
| 493 | </p> | ||
| 494 | <p>GNU AS started it’s life to only function as a compiler pass, but | ||
| 495 | these days it can also be used as a source level assembler. When used as | ||
| 496 | a source level assembler, it has a companion assembler preprocessor | ||
| 497 | called <code>gasp</code>. This has a syntax similar to most other assembler | ||
| 498 | macros packages. GAS emits a relocatable object file from the assembler | ||
| 499 | source. The object file contains the executable part of the application, | ||
| 500 | and debug symbols. | ||
| 501 | </p> | ||
| 502 | <p>LD is responsible for resolving the addresses and symbols to something | ||
| 503 | that will be fully self-contained. Some RTOS’s use relocatable object | ||
| 504 | file formats like <code>a.out</code>, but more commonly the final image will | ||
| 505 | only use absolute addresses for symbols. This enables code to be burned | ||
| 506 | into PROMS as well. Although LD can produce an executable image, there | ||
| 507 | is usually a hidden object file called <code>crt0.o</code> that is required as | ||
| 508 | startup code. With this startup code and a memory map, the executable | ||
| 509 | image will actually run on the target environment. <a href="#Crt0">Startup | ||
| 510 | Files</a>. | ||
| 511 | </p> | ||
| 512 | <p>The startup code usually defines a special symbol like <code>_start</code> | ||
| 513 | that is the default base address for the application, and the first | ||
| 514 | symbol in the executable image. If you plan to use any routines from the | ||
| 515 | standard C library, you’ll also need to implement the functions that | ||
| 516 | this library is dependent on. <a href="#Libraries">Porting Newlib</a>. | ||
| 517 | </p> | ||
| 518 | <hr> | ||
| 519 | <span id="Options"></span><div class="header"> | ||
| 520 | <p> | ||
| 521 | Previous: <a href="#Overview" accesskey="p" rel="prev">Compilation passes</a>, Up: <a href="#GCC" accesskey="u" rel="up">Porting GCC</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 522 | </div> | ||
| 523 | <h4 class="node-heading">Options</h4> | ||
| 524 | |||
| 525 | <p>Options for the various development tools are covered in more detail | ||
| 526 | elsewhere. Still, the amount of options can be an overwhelming amount of | ||
| 527 | stuff, so the options most suited to embedded systems are summarized | ||
| 528 | here. If you use GCC as the main driver for all the passes, most of the | ||
| 529 | linker options can be passed directly to the compiler. There are also | ||
| 530 | GCC options that control how the GCC driver formats the command line | ||
| 531 | arguments for the linker. | ||
| 532 | </p> | ||
| 533 | |||
| 534 | <hr> | ||
| 535 | <span id="GCC-Options"></span><div class="header"> | ||
| 536 | <p> | ||
| 537 | Next: <a href="#GAS-Options" accesskey="n" rel="next">GAS Options</a>, Up: <a href="#Options" accesskey="u" rel="up">Options</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 538 | </div> | ||
| 539 | <h4 class="node-heading">GCC Options</h4> | ||
| 540 | <p>Most of the GCC options that we’re interested control how the GCC driver | ||
| 541 | formats the options for the linker pass. | ||
| 542 | </p> | ||
| 543 | <dl compact="compact"> | ||
| 544 | <dt><span><code>-nostartfiles</code></span></dt> | ||
| 545 | <dt><span><code>-nostdlib</code></span></dt> | ||
| 546 | <dt><span><code>-Xlinker</code></span></dt> | ||
| 547 | <dd><p>Pass the next option directly to the linker. | ||
| 548 | </p> | ||
| 549 | </dd> | ||
| 550 | <dt><span><code>-v</code></span></dt> | ||
| 551 | <dt><span><code>-fpic</code></span></dt> | ||
| 552 | </dl> | ||
| 553 | |||
| 554 | <hr> | ||
| 555 | <span id="GAS-Options"></span><div class="header"> | ||
| 556 | <p> | ||
| 557 | Next: <a href="#LD-Options" accesskey="n" rel="next">LD Options</a>, Previous: <a href="#GCC-Options" accesskey="p" rel="prev">GCC Options</a>, Up: <a href="#Options" accesskey="u" rel="up">Options</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 558 | </div> | ||
| 559 | <h4 class="node-heading">GAS Options</h4> | ||
| 560 | |||
| 561 | <hr> | ||
| 562 | <span id="LD-Options"></span><div class="header"> | ||
| 563 | <p> | ||
| 564 | Previous: <a href="#GAS-Options" accesskey="p" rel="prev">GAS Options</a>, Up: <a href="#Options" accesskey="u" rel="up">Options</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 565 | </div> | ||
| 566 | <h4 class="node-heading">LD Options</h4> | ||
| 567 | |||
| 568 | |||
| 569 | <hr> | ||
| 570 | </div> | ||
| 571 | </div> | ||
| 572 | <div class="chapter" id="Libraries"> | ||
| 573 | <div class="header"> | ||
| 574 | <p> | ||
| 575 | Next: <a href="#GDB" accesskey="n" rel="next">Writing a new GDB backend</a>, Previous: <a href="#GCC" accesskey="p" rel="prev">Porting GCC</a>, Up: <a href="#Top" accesskey="u" rel="up">Embed with GNU</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 576 | </div> | ||
| 577 | <span id="Porting-newlib"></span><h2 class="chapter">3 Porting newlib</h2> | ||
| 578 | |||
| 579 | |||
| 580 | <ul class="section-toc"> | ||
| 581 | <li><a href="#Crt0" accesskey="1">Crt0, the main startup file</a></li> | ||
| 582 | <li><a href="#Linker-Scripts" accesskey="2">Linker scripts for memory management</a></li> | ||
| 583 | <li><a href="#What-to-do-now" accesskey="3">What to do when you have a binary image</a></li> | ||
| 584 | <li><a href="#Libc" accesskey="4">Libraries</a></li> | ||
| 585 | </ul> | ||
| 586 | <hr> | ||
| 587 | <div class="section" id="Crt0"> | ||
| 588 | <div class="header"> | ||
| 589 | <p> | ||
| 590 | Next: <a href="#Linker-Scripts" accesskey="n" rel="next">Linker scripts for memory management</a>, Up: <a href="#Libraries" accesskey="u" rel="up">Porting newlib</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 591 | </div> | ||
| 592 | <span id="Crt0_002c-the-main-startup-file"></span><h3 class="section">3.1 Crt0, the main startup file</h3> | ||
| 593 | |||
| 594 | <p>To make a program that has been compiled with GCC to run, you | ||
| 595 | need to write some startup code. The initial piece of startup code is | ||
| 596 | called a crt0. (C RunTime 0) This is usually written in assembler, and | ||
| 597 | it’s object gets linked in first, and bootstraps the rest of the | ||
| 598 | application when executed. This file needs to do the following things. | ||
| 599 | </p> | ||
| 600 | <ol> | ||
| 601 | <li> Initialize anything that needs it. This init section varies. If you are | ||
| 602 | developing an application that gets download to a ROM monitor, then | ||
| 603 | there is usually no need for any special initialization. The ROM monitor | ||
| 604 | handles it for you. | ||
| 605 | |||
| 606 | <p>If you plan to burn your code in a ROM, then the crt0 typically has to | ||
| 607 | do all the hardware initialization that is required to run an | ||
| 608 | application. This can include things like initializing serial ports or | ||
| 609 | run a memory check. It all depends on the hardware. | ||
| 610 | </p> | ||
| 611 | </li><li> Zero the BSS section. This is for uninitialized data. All the addresses in | ||
| 612 | this section need to be initialized to zero so that programs that forget | ||
| 613 | to check new variables default value will get unpredictable results. | ||
| 614 | |||
| 615 | </li><li> Call main() | ||
| 616 | This is what basically starts things running. If your ROM monitor | ||
| 617 | supports it, then first setup argc and argv for command line arguments | ||
| 618 | and an environment pointer. Then branch to main(). For G++ the the main | ||
| 619 | routine gets a branch to __main inserted by the code generator at the | ||
| 620 | very top. __main() is used by G++ to initialize it’s internal tables. | ||
| 621 | __main() then returns back to your original main() and your code gets | ||
| 622 | executed. | ||
| 623 | |||
| 624 | </li><li> Call exit() | ||
| 625 | After main() has returned, you need to cleanup things and return control | ||
| 626 | of the hardware from the application. On some hardware, there is nothing | ||
| 627 | to return to, especially if your program is in ROM. Sometimes the best | ||
| 628 | thing to do in this case is do a hardware reset, or branch back to the | ||
| 629 | start address all over again. | ||
| 630 | |||
| 631 | <p>When there is a ROM monitor present, usually a user trap can be called | ||
| 632 | and then the ROM takes over. Pick a safe vector with no side | ||
| 633 | effects. Some ROMs have a builtin trap handler just for this case. | ||
| 634 | </p></li></ol> | ||
| 635 | <p>portable between all the m68k based boards we have here. | ||
| 636 | <a href="#crt0_002eS">Example Crt0.S</a>. | ||
| 637 | </p> | ||
| 638 | |||
| 639 | <div class="example"> | ||
| 640 | <pre class="example">/* ANSI concatenation macros. */ | ||
| 641 | |||
| 642 | #define CONCAT1(a, b) CONCAT2(a, b) | ||
| 643 | #define CONCAT2(a, b) a ## b | ||
| 644 | </pre></div> | ||
| 645 | <p>These we’ll use later. | ||
| 646 | </p> | ||
| 647 | <div class="example"> | ||
| 648 | <pre class="example">/* These are predefined by new versions of GNU cpp. */ | ||
| 649 | |||
| 650 | #ifndef __USER_LABEL_PREFIX__ | ||
| 651 | #define __USER_LABEL_PREFIX__ _ | ||
| 652 | #endif | ||
| 653 | |||
| 654 | /* Use the right prefix for global labels. */ | ||
| 655 | #define SYM(x) CONCAT1 (__USER_LABEL_PREFIX__, x) | ||
| 656 | |||
| 657 | </pre></div> | ||
| 658 | |||
| 659 | <p>These macros are to make this code portable between both <em>COFF</em> and | ||
| 660 | <em>a.out</em>. <em>COFF</em> always has an <var>_ (underline)</var> prepended on | ||
| 661 | the front of all global symbol names. <em>a.out</em> has none. | ||
| 662 | </p> | ||
| 663 | <div class="example"> | ||
| 664 | <pre class="example">#ifndef __REGISTER_PREFIX__ | ||
| 665 | #define __REGISTER_PREFIX__ | ||
| 666 | #endif | ||
| 667 | |||
| 668 | /* Use the right prefix for registers. */ | ||
| 669 | #define REG(x) CONCAT1 (__REGISTER_PREFIX__, x) | ||
| 670 | |||
| 671 | #define d0 REG (d0) | ||
| 672 | #define d1 REG (d1) | ||
| 673 | #define d2 REG (d2) | ||
| 674 | #define d3 REG (d3) | ||
| 675 | #define d4 REG (d4) | ||
| 676 | #define d5 REG (d5) | ||
| 677 | #define d6 REG (d6) | ||
| 678 | #define d7 REG (d7) | ||
| 679 | #define a0 REG (a0) | ||
| 680 | #define a1 REG (a1) | ||
| 681 | #define a2 REG (a2) | ||
| 682 | #define a3 REG (a3) | ||
| 683 | #define a4 REG (a4) | ||
| 684 | #define a5 REG (a5) | ||
| 685 | #define a6 REG (a6) | ||
| 686 | #define fp REG (fp) | ||
| 687 | #define sp REG (sp) | ||
| 688 | </pre></div> | ||
| 689 | |||
| 690 | <p>This is for portability between assemblers. Some register names have a | ||
| 691 | <var>%</var> or <var>$</var> prepended to the register name. | ||
| 692 | </p> | ||
| 693 | <div class="example"> | ||
| 694 | <pre class="example">/* | ||
| 695 | * Set up some room for a stack. We just grab a chunk of memory. | ||
| 696 | */ | ||
| 697 | .set stack_size, 0x2000 | ||
| 698 | .comm SYM (stack), stack_size | ||
| 699 | </pre></div> | ||
| 700 | |||
| 701 | <p>Set up space for the stack. This can also be done in the linker script, | ||
| 702 | but it typically gets done here. | ||
| 703 | </p> | ||
| 704 | <div class="example"> | ||
| 705 | <pre class="example">/* | ||
| 706 | * Define an empty environment. | ||
| 707 | */ | ||
| 708 | .data | ||
| 709 | .align 2 | ||
| 710 | SYM (environ): | ||
| 711 | .long 0 | ||
| 712 | </pre></div> | ||
| 713 | |||
| 714 | <p>Set up an empty space for the environment. This is bogus on any most ROM | ||
| 715 | monitor, but we setup a valid address for it, and pass it to main. At | ||
| 716 | least that way if an application checks for it, it won’t crash. | ||
| 717 | </p> | ||
| 718 | <div class="example"> | ||
| 719 | <pre class="example"> .align 2 | ||
| 720 | .text | ||
| 721 | .global SYM (stack) | ||
| 722 | |||
| 723 | .global SYM (main) | ||
| 724 | .global SYM (exit) | ||
| 725 | /* | ||
| 726 | * This really should be __bss_start, not SYM (__bss_start). | ||
| 727 | */ | ||
| 728 | .global __bss_start | ||
| 729 | </pre></div> | ||
| 730 | |||
| 731 | <p>Setup a few global symbols that get used elsewhere. <var>__bss_start</var> | ||
| 732 | needs to be unchanged, as it’s setup by the linker script. | ||
| 733 | </p> | ||
| 734 | <div class="example"> | ||
| 735 | <pre class="example">/* | ||
| 736 | * start -- set things up so the application will run. | ||
| 737 | */ | ||
| 738 | SYM (start): | ||
| 739 | link a6, #-8 | ||
| 740 | moveal #SYM (stack) + stack_size, sp | ||
| 741 | |||
| 742 | /* | ||
| 743 | * zerobss -- zero out the bss section | ||
| 744 | */ | ||
| 745 | moveal #__bss_start, a0 | ||
| 746 | moveal #SYM (end), a1 | ||
| 747 | 1: | ||
| 748 | movel #0, (a0) | ||
| 749 | leal 4(a0), a0 | ||
| 750 | cmpal a0, a1 | ||
| 751 | bne 1b | ||
| 752 | </pre></div> | ||
| 753 | |||
| 754 | <p>The global symbol <code>start</code> is used by the linker as the default | ||
| 755 | address to use for the <code>.text</code> section. then it zeros the | ||
| 756 | <code>.bss</code> section so the uninitialized data will all be cleared. Some | ||
| 757 | programs have wild side effects from having the .bss section let | ||
| 758 | uncleared. Particularly it causes problems with some implementations of | ||
| 759 | <code>malloc</code>. | ||
| 760 | </p> | ||
| 761 | <div class="example"> | ||
| 762 | <pre class="example">/* | ||
| 763 | * Call the main routine from the application to get it going. | ||
| 764 | * main (argc, argv, environ) | ||
| 765 | * We pass argv as a pointer to NULL. | ||
| 766 | */ | ||
| 767 | pea 0 | ||
| 768 | pea SYM (environ) | ||
| 769 | pea sp@(4) | ||
| 770 | pea 0 | ||
| 771 | jsr SYM (main) | ||
| 772 | movel d0, sp@- | ||
| 773 | </pre></div> | ||
| 774 | |||
| 775 | <p>Setup the environment pointer and jump to <code>main()</code>. When | ||
| 776 | <code>main()</code> returns, it drops down to the <code>exit</code> routine below. | ||
| 777 | </p> | ||
| 778 | <div class="example"> | ||
| 779 | <pre class="example">/* | ||
| 780 | * _exit -- Exit from the application. Normally we cause a user trap | ||
| 781 | * to return to the ROM monitor for another run. | ||
| 782 | */ | ||
| 783 | SYM (exit): | ||
| 784 | trap #0 | ||
| 785 | </pre></div> | ||
| 786 | |||
| 787 | <p>Implementing <code>exit</code> here is easy. Both the <code>rom68k</code> and <code>bug</code> | ||
| 788 | can handle a user caused exception of <code>zero</code> with no side effects. | ||
| 789 | Although the <code>bug</code> monitor has a user caused trap that will return | ||
| 790 | control to the ROM monitor, this solution has been more portable. | ||
| 791 | </p> | ||
| 792 | <hr> | ||
| 793 | </div> | ||
| 794 | <div class="section" id="Linker-Scripts"> | ||
| 795 | <div class="header"> | ||
| 796 | <p> | ||
| 797 | Next: <a href="#What-to-do-now" accesskey="n" rel="next">What to do when you have a binary image</a>, Previous: <a href="#Crt0" accesskey="p" rel="prev">Crt0, the main startup file</a>, Up: <a href="#Libraries" accesskey="u" rel="up">Porting newlib</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 798 | </div> | ||
| 799 | <span id="Linker-scripts-for-memory-management"></span><h3 class="section">3.2 Linker scripts for memory management</h3> | ||
| 800 | |||
| 801 | <p>The linker script sets up the memory map of an application. It also | ||
| 802 | sets up default values for variables used elsewhere by sbrk() and the | ||
| 803 | crt0. These default variables are typically called <code>_bss_start</code> and | ||
| 804 | <code>_end</code>. | ||
| 805 | </p> | ||
| 806 | <p>For G++, the constructor and destructor tables must also be setup here. | ||
| 807 | The actual section names vary depending on the object file format. For | ||
| 808 | <code>a.out</code> and <code>coff</code>, the three main sections are <code>.text</code>, | ||
| 809 | <code>.data</code>, and <code>.bss</code>. | ||
| 810 | </p> | ||
| 811 | <p>Now that you have an image, you can test to make sure it got the | ||
| 812 | memory map right. You can do this by having the linker create a memory | ||
| 813 | map (by using the <code>-Map</code> option), or afterwards by using <code>nm</code> to | ||
| 814 | check a few critical addresses like <code>start</code>, <code>bss_end</code>, and | ||
| 815 | <code>_etext</code>. | ||
| 816 | </p> | ||
| 817 | <p>Here’s a breakdown of a linker script for a m68k based target board. | ||
| 818 | See the file <code>libgloss/m68k/idp.ld</code>, or go to the appendixes in | ||
| 819 | the end of the manual. <a href="#idp_002eld">Example Linker Script</a>. | ||
| 820 | </p> | ||
| 821 | <div class="example"> | ||
| 822 | <pre class="example">STARTUP(crt0.o) | ||
| 823 | OUTPUT_ARCH(m68k) | ||
| 824 | INPUT(idp.o) | ||
| 825 | SEARCH_DIR(.) | ||
| 826 | __DYNAMIC = 0; | ||
| 827 | </pre></div> | ||
| 828 | |||
| 829 | <p>The <code>STARTUP</code> command loads the file specified so that it’s | ||
| 830 | first. In this case it also doubles to load the file as well, because | ||
| 831 | the m68k-coff configuration defaults to not linking in the crt0.o by | ||
| 832 | default. It assumes that the developer probably has their own crt0.o. | ||
| 833 | This behavior is controlled in the config file for each architecture. | ||
| 834 | It’s a macro called <code>STARTFILE_SPEC</code>, and if it’s set to | ||
| 835 | <code>null</code>, then when <code>gcc</code> formats it’s command line, it doesn’t | ||
| 836 | add <code>crto.o</code>. Any file name can be specified here, but the default | ||
| 837 | is always <code>crt0.o</code>. | ||
| 838 | </p> | ||
| 839 | <p>Course if you only use <code>ld</code> to link, then the control of whether or | ||
| 840 | not to link in <code>crt0.o</code> is done on the command line. If you have | ||
| 841 | multiple crto files, then you can leave this out all together, and link | ||
| 842 | in the <code>crt0.o</code> in the makefile, or by having different linker | ||
| 843 | scripts. Sometimes this is done for initializing floating point | ||
| 844 | optionally, or to add device support. | ||
| 845 | </p> | ||
| 846 | <p>The <code>OUTPUT_ARCH</code> sets architecture the output file is for. | ||
| 847 | </p> | ||
| 848 | <p><code>INPUT</code> loads in the file specified. In this case, it’s a relocated | ||
| 849 | library that contains the definitions for the low-level functions need | ||
| 850 | by libc.a. This could have also been specified on the command line, but | ||
| 851 | as it’s always needed, it might as well be here as a default. | ||
| 852 | <code>SEARCH_DIR</code> specifies the path to look for files, and | ||
| 853 | <code>_DYNAMIC</code> means in this case there are no shared libraries. | ||
| 854 | </p> | ||
| 855 | <div class="example"> | ||
| 856 | <pre class="example">/* | ||
| 857 | * Setup the memory map of the MC68ec0x0 Board (IDP) | ||
| 858 | * stack grows up towards high memory. This works for | ||
| 859 | * both the rom68k and the mon68k monitors. | ||
| 860 | */ | ||
| 861 | MEMORY | ||
| 862 | { | ||
| 863 | ram : ORIGIN = 0x10000, LENGTH = 2M | ||
| 864 | } | ||
| 865 | </pre></div> | ||
| 866 | |||
| 867 | <p>This specifies a name for a section that can be referred to later in the | ||
| 868 | script. In this case, it’s only a pointer to the beginning of free RAM | ||
| 869 | space, with an upper limit at 2M. If the output file exceeds the upper | ||
| 870 | limit, it will produce an error message. | ||
| 871 | </p> | ||
| 872 | <div class="example"> | ||
| 873 | <pre class="example">/* | ||
| 874 | * stick everything in ram (of course) | ||
| 875 | */ | ||
| 876 | SECTIONS | ||
| 877 | { | ||
| 878 | .text : | ||
| 879 | { | ||
| 880 | CREATE_OBJECT_SYMBOLS | ||
| 881 | *(.text) | ||
| 882 | etext = .; | ||
| 883 | __CTOR_LIST__ = .; | ||
| 884 | LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2) | ||
| 885 | *(.ctors) | ||
| 886 | LONG(0) | ||
| 887 | __CTOR_END__ = .; | ||
| 888 | __DTOR_LIST__ = .; | ||
| 889 | LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2) | ||
| 890 | *(.dtors) | ||
| 891 | LONG(0) | ||
| 892 | __DTOR_END__ = .; | ||
| 893 | *(.lit) | ||
| 894 | *(.shdata) | ||
| 895 | } > ram | ||
| 896 | .shbss SIZEOF(.text) + ADDR(.text) : { | ||
| 897 | *(.shbss) | ||
| 898 | } | ||
| 899 | </pre></div> | ||
| 900 | |||
| 901 | <p>Set up the <code>.text</code> section. In a <code>COFF</code> file, .text is where | ||
| 902 | all the actual instructions are. This also sets up the <em>CONTRUCTOR</em> | ||
| 903 | and the <em>DESTRUCTOR</em> tables for <code>G++</code>. Notice that the section | ||
| 904 | description redirects itself to the <em>ram</em> variable setup earlier. | ||
| 905 | </p> | ||
| 906 | <div class="example"> | ||
| 907 | <pre class="example"> .talias : { } > ram | ||
| 908 | .data : { | ||
| 909 | *(.data) | ||
| 910 | CONSTRUCTORS | ||
| 911 | _edata = .; | ||
| 912 | } > ram | ||
| 913 | </pre></div> | ||
| 914 | |||
| 915 | <p>Setup the <code>.data</code> section. In a <code>coff</code> file, this is where all | ||
| 916 | he initialized data goes. <code>CONSTRUCTORS</code> is a special command used | ||
| 917 | by <code>ld</code>. | ||
| 918 | </p> | ||
| 919 | <div class="example"> | ||
| 920 | <pre class="example"> .bss SIZEOF(.data) + ADDR(.data) : | ||
| 921 | { | ||
| 922 | __bss_start = ALIGN(0x8); | ||
| 923 | *(.bss) | ||
| 924 | *(COMMON) | ||
| 925 | end = ALIGN(0x8); | ||
| 926 | _end = ALIGN(0x8); | ||
| 927 | __end = ALIGN(0x8); | ||
| 928 | } | ||
| 929 | .mstack : { } > ram | ||
| 930 | .rstack : { } > ram | ||
| 931 | .stab . (NOLOAD) : | ||
| 932 | { | ||
| 933 | [ .stab ] | ||
| 934 | } | ||
| 935 | .stabstr . (NOLOAD) : | ||
| 936 | { | ||
| 937 | [ .stabstr ] | ||
| 938 | } | ||
| 939 | } | ||
| 940 | </pre></div> | ||
| 941 | |||
| 942 | <p>Setup the <code>.bss</code> section. In a <code>COFF</code> file, this is where | ||
| 943 | unitialized data goes. The symbols <code>_bss_start</code> and <code>_end</code> | ||
| 944 | are setup here for use by the <code>crt0.o</code> when it zero’s the | ||
| 945 | <code>.bss</code> section. | ||
| 946 | </p> | ||
| 947 | |||
| 948 | <hr> | ||
| 949 | </div> | ||
| 950 | <div class="section" id="What-to-do-now"> | ||
| 951 | <div class="header"> | ||
| 952 | <p> | ||
| 953 | Next: <a href="#Libc" accesskey="n" rel="next">Libraries</a>, Previous: <a href="#Linker-Scripts" accesskey="p" rel="prev">Linker scripts for memory management</a>, Up: <a href="#Libraries" accesskey="u" rel="up">Porting newlib</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 954 | </div> | ||
| 955 | <span id="What-to-do-when-you-have-a-binary-image"></span><h3 class="section">3.3 What to do when you have a binary image</h3> | ||
| 956 | |||
| 957 | <p>A few ROM monitors load binary images, typically <code>a.out</code>, but most all | ||
| 958 | will load an <code>srecord</code>. An srecord is an ASCII representation of a binary | ||
| 959 | image. At it’s simplest, an srecord is an address, followed by a byte | ||
| 960 | count, followed by the bytes, and a 2’s compliment checksum. A whole | ||
| 961 | srecord file has an optional <em>start</em> record, and a required <em>end</em> | ||
| 962 | record. To make an srecord from a binary image, the GNU <code>objcopy</code> program | ||
| 963 | is used. This will read the image and make an srecord from it. To do | ||
| 964 | this, invoke objcopy like this: <code>objcopy -O srec infile outfile</code>. Most | ||
| 965 | PROM burners also read srecords or a similar format. Use <code>objdump -i</code> to | ||
| 966 | get a list of support object files types for your architecture. | ||
| 967 | </p> | ||
| 968 | <hr> | ||
| 969 | </div> | ||
| 970 | <div class="section" id="Libc"> | ||
| 971 | <div class="header"> | ||
| 972 | <p> | ||
| 973 | Previous: <a href="#What-to-do-now" accesskey="p" rel="prev">What to do when you have a binary image</a>, Up: <a href="#Libraries" accesskey="u" rel="up">Porting newlib</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 974 | </div> | ||
| 975 | <span id="Libraries-1"></span><h3 class="section">3.4 Libraries</h3> | ||
| 976 | |||
| 977 | <p>This describes <code>newlib</code>, a freely available libc replacement. Most | ||
| 978 | applications use calls in the standard C library. When initially linking | ||
| 979 | in libc.a, several I/O functions are undefined. If you don’t plan on | ||
| 980 | doing any I/O, then you’re OK, otherwise they need to be created. These | ||
| 981 | routines are read, write, open, close. sbrk, and kill. Open & close | ||
| 982 | don’t need to be fully supported unless you have a filesystems, so | ||
| 983 | typically they are stubbed out. Kill is also a stub, since you can’t do | ||
| 984 | process control on an embedded system. | ||
| 985 | </p> | ||
| 986 | <p>Sbrk() is only needed by applications that do dynamic memory | ||
| 987 | allocation. It’s uses the symbol <code>_end</code> that is setup in the linker | ||
| 988 | script. It also requires a compile time option to set the upper size | ||
| 989 | limit on the heap space. This leaves us with read and write, which are | ||
| 990 | required for serial I/O. Usually these two routines are written in C, | ||
| 991 | and call a lower level function for the actual I/O operation. These two | ||
| 992 | lowest level I/O primitives are inbyte() and outbyte(), and are also | ||
| 993 | used by GDB back ends if you’ve written an exception handler. Some | ||
| 994 | systems also implement a havebyte() for input as well. | ||
| 995 | </p> | ||
| 996 | <p>Other commonly included functions are routines for manipulating | ||
| 997 | LED’s on the target (if they exist) or low level debug help. Typically a | ||
| 998 | putnum() for printing words and bytes as a hex number is helpful, as | ||
| 999 | well as a low-level print() to output simple strings. | ||
| 1000 | </p> | ||
| 1001 | <p>As libg++ uses the I/O routines in libc.a, if read and write work, | ||
| 1002 | then libg++ will also work with no additional changes. | ||
| 1003 | </p> | ||
| 1004 | |||
| 1005 | <ul class="section-toc"> | ||
| 1006 | <li><a href="#I_002fO-Support" accesskey="1">Making I/O work</a></li> | ||
| 1007 | <li><a href="#Memory-Support" accesskey="2">Routines for dynamic memory allocation</a></li> | ||
| 1008 | <li><a href="#Misc-Support" accesskey="3">Misc support routines</a></li> | ||
| 1009 | <li><a href="#Debugging" accesskey="4">Useful debugging functions</a></li> | ||
| 1010 | </ul> | ||
| 1011 | <hr> | ||
| 1012 | <div class="subsection" id="I_002fO-Support"> | ||
| 1013 | <div class="header"> | ||
| 1014 | <p> | ||
| 1015 | Next: <a href="#Memory-Support" accesskey="n" rel="next">Routines for dynamic memory allocation</a>, Up: <a href="#Libc" accesskey="u" rel="up">Libraries</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1016 | </div> | ||
| 1017 | <span id="Making-I_002fO-work"></span><h4 class="subsection">3.4.1 Making I/O work</h4> | ||
| 1018 | |||
| 1019 | <hr> | ||
| 1020 | </div> | ||
| 1021 | <div class="subsection" id="Memory-Support"> | ||
| 1022 | <div class="header"> | ||
| 1023 | <p> | ||
| 1024 | Next: <a href="#Misc-Support" accesskey="n" rel="next">Misc support routines</a>, Previous: <a href="#I_002fO-Support" accesskey="p" rel="prev">Making I/O work</a>, Up: <a href="#Libc" accesskey="u" rel="up">Libraries</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1025 | </div> | ||
| 1026 | <span id="Routines-for-dynamic-memory-allocation"></span><h4 class="subsection">3.4.2 Routines for dynamic memory allocation</h4> | ||
| 1027 | <p>To support using any of the memory functions, you need to implement | ||
| 1028 | sbrk(). <code>malloc()</code>, <code>calloc()</code>, and <code>realloc()</code> all call | ||
| 1029 | <code>sbrk()</code> at there lowest level. <code>caddr_t</code> is defined elsewhere | ||
| 1030 | as <code>char *</code>. <code>RAMSIZE</code> is presently a compile time option. All | ||
| 1031 | this does is move a pointer to heap memory and check for the upper | ||
| 1032 | limit. <a href="#glue_002ec">Example libc support code</a>. <code>sbrk()</code> returns a | ||
| 1033 | pointer to the previous value before more memory was allocated. | ||
| 1034 | </p> | ||
| 1035 | <div class="example"> | ||
| 1036 | <pre class="example">/* _end is set in the linker command file * | ||
| 1037 | extern caddr_t _end;/ | ||
| 1038 | |||
| 1039 | /* just in case, most boards have at least some memory */ | ||
| 1040 | #ifndef RAMSIZE | ||
| 1041 | # define RAMSIZE (caddr_t)0x100000 | ||
| 1042 | #endif | ||
| 1043 | |||
| 1044 | /* | ||
| 1045 | * sbrk -- changes heap size size. Get nbytes more | ||
| 1046 | * RAM. We just increment a pointer in what's | ||
| 1047 | * left of memory on the board. | ||
| 1048 | */ | ||
| 1049 | caddr_t | ||
| 1050 | sbrk(nbytes) | ||
| 1051 | int nbytes; | ||
| 1052 | { | ||
| 1053 | static caddr_t heap_ptr = NULL; | ||
| 1054 | caddr_t base; | ||
| 1055 | |||
| 1056 | if (heap_ptr == NULL) { | ||
| 1057 | heap_ptr = (caddr_t)&_end; | ||
| 1058 | } | ||
| 1059 | |||
| 1060 | if ((RAMSIZE - heap_ptr) >= 0) { | ||
| 1061 | base = heap_ptr; | ||
| 1062 | heap_ptr += nbytes; | ||
| 1063 | return (base); | ||
| 1064 | } else { | ||
| 1065 | errno = ENOMEM; | ||
| 1066 | return ((caddr_t)-1); | ||
| 1067 | } | ||
| 1068 | } | ||
| 1069 | </pre></div> | ||
| 1070 | |||
| 1071 | <hr> | ||
| 1072 | </div> | ||
| 1073 | <div class="subsection" id="Misc-Support"> | ||
| 1074 | <div class="header"> | ||
| 1075 | <p> | ||
| 1076 | Next: <a href="#Debugging" accesskey="n" rel="next">Useful debugging functions</a>, Previous: <a href="#Memory-Support" accesskey="p" rel="prev">Routines for dynamic memory allocation</a>, Up: <a href="#Libc" accesskey="u" rel="up">Libraries</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1077 | </div> | ||
| 1078 | <span id="Misc-support-routines"></span><h4 class="subsection">3.4.3 Misc support routines</h4> | ||
| 1079 | |||
| 1080 | <p>These are called by <code>newlib</code> but don’t apply to the embedded | ||
| 1081 | environment. <code>isatty()</code> is self explanatory. <code>kill()</code> doesn’t | ||
| 1082 | apply either in an environment withno process control, so it justs | ||
| 1083 | exits, which is a similar enough behavior. <code>getpid()</code> can safely | ||
| 1084 | return any value greater than 1. The value doesn’t effect anything in | ||
| 1085 | <code>newlib</code> because once again there is no process control. | ||
| 1086 | </p> | ||
| 1087 | <div class="example"> | ||
| 1088 | <pre class="example">/* | ||
| 1089 | * isatty -- returns 1 if connected to a terminal device, | ||
| 1090 | * returns 0 if not. Since we're hooked up to a | ||
| 1091 | * serial port, we'll say yes and return a 1. | ||
| 1092 | */ | ||
| 1093 | int | ||
| 1094 | isatty(fd) | ||
| 1095 | int fd; | ||
| 1096 | { | ||
| 1097 | return (1); | ||
| 1098 | } | ||
| 1099 | |||
| 1100 | /* | ||
| 1101 | * getpid -- only one process, so just return 1. | ||
| 1102 | */ | ||
| 1103 | #define __MYPID 1 | ||
| 1104 | int | ||
| 1105 | getpid() | ||
| 1106 | { | ||
| 1107 | return __MYPID; | ||
| 1108 | } | ||
| 1109 | |||
| 1110 | /* | ||
| 1111 | * kill -- go out via exit... | ||
| 1112 | */ | ||
| 1113 | int | ||
| 1114 | kill(pid, sig) | ||
| 1115 | int pid; | ||
| 1116 | int sig; | ||
| 1117 | { | ||
| 1118 | if(pid == __MYPID) | ||
| 1119 | _exit(sig); | ||
| 1120 | return 0; | ||
| 1121 | } | ||
| 1122 | </pre></div> | ||
| 1123 | |||
| 1124 | <hr> | ||
| 1125 | </div> | ||
| 1126 | <div class="subsection" id="Debugging"> | ||
| 1127 | <div class="header"> | ||
| 1128 | <p> | ||
| 1129 | Previous: <a href="#Misc-Support" accesskey="p" rel="prev">Misc support routines</a>, Up: <a href="#Libc" accesskey="u" rel="up">Libraries</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1130 | </div> | ||
| 1131 | <span id="Useful-debugging-functions"></span><h4 class="subsection">3.4.4 Useful debugging functions</h4> | ||
| 1132 | |||
| 1133 | <p>There are always a few useful functions for debugging your project in | ||
| 1134 | progress. I typically implement a simple <code>print()</code> routine that | ||
| 1135 | runs standalone in liblgoss, with no <code>newlib</code> support. The I/O | ||
| 1136 | function <code>outbyte()</code> can also be used for low level debugging. Many | ||
| 1137 | times print will work when there are problems that cause <code>printf()</code> to | ||
| 1138 | cause an exception. <code>putnum()</code> is just to print out values in hex | ||
| 1139 | so they are easier to read. | ||
| 1140 | </p> | ||
| 1141 | <div class="example"> | ||
| 1142 | <pre class="example">/* | ||
| 1143 | * print -- do a raw print of a string | ||
| 1144 | */ | ||
| 1145 | int | ||
| 1146 | print(ptr) | ||
| 1147 | char *ptr; | ||
| 1148 | { | ||
| 1149 | while (*ptr) { | ||
| 1150 | outbyte (*ptr++); | ||
| 1151 | } | ||
| 1152 | } | ||
| 1153 | |||
| 1154 | /* | ||
| 1155 | * putnum -- print a 32 bit number in hex | ||
| 1156 | */ | ||
| 1157 | int | ||
| 1158 | putnum (num) | ||
| 1159 | unsigned int num; | ||
| 1160 | { | ||
| 1161 | char buffer[9]; | ||
| 1162 | int count; | ||
| 1163 | char *bufptr = buffer; | ||
| 1164 | int digit; | ||
| 1165 | |||
| 1166 | for (count = 7 ; count >= 0 ; count--) { | ||
| 1167 | digit = (num >> (count * 4)) & 0xf; | ||
| 1168 | |||
| 1169 | if (digit <= 9) | ||
| 1170 | *bufptr++ = (char) ('0' + digit); | ||
| 1171 | else | ||
| 1172 | *bufptr++ = (char) ('a' - 10 + digit); | ||
| 1173 | } | ||
| 1174 | |||
| 1175 | *bufptr = (char) 0; | ||
| 1176 | print (buffer); | ||
| 1177 | return; | ||
| 1178 | } | ||
| 1179 | </pre></div> | ||
| 1180 | |||
| 1181 | <p>If there are LEDs on the board, they can also be put to use for | ||
| 1182 | debugging when the serial I/O code is being written. I usually implement | ||
| 1183 | a <code>zylons()</code> function, which strobes the LEDS (if there is more | ||
| 1184 | than one) in sequence, creating a rotating effect. This is convenient | ||
| 1185 | between I/O to see if the target is still alive. Another useful LED | ||
| 1186 | function is <code>led_putnum()</code>, which takes a digit and displays it as | ||
| 1187 | a bit pattern or number. These usually have to be written in assembler | ||
| 1188 | for each target board. Here are a number of C based routines that may be | ||
| 1189 | useful. | ||
| 1190 | </p> | ||
| 1191 | <p><code>led_putnum()</code> puts a number on a single digit segmented | ||
| 1192 | LED display. This LED is set by setting a bit mask to an address, where | ||
| 1193 | 1 turns the segment off, and 0 turns it on. There is also a little | ||
| 1194 | decimal point on the LED display, so it gets the leftmost bit. The other | ||
| 1195 | bits specify the segment location. The bits look like: | ||
| 1196 | </p> | ||
| 1197 | <div class="example"> | ||
| 1198 | <pre class="example"> [d.p | g | f | e | d | c | b | a ] is the byte. | ||
| 1199 | </pre></div> | ||
| 1200 | |||
| 1201 | <p>The locations are set up as: | ||
| 1202 | </p> | ||
| 1203 | <div class="example"> | ||
| 1204 | <pre class="example"> a | ||
| 1205 | ----- | ||
| 1206 | f | | b | ||
| 1207 | | g | | ||
| 1208 | ----- | ||
| 1209 | | | | ||
| 1210 | e | | c | ||
| 1211 | ----- | ||
| 1212 | d | ||
| 1213 | </pre></div> | ||
| 1214 | |||
| 1215 | <p>This takes a number that’s already been converted to a string, and | ||
| 1216 | prints it. | ||
| 1217 | </p> | ||
| 1218 | <div class="example"> | ||
| 1219 | <pre class="example">#define LED_ADDR 0xd00003 | ||
| 1220 | |||
| 1221 | void | ||
| 1222 | led_putnum ( num ) | ||
| 1223 | char num; | ||
| 1224 | { | ||
| 1225 | static unsigned char *leds = (unsigned char *)LED_ADDR; | ||
| 1226 | static unsigned char num_bits [18] = { | ||
| 1227 | 0xff, /* clear all */ | ||
| 1228 | 0xc0, 0xf9, 0xa4, 0xb0, 0x99, 0x92, 0x82, 0xf8, 0x80, 0x98, /* numbers 0-9 */ | ||
| 1229 | 0x98, 0x20, 0x3, 0x27, 0x21, 0x4, 0xe /* letters a-f */ | ||
| 1230 | }; | ||
| 1231 | |||
| 1232 | if (num >= '0' && num <= '9') | ||
| 1233 | num = (num - '0') + 1; | ||
| 1234 | |||
| 1235 | if (num >= 'a' && num <= 'f') | ||
| 1236 | num = (num - 'a') + 12; | ||
| 1237 | |||
| 1238 | if (num == ' ') | ||
| 1239 | num = 0; | ||
| 1240 | |||
| 1241 | *leds = num_bits[num]; | ||
| 1242 | } | ||
| 1243 | |||
| 1244 | /* | ||
| 1245 | * zylons -- draw a rotating pattern. NOTE: this function never returns. | ||
| 1246 | */ | ||
| 1247 | void | ||
| 1248 | zylons() | ||
| 1249 | { | ||
| 1250 | unsigned char *leds = (unsigned char *)LED_ADDR; | ||
| 1251 | unsigned char curled = 0xfe; | ||
| 1252 | |||
| 1253 | while (1) | ||
| 1254 | { | ||
| 1255 | *leds = curled; | ||
| 1256 | curled = (curled >> 1) | (curled << 7); | ||
| 1257 | delay ( 200 ); | ||
| 1258 | } | ||
| 1259 | } | ||
| 1260 | </pre></div> | ||
| 1261 | |||
| 1262 | |||
| 1263 | <hr> | ||
| 1264 | </div> | ||
| 1265 | </div> | ||
| 1266 | </div> | ||
| 1267 | <div class="chapter" id="GDB"> | ||
| 1268 | <div class="header"> | ||
| 1269 | <p> | ||
| 1270 | Next: <a href="#Binutils" accesskey="n" rel="next">Binutils</a>, Previous: <a href="#Libraries" accesskey="p" rel="prev">Porting newlib</a>, Up: <a href="#Top" accesskey="u" rel="up">Embed with GNU</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1271 | </div> | ||
| 1272 | <span id="Writing-a-new-GDB-backend"></span><h2 class="chapter">4 Writing a new GDB backend</h2> | ||
| 1273 | |||
| 1274 | <p>Typically, either the low-level I/O routines are used for debugging, or | ||
| 1275 | LEDs, if present. It is much easier to use GDb for debugging an | ||
| 1276 | application. There are several different techniques used to have GDB work | ||
| 1277 | remotely. Commonly more than one kind of GDB interface is used to cober | ||
| 1278 | a wide variety of development needs. | ||
| 1279 | </p> | ||
| 1280 | <p>The most common style of GDB backend is an exception handler for | ||
| 1281 | breakpoints. This is also called a <em>gdb stub</em>, and is requires the | ||
| 1282 | two additional lines of init code in your <code>main()</code> routine. The GDB | ||
| 1283 | stubs all use the GDB <em>remote protocol</em>. When the application gets a | ||
| 1284 | breakpoint exception, it communicates to GDB on the host. | ||
| 1285 | </p> | ||
| 1286 | <p>Another common style of interfacing GDB to a target is by using an | ||
| 1287 | existing ROM monitor. These break down into two main kinds, a similar | ||
| 1288 | protocol to the GDB remote protocol, and an interface that uses the ROM | ||
| 1289 | monitor directly. This kind has GDB simulating a human operator, and all | ||
| 1290 | GDB does is work as a command formatter and parser. | ||
| 1291 | </p> | ||
| 1292 | |||
| 1293 | <ul class="section-toc"> | ||
| 1294 | <li><a href="#GNU-remote-protocol" accesskey="1">The standard remote protocol</a></li> | ||
| 1295 | <li><a href="#Exception-handler" accesskey="2">A linked in exception handler</a></li> | ||
| 1296 | <li><a href="#ROM-monitors" accesskey="3">Using a ROM monitor as a backend</a></li> | ||
| 1297 | <li><a href="#Other-remote-protocols" accesskey="4">Adding support for new protocols</a></li> | ||
| 1298 | </ul> | ||
| 1299 | <hr> | ||
| 1300 | <div class="section" id="GNU-remote-protocol"> | ||
| 1301 | <div class="header"> | ||
| 1302 | <p> | ||
| 1303 | Next: <a href="#Exception-handler" accesskey="n" rel="next">A linked in exception handler</a>, Up: <a href="#GDB" accesskey="u" rel="up">Writing a new GDB backend</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1304 | </div> | ||
| 1305 | <span id="The-standard-remote-protocol"></span><h3 class="section">4.1 The standard remote protocol</h3> | ||
| 1306 | |||
| 1307 | <p>The standard remote protocol is a simple, packet based scheme. A debug | ||
| 1308 | packet whose contents are <em><data></em> is encapsulated for transmission | ||
| 1309 | in the form: | ||
| 1310 | </p> | ||
| 1311 | <div class="example"> | ||
| 1312 | <pre class="example"> $ <data> # CSUM1 CSUM2 | ||
| 1313 | </pre></div> | ||
| 1314 | |||
| 1315 | <p><em><data></em> must be ASCII alphanumeric and cannot include characters | ||
| 1316 | <code>$</code> or <code>#</code>. If <em><data></em> starts with two characters | ||
| 1317 | followed by <code>:</code>, then the existing stubs interpret this as a | ||
| 1318 | sequence number. For example, the command <code>g</code> is used to read the | ||
| 1319 | values of the registers. So, a packet to do this would look like | ||
| 1320 | </p> | ||
| 1321 | <div class="example"> | ||
| 1322 | <pre class="example"> $g#67 | ||
| 1323 | </pre></div> | ||
| 1324 | |||
| 1325 | <p><em>CSUM1</em> and <em>CSUM2</em> are an ascii representation in hex of an | ||
| 1326 | 8-bit checksum of <em><data></em>, the most significant nibble is sent first. | ||
| 1327 | the hex digits 0-9,a-f are used. | ||
| 1328 | </p> | ||
| 1329 | <p>A simple protocol is used when communicating with the target. This is | ||
| 1330 | mainly to give a degree of error handling over the serial cable. For | ||
| 1331 | each packet transmitted successfully, the target responds with a | ||
| 1332 | <code>+</code> (<code>ACK</code>). If there was a transmission error, then the target | ||
| 1333 | responds with a <code>-</code> (<code>NAK</code>). An error is determined when the | ||
| 1334 | checksum doesn’t match the calculated checksum for that data record. | ||
| 1335 | Upon reciept of the <code>ACK</code>, <code>GDB</code> can then transmit the next | ||
| 1336 | packet. | ||
| 1337 | </p> | ||
| 1338 | <p>Here is a list of the main functions that need to be supported. Each data | ||
| 1339 | packet is a command with a set number of bytes in the command packet. | ||
| 1340 | Most commands either return data, or respond with a <code>NAK</code>. Commands | ||
| 1341 | that don’t return data respond with an <code>ACK</code>. All data values are | ||
| 1342 | ascii hex digits. Every byte needs two hex digits to represent t. This | ||
| 1343 | means that a byte with the value ‘<samp>7</samp>’ becomes ‘<samp>07</samp>’. On a 32 bit | ||
| 1344 | machine this works out to 8 characters per word. All of the bytes in a | ||
| 1345 | word are stored in the target byte order. When writing the host side of | ||
| 1346 | the GDB protocol, be careful of byte order, and make sure that the code | ||
| 1347 | will run on both big and little endian hosts and produce the same answers. | ||
| 1348 | </p> | ||
| 1349 | <p>These functions are the minimum required to make a GDB backend work. All | ||
| 1350 | other commands are optional, and not supported by all GDB backends. | ||
| 1351 | </p> | ||
| 1352 | <dl compact="compact"> | ||
| 1353 | <dt><span>‘<samp>read registers <code>g</code></samp>’</span></dt> | ||
| 1354 | <dd> | ||
| 1355 | <p>returns <code>XXXXXXXX...</code> | ||
| 1356 | </p> | ||
| 1357 | <p>Registers are in the internal order for GDB, and the bytes in a register | ||
| 1358 | are in the same order the machine uses. All values are in sequence | ||
| 1359 | starting with register 0. All registers are listed in the same packet. A | ||
| 1360 | sample packet would look like <code>$g#</code>. | ||
| 1361 | </p> | ||
| 1362 | </dd> | ||
| 1363 | <dt><span>‘<samp>write registers <code>GXXXXXXXX...</code></samp>’</span></dt> | ||
| 1364 | <dd><p><code>XXXXXXXX</code> is the value to set the register to. Registers are in | ||
| 1365 | the internal order for GDB, and the bytes in a register are in the same | ||
| 1366 | order the machine uses. All values are in sequence starting with | ||
| 1367 | register 0. All registers values are listed in the same packet. A sample | ||
| 1368 | packet would look like <code>$G000000001111111122222222...#</code> | ||
| 1369 | </p> | ||
| 1370 | <p>returns <code>ACK</code> or <code>NAK</code> | ||
| 1371 | </p> | ||
| 1372 | </dd> | ||
| 1373 | <dt><span>‘<samp>read memory <code>mAAAAAAAA,LLLL</code></samp>’</span></dt> | ||
| 1374 | <dd><p><code>AAAAAAAA</code> is address, <code>LLLL</code> is length. A sample packet would | ||
| 1375 | look like <code>$m00005556,0024#</code>. This would request 24 bytes starting | ||
| 1376 | at address <em>00005556</em> | ||
| 1377 | </p> | ||
| 1378 | <p>returns <code>XXXXXXXX...</code> | ||
| 1379 | <code>XXXXXXXX</code> is the memory contents. Fewer bytes than requested will | ||
| 1380 | be returned if only part of the data can be read. This can be determined | ||
| 1381 | by counting the values till the end of packet <code>#</code> is seen and | ||
| 1382 | comparing that with the total count of bytes that was requested. | ||
| 1383 | </p> | ||
| 1384 | </dd> | ||
| 1385 | <dt><span>‘<samp>write memory <code>MAAAAAAAA,LLLL:XXXXXXXX</code></samp>’</span></dt> | ||
| 1386 | <dd><p><code>AAAAAAAA</code> is the starting address, <code>LLLL</code> is the number of | ||
| 1387 | bytes to be written, and <code>XXXXXXXX</code> is value to be written. A | ||
| 1388 | sample packet would look like | ||
| 1389 | <code>$M00005556,0024:101010101111111100000000...#</code> | ||
| 1390 | </p> | ||
| 1391 | <p>returns <code>ACK</code> or <code>NAK</code> for an error. <code>NAK</code> is also | ||
| 1392 | returned when only part of the data is written. | ||
| 1393 | </p> | ||
| 1394 | </dd> | ||
| 1395 | <dt><span>‘<samp>continue <code>cAAAAAAAAA</code></samp>’</span></dt> | ||
| 1396 | <dd><p><code>AAAAAAAA</code> is address to resume execution at. If <code>AAAAAAAA</code> is | ||
| 1397 | omitted, resume at the curent address of the <code>pc</code> register. | ||
| 1398 | </p> | ||
| 1399 | <p>returns the same replay as <code>last signal</code>. There is no immediate | ||
| 1400 | replay to <code>cont</code> until the next breakpoint is reached, and the | ||
| 1401 | program stops executing. | ||
| 1402 | </p> | ||
| 1403 | </dd> | ||
| 1404 | <dt><span>‘<samp>step sAA..AA</samp>’</span></dt> | ||
| 1405 | <dd><p><code>AA..AA</code> is address to resume | ||
| 1406 | If <code>AA..AA</code> is omitted, resume at same address. | ||
| 1407 | </p> | ||
| 1408 | <p>returns the same replay as <code>last signal</code>. There is no immediate | ||
| 1409 | replay to <code>step</code> until the next breakpoint is reached, and the | ||
| 1410 | program stops executing. | ||
| 1411 | </p> | ||
| 1412 | </dd> | ||
| 1413 | <dt><span>‘<samp>last signal <code>?</code></samp>’</span></dt> | ||
| 1414 | <dd> | ||
| 1415 | <p>This returns one of the following: | ||
| 1416 | </p> | ||
| 1417 | <ul> | ||
| 1418 | <li> <code>SAA</code> | ||
| 1419 | Where <code>AA</code> is the number of the last signal. | ||
| 1420 | Exceptions on the target are converted to the most similar Unix style | ||
| 1421 | signal number, like <code>SIGSEGV</code>. A sample response of this type would | ||
| 1422 | look like <code>$S05#</code>. | ||
| 1423 | |||
| 1424 | </li><li> TAAnn:XXXXXXXX;nn:XXXXXXXX;nn:XXXXXXXX; | ||
| 1425 | <code>AA</code> is the signal number. | ||
| 1426 | <code>nn</code> is the register number. | ||
| 1427 | <code>XXXXXXXX</code> is the register value. | ||
| 1428 | |||
| 1429 | </li><li> WAA | ||
| 1430 | The process exited, and <code>AA</code> is the exit status. This is only | ||
| 1431 | applicable for certains sorts of targets. | ||
| 1432 | |||
| 1433 | </li></ul> | ||
| 1434 | |||
| 1435 | <p>These are used in some GDB backends, but not all. | ||
| 1436 | </p> | ||
| 1437 | </dd> | ||
| 1438 | <dt><span>‘<samp>write reg <code>Pnn=XXXXXXXX</code></samp>’</span></dt> | ||
| 1439 | <dd><p>Write register <code>nn</code> with value <code>XXXXXXXX</code>. | ||
| 1440 | </p> | ||
| 1441 | <p>returns <code>ACK</code> or <code>NAK</code> | ||
| 1442 | </p> | ||
| 1443 | </dd> | ||
| 1444 | <dt><span>‘<samp>kill request k</samp>’</span></dt> | ||
| 1445 | <dt><span>‘<samp>toggle debug d</samp>’</span></dt> | ||
| 1446 | <dd><p>toggle debug flag (see 386 & 68k stubs) | ||
| 1447 | </p> | ||
| 1448 | </dd> | ||
| 1449 | <dt><span>‘<samp>reset r</samp>’</span></dt> | ||
| 1450 | <dd><p>reset – see sparc stub. | ||
| 1451 | </p> | ||
| 1452 | </dd> | ||
| 1453 | <dt><span>‘<samp>reserved <code>other</code></samp>’</span></dt> | ||
| 1454 | <dd><p>On other requests, the stub should ignore the request and send an empty | ||
| 1455 | response <code>$#<checksum></code>. This way we can extend the protocol and GDB | ||
| 1456 | can tell whether the stub it is talking to uses the old or the new. | ||
| 1457 | </p> | ||
| 1458 | </dd> | ||
| 1459 | <dt><span>‘<samp>search <code>tAA:PP,MM</code></samp>’</span></dt> | ||
| 1460 | <dd><p>Search backwards starting at address <code>AA</code> for a match with pattern | ||
| 1461 | PP and mask <code>MM</code>. <code>PP</code> and <code>MM</code> are 4 bytes. | ||
| 1462 | </p> | ||
| 1463 | </dd> | ||
| 1464 | <dt><span>‘<samp>general query <code>qXXXX</code></samp>’</span></dt> | ||
| 1465 | <dd><p>Request info about XXXX. | ||
| 1466 | </p> | ||
| 1467 | </dd> | ||
| 1468 | <dt><span>‘<samp>general set <code>QXXXX=yyyy</code></samp>’</span></dt> | ||
| 1469 | <dd><p>Set value of <code>XXXX</code> to <code>yyyy</code>. | ||
| 1470 | </p> | ||
| 1471 | </dd> | ||
| 1472 | <dt><span>‘<samp>query sect offs <code>qOffsets</code></samp>’</span></dt> | ||
| 1473 | <dd><p>Get section offsets. Reply is <code>Text=xxx;Data=yyy;Bss=zzz</code> | ||
| 1474 | </p> | ||
| 1475 | </dd> | ||
| 1476 | <dt><span>‘<samp>console output Otext</samp>’</span></dt> | ||
| 1477 | <dd><p>Send text to stdout. The text gets display from the target side of the | ||
| 1478 | serial connection. | ||
| 1479 | </p> | ||
| 1480 | </dd> | ||
| 1481 | </dl> | ||
| 1482 | |||
| 1483 | <p>Responses can be run-length encoded to save space. A <code>*</code>means that | ||
| 1484 | the next character is an ASCII encoding giving a repeat count which | ||
| 1485 | stands for that many repetitions of the character preceding the <code>*</code>. | ||
| 1486 | The encoding is n+29, yielding a printable character where n >=3 | ||
| 1487 | (which is where run length encoding starts to win). You can’t use a | ||
| 1488 | value of where n >126 because it’s only a two byte value. An example | ||
| 1489 | would be a <code>0*03</code> means the same thing as <code>0000</code>. | ||
| 1490 | </p> | ||
| 1491 | <hr> | ||
| 1492 | </div> | ||
| 1493 | <div class="section" id="Exception-handler"> | ||
| 1494 | <div class="header"> | ||
| 1495 | <p> | ||
| 1496 | Next: <a href="#ROM-monitors" accesskey="n" rel="next">Using a ROM monitor as a backend</a>, Previous: <a href="#GNU-remote-protocol" accesskey="p" rel="prev">The standard remote protocol</a>, Up: <a href="#GDB" accesskey="u" rel="up">Writing a new GDB backend</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1497 | </div> | ||
| 1498 | <span id="A-linked-in-exception-handler"></span><h3 class="section">4.2 A linked in exception handler</h3> | ||
| 1499 | |||
| 1500 | <p>A <em>GDB stub</em> consists of two parts, support for the exception | ||
| 1501 | handler, and the exception handler itself. The exception handler needs | ||
| 1502 | to communicate to GDB on the host whenever there is a breakpoint | ||
| 1503 | exception. When GDB starts a program running on the target, it’s polling | ||
| 1504 | the serial port during execution looking for any debug packets. So when | ||
| 1505 | a breakpoint occurs, the exception handler needs to save state, and send | ||
| 1506 | a GDB remote protocol packet to GDB on the host. GDB takes any output | ||
| 1507 | that isn’t a debug command packet and displays it in the command window. | ||
| 1508 | </p> | ||
| 1509 | <p>Support for the exception handler varies between processors, but the | ||
| 1510 | minimum supported functions are those needed by GDB. These are functions | ||
| 1511 | to support the reading and writing of registers, the reading and writing | ||
| 1512 | of memory, start execution at an address, single step, and last signal. | ||
| 1513 | Sometimes other functions for adjusting the baud rate, or resetting the | ||
| 1514 | hardware are implemented. | ||
| 1515 | </p> | ||
| 1516 | <p>Once GDB gets the command packet from the breakpoint, it will read a few | ||
| 1517 | registers and memory locations an then wait for the user. When the user | ||
| 1518 | types <code>run</code> or <code>continue</code> a <code>continue</code> command is issued | ||
| 1519 | to the backend, and control returns from the breakpoint routine to the | ||
| 1520 | application. | ||
| 1521 | </p> | ||
| 1522 | <hr> | ||
| 1523 | </div> | ||
| 1524 | <div class="section" id="ROM-monitors"> | ||
| 1525 | <div class="header"> | ||
| 1526 | <p> | ||
| 1527 | Next: <a href="#Other-remote-protocols" accesskey="n" rel="next">Adding support for new protocols</a>, Previous: <a href="#Exception-handler" accesskey="p" rel="prev">A linked in exception handler</a>, Up: <a href="#GDB" accesskey="u" rel="up">Writing a new GDB backend</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1528 | </div> | ||
| 1529 | <span id="Using-a-ROM-monitor-as-a-backend"></span><h3 class="section">4.3 Using a ROM monitor as a backend</h3> | ||
| 1530 | <p>GDB also can mimic a human user and use a ROM monitors normal debug | ||
| 1531 | commands as a backend. This consists mostly of sending and parsing | ||
| 1532 | <code>ASCII</code> strings. All the ROM monitor interfaces share a common set | ||
| 1533 | of routines in <code>gdb/monitor.c</code>. This supports adding new ROM | ||
| 1534 | monitor interfaces by filling in a structure with the common commands | ||
| 1535 | GDB needs. GDb already supports several command ROM monitors, including | ||
| 1536 | Motorola’s <code>Bug</code> monitor for their VME boards, and the Rom68k | ||
| 1537 | monitor by Integrated Systems, Inc. for various m68k based boards. GDB | ||
| 1538 | also supports the custom ROM monitors on the WinBond and Oki PA based | ||
| 1539 | targets. There is builtin support for loading files to ROM monitors | ||
| 1540 | specifically. GDB can convert a binary into an srecord and then load it | ||
| 1541 | as an ascii file, or using <code>xmodem</code>. | ||
| 1542 | </p> | ||
| 1543 | |||
| 1544 | <hr> | ||
| 1545 | </div> | ||
| 1546 | <div class="section" id="Other-remote-protocols"> | ||
| 1547 | <div class="header"> | ||
| 1548 | <p> | ||
| 1549 | Previous: <a href="#ROM-monitors" accesskey="p" rel="prev">Using a ROM monitor as a backend</a>, Up: <a href="#GDB" accesskey="u" rel="up">Writing a new GDB backend</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1550 | </div> | ||
| 1551 | <span id="Adding-support-for-new-protocols"></span><h3 class="section">4.4 Adding support for new protocols</h3> | ||
| 1552 | |||
| 1553 | <hr> | ||
| 1554 | <span id="Binutils"></span><div class="header"> | ||
| 1555 | <p> | ||
| 1556 | Next: <a href="#Code-Listings" accesskey="n" rel="next">Code Listings</a>, Previous: <a href="#GDB" accesskey="p" rel="prev">Writing a new GDB backend</a>, Up: <a href="#Top" accesskey="u" rel="up">Embed with GNU</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1557 | </div> | ||
| 1558 | <h4 class="node-heading">Binutils</h4> | ||
| 1559 | |||
| 1560 | <hr> | ||
| 1561 | </div> | ||
| 1562 | </div> | ||
| 1563 | <div class="appendix" id="Code-Listings"> | ||
| 1564 | <div class="header"> | ||
| 1565 | <p> | ||
| 1566 | Next: <a href="#idp_002eld" accesskey="n" rel="next">Linker script for the IDP board</a>, Previous: <a href="#Binutils" accesskey="p" rel="prev">Binutils</a>, Up: <a href="#Top" accesskey="u" rel="up">Embed with GNU</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1567 | </div> | ||
| 1568 | <span id="Code-Listings-1"></span><h2 class="appendix">Appendix A Code Listings</h2> | ||
| 1569 | |||
| 1570 | |||
| 1571 | <ul class="section-toc"> | ||
| 1572 | <li><a href="#idp_002eld" accesskey="1">Linker script for the IDP board</a></li> | ||
| 1573 | <li><a href="#crt0_002eS" accesskey="2">crt0.S - The startup file</a></li> | ||
| 1574 | <li><a href="#glue_002ec" accesskey="3">C based "glue" code.</a></li> | ||
| 1575 | <li><a href="#mvme_002eS" accesskey="4">I/O assembler code sample</a></li> | ||
| 1576 | <li><a href="#io_002ec" accesskey="5">I/O code sample</a></li> | ||
| 1577 | <li><a href="#leds_002ec" accesskey="6">Led control sample</a></li> | ||
| 1578 | </ul> | ||
| 1579 | <hr> | ||
| 1580 | <div class="section" id="idp_002eld"> | ||
| 1581 | <div class="header"> | ||
| 1582 | <p> | ||
| 1583 | Next: <a href="#crt0_002eS" accesskey="n" rel="next">crt0.S - The startup file</a>, Previous: <a href="#Code-Listings" accesskey="p" rel="prev">Code Listings</a>, Up: <a href="#Code-Listings" accesskey="u" rel="up">Code Listings</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1584 | </div> | ||
| 1585 | <span id="Linker-script-for-the-IDP-board"></span><h3 class="section">A.1 Linker script for the IDP board</h3> | ||
| 1586 | |||
| 1587 | <p>This is the linker script script that is used on the Motorola IDP board. | ||
| 1588 | </p> | ||
| 1589 | <div class="example"> | ||
| 1590 | <pre class="example">STARTUP(crt0.o) | ||
| 1591 | OUTPUT_ARCH(m68k) | ||
| 1592 | INPUT(idp.o) | ||
| 1593 | SEARCH_DIR(.) | ||
| 1594 | __DYNAMIC = 0; | ||
| 1595 | /* | ||
| 1596 | * Setup the memory map of the MC68ec0x0 Board (IDP) | ||
| 1597 | * stack grows up towards high memory. This works for | ||
| 1598 | * both the rom68k and the mon68k monitors. | ||
| 1599 | */ | ||
| 1600 | MEMORY | ||
| 1601 | { | ||
| 1602 | ram : ORIGIN = 0x10000, LENGTH = 2M | ||
| 1603 | } | ||
| 1604 | /* | ||
| 1605 | * stick everything in ram (of course) | ||
| 1606 | */ | ||
| 1607 | SECTIONS | ||
| 1608 | { | ||
| 1609 | .text : | ||
| 1610 | { | ||
| 1611 | CREATE_OBJECT_SYMBOLS | ||
| 1612 | *(.text) | ||
| 1613 | etext = .; | ||
| 1614 | __CTOR_LIST__ = .; | ||
| 1615 | LONG((__CTOR_END__ - __CTOR_LIST__) / 4 - 2) | ||
| 1616 | *(.ctors) | ||
| 1617 | LONG(0) | ||
| 1618 | __CTOR_END__ = .; | ||
| 1619 | __DTOR_LIST__ = .; | ||
| 1620 | LONG((__DTOR_END__ - __DTOR_LIST__) / 4 - 2) | ||
| 1621 | *(.dtors) | ||
| 1622 | LONG(0) | ||
| 1623 | __DTOR_END__ = .; | ||
| 1624 | *(.lit) | ||
| 1625 | *(.shdata) | ||
| 1626 | } > ram | ||
| 1627 | .shbss SIZEOF(.text) + ADDR(.text) : { | ||
| 1628 | *(.shbss) | ||
| 1629 | } | ||
| 1630 | .talias : { } > ram | ||
| 1631 | .data : { | ||
| 1632 | *(.data) | ||
| 1633 | CONSTRUCTORS | ||
| 1634 | _edata = .; | ||
| 1635 | } > ram | ||
| 1636 | |||
| 1637 | .bss SIZEOF(.data) + ADDR(.data) : | ||
| 1638 | { | ||
| 1639 | __bss_start = ALIGN(0x8); | ||
| 1640 | *(.bss) | ||
| 1641 | *(COMMON) | ||
| 1642 | end = ALIGN(0x8); | ||
| 1643 | _end = ALIGN(0x8); | ||
| 1644 | __end = ALIGN(0x8); | ||
| 1645 | } | ||
| 1646 | .mstack : { } > ram | ||
| 1647 | .rstack : { } > ram | ||
| 1648 | .stab . (NOLOAD) : | ||
| 1649 | { | ||
| 1650 | [ .stab ] | ||
| 1651 | } | ||
| 1652 | .stabstr . (NOLOAD) : | ||
| 1653 | { | ||
| 1654 | [ .stabstr ] | ||
| 1655 | } | ||
| 1656 | } | ||
| 1657 | </pre></div> | ||
| 1658 | |||
| 1659 | <hr> | ||
| 1660 | </div> | ||
| 1661 | <div class="section" id="crt0_002eS"> | ||
| 1662 | <div class="header"> | ||
| 1663 | <p> | ||
| 1664 | Next: <a href="#glue_002ec" accesskey="n" rel="next">C based "glue" code.</a>, Previous: <a href="#idp_002eld" accesskey="p" rel="prev">Linker script for the IDP board</a>, Up: <a href="#Code-Listings" accesskey="u" rel="up">Code Listings</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1665 | </div> | ||
| 1666 | <span id="crt0_002eS-_002d-The-startup-file"></span><h3 class="section">A.2 crt0.S - The startup file</h3> | ||
| 1667 | |||
| 1668 | <div class="example"> | ||
| 1669 | <pre class="example">/* | ||
| 1670 | * crt0.S -- startup file for m68k-coff | ||
| 1671 | * | ||
| 1672 | */ | ||
| 1673 | |||
| 1674 | .title "crt0.S for m68k-coff" | ||
| 1675 | |||
| 1676 | /* These are predefined by new versions of GNU cpp. */ | ||
| 1677 | |||
| 1678 | #ifndef __USER_LABEL_PREFIX__ | ||
| 1679 | #define __USER_LABEL_PREFIX__ _ | ||
| 1680 | #endif | ||
| 1681 | |||
| 1682 | #ifndef __REGISTER_PREFIX__ | ||
| 1683 | #define __REGISTER_PREFIX__ | ||
| 1684 | #endif | ||
| 1685 | |||
| 1686 | /* ANSI concatenation macros. */ | ||
| 1687 | |||
| 1688 | #define CONCAT1(a, b) CONCAT2(a, b) | ||
| 1689 | #define CONCAT2(a, b) a ## b | ||
| 1690 | |||
| 1691 | /* Use the right prefix for global labels. */ | ||
| 1692 | |||
| 1693 | #define SYM(x) CONCAT1 (__USER_LABEL_PREFIX__, x) | ||
| 1694 | |||
| 1695 | /* Use the right prefix for registers. */ | ||
| 1696 | |||
| 1697 | #define REG(x) CONCAT1 (__REGISTER_PREFIX__, x) | ||
| 1698 | |||
| 1699 | #define d0 REG (d0) | ||
| 1700 | #define d1 REG (d1) | ||
| 1701 | #define d2 REG (d2) | ||
| 1702 | #define d3 REG (d3) | ||
| 1703 | #define d4 REG (d4) | ||
| 1704 | #define d5 REG (d5) | ||
| 1705 | #define d6 REG (d6) | ||
| 1706 | #define d7 REG (d7) | ||
| 1707 | #define a0 REG (a0) | ||
| 1708 | #define a1 REG (a1) | ||
| 1709 | #define a2 REG (a2) | ||
| 1710 | #define a3 REG (a3) | ||
| 1711 | #define a4 REG (a4) | ||
| 1712 | #define a5 REG (a5) | ||
| 1713 | #define a6 REG (a6) | ||
| 1714 | #define fp REG (fp) | ||
| 1715 | #define sp REG (sp) | ||
| 1716 | |||
| 1717 | /* | ||
| 1718 | * Set up some room for a stack. We just grab a chunk of memory. | ||
| 1719 | */ | ||
| 1720 | .set stack_size, 0x2000 | ||
| 1721 | .comm SYM (stack), stack_size | ||
| 1722 | |||
| 1723 | /* | ||
| 1724 | * Define an empty environment. | ||
| 1725 | */ | ||
| 1726 | .data | ||
| 1727 | .align 2 | ||
| 1728 | SYM (environ): | ||
| 1729 | .long 0 | ||
| 1730 | |||
| 1731 | .align 2 | ||
| 1732 | .text | ||
| 1733 | .global SYM (stack) | ||
| 1734 | |||
| 1735 | .global SYM (main) | ||
| 1736 | .global SYM (exit) | ||
| 1737 | /* | ||
| 1738 | * This really should be __bss_start, not SYM (__bss_start). | ||
| 1739 | */ | ||
| 1740 | .global __bss_start | ||
| 1741 | |||
| 1742 | /* | ||
| 1743 | * start -- set things up so the application will run. | ||
| 1744 | */ | ||
| 1745 | SYM (start): | ||
| 1746 | link a6, #-8 | ||
| 1747 | moveal #SYM (stack) + stack_size, sp | ||
| 1748 | |||
| 1749 | /* | ||
| 1750 | * zerobss -- zero out the bss section | ||
| 1751 | */ | ||
| 1752 | moveal #__bss_start, a0 | ||
| 1753 | moveal #SYM (end), a1 | ||
| 1754 | 1: | ||
| 1755 | movel #0, (a0) | ||
| 1756 | leal 4(a0), a0 | ||
| 1757 | cmpal a0, a1 | ||
| 1758 | bne 1b | ||
| 1759 | |||
| 1760 | /* | ||
| 1761 | * Call the main routine from the application to get it going. | ||
| 1762 | * main (argc, argv, environ) | ||
| 1763 | * We pass argv as a pointer to NULL. | ||
| 1764 | */ | ||
| 1765 | pea 0 | ||
| 1766 | pea SYM (environ) | ||
| 1767 | pea sp@(4) | ||
| 1768 | pea 0 | ||
| 1769 | jsr SYM (main) | ||
| 1770 | movel d0, sp@- | ||
| 1771 | |||
| 1772 | /* | ||
| 1773 | * _exit -- Exit from the application. Normally we cause a user trap | ||
| 1774 | * to return to the ROM monitor for another run. | ||
| 1775 | */ | ||
| 1776 | SYM (exit): | ||
| 1777 | trap #0 | ||
| 1778 | </pre></div> | ||
| 1779 | |||
| 1780 | <hr> | ||
| 1781 | </div> | ||
| 1782 | <div class="section" id="glue_002ec"> | ||
| 1783 | <div class="header"> | ||
| 1784 | <p> | ||
| 1785 | Next: <a href="#mvme_002eS" accesskey="n" rel="next">I/O assembler code sample</a>, Previous: <a href="#crt0_002eS" accesskey="p" rel="prev">crt0.S - The startup file</a>, Up: <a href="#Code-Listings" accesskey="u" rel="up">Code Listings</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 1786 | </div> | ||
| 1787 | <span id="C-based-_0022glue_0022-code_002e"></span><h3 class="section">A.3 C based "glue" code.</h3> | ||
| 1788 | |||
| 1789 | <div class="example"> | ||
| 1790 | <pre class="example"> | ||
| 1791 | |||
| 1792 | /* | ||
| 1793 | * glue.c -- all the code to make GCC and the libraries run on | ||
| 1794 | * a bare target board. These should work with any | ||
| 1795 | * target if inbyte() and outbyte() exist. | ||
| 1796 | */ | ||
| 1797 | |||
| 1798 | #include <sys/types.h> | ||
| 1799 | #include <sys/stat.h> | ||
| 1800 | #include <errno.h> | ||
| 1801 | #ifndef NULL | ||
| 1802 | #define NULL 0 | ||
| 1803 | #endif | ||
| 1804 | |||
| 1805 | /* FIXME: this is a hack till libc builds */ | ||
| 1806 | __main() | ||
| 1807 | { | ||
| 1808 | return; | ||
| 1809 | } | ||
| 1810 | |||
| 1811 | #undef errno | ||
| 1812 | int errno; | ||
| 1813 | |||
| 1814 | extern caddr_t _end; /* _end is set in the linker command file */ | ||
| 1815 | extern int outbyte(); | ||
| 1816 | extern unsigned char inbyte(); | ||
| 1817 | extern int havebyte(); | ||
| 1818 | |||
| 1819 | /* just in case, most boards have at least some memory */ | ||
| 1820 | #ifndef RAMSIZE | ||
| 1821 | # define RAMSIZE (caddr_t)0x100000 | ||
| 1822 | #endif | ||
| 1823 | |||
| 1824 | /* | ||
| 1825 | * read -- read bytes from the serial port. Ignore fd, since | ||
| 1826 | * we only have stdin. | ||
| 1827 | */ | ||
| 1828 | int | ||
| 1829 | read(fd, buf, nbytes) | ||
| 1830 | int fd; | ||
| 1831 | char *buf; | ||
| 1832 | int nbytes; | ||
| 1833 | { | ||
| 1834 | int i = 0; | ||
| 1835 | |||
| 1836 | for (i = 0; i < nbytes; i++) { | ||
| 1837 | *(buf + i) = inbyte(); | ||
| 1838 | if ((*(buf + i) == '\n') || (*(buf + i) == '\r')) { | ||
| 1839 | (*(buf + i)) = 0; | ||
| 1840 | break; | ||
| 1841 | } | ||
| 1842 | } | ||
| 1843 | return (i); | ||
| 1844 | } | ||
| 1845 | |||
| 1846 | /* | ||
| 1847 | * write -- write bytes to the serial port. Ignore fd, since | ||
| 1848 | * stdout and stderr are the same. Since we have no filesystem, | ||
| 1849 | * open will only return an error. | ||
| 1850 | */ | ||
| 1851 | int | ||
| 1852 | write(fd, buf, nbytes) | ||
| 1853 | int fd; | ||
| 1854 | char *buf; | ||
| 1855 | int nbytes; | ||
| 1856 | { | ||
| 1857 | int i; | ||
| 1858 | |||
| 1859 | for (i = 0; i < nbytes; i++) { | ||
| 1860 | if (*(buf + i) == '\n') { | ||
| 1861 | outbyte ('\r'); | ||
| 1862 | } | ||
| 1863 | outbyte (*(buf + i)); | ||
| 1864 | } | ||
| 1865 | return (nbytes); | ||
| 1866 | } | ||
| 1867 | |||
| 1868 | /* | ||
| 1869 | * open -- open a file descriptor. We don't have a filesystem, so | ||
| 1870 | * we return an error. | ||
| 1871 | */ | ||
| 1872 | int | ||
| 1873 | open(buf, flags, mode) | ||
| 1874 | char *buf; | ||
| 1875 | int flags; | ||
| 1876 | int mode; | ||
| 1877 | { | ||
| 1878 | errno = EIO; | ||
| 1879 | return (-1); | ||
| 1880 | } | ||
| 1881 | |||
| 1882 | /* | ||
| 1883 | * close -- close a file descriptor. We don't need | ||
| 1884 | * to do anything, but pretend we did. | ||
| 1885 | */ | ||
| 1886 | int | ||
| 1887 | close(fd) | ||
| 1888 | int fd; | ||
| 1889 | { | ||
| 1890 | return (0); | ||
| 1891 | } | ||
| 1892 | |||
| 1893 | /* | ||
| 1894 | * sbrk -- changes heap size size. Get nbytes more | ||
| 1895 | * RAM. We just increment a pointer in what's | ||
| 1896 | * left of memory on the board. | ||
| 1897 | */ | ||
| 1898 | caddr_t | ||
| 1899 | sbrk(nbytes) | ||
| 1900 | int nbytes; | ||
| 1901 | { | ||
| 1902 | static caddr_t heap_ptr = NULL; | ||
| 1903 | caddr_t base; | ||
| 1904 | |||
| 1905 | if (heap_ptr == NULL) { | ||
| 1906 | heap_ptr = (caddr_t)&_end; | ||
| 1907 | } | ||
| 1908 | |||
| 1909 | if ((RAMSIZE - heap_ptr) >= 0) { | ||
| 1910 | base = heap_ptr; | ||
| 1911 | heap_ptr += nbytes; | ||
| 1912 | return (base); | ||
| 1913 | } else { | ||
| 1914 | errno = ENOMEM; | ||
| 1915 | return ((caddr_t)-1); | ||
| 1916 | } | ||
| 1917 | } | ||
| 1918 | |||
| 1919 | /* | ||
| 1920 | * isatty -- returns 1 if connected to a terminal device, | ||
| 1921 | * returns 0 if not. Since we're hooked up to a | ||
| 1922 | * serial port, we'll say yes and return a 1. | ||
| 1923 | */ | ||
| 1924 | int | ||
| 1925 | isatty(fd) | ||
| 1926 | int fd; | ||
| 1927 | { | ||
| 1928 | return (1); | ||
| 1929 | } | ||
| 1930 | |||
| 1931 | /* | ||
| 1932 | * lseek -- move read/write pointer. Since a serial port | ||
| 1933 | * is non-seekable, we return an error. | ||
| 1934 | */ | ||
| 1935 | off_t | ||
| 1936 | lseek(fd, offset, whence) | ||
| 1937 | int fd; | ||
| 1938 | off_t offset; | ||
| 1939 | int whence; | ||
| 1940 | { | ||
| 1941 | errno = ESPIPE; | ||
| 1942 | return ((off_t)-1); | ||
| 1943 | } | ||
| 1944 | |||
| 1945 | /* | ||
| 1946 | * fstat -- get status of a file. Since we have no file | ||
| 1947 | * system, we just return an error. | ||
| 1948 | */ | ||
| 1949 | int | ||
| 1950 | fstat(fd, buf) | ||
| 1951 | int fd; | ||
| 1952 | struct stat *buf; | ||
| 1953 | { | ||
| 1954 | errno = EIO; | ||
| 1955 | return (-1); | ||
| 1956 | } | ||
| 1957 | |||
| 1958 | /* | ||
| 1959 | * getpid -- only one process, so just return 1. | ||
| 1960 | */ | ||
| 1961 | #define __MYPID 1 | ||
| 1962 | int | ||
| 1963 | getpid() | ||
| 1964 | { | ||
| 1965 | return __MYPID; | ||
| 1966 | } | ||
| 1967 | |||
| 1968 | /* | ||
| 1969 | * kill -- go out via exit... | ||
| 1970 | */ | ||
| 1971 | int | ||
| 1972 | kill(pid, sig) | ||
| 1973 | int pid; | ||
| 1974 | int sig; | ||
| 1975 | { | ||
| 1976 | if(pid == __MYPID) | ||
| 1977 | _exit(sig); | ||
| 1978 | return 0; | ||
| 1979 | } | ||
| 1980 | |||
| 1981 | /* | ||
| 1982 | * print -- do a raw print of a string | ||
| 1983 | */ | ||
| 1984 | int | ||
| 1985 | print(ptr) | ||
| 1986 | char *ptr; | ||
| 1987 | { | ||
| 1988 | while (*ptr) { | ||
| 1989 | outbyte (*ptr++); | ||
| 1990 | } | ||
| 1991 | } | ||
| 1992 | |||
| 1993 | /* | ||
| 1994 | * putnum -- print a 32 bit number in hex | ||
| 1995 | */ | ||
| 1996 | int | ||
| 1997 | putnum (num) | ||
| 1998 | unsigned int num; | ||
| 1999 | { | ||
| 2000 | char buffer[9]; | ||
| 2001 | int count; | ||
| 2002 | char *bufptr = buffer; | ||
| 2003 | int digit; | ||
| 2004 | |||
| 2005 | for (count = 7 ; count >= 0 ; count--) { | ||
| 2006 | digit = (num >> (count * 4)) & 0xf; | ||
| 2007 | |||
| 2008 | if (digit <= 9) | ||
| 2009 | *bufptr++ = (char) ('0' + digit); | ||
| 2010 | else | ||
| 2011 | *bufptr++ = (char) ('a' - 10 + digit); | ||
| 2012 | } | ||
| 2013 | |||
| 2014 | *bufptr = (char) 0; | ||
| 2015 | print (buffer); | ||
| 2016 | return; | ||
| 2017 | } | ||
| 2018 | </pre></div> | ||
| 2019 | |||
| 2020 | <hr> | ||
| 2021 | </div> | ||
| 2022 | <div class="section" id="mvme_002eS"> | ||
| 2023 | <div class="header"> | ||
| 2024 | <p> | ||
| 2025 | Next: <a href="#io_002ec" accesskey="n" rel="next">I/O code sample</a>, Previous: <a href="#glue_002ec" accesskey="p" rel="prev">C based "glue" code.</a>, Up: <a href="#Code-Listings" accesskey="u" rel="up">Code Listings</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 2026 | </div> | ||
| 2027 | <span id="I_002fO-assembler-code-sample"></span><h3 class="section">A.4 I/O assembler code sample</h3> | ||
| 2028 | |||
| 2029 | <div class="example"> | ||
| 2030 | <pre class="example">/* | ||
| 2031 | * mvme.S -- board support for m68k | ||
| 2032 | */ | ||
| 2033 | |||
| 2034 | .title "mvme.S for m68k-coff" | ||
| 2035 | |||
| 2036 | /* These are predefined by new versions of GNU cpp. */ | ||
| 2037 | |||
| 2038 | #ifndef __USER_LABEL_PREFIX__ | ||
| 2039 | #define __USER_LABEL_PREFIX__ _ | ||
| 2040 | #endif | ||
| 2041 | |||
| 2042 | #ifndef __REGISTER_PREFIX__ | ||
| 2043 | #define __REGISTER_PREFIX__ | ||
| 2044 | #endif | ||
| 2045 | |||
| 2046 | /* ANSI concatenation macros. */ | ||
| 2047 | |||
| 2048 | #define CONCAT1(a, b) CONCAT2(a, b) | ||
| 2049 | #define CONCAT2(a, b) a ## b | ||
| 2050 | |||
| 2051 | /* Use the right prefix for global labels. */ | ||
| 2052 | |||
| 2053 | #define SYM(x) CONCAT1 (__USER_LABEL_PREFIX__, x) | ||
| 2054 | |||
| 2055 | /* Use the right prefix for registers. */ | ||
| 2056 | |||
| 2057 | #define REG(x) CONCAT1 (__REGISTER_PREFIX__, x) | ||
| 2058 | |||
| 2059 | #define d0 REG (d0) | ||
| 2060 | #define d1 REG (d1) | ||
| 2061 | #define d2 REG (d2) | ||
| 2062 | #define d3 REG (d3) | ||
| 2063 | #define d4 REG (d4) | ||
| 2064 | #define d5 REG (d5) | ||
| 2065 | #define d6 REG (d6) | ||
| 2066 | #define d7 REG (d7) | ||
| 2067 | #define a0 REG (a0) | ||
| 2068 | #define a1 REG (a1) | ||
| 2069 | #define a2 REG (a2) | ||
| 2070 | #define a3 REG (a3) | ||
| 2071 | #define a4 REG (a4) | ||
| 2072 | #define a5 REG (a5) | ||
| 2073 | #define a6 REG (a6) | ||
| 2074 | #define fp REG (fp) | ||
| 2075 | #define sp REG (sp) | ||
| 2076 | #define vbr REG (vbr) | ||
| 2077 | |||
| 2078 | .align 2 | ||
| 2079 | .text | ||
| 2080 | .global SYM (_exit) | ||
| 2081 | .global SYM (outln) | ||
| 2082 | .global SYM (outbyte) | ||
| 2083 | .global SYM (putDebugChar) | ||
| 2084 | .global SYM (inbyte) | ||
| 2085 | .global SYM (getDebugChar) | ||
| 2086 | .global SYM (havebyte) | ||
| 2087 | .global SYM (exceptionHandler) | ||
| 2088 | |||
| 2089 | .set vbr_size, 0x400 | ||
| 2090 | .comm SYM (vbr_table), vbr_size | ||
| 2091 | |||
| 2092 | /* | ||
| 2093 | * inbyte -- get a byte from the serial port | ||
| 2094 | * d0 - contains the byte read in | ||
| 2095 | */ | ||
| 2096 | .align 2 | ||
| 2097 | SYM (getDebugChar): /* symbol name used by m68k-stub */ | ||
| 2098 | SYM (inbyte): | ||
| 2099 | link a6, #-8 | ||
| 2100 | trap #15 | ||
| 2101 | .word inchr | ||
| 2102 | moveb sp@, d0 | ||
| 2103 | extbl d0 | ||
| 2104 | unlk a6 | ||
| 2105 | rts | ||
| 2106 | |||
| 2107 | /* | ||
| 2108 | * outbyte -- sends a byte out the serial port | ||
| 2109 | * d0 - contains the byte to be sent | ||
| 2110 | */ | ||
| 2111 | .align 2 | ||
| 2112 | SYM (putDebugChar): /* symbol name used by m68k-stub */ | ||
| 2113 | SYM (outbyte): | ||
| 2114 | link fp, #-4 | ||
| 2115 | moveb fp@(11), sp@ | ||
| 2116 | trap #15 | ||
| 2117 | .word outchr | ||
| 2118 | unlk fp | ||
| 2119 | rts | ||
| 2120 | |||
| 2121 | /* | ||
| 2122 | * outln -- sends a string of bytes out the serial port with a CR/LF | ||
| 2123 | * a0 - contains the address of the string's first byte | ||
| 2124 | * a1 - contains the address of the string's last byte | ||
| 2125 | */ | ||
| 2126 | .align 2 | ||
| 2127 | SYM (outln): | ||
| 2128 | link a6, #-8 | ||
| 2129 | moveml a0/a1, sp@ | ||
| 2130 | trap #15 | ||
| 2131 | .word outln | ||
| 2132 | unlk a6 | ||
| 2133 | rts | ||
| 2134 | |||
| 2135 | /* | ||
| 2136 | * outstr -- sends a string of bytes out the serial port without a CR/LF | ||
| 2137 | * a0 - contains the address of the string's first byte | ||
| 2138 | * a1 - contains the address of the string's last byte | ||
| 2139 | */ | ||
| 2140 | .align 2 | ||
| 2141 | SYM (outstr): | ||
| 2142 | link a6, #-8 | ||
| 2143 | moveml a0/a1, sp@ | ||
| 2144 | trap #15 | ||
| 2145 | .word outstr | ||
| 2146 | unlk a6 | ||
| 2147 | rts | ||
| 2148 | |||
| 2149 | /* | ||
| 2150 | * havebyte -- checks to see if there is a byte in the serial port, | ||
| 2151 | * returns 1 if there is a byte, 0 otherwise. | ||
| 2152 | */ | ||
| 2153 | SYM (havebyte): | ||
| 2154 | trap #15 | ||
| 2155 | .word instat | ||
| 2156 | beqs empty | ||
| 2157 | movel #1, d0 | ||
| 2158 | rts | ||
| 2159 | empty: | ||
| 2160 | movel #0, d0 | ||
| 2161 | rts | ||
| 2162 | |||
| 2163 | /* | ||
| 2164 | * These constants are for the MVME-135 board's boot monitor. They | ||
| 2165 | * are used with a TRAP #15 call to access the monitor's I/O routines. | ||
| 2166 | * they must be in the word following the trap call. | ||
| 2167 | */ | ||
| 2168 | .set inchr, 0x0 | ||
| 2169 | .set instat, 0x1 | ||
| 2170 | .set inln, 0x2 | ||
| 2171 | .set readstr, 0x3 | ||
| 2172 | .set readln, 0x4 | ||
| 2173 | .set chkbrk, 0x5 | ||
| 2174 | |||
| 2175 | .set outchr, 0x20 | ||
| 2176 | .set outstr, 0x21 | ||
| 2177 | .set outln, 0x22 | ||
| 2178 | .set write, 0x23 | ||
| 2179 | .set writeln, 0x24 | ||
| 2180 | .set writdln, 0x25 | ||
| 2181 | .set pcrlf, 0x26 | ||
| 2182 | .set eraseln, 0x27 | ||
| 2183 | .set writd, 0x28 | ||
| 2184 | .set sndbrk, 0x29 | ||
| 2185 | |||
| 2186 | .set tm_ini, 0x40 | ||
| 2187 | .set dt_ini, 0x42 | ||
| 2188 | .set tm_disp, 0x43 | ||
| 2189 | .set tm_rd, 0x44 | ||
| 2190 | |||
| 2191 | .set redir, 0x60 | ||
| 2192 | .set redir_i, 0x61 | ||
| 2193 | .set redir_o, 0x62 | ||
| 2194 | .set return, 0x63 | ||
| 2195 | .set bindec, 0x64 | ||
| 2196 | |||
| 2197 | .set changev, 0x67 | ||
| 2198 | .set strcmp, 0x68 | ||
| 2199 | .set mulu32, 0x69 | ||
| 2200 | .set divu32, 0x6A | ||
| 2201 | .set chk_sum, 0x6B | ||
| 2202 | |||
| 2203 | </pre></div> | ||
| 2204 | |||
| 2205 | <hr> | ||
| 2206 | </div> | ||
| 2207 | <div class="section" id="io_002ec"> | ||
| 2208 | <div class="header"> | ||
| 2209 | <p> | ||
| 2210 | Next: <a href="#leds_002ec" accesskey="n" rel="next">Led control sample</a>, Previous: <a href="#mvme_002eS" accesskey="p" rel="prev">I/O assembler code sample</a>, Up: <a href="#Code-Listings" accesskey="u" rel="up">Code Listings</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 2211 | </div> | ||
| 2212 | <span id="I_002fO-code-sample"></span><h3 class="section">A.5 I/O code sample</h3> | ||
| 2213 | |||
| 2214 | <div class="example"> | ||
| 2215 | <pre class="example">#include "w89k.h" | ||
| 2216 | |||
| 2217 | /* | ||
| 2218 | * outbyte -- shove a byte out the serial port. We wait till the byte | ||
| 2219 | */ | ||
| 2220 | int | ||
| 2221 | outbyte(byte) | ||
| 2222 | unsigned char byte; | ||
| 2223 | { | ||
| 2224 | while ((inp(RS232REG) & TRANSMIT) == 0x0) { } ; | ||
| 2225 | return (outp(RS232PORT, byte)); | ||
| 2226 | } | ||
| 2227 | |||
| 2228 | /* | ||
| 2229 | * inbyte -- get a byte from the serial port | ||
| 2230 | */ | ||
| 2231 | unsigned char | ||
| 2232 | inbyte() | ||
| 2233 | { | ||
| 2234 | while ((inp(RS232REG) & RECEIVE) == 0x0) { }; | ||
| 2235 | return (inp(RS232PORT)); | ||
| 2236 | } | ||
| 2237 | </pre></div> | ||
| 2238 | |||
| 2239 | <hr> | ||
| 2240 | </div> | ||
| 2241 | <div class="section" id="leds_002ec"> | ||
| 2242 | <div class="header"> | ||
| 2243 | <p> | ||
| 2244 | Previous: <a href="#io_002ec" accesskey="p" rel="prev">I/O code sample</a>, Up: <a href="#Code-Listings" accesskey="u" rel="up">Code Listings</a> [<a href="#SEC_Contents" title="Table of contents" rel="contents">Contents</a>]</p> | ||
| 2245 | </div> | ||
| 2246 | <span id="Led-control-sample"></span><h3 class="section">A.6 Led control sample</h3> | ||
| 2247 | |||
| 2248 | <div class="example"> | ||
| 2249 | <pre class="example">/* | ||
| 2250 | * leds.h -- control the led's on a Motorola mc68ec0x0 board. | ||
| 2251 | */ | ||
| 2252 | |||
| 2253 | #ifndef __LEDS_H__ | ||
| 2254 | #define __LEDS_H__ | ||
| 2255 | |||
| 2256 | #define LED_ADDR 0xd00003 | ||
| 2257 | #define LED_0 ~0x1 | ||
| 2258 | #define LED_1 ~0x2 | ||
| 2259 | #define LED_2 ~0x4 | ||
| 2260 | #define LED_3 ~0x8 | ||
| 2261 | #define LED_4 ~0x10 | ||
| 2262 | #define LED_5 ~0x20 | ||
| 2263 | #define LED_6 ~0x40 | ||
| 2264 | #define LED_7 ~0x80 | ||
| 2265 | #define LEDS_OFF 0xff | ||
| 2266 | #define LEDS_ON 0x0 | ||
| 2267 | |||
| 2268 | #define FUDGE(x) ((x >= 0xa && x <= 0xf) ? (x + 'a') & 0x7f : (x + '0') & 0x7f) | ||
| 2269 | |||
| 2270 | extern void led_putnum( char ); | ||
| 2271 | |||
| 2272 | #endif /* __LEDS_H__ */ | ||
| 2273 | |||
| 2274 | /* | ||
| 2275 | * leds.c -- control the led's on a Motorola mc68ec0x0 (IDP)board. | ||
| 2276 | */ | ||
| 2277 | #include "leds.h" | ||
| 2278 | |||
| 2279 | void zylons(); | ||
| 2280 | void led_putnum(); | ||
| 2281 | |||
| 2282 | /* | ||
| 2283 | * led_putnum -- print a hex number on the LED. the value of num must be a char with | ||
| 2284 | * the ascii value. ie... number 0 is '0', a is 'a', ' ' (null) clears | ||
| 2285 | * the led display. | ||
| 2286 | * Setting the bit to 0 turns it on, 1 turns it off. | ||
| 2287 | * the LED's are controlled by setting the right bit mask in the base | ||
| 2288 | * address. | ||
| 2289 | * The bits are: | ||
| 2290 | * [d.p | g | f | e | d | c | b | a ] is the byte. | ||
| 2291 | * | ||
| 2292 | * The locations are: | ||
| 2293 | * | ||
| 2294 | * a | ||
| 2295 | * ----- | ||
| 2296 | * f | | b | ||
| 2297 | * | g | | ||
| 2298 | * ----- | ||
| 2299 | * | | | ||
| 2300 | * e | | c | ||
| 2301 | * ----- | ||
| 2302 | * d . d.p (decimal point) | ||
| 2303 | */ | ||
| 2304 | void | ||
| 2305 | led_putnum ( num ) | ||
| 2306 | char num; | ||
| 2307 | { | ||
| 2308 | static unsigned char *leds = (unsigned char *)LED_ADDR; | ||
| 2309 | static unsigned char num_bits [18] = { | ||
| 2310 | 0xff, /* clear all */ | ||
| 2311 | 0xc0, 0xf9, 0xa4, 0xb0, 0x99, 0x92, 0x82, 0xf8, 0x80, 0x98, /* numbers 0-9 */ | ||
| 2312 | 0x98, 0x20, 0x3, 0x27, 0x21, 0x4, 0xe /* letters a-f */ | ||
| 2313 | }; | ||
| 2314 | |||
| 2315 | if (num >= '0' && num <= '9') | ||
| 2316 | num = (num - '0') + 1; | ||
| 2317 | |||
| 2318 | if (num >= 'a' && num <= 'f') | ||
| 2319 | num = (num - 'a') + 12; | ||
| 2320 | |||
| 2321 | if (num == ' ') | ||
| 2322 | num = 0; | ||
| 2323 | |||
| 2324 | *leds = num_bits[num]; | ||
| 2325 | } | ||
| 2326 | |||
| 2327 | /* | ||
| 2328 | * zylons -- draw a rotating pattern. NOTE: this function never returns. | ||
| 2329 | */ | ||
| 2330 | void | ||
| 2331 | zylons() | ||
| 2332 | { | ||
| 2333 | unsigned char *leds = (unsigned char *)LED_ADDR; | ||
| 2334 | unsigned char curled = 0xfe; | ||
| 2335 | |||
| 2336 | while (1) | ||
| 2337 | { | ||
| 2338 | *leds = curled; | ||
| 2339 | curled = (curled >> 1) | (curled << 7); | ||
| 2340 | delay ( 200 ); | ||
| 2341 | } | ||
| 2342 | } | ||
| 2343 | </pre></div> | ||
| 2344 | |||
| 2345 | </div> | ||
| 2346 | </div> | ||
| 2347 | </div> | ||
| 2348 | |||
| 2349 | |||
| 2350 | |||
| 2351 | </body> | ||
| 2352 | </html> | ||