qi-hardware
/
iris
mirror of git://projects.qi-hardware.com/iris.git
1
0
Fork 0
Code

new directory organization

This commit is contained in:
Bas Wijnen 2013-05-14 18:30:50 -04:00
parent b06e011a07
commit fa021a80f0
62 changed files with 133 additions and 2572 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

676
GPL-3
View File

@ -1,676 +0,0 @@
GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
Preamble
The GNU General Public License is a free, copyleft license for
software and other kinds of works.
The licenses for most software and other practical works are designed
to take away your freedom to share and change the works. By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users. We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors. You can apply it to
your programs, too.
When we speak of free software, we are referring to freedom, not
price. Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.
To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights. Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.
For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received. You must make sure that they, too, receive
or can get the source code. And you must show them these terms so they
know their rights.
Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.
For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software. For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.
Some devices are designed to deny users access to install or run
modified versions of the software inside them, although the manufacturer
can do so. This is fundamentally incompatible with the aim of
protecting users' freedom to change the software. The systematic
pattern of such abuse occurs in the area of products for individuals to
use, which is precisely where it is most unacceptable. Therefore, we
have designed this version of the GPL to prohibit the practice for those
products. If such problems arise substantially in other domains, we
stand ready to extend this provision to those domains in future versions
of the GPL, as needed to protect the freedom of users.
Finally, every program is threatened constantly by software patents.
States should not allow patents to restrict development and use of
software on general-purpose computers, but in those that do, we wish to
avoid the special danger that patents applied to a free program could
make it effectively proprietary. To prevent this, the GPL assures that
patents cannot be used to render the program non-free.
The precise terms and conditions for copying, distribution and
modification follow.
TERMS AND CONDITIONS
0. Definitions.
"This License" refers to version 3 of the GNU General Public License.
"Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.
"The Program" refers to any copyrightable work licensed under this
License. Each licensee is addressed as "you". "Licensees" and
"recipients" may be individuals or organizations.
To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy. The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.
A "covered work" means either the unmodified Program or a work based
on the Program.
To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy. Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.
To "convey" a work means any kind of propagation that enables other
parties to make or receive copies. Mere interaction with a user through
a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License. If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.
1. Source Code.
The "source code" for a work means the preferred form of the work
for making modifications to it. "Object code" means any non-source
form of a work.
A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.
The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form. A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.
The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities. However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work. For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.
The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding
Source.
The Corresponding Source for a work in source code form is that
same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met. This License explicitly affirms your unlimited
permission to run the unmodified Program. The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work. This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force. You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright. Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under
the conditions stated below. Sublicensing is not allowed; section 10
makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such
measures.
When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work's
users, your or third parties' legal rights to forbid circumvention of
technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified
it, and giving a relevant date.
b) The work must carry prominent notices stating that it is
released under this License and any conditions added under section
7. This requirement modifies the requirement in section 4 to
"keep intact all notices".
c) You must license the entire work, as a whole, under this
License to anyone who comes into possession of a copy. This
License will therefore apply, along with any applicable section 7
additional terms, to the whole of the work, and all its parts,
regardless of how they are packaged. This License gives no
permission to license the work in any other way, but it does not
invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display
Appropriate Legal Notices; however, if the Program has interactive
interfaces that do not display Appropriate Legal Notices, your
work need not make them do so.
A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit. Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:
a) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by the
Corresponding Source fixed on a durable physical medium
customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product
(including a physical distribution medium), accompanied by a
written offer, valid for at least three years and valid for as
long as you offer spare parts or customer support for that product
model, to give anyone who possesses the object code either (1) a
copy of the Corresponding Source for all the software in the
product that is covered by this License, on a durable physical
medium customarily used for software interchange, for a price no
more than your reasonable cost of physically performing this
conveying of source, or (2) access to copy the
Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the
written offer to provide the Corresponding Source. This
alternative is allowed only occasionally and noncommercially, and
only if you received the object code with such an offer, in accord
with subsection 6b.
d) Convey the object code by offering access from a designated
place (gratis or for a charge), and offer equivalent access to the
Corresponding Source in the same way through the same place at no
further charge. You need not require recipients to copy the
Corresponding Source along with the object code. If the place to
copy the object code is a network server, the Corresponding Source
may be on a different server (operated by you or a third party)
that supports equivalent copying facilities, provided you maintain
clear directions next to the object code saying where to find the
Corresponding Source. Regardless of what server hosts the
Corresponding Source, you remain obligated to ensure that it is
available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided
you inform other peers where the object code and Corresponding
Source of the work are being offered to the general public at no
charge under subsection 6d.
A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.
A "User Product" is either (1) a "consumer product", which means any
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling. In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage. For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product. A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.
"Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source. The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.
If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information. But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).
The requirement to provide Installation Information does not include a
requirement to continue to provide support service, warranty, or updates
for a work that has been modified or installed by the recipient, or for
the User Product in which it has been modified or installed. Access to a
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.
7. Additional Terms.
"Additional permissions" are terms that supplement the terms of this
License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program shall
be treated as though they were included in this License, to the extent
that they are valid under applicable law. If additional permissions
apply only to part of the Program, that part may be used separately
under those permissions, but the entire Program remains governed by
this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it. (Additional permissions may be written to require their own
removal in certain cases when you modify the work.) You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the
terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or
author attributions in that material or in the Appropriate Legal
Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or
requiring that modified versions of such material be marked in
reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or
authors of the material; or
e) Declining to grant rights under trademark law for use of some
trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that
material by anyone who conveys the material (or modified versions of
it) with contractual assumptions of liability to the recipient, for
any liability that these contractual assumptions directly impose on
those licensors and authors.
All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10. If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term. If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the
form of a separately written license, or stated as exceptions;
the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly
provided under this License. Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).
However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.
Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License. If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or
run a copy of the Program. Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance. However,
nothing other than this License grants you permission to propagate or
modify any covered work. These actions infringe copyright if you do
not accept this License. Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License. You are not responsible
for enforcing compliance by third parties with this License.
An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations. If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License. For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.
11. Patents.
A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based. The
work thus licensed is called the contributor's "contributor version".
A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired or
hereafter acquired, that would be infringed by some manner, permitted
by this License, of making, using, or selling its contributor version,
but do not include claims that would be infringed only as a
consequence of further modification of the contributor version. For
purposes of this definition, "control" includes the right to grant
patent sublicenses in a manner consistent with the requirements of
this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify and
propagate the contents of its contributor version.
In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a patent
(such as an express permission to practice a patent or covenant not to
sue for patent infringement). To "grant" such a patent license to a
party means to make such an agreement or commitment not to enforce a
patent against the party.
If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through a
publicly available network server or other readily accessible means,
then you must either (1) cause the Corresponding Source to be so
available, or (2) arrange to deprive yourself of the benefit of the
patent license for this particular work, or (3) arrange, in a manner
consistent with the requirements of this License, to extend the patent
license to downstream recipients. "Knowingly relying" means you have
actual knowledge that, but for the patent license, your conveying the
covered work in a country, or your recipient's use of the covered work
in a country, would infringe one or more identifiable patents in that
country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.
A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License. You may not convey a covered
work if you are a party to an arrangement with a third party that is
in the business of distributing software, under which you make payment
to the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License. If you cannot convey a
covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may
not convey it at all. For example, if you agree to terms that obligate you
to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program.
13. Use with the GNU Affero General Public License.
Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work. The terms of this
License will continue to apply to the part which is the covered work,
but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the
combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of
the GNU General Public License from time to time. Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.
Each version is given a distinguishing version number. If the
Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation. If the Program does not specify a version number of the
GNU General Public License, you may choose any version ever published
by the Free Software Foundation.
If the Program specifies that a proxy can decide which future
versions of the GNU General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you
to choose that version for the Program.
Later license versions may give you additional or different
permissions. However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow a
later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:
<program> Copyright (C) <year> <name of author>
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License. Of course, your program's commands
might be different; for a GUI interface, you would use an "about box".
You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see
<http://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your program
into proprietary programs. If your program is a subroutine library, you
may consider it more useful to permit linking proprietary applications with
the library. If this is what you want to do, use the GNU Lesser General
Public License instead of this License. But first, please read
<http://www.gnu.org/philosophy/why-not-lgpl.html>.

129
Makefile.am
View File

@ -27,29 +27,29 @@ objcopyflags = -S $(addprefix --remove-section=.,$(junk))
start_load = 0x80003000
load = 0x80000000
noinst_DATA = iris.raw mips/start.raw mips/start-hack.S mips/nanonote/sdram-setup.raw
noinst_PROGRAMS = iris.elf mips/start.elf mips/nanonote/sdram-setup.elf
noinst_DATA = iris.raw mips/start.raw mips/start-hack.S mips/board/sdram-setup.raw
noinst_PROGRAMS = iris.elf mips/start.elf mips/board/sdram-setup.elf
%.raw: %.elf
$(OBJCOPY) $(objcopyflags) -Obinary $< $@
# Define boot_threads depending on selected mode.
if UDC
boot_threads = udc
boot_threads = hardware/udc
else
if UNBRICK
boot_threads = sdmmc usbmassstorage
boot_threads = hardware/sdmmc glue/usbmassstorage
else
boot_threads = sdmmc partition fat
boot_threads = hardware/sdmmc glue/partition glue/fat
noinst_DATA += iris.tar.gz
endif
endif
# Threadlist must be the last file on the line below.
iris_sources = panic.cc data.cc alloc.cc memory.cc invoke.cc schedule.cc mips/interrupts.cc mips/arch.cc threadlist.S
boot_sources = mips/init.cc mips/nanonote/board.cc
headers = kernel.hh iris.hh devices.hh ui.hh keys.hh mips/arch.hh mips/nanonote/jz4740.hh mips/nanonote/board.hh mips/nand.hh
iris_elf_CPPFLAGS = -O5 -fno-inline -I. -Imips -Imips/nanonote -Wa,-mips32 -DNANONOTE -DUSE_SERIAL
iris_sources = kernel/panic.cc kernel/data.cc kernel/alloc.cc kernel/memory.cc kernel/invoke.cc kernel/schedule.cc mips/interrupts.cc mips/arch.cc source/boot/threadlist.S
boot_sources = mips/init.cc mips/board/board.cc
headers = include/kernel.hh include/iris.hh include/devices.hh include/ui.hh include/keys.hh mips/arch.hh mips/board/jz4740.hh mips/board/board.hh mips/nand.hh
iris_elf_CPPFLAGS = -O5 -fno-inline -Iinclude -Imips -Imips/board -Wa,-mips32 -DNANONOTE -DUSE_SERIAL
iris_elf_CXXFLAGS = -Wno-unused-parameter -fno-strict-aliasing -fno-builtin -ggdb3
iris_elf_LDFLAGS = -Wl,--omagic -Wl,-Ttext -Wl,$(load) -nostdlib
iris_elf_SOURCES = mips/entry.S ${iris_sources} mips/boot.S ${boot_sources} ${headers}
@ -61,35 +61,35 @@ mips_start_elf_SOURCES = mips/start-hack.S iris.raw
mips/start-hack.S: mips/start.S iris.raw
cp $< $@
mips_nanonote_sdram_setup_elf_DEPENDENCIES = mips/nanonote/sdram-setup.ld
mips_nanonote_sdram_setup_elf_CPPFLAGS = -O5 -fno-inline -I. -Imips -Imips/nanonote -Wa,-mips32
mips_nanonote_sdram_setup_elf_CXXFLAGS = -Wno-unused-parameter -fno-strict-aliasing -fno-builtin -ggdb3
mips_nanonote_sdram_setup_elf_LDFLAGS = -Wl,--omagic -Wl,-T -Wl,mips/nanonote/sdram-setup.ld -nostdlib
mips_nanonote_sdram_setup_elf_SOURCES = mips/nanonote/sdram-setup.cc
mips_board_sdram_setup_elf_DEPENDENCIES = mips/board/sdram-setup.ld
mips_board_sdram_setup_elf_CPPFLAGS = -O5 -fno-inline -Iinclude -Imips -Imips/board -Wa,-mips32
mips_board_sdram_setup_elf_CXXFLAGS = -Wno-unused-parameter -fno-strict-aliasing -fno-builtin -ggdb3
mips_board_sdram_setup_elf_LDFLAGS = -Wl,--omagic -Wl,-T -Wl,mips/board/sdram-setup.ld -nostdlib
mips_board_sdram_setup_elf_SOURCES = mips/board/sdram-setup.cc
program_targets = \
source/alarm.elf \
source/ball.elf \
source/boot.elf \
source/booter.elf \
source/bootinit.elf \
source/bsquare.elf \
source/buzzer.elf \
source/init.elf \
source/boot.elf \
source/gpio.elf \
source/lcd.elf \
source/nand.elf \
source/rtc.elf \
source/sdmmc.elf \
source/udc.elf \
source/elfrun.elf \
source/fat.elf \
source/font.elf \
source/gpio.elf \
source/gui.elf \
source/init.elf \
source/lcd.elf \
source/metronome.elf \
source/nand.elf \
source/partition.elf \
source/rtc.elf \
source/sdmmc.elf \
source/test.elf \
source/udc.elf \
source/usbmassstorage.elf
source/usbmassstorage.elf \
source/alarm.elf \
source/ball.elf \
source/booter.elf \
source/bsquare.elf \
source/buzzer.elf \
source/metronome.elf \
source/test.elf
fs_targets = \
fs/alarm.elf \
@ -117,14 +117,14 @@ fs_targets = \
noinst_PROGRAMS += $(program_targets)
noinst_DATA += $(fs_targets)
AM_CPPFLAGS = -O5 -fno-inline -I. -I./mips -I./mips/nanonote -Wa,-mips32 -DNANONOTE
AM_CPPFLAGS = -O5 -fno-inline -Iinclude -Imips -Imips/board -Wa,-mips32 -DNANONOTE
AM_CXXFLAGS = -Wno-unused-parameter -fno-strict-aliasing -fno-builtin -ggdb3
AM_LDFLAGS = -nostdlib
BUILT_SOURCES = $(headers) source/charset.data server
BUILT_SOURCES = $(headers) source/data/charset.data server
threadlist.S: mkthreadlist Makefile $(addprefix fs/,$(addsuffix .elf,bootinit $(boot_threads)))
$(top_srcdir)/$< bootinit $(boot_threads) > $@
source/boot/threadlist.S: source/boot/mkthreadlist Makefile $(addprefix fs/,$(addsuffix .elf,bootinit $(notdir $(boot_threads))))
$< bootinit $(boot_threads) > $@
PYPP = /usr/bin/pypp
%.cc: %.ccp
@ -132,45 +132,50 @@ PYPP = /usr/bin/pypp
%.hh: %.hhp
$(PYPP) --name $< < $< > $@
source/charset.data: source/charset
source/data/charset.data: source/data/charset
$< > $@
fs/font.dat: courier-10+8+32.png makefont
./makefont $< > $@
fs/%: %
fs/font.dat: source/data/courier-10+8+32.png source/data/makefont
source/data/makefont $< > $@
fs/init.config: source/data/init.config
ln -s ../$< $@
fs/%.elf: source/%.elf
mkdir -p fs
$(OBJCOPY) -S $< $@
source_alarm_elf_SOURCES = source/crt0.cc source/alarm.cc ${headers}
source_ball_elf_SOURCES = source/crt0.cc source/ball.cc ${headers}
source_boot_elf_SOURCES = source/crt0.cc source/boot.cc ${headers}
source_booter_elf_SOURCES = source/crt0.cc source/booter.cc ${headers}
source_bootinit_elf_SOURCES = source/crt0.cc source/bootinit.cc ${headers}
source_bsquare_elf_SOURCES = source/crt0.cc source/bsquare.cc ${headers}
source_buzzer_elf_SOURCES = source/crt0.cc source/buzzer.cc ${headers}
source_elfrun_elf_SOURCES = source/crt0.cc source/elfrun.cc ${headers}
source_fat_elf_SOURCES = source/crt0.cc source/fat.cc ${headers}
source_font_elf_SOURCES = source/crt0.cc source/font.cc ${headers}
source_gpio_elf_SOURCES = source/crt0.cc source/gpio.cc ${headers}
source_gui_elf_SOURCES = source/crt0.cc source/gui.cc ${headers}
source_init_elf_SOURCES = source/crt0.cc source/init.cc ${headers}
source_lcd_elf_SOURCES = source/crt0.cc source/lcd.cc ${headers}
source_metronome_elf_SOURCES = source/crt0.cc source/metronome.cc ${headers}
source_nand_elf_SOURCES = source/crt0.cc source/nand.cc ${headers}
source_partition_elf_SOURCES = source/crt0.cc source/partition.cc ${headers}
source_rtc_elf_SOURCES = source/crt0.cc source/rtc.cc ${headers}
source_sdmmc_elf_SOURCES = source/crt0.cc source/sdmmc.cc ${headers}
source_test_elf_SOURCES = source/crt0.cc source/test.cc ${headers}
source_udc_elf_SOURCES = source/crt0.cc source/udc.cc ${headers}
source_usbmassstorage_elf_SOURCES = source/crt0.cc source/usbmassstorage.cc ${headers}
source_bootinit_elf_SOURCES = source/boot/crt0.cc source/boot/bootinit.cc ${headers}
source_init_elf_SOURCES = source/boot/crt0.cc source/boot/init.cc ${headers}
source_boot_elf_SOURCES = source/boot/crt0.cc source/hardware/boot.cc ${headers}
source_buzzer_elf_SOURCES = source/boot/crt0.cc source/hardware/buzzer.cc ${headers}
source_gpio_elf_SOURCES = source/boot/crt0.cc source/hardware/gpio.cc ${headers}
source_lcd_elf_SOURCES = source/boot/crt0.cc source/hardware/lcd.cc ${headers}
source_nand_elf_SOURCES = source/boot/crt0.cc source/hardware/nand.cc ${headers}
source_rtc_elf_SOURCES = source/boot/crt0.cc source/hardware/rtc.cc ${headers}
source_sdmmc_elf_SOURCES = source/boot/crt0.cc source/hardware/sdmmc.cc ${headers}
source_udc_elf_SOURCES = source/boot/crt0.cc source/hardware/udc.cc ${headers}
#source_buffer_elf_SOURCES = source/boot/crt0.cc source/glue/buffer.cc ${headers}
source_elfrun_elf_SOURCES = source/boot/crt0.cc source/glue/elfrun.cc ${headers}
source_fat_elf_SOURCES = source/boot/crt0.cc source/glue/fat.cc ${headers}
source_font_elf_SOURCES = source/boot/crt0.cc source/glue/font.cc ${headers}
source_gui_elf_SOURCES = source/boot/crt0.cc source/glue/gui.cc ${headers}
source_partition_elf_SOURCES = source/boot/crt0.cc source/glue/partition.cc ${headers}
source_usbmassstorage_elf_SOURCES = source/boot/crt0.cc source/glue/usbmassstorage.cc ${headers}
source_metronome_elf_SOURCES = source/boot/crt0.cc source/application/metronome.cc ${headers}
source_test_elf_SOURCES = source/boot/crt0.cc source/application/test.cc ${headers}
source_alarm_elf_SOURCES = source/boot/crt0.cc source/application/alarm.cc ${headers}
source_ball_elf_SOURCES = source/boot/crt0.cc source/application/ball.cc ${headers}
source_booter_elf_SOURCES = source/boot/crt0.cc source/application/booter.cc ${headers}
source_bsquare_elf_SOURCES = source/boot/crt0.cc source/application/bsquare.cc ${headers}
server:
test -e native/Makefile || native/autogen.sh
$(MAKE) -C native
# This target is meaningless for SD boot mode.
test: mips/start.raw mips/start.elf server mips/nanonote/sdram-setup.raw fs/init.config fs/font.dat
test: mips/start.raw mips/start.elf server mips/board/sdram-setup.raw fs/init.config fs/font.dat
echo shutdown | nc localhost 5050 || true
native/usb-server
echo 'reboot $(start_load) 0x$(shell /bin/sh -c '$(OBJDUMP) -t mips/start.elf | grep __start$$ | cut -b1-8') mips/start.raw' | nc localhost 5050
@ -213,4 +218,4 @@ debug:
autoclean: maintainer-clean
$(MAKE) -C native autoclean
rm -rf aclocal.m4 configure depcomp fs install-sh iris.raw iris-sd.tar Makefile.in missing $(iris_sources) $(boot_sources) $(sources) $(headers) mips/start-hack.S mips/start.raw
rm -rf aclocal.m4 configure depcomp fs install-sh iris.raw iris-sd.tar Makefile.in missing $(iris_sources) $(boot_sources) $(sources) $(headers) mips/start-hack.S mips/start.raw mips/start.raw.gz source/data/charset.data iris.tar.gz

37
README.build
View File

@ -1,37 +0,0 @@
Building Iris.
For building, you will need:
- A compiler to create mips binaries. Unless you run on a mips platform, which
is unlikely, that means a cross-compiler.
- The pythonic preprocessor, pypp.
- Python
- mkimage, from the Debian package uboot-mkimage.
The last two can simply be installed using your favorite package manager. For
the cross compiler, please follow the instructions from
report/cross-compiler.tex.
Pypp can be downloaded using
svn co http://a82-93-13-222.adsl.xs4all.nl/svn/trunk/pypp
To build, it needs libshevek, which can be downloaded with
svn co http://a82-93-13-222.adsl.xs4all.nl/svn/trunk/libshevek
For both of them, dpkg-buildpackage -uc -us in their directory creates a Debian
package which can be installed. Install libshevek*deb before building pypp.
If you are not using Debian, use
autoreconf -f -i -s
./configure --prefix=/usr
make
make install
When all is installed, "make" should be enough to create "uimage". To use it,
make the first partition of an SD card (it really must be SD; MMC does not
work) smaller than 32 MB; I use 16 MB myself. Format it as FAT and copy uimage
to it. Then insert it in the Trendtac (it fits upside down) and boot with
Fn+left Ctrl+left Shift pressed. When caps and scroll lock are flashing, Iris
is booting (the flashing lights are from uboot, not from Iris, but they
indicate that the SD image is used). Then you can release the keys.
If anything doesn't work, or you have other comments, please send a message to
Bas Wijnen <wijnen@debian.org>. Thanks.

6
autogen.sh
View File

@ -1,3 +1,7 @@
#!/bin/sh
autoreconf --force --install --symlink
./configure --host mipsel-linux-gnu "$@"
if [ $# -eq 0 ] ; then
./configure --host mipsel-linux-gnu --enable-udc-boot
else
./configure --host mipsel-linux-gnu "$@"
fi

47
clocks.txt
View File

@ -1,47 +0,0 @@
cclk: cpu clock. Fastest clock in the system.
hclk: high-speed peripheral bus clock.
pclk: peripheral bus clock.
mclk: memory clock, for emc.
ldclk: lcd device clock.
lpclk: lcd pixel clock.
cim_mclk: clock output for cim.
cim_pclk: clock input for cim.
i2sclk: codec clock.
mscclk: msc clock.
ssiclk: ssi clock.
exclk: 12MHz clock output, used by uart, i2c, ssi, tcu, usb2.0-phy.
rtclk: 32768Hz clock input for rtc.
cclk: 252M
hclk: 84M
pclk: 84M
mclk: 84M
ldclk: 84M; must not be larger than 150M
lpclk: 25295340 (70Hz screen refresh)
cim_mclk: not used.
cim_pclk: not used.
i2sclk: must be 12M
mscclk: must not be larger than 400k during init; not larger than 25M later.
ssiclk: not used.
exclk: 12M, not adjustable.
rtclk: 32768, not adjustable.
usb clock, for host and device, must be 48M.
restrictions:
- cclk must be i*hclk
- i must not be 24 or 32
- hclk = mclk or hclk = 2*mclk
- mclk = k*pclk
so:
- pclk is set
- mclk = k*pclk
- hclk = l*mclk = l*k*pclk; l = 1 or 2
- cclk = i*hclk = i*l*k*pclk; i != 24 or 32
In the code:
m = 42
n = 2
no = 1
So clkout = 12M * 21 = 252M; this is the pll clock frequency.

0
devices.hhp → include/devices.hhp
View File

0
iris.hhp → include/iris.hhp
View File

0
kernel.hhp → include/kernel.hhp
View File

0
keys.hhp → include/keys.hhp
View File

0
ui.hhp → include/ui.hhp
View File

0
alloc.ccp → kernel/alloc.ccp
View File

0
data.ccp → kernel/data.ccp
View File

0
invoke.ccp → kernel/invoke.ccp
View File

0
memory.ccp → kernel/memory.ccp
View File

0
panic.ccp → kernel/panic.ccp
View File

0
schedule.ccp → kernel/schedule.ccp
View File

89
mbr+fat.txt
View File

@ -1,89 +0,0 @@
mbr structure. Size: 200.
000 1b8 code or fat:
00 3 jump instruction
03 8 OEM name
0b 2 bytes per sector
0d 1 sectors per cluster
0e 2 reserved sectors (incl. boot sector, from boot sector)
10 1 number of fats
11 2 non fat32: number of entries in root directory
13 2 total number of sectors on disk if < 32MB
15 1 media descriptor (bit 2 set means removable)
16 2 non fat32: sectors per fat
18 2 sectors per track
1a 2 heads
1c 4 number of sectors before boot sector
20 4 number of sectors on disk, if > 32MB
24 xx 4 sectors per fat
28 xx 2 bit 0-4: active fat, bit 7 set: write to all fats.
2a xx 2 file system version number
2c xx 4 cluster number for root directory
30 xx 2 sector number for FSInfo structure
32 xx 2 boot sector backup sector
34 xx c reserved
40 24 1 drive number
41 25 1 current head (dos internal)
42 26 1 boot signature (with 0x29, the next 3 fields are valid)
43 27 4 volume id
47 2b b volume label
52 36 8 file system type "FAT16 " / "FAT32 " / ...
1b8 004 disk signature
1bc 002 null
1be 010 partition 0
1ce 010 partition 1
1de 010 partition 2
1ee 010 partition 3
1fe 002 mbr signature: 55 aa.
Partition structure. Size: 10.
0 1 bootable flag 00=no; 80=yes.
1 3 first sector in partition, chs
4 1 partition type
5 3 last sector in partition, chs
8 4 first sector in partition, lba
c 4 number of sectors in partition, for lba
CHS address. Size: 3.
head = chs[0]
sector = chs[1] & 0x3f
cylinder = (chs[1] & 0xc0) << 2 | chs[2]
Fat filesystem information sector. Size: 200.
000 4 signature: 52 52 61 41
004 1e0 unused
1e4 4 fsinfo signature: 72 72 41 61
1e8 4 number of free clusters
1ec 4 most recently allocated cluster
1f0 c reserved
1fc 2 unknown
1fe 2 boot record signature: 55 aa
Directory entry. Size: 20.
00 8 name
08 3 extension
0b 1 attributes (00arshdv)
0c 1 0
0d 1 creation time: (milli?)seconds
0e 2 creation time: hour and minute
10 2 creation date
12 2 last accessed date
14 2 cluster[31:16]
16 2 time
18 2 date
1a 2 cluster[15:0]
1c 4 file size
long file name: stored in directory entries immediately before the 8.3 name (last entry is first part of name)
00 1 ordinal field, bit 6 set means highest.
01 a 5 unicode characters.
0b 1 attribute: 000rsh0v.
0c 1 0
0d 1 checksum of short filename.
0e c 6 unicode characters.
1a 2 0
1c 4 2 unicode characters.
checksum is name[0] rotated 11 times, name[1] 10 times, etc and all added up.

10
mips/arch.ccp
View File

@ -277,11 +277,11 @@ void arch_register_interrupt (unsigned num, kReceiver *r):
// And enable or disable the interrupt.
if r:
//if num != 0x18:
//kdebug ("enabled interrupt ")
//kdebug_num (num)
//kdebug (", state: ")
//kdebug_num (INTC_ISR)
//kdebug ("\n")
// kdebug ("enabled interrupt ")
// kdebug_num (num)
// kdebug (", state: ")
// kdebug_num (INTC_IMR)
// kdebug ("\n")
intc_unmask_irq (num)
else:
//kdebug ("disabled interrupt ")

10
mips/entry.S
View File

@ -30,20 +30,20 @@
#include "arch.hh"
addr_000:
#if 0
#if 1
// TLB refill
lui $k0, 0x8000
lw $k1, 0x174($k0) // directory
mfc0 $k0, $CP0_ENTRY_HI
srl $k0, $k0, 19
and $k0, $k0, 0xffc
andi $k0, $k0, 0xffc
addu $k0, $k0, $k1
beq $zero, $k0, zero_refill
lw $k0, 0($k0)
beq $zero, $k0, zero_refill
mfc0 $k1, $CP0_ENTRY_HI
srl $k1, $k1, 10
and $k1, $k1, 0xff8
add $k0, $k0, $k1
andi $k1, $k1, 0x7f8
addu $k0, $k0, $k1
lw $k1, 0($k0)
mtc0 $k1, $CP0_ENTRY_LO0
lw $k1, 4($k0)

2
mips/init.ccp
View File

@ -20,7 +20,7 @@
// Also declare things which only work during kernel init.
#define INIT
#define ARCH
#include "../kernel.hh"
#include "kernel.hh"
#include <elf.h>
#define NUM_SLOTS 8

20
mips/interrupts.ccp
View File

@ -18,7 +18,7 @@
// along with this program. If not, see <http://www.gnu.org/licenses/>.
#define ARCH
#include "../kernel.hh"
#include "kernel.hh"
void arch_flush_cache ():
__asm__ volatile ("\t.set noreorder\n"
@ -73,7 +73,6 @@ static kThread *handle_exit ():
/// Otherwise, the ultra-fast code in entry.S is used.
kThread *tlb_refill ():
++dbg_code.h
kdebug_num ((unsigned)directory)
old_current = current
if !directory:
unsigned addr
@ -82,9 +81,6 @@ kThread *tlb_refill ():
return handle_exit ()
unsigned EntryHi
cp0_get (CP0_ENTRY_HI, EntryHi)
kdebug (" tlb ")
kdebug_num (EntryHi)
kdebug ("\n")
Table *t = directory[EntryHi >> 21]
if !t:
unsigned addr
@ -116,15 +112,19 @@ kThread *interrupt ():
++dbg_code.h
old_current = current
unsigned ipr = INTC_IPR
//if ipr & ~((1 << TIMER_INTERRUPT) | (1 << 0x18)):
// kdebug ("interrupt: ")
// kdebug_num (ipr)
// kdebug ("&")
// kdebug_num (~INTC_IMR)
for unsigned i = 0; i < 32; ++i:
if ipr & (1 << i):
// Handle timer interrupts specially: don't disable them.
if i == TIMER_INTERRUPT:
continue
//if i != 0x18:
//kdebug ("interrupt: ")
//kdebug_num (i, 2)
//kdebug ("\n")
// kdebug (" ")
// kdebug_num (i, 2)
// Disable the interrupt while handling it.
intc_mask_irq (i)
intc_ack_irq (i)
@ -135,6 +135,8 @@ kThread *interrupt ():
c.data[1] = 0
arch_interrupt_receiver[i]->send_message (0, &c)
arch_interrupt_receiver[i] = NULL
//if ipr & ~((1 << TIMER_INTERRUPT) | (1 << 0x18)):
// kdebug ("\n")
if ipr & (1 << TIMER_INTERRUPT):
#if defined (TRENDTAC)
ost_clear_uf (0)
@ -155,7 +157,7 @@ void flush_tlb (unsigned asid):
cp0_get (CP0_ENTRY_HI, hi)
if (hi & 0x1f) == asid:
// Set asid to 0, which is only used by the idle task.
cp0_set (CP0_ENTRY_HI, 0x2000 * tlb)
cp0_set (CP0_ENTRY_HI, 0x2000 * (tlb + 2))
__asm__ volatile ("tlbwi")
static void arch_invoke ():

37
mips/nanonote/board.ccp
View File

@ -23,9 +23,21 @@
void board_init ():
pll_init ()
cpm_start_all ()
// Timer interrupts and buzzer.
cpm_start_tcu ()
// Stop all clocks, except the RTC and timer interrupt source.
CPM_CLKGR = 0x7fff & ~(CPM_CLKGR_RTC | CPM_CLKGR_TCU)
// Make sure the rtc is able to boot the device.
while !rtc_write_ready ():
rtc_enabled ()
while !rtc_write_ready ():
// Set wakeup assertion time, so it actually wakes up.
rtc_set_hrcr_val (0xfe0)
while !rtc_write_ready ():
// Set glitch detection to a low value.
rtc_set_hwfcr_val (0x1e0)
while !rtc_write_ready ():
// Allow rtc alarm to wake up device.
rtc_enable_alarm_wakeup ()
while !rtc_write_ready ():
// sdram memory.
gpio_as_sdram_16bit ()
// flash memory.
@ -86,26 +98,13 @@ void arch_reboot ():
while true:
void arch_poweroff ():
// Power off.
// First enable interrupts, so it can be awoken.
// Disable all interrupts which shouldn't wake it (only an issue while powering down, really).
INTC_IMSR = ~0
intc_unmask_irq (IRQ_RTC)
intc_unmask_irq (IRQ_GPIO3)
GPIO_PXIMS (3) = ~0
gpio_unmask_irq (3, 29)
// Clear interrupt flags.
gpio_ack_irq (3, 29)
intc_ack_irq (IRQ_GPIO3)
intc_ack_irq (IRQ_RTC)
// Clear pending interrupts and enable interrupts.
cp0_set (CP0_STATUS, 0x1000ff01)
// Make sure the rtc is running.
// Make sure the rtc is running; it wakes the device up.
cpm_start_rtc ()
while !rtc_write_ready ():
rtc_enabled ()
while !rtc_write_ready ():
rtc_set_hwfcr_val (0x1e0)
while !rtc_write_ready ():
rtc_set_hrcr_val (0x7f)
while !rtc_write_ready ():
kdebug ("Power down.\n")

2
native/Makefile.am
View File

@ -20,7 +20,7 @@ AUTOMAKE_OPTIONS = foreign
bin_PROGRAMS = usb-server
usb_server_SOURCES = usb-server.cc
usb_server_CPPFLAGS = $(SHEVEK_CFLAGS) -DSTAGE1_FILE=\"mips/nanonote/sdram-setup.raw\" -I.. -DCOPYRIGHT_YEARS=\"2009-2012\" -DCOPYRIGHT_AUTHOR=\"Bas\ Wijnen\" -DCOPYRIGHT_EMAIL=\"wijnen@debian.org\"
usb_server_CPPFLAGS = $(SHEVEK_CFLAGS) -DSTAGE1_FILE=\"mips/nanonote/sdram-setup.raw\" -I../include -DCOPYRIGHT_YEARS=\"2009-2012\" -DCOPYRIGHT_AUTHOR=\"Bas\ Wijnen\" -DCOPYRIGHT_EMAIL=\"wijnen@debian.org\"
usb_server_LDFLAGS = $(SHEVEK_LIBS) -lusb
PYPP = /usr/bin/pypp

125
plan
View File

@ -1,125 +0,0 @@
caps zonder size limit?
invoke ipc: try sync; try receiver memory; try caller memory; fail.
memories map:
top
- lcd
- keyboard
- sound
- led
- udc
- battery
- beeper
- msc
- nand
- filesystem
- network
- top session manager
- - user session
- - - program container
- - - - driver emulation
- - - - driver emulation
- - - - program
- - - program container
- - - - driver emulation
- - - - program
- - user session
...
te doen:
- caps in init met een cap per process
- die cap bevat caps in target memory met een cap per service
- die cap bevat een user van de service
- sysreq is geen aangeboden service, usbfs wel
- sysreq schakelt tussen running processes incl. user switching.
- display interface: put pixel commando
- typewriter: print toetsen op scherm; shell?
- terminal
- emulaties automatisch per proces
- start programma van filesystem
- nand driver
- filesystems met backing store
Boot process:
- bootinit and filesystem (and backing store) are started.
- bootinit starts run.elf and loads init.elf.
- run starts init.
- init loads init.config and executes it.
- during that process, the initial programs are killed.
Order:
run.elf
init.elf
init.config
load.elf
drivers
emulations
programs
init.config is a script:
# load <name> = <filename> load a file into memory. Don't use this after killbootthreads.
load session = session.config
load driver_lcd = lcd.elf
load driver_buzzer = buzzer.elf
load driver_gpio = gpio.elf
load driver_audio = audio.elf
load driver_udc = udc.elf
load driver_nand = nand.elf
load emu_lcd = emu_display.elf
load emu_buzzer = emu_buzzer.elf
load emu_keyboard = emu_keyboard.elf
load emu_audio = emu_audio.elf
load emu_udc = emu_udc.elf
# killbootthreads destroy bootinit, bootfs and bootstore.
killbootthreads
# receive <cap> = <name> (<type> [, <index>]) prepare to accept a capability from a named program.
receive display = driver_lcd (display)
receive display_bright = driver_lcd (setting)
receive buzzer = driver_buzzer (buzzer)
receive keyboard = driver_gpio (keyboard, 0)
receive sysreq = driver_gpio (keyboard, 1)
receive audio = driver_audio (audio)
receive udc = driver_udc (udc)
receive nand = driver_nand (wstring)
# driver <name> run a previously loaded program priviledged.
driver driver_lcd
driver driver_buzzer
driver driver_gpio
driver driver_audio
driver driver_udc
driver driver_nand
# wait wait until all expected capabilities are received.
wait
# sysreq <cap> use a capability as the system request keyboard.
sysreq sysreq
# give <name> (<type> [, <index>]) = <cap> give this capability to this program when it requests it.
give emu_display (display) = display
give emu_display_bright (setting) = display_bright
give emu_buzzer (buzzer) = buzzer
give emu_keyboard (keyboard, 0) = keyboard
give emu_audio (audio) = audio
give emu_udc (udc) = udc
# run <name> run a previously loaded program (normally).
run emu_lcd
run emu_buzzer
run emu_keyboard
run emu_audio
run emu_udc
# include <name> include a loaded file as another config file.
include session
# loop sit and do nothing (respond to system request).
loop

88
report/cross-compiler.tex
View File

@ -1,88 +0,0 @@
% Iris: micro-kernel for a capability-based operating system.
% cross-compiler.tex: Cross-compiler building instructions.
% Copyright 2009 Bas Wijnen <wijnen@debian.org>
%
% This program is free software: you can redistribute it and/or modify
% it under the terms of the GNU General Public License as published by
% the Free Software Foundation, either version 3 of the License, or
% (at your option) any later version.
%
% This program is distributed in the hope that it will be useful,
% but WITHOUT ANY WARRANTY; without even the implied warranty of
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
% GNU General Public License for more details.
%
% You should have received a copy of the GNU General Public License
% along with this program. If not, see <http://www.gnu.org/licenses/>.
\documentclass{shevek}
\begin{document}
\title{Setting up a cross-compiler}
\author{Bas Wijnen}
\date{\today}
\maketitle
\begin{abstract}
This report details how I have set up a cross-compiler. Since it was not
trivial, I think it may be useful for others. After reading this, you should
be able to set up a cross-compiler yourself. It is assumed that the host computer, where the compiler should be running, is a Debian machine.
\end{abstract}
\tableofcontents
\section{Introduction}
A cross-compiler is a compiler which builds code that should be run on a different platform. This can be useful for building code for embedded devices which are incapable of running a compiler themselves, or where it is not practical to do so. If you are reading this, you probably need one. I'm sure you know why you do. Possibly you have also found out that it is not trivial to set it up. This is a step by step report of how I set up a cross-compiler for mipsel. All problems I encountered (and solved) are explained.
A cross-compiler needs cross-binutils and some system libraries. I shall first describe how to install these.
\section{Binutils}
To create a cross-compiler, cross-binutils are needed. They must be built from
source. I did \verb+apt-get source binutils+ to get the sources, then I cd'd into the source directory and did
\verb+TARGET=mipsel-linux-gnu fakeroot debian/rules binary-cross+ to build and
in the original directory \verb+dpkg -i *.deb+ (as root) to install them.
\section{System libraries}
libc6-dev and some other libraries must be installed in cross versions.
\textit{dpkg-cross} is used to build and install them. However, that doesn't
resolve dependencies, and can't download files from a mirror. So that's a
problem. Furthermore, once the compiler is working, other cross-libraries may
be required for the actual cross-building. Then again, the dependencies must
be resolved. It is not practical to do that by hand.
For this purpose, I wrote a script which resolves dependencies of a packages,
filters them to remove the unneeded ones, downloads them and installs them with
dpkg-cross. This is very hackish: it uses human-readable output of programs
like apt-cache to do its work. This output can change its format, I suppose.
But so far I didn't find any other way, so it'll have to do. At least it works
for me. Note that the user running the script must be allowed to run
dpkg-cross as root using sudo. This is achieved (for anyone, not just that
user) by adding to /etc/sudoers \verb+ALL ALL=NOPASSWD:/usr/bin/dpkg-cross+.
In /etc/dpkg-cross/cross-compile, you will need to add your gcc version to the
keepdeps line, in my case \verb+gcc-4.2-base+. This didn't seem to be possible
with command line options (so the comment above that block probably refers only
to the removedeps line).
When this is done, cross-libraries can be installed using the script. I needed
\verb+./cross-install libc6-dev libc6-dev-mips64 libc6-dev-mipsn32+. This
results in packages with those names and \verb+-mipsel-cross+ appended.
\section{Gcc}
For gcc, I did \verb+apt-get source gcc-4.2+ (4.3 didn't work), followed by
\verb+export GCC_TARGET=mipsel+ and \verb+export DEB_CROSS_INDEPENDENT=yes+.
Then in the source directory \verb+debian/rules control+, and finally
\verb+dpkg-buildpackage -uc -us -b -rfakeroot+ and of course
\verb+dpkg --install *.deb+ in the original directory. This failed for
gobjc++-4.2, which I didn't need anyway, so I removed it again.
That results in a cross compiler which can be called using
\verb+mipsel-linux-gnu-gcc+.
\section{Conclusion}
Setting up a cross-compiler is much harder than it should be. Especially
sorting out the dependencies and downloading libraries is very hard. It would
be good if this would be made easier. My cross-install script does this, but
in a fragile and hackish way. However, it does result in a usable
cross-building environment, where new libraries for cross-building can be
easily installed.
\end{document}

388
report/kernel.tex
View File

@ -1,388 +0,0 @@
% Iris: micro-kernel for a capability-based operating system.
% kernel.tex: Description of Iris.
% Copyright 2009 Bas Wijnen <wijnen@debian.org>
%
% This program is free software: you can redistribute it and/or modify
% it under the terms of the GNU General Public License as published by
% the Free Software Foundation, either version 3 of the License, or
% (at your option) any later version.
%
% This program is distributed in the hope that it will be useful,
% but WITHOUT ANY WARRANTY; without even the implied warranty of
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
% GNU General Public License for more details.
%
% You should have received a copy of the GNU General Public License
% along with this program. If not, see <http://www.gnu.org/licenses/>.
\documentclass{shevek}
\begin{document}
\title{Overview of Iris}
\author{Bas Wijnen}
\date{\today}
\maketitle
\begin{abstract}
This document briefly describes the inner workings of my kernel, Iris,
including the reasons for the choices that were made. It is meant to be
understandable (with effort) for people who know nothing of operating systems.
On the other hand, it should also be readable for people who know about
computer architecture, but want to know about this kernel. It is probably
better suited for the latter category.
\end{abstract}
\tableofcontents
\section{Operating systems}
This section describes what the purpose of an operating system is, and defines
what I call an ``operating system''\footnote{Different people use very
different definitions, so this is not as trivial as it sounds.}. It also goes
into some detail about microkernels and capabilities. If you already know, you
can safely skip this section. It contains no information about Iris.
\subsection{The goal of an operating system}
In the 1980s, a computer could only run one program at a time. When the
program had finished, the next one could be started. This follows the
processor itself: it runs a program, from the beginning until the end, and
can't run more than one program simultaneously\footnote{Multi-core processors
technically can run multiple programs simultaneously, but I'm not talking about
those here.}. In those days, an \textit{operating system} was the program that
allowed other programs to be started. The best known operating systems were
called \textit{Disk operating system}, or \textit{DOS} (of which there were
several).
At some point, there was a need for programs that would ``help'' other programs
in some way. For example, they could provide a calculator which would pop up
when the user pressed a certain key combination. Such programs were called
\textit{terminate and stay resident} programs, or TSRs. This name came from
the fact that they terminated, in the sense that they would allow the next
program to be run, but they would stay resident and do their job in the
background.
At some point, people wanted to de \textit{multitasking}. That is, multiple
``real'' programs should run concurrently, not just some helpers. The easiest
way to implement this is with \textit{cooperative multitasking}. Every program
returns control to the system every now and then. The system switches between
all the running programs. The result is that every program runs for a short
time, several times per second. For the user, this looks like the programs are
all running simultaneously, while in reality it is similar to a chess master
playing simultaneously on many boards: he really plays on one board at a time,
but switches a lot. On such a system, the \textit{kernel} is the program that
chooses which program to run next. The \textit{operating system} is the kernel
plus some support programs which allow the user to control the system.
On a system where multiple programs all think they ``own'' the computer, there
is another problem: if more than one program tries to access the same device,
it is very likely that at least one of them, and probably both, will fail. For
this reason, \textit{device drivers} on a multitasking system must not only
allow the device to be controlled, but they must also make sure that concurrent
access doesn't fail. The simplest way to achieve this is simply to disallow
it (let all operations fail that don't come from the first program using the
driver). A better way, if the device can handle it, is to somehow make sure
that both work.
There is one problem with cooperative multitasking: when one program crashes,
or for some other reason doesn't return control to the system, the other
programs stop running as well. The solution to this is \textit{preemptive
multitasking}. This means that every program is interrupted every now and
then, without asking for it, and the system switches to a different program.
This makes the kernel slightly more complex, because it must take care to store
every aspect of the running programs. After all, the program doesn't expect to
be interrupted, so it can't expect its state to change either. This shouldn't
be a problem though. It's just something to remember when writing the kernel.
Concluding, every modern desktop kernel uses preemptive multitasking. This
requires a timer interrupt. The operating system consists of this kernel, plus
the support programs that allow the user to control the system.
\subsection{Microkernel}
Most modern kernels are so-called \textit{monolithic} kernels: they include
most of the operating system. In particular, they include the device drivers.
This is useful, because the device drivers need special attention anyway, and
they are very kernel-specific. Modern processors allow the kernel to protect
access to the hardware, so that programs can't interfere with each other. A
device driver which doesn't properly ask the kernel will simply not be allowed
to control the device.
However, adding device drivers and everything that comes with them
(filesystems, for example) to the kernel makes it a very large program.
Furthermore, it makes it an ever-changing program: as new devices are built,
new drivers must be added. Such a program can never become stable and
bug-free.
Conceptually much nicer is the microkernel. It includes the minimum that is
needed for a kernel, and nothing more. It does include task switching and some
mehtod for tasks to communicate with each other. It also ``handles'' hardware
interrupts, but all it really does is passing them to the device driver, which
is mostly a normal program. Some microkernels don't do memory manangement
(deciding which programs get how much and which memory), while others do.
The drawback of a microkernel is that it requires much more communication
between tasks. Where a monolithic kernel can serve a driver request from a
task directly, a microkernel must pass it to a device driver. Usually there
will be an answer, which must be passed back to the task. This means more task
switches. This doesn't need to be a big problem, if task switching is
optimized: because of the simpler structure of the microkernel, it can be much
faster at this than a monolithic kernel. And even if the end result is
slightly slower, in my opinion the stability is still enough reason to prefer a
microkernel over a monolitic one.
Summarizing, a microkernel needs to do task switching and inter-process
communication. Because mapping memory into an address space is closely related
to task switching, it is possible to include memory management as well. The
kernel must accept hardware interrupts, but doesn't handle them (except the
timer interrupt).
\subsection{Capabilities}
Above I explained that the kernel must allow processes to communicate. Many
systems allow communication through the filesystem: one process writes to a
file, and an other process reads from it. This implies that any process can
communicate with any other process, if they only have a place to write in the
filesystem, where the other can read.
This is a problem because of security. If a process cannot communicate with
any part of the system, except the parts that it really needs to perform its
operation, it cannot leak or damage the other parts of the system either. The
reason that this is relevant is not that users will run programs that try to
ruin their system (although this may happen as well), but that programs may
break and damage random parts of the system, or be taken over by
crackers\footnote{Crackers are better known by the public as ``hackers''.
However, I use this word to describe people who like to play with software (or
sometimes also with other things). Therefore the malicious people who use
hacking skills for evil need a different name.}. If the broken or malicious
process has fewer rights, it will also do less damage to the system.
This leads to the goal of giving each process as little rights as possible.
For this, it is best to have rights in a very fine-grained way. Every
operation of a driver (be it a hardware device driver, or just a shared program
such as a file system) should have its own key, which can be given out without
giving keys to the entire driver (or even multiple drivers). Such a key is
called a capability. For example, a capability can allow the holder to access
a single file, or to use one specific network connection, or to see what keys
are typed by the user.
Some operations are performed directly on the kernel itself. For those, the
kernel can provide its own capabilities. Processes can create their own
objects which can receive capability calls, and capabilities for those can be
generated by them. Processes can copy capabilities to other processes, if they
have a channel to send them (using an existing capability). This way, any
operation of the process with the external world goes through a capability, and
only one system call is needed: \textit{invoke}.
This has a very nice side-effect, which is that it becomes very easy to tap
communication of a task you control. This means that a user can redirect
certain requests from programs which don't do exactly what is desired to do
nicer things. For example, a program can be prevented from opening pop-up
windows. In other words, it puts control of the computer from the programmer
into the hands of the user (as far as allowed by the system administrator).
This is a very good thing.
\section{Communication}
This section shortly describes how communication between threads is performed
by Iris. Below are more details about the kernel structures, this section just
explains which steps are taken.
Iris doesn't hold any state about the communication, other than the state that
it holds for threads on request of the threads (in the memory paid for by the
threads). For Iris, there is no such thing as a \textit{conversation}. There
are messages. When there is a conversation, Iris just sees several messages
going both ways. For Iris these are not connected\footnote{This is not
entirely true; Iris has call capabilities as an optimization feature. They do
implement some conversation aspects. But they are only an optimization: Iris
doesn't require them to be used.}.
So understanding communication between threads boils down to understanding the
transfer of a single message. A message is short: four 32-bit words of data,
plus four capabilities. Besides that, a 64-bit protected value is sent. This
value is set by the creator of the capability, usually the server, and cannot
be changed by the invoker.
Sending a message between threads is mostly about a Receiver object. The
server has a Receiver, for which it creates a capability (with the mentioned
protected data). If a client wants to contact the server, it must get this
capability.
The client then invokes the capability with four data words and four
capabilities (possibly set to 0). The message is queued by the receiver. The
capabilities are stored into a Caps object.
When the server is ready for it, it queries the receiver for new messages. It
then gets the protected data, the four data words and copies of the
capabilities. The ones in the receiver's Caps are invalidated and can be
reused after that. Note that it does not get a capability of the sender,
unless the sender sends it. There is no way for the server to know who is
sending the message, only which capability was used (through the protected
data).
\section{Kernel objects}
This section describes all kernel objects of Iris, and the operations that can
be performed on them. One operation is possible on any kernel object (except a
message and reply and call Capabilities). This operation is \textit{degrade}.
It creates a copy of the capability with some rights removed. This can be
useful when giving away a capability.
\subsection{Memory}
A Memory object is a container for storing things. All objects live inside a
Memory object. A Memory object can contain other Memory objects, Capabilities,
Receivers, Threads, Pages and Cappages.
A Memory object is also an address space. Pages can be mapped (and unmapped).
Any Thread in a Memory object uses this address space while it is running.
Every Memory object has a limit. When this limit is reached, no more Pages can
be allocated for it (including Pages which it uses to store other objects).
Using a new Page in a Memory object implies using it in all ancestor Memory
objects. This means that setting a limit which is higher than the parent's
limit means that the parent's limit applies anyway.
Operations on Memory objects:
\begin{itemize}
\item Create a new item of type Receiver, Memory, Thread, Page, or Cappage.
\item Destroy an item of any type, which is owned by the Memory.
\item List items owned by the Memory, Pages mapped in it, and messages in owned
Receiver's queues.
\item Map a Page at an address.
\item Get the Page which is mapped at a certain address.
\item Get and set the limit, which is checked when allocating pages for this
Memory or any sub-structure.
\item Drop a capability. This can only be done by Threads owned by the Memory,
because only they can present capabilities owned by it.\footnote{Iris checks if
presented capabilities are owned by the Thread's Memory. If they aren't, no
capability is passed instead. The destroy operation destroys an object that a
capability points to. Drop destroys the capability itself. If a Thread from
an other Memory would try to drop a capability, Iris would refuse to send it in
the message, or it would not be dropped because it would be owned by a
different Memory.}
\end{itemize}
\subsection{Receiver}
A receiver object is used for inter-process communication. Capabilities can be
created from it. When those are invoked, the receiver can be used to retrieve
the message.
Operations on Receiver objects:
\begin{itemize}
\item Set the owner. This is the Thread that messages will be sent to when
they arrive. Messages are stored in the receiver until the owner is ready to
accept them. If it is waiting while the message arrives, it is immediately
delivered.
\item Create a capability. The new capability should be given to Threads who
need to send a message to the receiver.
\item Create a call capability. This is an optimization. Because
\textit{calls} happen a lot, where a capability is created, sent in a message,
then a reply is sent over this new capability, and then it is dropped. This
can be done using a call capability. The call capability is invoked instead of
the target, and the target is specified where the reply capability should be.
The message is sent to the call capability (which is handled by the Receiver in
the kernel). It creates a new reply capability and sends the message to the
target with it. When the reply capability is invoked, the message is sent to
the owner, and the capability is dropped. This approach reduces the number of
kernel calls from four (create, call, reply, drop) to two (call, reply).
\end{itemize}
\subsection{Thread}
Thread objects hold the information about the current state of a thread. This
state is used to continue running the thread. The address space is used to map
the memory for the Thread. Different Threads in the same address space have
the same memory mapping. All Threads in one address space (often there is only
one) together are called a process.
Because all threads have a capability to their own Thread object (for claiming
Receivers), this is also used to make some calls which don't actually need an
object. The reason that these are not operations on some fake object which
every process implicitly owns, is that for debugging it may be useful to see
every action of a process. In that case, all its capabilities must be pointing
to the watcher, which will send them through to the actual target (or not).
With such an implicit capability, it would be impossible to intercept these
calls.
Operations on Thread objects:
\begin{itemize}
\item Get information about the thread. Details of this are
architecture-specific. Standard ways are defined for getting and setting some
flags (whether the process is running or waiting for a message, setting these
flags is a way to control this for other Threads), the program counter and the
stack pointer. This call is also used to get the contents of processor
registers and possibly other information which is different per Thread.
\item Let Iris schedule the next process. This is not thread-specific.
\item Get the top Memory object. This is not thread-specific. Most Threads
are not allowed to perform this operation. It is given to the initial Threads.
They can pass it on to Threads that need it (if any).
\item In the same category, register a Receiver for an interrupt. Upon
registration, the interrupt is enabled. When the interrupt arrives, the
registered Receiver gets a message from Iris and the interrupt is disabled
again. After the Thread has handled the interrupt, it must reregister it in
order to enable it again.
\item Allocate a range of contiguous physical memory. This is only relevant
for device drivers whose device will directly access the storage, such as the
display driver. The result of this call is that the memory is counted as used
by the Thread, and it is reserved, but it is not returned. Instead, the
address of physical memory is returned, and the pages need to be retrieved with
the next operation. This capability is not present in normally created
threads.
\item Allocate a page of physical memory. This is used in combination with the
previous operation to reserve a block of physical memory, and by device drivers
to map I/O memory into their address space. There is a flag indicating whether
this memory should be freed (ranges) or not (I/O). Users of this operation are
trusted to handle it properly; no checks are done to ensure that no kernel
memory is leaked, or that the allocated memory isn't used by other threads or
the kernel. Of course, this capability is not present in normally created
threads.
\item Get the physical address of a page. Only device drivers need to know the
physical address of their pages, so this operation is not available on normal
threads.
\item And similarly, allow these priviledged operations (or some of them) in an
other thread. This is a property of the caller, because the target thread
normally doesn't have the permission to do this (otherwise the call would not
be needed). The result of this operation is a new Thread capability with all
specified rights set. Normally this is inserted in a priviledged process's
address space during setup, before it is run (instead of the capability which
is obtained during Thread creation).
\end{itemize}
\subsection{Page and Cappage}
A Page can be used to store user data. It can be mapped into an address space
(a Memory object). Threads can then use the data directly. A Cappage is very
similar, in that it is owned by the user. However, the user cannot see its
contents directly. It contains a frame with Capabilities. They can be invoked
like other owned capabilities. The main feature of a Cappage, however, is that
they can be shared. It is a fast way to copy many capabilities to a different
address space. Capabilities in a Cappage are not directly owned by the Memory,
and thus cannot be dropped.
Operations on Page and Cappage objects:
\begin{itemize}
\item Copy or move the frame to a different Page, which is usually in a
different Memory. This way, large amounts of data can be copied between
address spaces without needing to really copy it.
\item Set or get flags, which contain information on whether the page is
shared, is writable, has a frame allocated, and is paying for the frame. Not
all flags can be set in all cases.
\item Cappages can also set a capability in the frame (pointed to with an index).
\end{itemize}
\subsection{Capability}
A capability object can be invoked to send a message to a receiver or to Iris
itself. The owner cannot see from the capability where it points. This is
important, because the user must be able to substitute the capability for a
different one, without the program noticing. In some cases, it is needed to
say things about capabilities. For example, a Memory can list the Capabilities
owned by it. In such a case, the list consists of Capabilities which point to
other Capabilities. These capabilities can also be used to destroy the target
capability (using an operation on the owning Memory object), for example.
Operations or capability objects:
\begin{itemize}
\item Get a copy of the capability.
\end{itemize}
\section{Interface classes}
Around Iris is a system of some programs to create the operating system. These
include the device drivers. While Iris itself needs no specific interfaces
from them, some interface classes are defined, which are used by the default
environment. By defining classes, it is possible to let a program use any
device of that type without needing changes to its code.
These definitions are in the source. A copy of the information here would only
lead to it getting outdated.
\end{document}

647
report/making-of.tex
View File

@ -1,647 +0,0 @@
% Iris: micro-kernel for a capability-based operating system.
% making-of.tex: Description of the process of writing Iris.
% Copyright 2009 Bas Wijnen <wijnen@debian.org>
%
% This program is free software: you can redistribute it and/or modify
% it under the terms of the GNU General Public License as published by
% the Free Software Foundation, either version 3 of the License, or
% (at your option) any later version.
%
% This program is distributed in the hope that it will be useful,
% but WITHOUT ANY WARRANTY; without even the implied warranty of
% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
% GNU General Public License for more details.
%
% You should have received a copy of the GNU General Public License
% along with this program. If not, see <http://www.gnu.org/licenses/>.
\documentclass{shevek}
\begin{document}
\title{Writing a kernel from scratch}
\author{Bas Wijnen}
\date{\today}
\maketitle
\begin{abstract}
This is a report of the process of writing a kernel (Iris) from scratch for
the cheap (€150) Trendtac laptop. In a following report I shall write about
the operating system on top of it. This document is written while writing the
system, so that no steps are forgotten. Choices are explained and problems
(and their solutions) are shown. After reading this, you should have a
thorough understanding of Iris, and (with significant effort) be able to write
a similar kernel yourself. This document assumes a working Debian system with
root access (for installing packages), and some knowledge about computer
architectures. (If you lack that knowledge, you can try to read it anyway and
check other sources when you see something new.)
\end{abstract}
\tableofcontents
\section{Hardware details}
The first step in the process of writing an operating system is finding out
what the system is you're going to program for. While most of the work is
supposed to be platform--independant, some parts, especially in the beginning,
will depend very much on the actual hardware. So I searched the net and found:
\begin{itemize}
\item There's a \textbf{Jz4730} chip inside, which implements most
functionality. It has a mips core, an OHCI USB host controller (so no USB2),
an AC97 audio device, a TFT display controller, an SD card reader, a network
device, and lots of general purpose I/O pins, which are used for the LEDs and
the keyboard. There are also two PWM outputs, one of which seems to be used
with the display. It also has some other features, such as a digital camera
controller, which are not used in the design.
\item There's a separate 4-port USB hub inside.
\item There's a serial port which is accessible with a tiny connector inside
the battery compartiment. It uses TTL signals, so to use it with a PC serial
port, the signals must be converted with a MAX232. That is normal for these
boards, so I already have one handy. The main problem in this case is that the
connector is an unusual one, so it may take some time until I can actually
connect things to the serial port.
\end{itemize}
First problem is how to write code which can be booted. This seems easy: put a
file named \textbf{uimage} on the first partition on an SD card, which must be
formatted FAT or ext3, and hold down Fn, left shift and left control while
booting. The partition must also not be larger than 32 MB.
The boot program is u-boot, which has good documentation on the web. Also,
there is a Debian package named uboot-mkimage, which has the mkimage executable
to create images that can be booted using u-boot. uimage should be in this
format.
To understand at least something of addresses, it's important to understand the
memory model of the mips architecture:
\begin{itemize}
\item usermode code will never reference anything in the upper half of the
memory (above 0x80000000). If it does, it receives a segmentation fault.
\item access in the lower half is paged and can be cached. This is called
kuseg when used from kernel code. It will access the same pages as non-kernel
code finds there.
\item the upper half is divided in 3 segments.
\item kseg0 runs from 0x80000000 to 0xa0000000. Access to this memory will
access physical memory from 0x00000000 to 0x20000000. It is cached, but not
mapped (meaning it accesses physical, not virtual, memory)
\item kseg1 runs from 0xa0000000 to 0xc0000000. It is identical to kseg0,
except that is is not cached.
\item kseg2 runs from 0xc0000000 to the top. It is mapped like user memory,
differently for each process, and can be cached. It is intended for
per-address space kernel structures. I shall not use it in Iris.\footnote{I
thought I wouldn't use kseg2. However, I needed to use it for kernel entry
code, as you can read below.}
\end{itemize}
U-boot has some standard commands. It can load the image from the SD card at
0x80600000. Even though the Linux image seems to use a different address, I'll
go with this one for now.
\section{Cross-compiler}
Next thing to do is build a cross-compiler so it is possible to try out some
things. This shouldn't need to be very complex, but it is. I wrote a separate
document about how to do this. Please read that if you don't have a working
cross-compiler, or if you would like to install libraries for cross-building
more easily.
\section{Choosing a language to write in}
Having a cross-compiler, the next thing to do is choose a language. I prefer
to use C++ for most things. I have used C for a previous kernel, though,
because it is more low-level. This time, I decided to try C++. But since I'm
not linking any libraries, I need to avoid things like new and delete. For
performance reasons I also don't use exceptions. They might need library
support as well. So what I use C++ for is classes with member functions, and
default function arguments. I'm not even using these all the time, and the
whole thing is very much like C anyway.
Except for one change I made: I'm using a \textit{pythonic preprocessor} I
wrote. It changes python-style indented code into something a C compiler
accepts. It shouldn't be too hard to understand if you see the kernel source.
Arguments to flow control instructions (if, while, for) do not need
parenthesis, but instead have a colon at the end of the line. After a colon at
the end of a line follows a possibly empty indented block, which is put in
brackets. Indenting a line with respect to the previous one without a colon
will not do anything: it makes it a continuation. Any line which is not empty
or otherwise special gets a semicolon at the end, so you don't need to type
those. When using both spaces and tabs (which I don't recommend), set the tab
width to 8 spaces.
\section{Making things run}
For loading a program, it must be a binary executable with a header. The
header is inserted by mkimage. It needs a load address and an entry point.
Initially at least, the load address is 0x80600000. The entry point must be
computed from the executable. The easiest way to do this is by making sure
that it is the first byte in the executable. The file can then be linked as
binary, so without any headers. This is done by giving the
\verb+--oformat binary+ switch to ld. I think the image is loaded without the
header, so that can be completely ignored while building. However, it might
include it. In that case, the entry point should be 0x40 higher, because
that's the size of the header.
\section{The first version of the kernel}
This sounds better than it is. The first version will be able to boot, and
somehow show that it did that. Not too impressive at all, and certainly not
usable. It is meant to find out if everything I wrote above actually works.
For this kernel I need several things: a program which can boot, and a way to
tell the user. As the way to tell the user, I decided to use the caps-lock
LED. The display is quite complex to program, I suppose, so I won't even try
at this stage. The LED should be easy. Especially because Linux can use it
too. I copied the code from the Linux kernel patch that seemed to be about the
LED, and that gave me the macros \verb+__gpio_as_output+, \verb+__gpio_set_pin+
and \verb+__gpio_clear_pin+. And of course there's \verb+CAPSLOCKLED_IO+,
which is the pin to set or clear.
I used these macros in a function I called \verb+kernel_entry+. In an endless
loop, it switches the LED on 1000000 times, then off 1000000 times. If the
time required to set the led is in the order of microseconds, the LED should be
blinking in the order of seconds. I tried with 1000 first, but that left the
LED on seemingly permanently, so it was appearantly way too fast.
This is the code I want to run, but it isn't quite ready for that yet. A C
function needs to have a stack when it is called. It is possible that u-boot
provides one, but it may also not do that. To be sure, it's best to use some
assembly as the real entry point, which sets up the stack and calls the
function.
The symbol that ld will use as its entry point must be called \verb+__start+
(on some other architectures with just one underscore). So I created a simple
assembly file which defines some stack space and does the setting up. It also
sets \$gp to the so-called \textit{global offset table}, and clears the .bss
section. This is needed to make compiler-generated code run properly.
Now how to build the image file? This is a problem. The ELF format allows
paged memory, which means that simply loading the file may not put everything
at its proper address. ld has an option for this, \verb+--omagic+. This is
meant for the a.out format, which isn't supported by mipsel binutils, but that
doesn't matter. The result is still that the .text section (with the
executable code) is first in the file, immediately followed by the .data
section. So that means that loading the file into memory at the right address
results in all parts of the file in the proper place. Adding
\verb+-Ttext 0x80600000+ makes everything right. However, the result is still
an ELF file. So I use objcopy with \verb+-Obinary+ to create a binary file
from it. At this point, I also extract the start address (the location of
\verb+__start+) from the ELF file, and use that for building uimage. That
way it is no longer needed that \_\_start is at the first byte of the file.
Booting from the SD card is as easy as it seemed, except that I first tried an
mmc card (which fits in the same slot, and usually works when SD is accepted)
and that didn't work. So you really need an SD card.
\section{Context switching}
One very central thing in the kernel is context switching. That is, we need to
know how the registers and the memory are organized when a user program is
running. In order to understand that, we must know how paging is done. I
already found that it is done by coprocessor 0, so now I need to find out how
that works.
On the net I found the \textit{MIPS32 architecture for developers}, version 3
of which is sub-titled \textit{the MIPS32 priviledged resource architecture}.
It explains everything there is to know about things which are not accessible
from normal programs. In other words, it is exactly the right book for
programming a kernel or device driver using this processor. How nice.
It explains that memory accesses to the lower 2GB are (almost always) mapped
through a TLB (translation lookaside buffer). This is an array of some records
where virtual to physical address mappings are stored. In case of a TLB-miss
(the virtual address cannot be found in the table), an exception is generated
and Iris must insert the mapping into the TLB.
This is very flexible, because I get to decide how I write the kernel. I shall
use something similar to the hardware implementation of the IBM PC: a page
directory which contains links to page tables, with each page table filled with
pointers to page information. It is useful to have a direct mapping from
virtual address to kernel data as well. There are several ways how this can be
achieved. The two simplest ones each have their own drawback: making a shadow
page directory with shadow page tables with links to the kernel structures
instead of the pages wastes some memory. Using only the shadow, and doing a
lookup of the physical address in the kernel structure (where it must be stored
anyway) wastes some cpu time during the lookup. At this moment I do not know
what is more expensive. I'll initially go for the cpu time wasting approach.
\section{Kernel entry}
Now that I have an idea of how a process looks in memory, I need to implement
kernel entry and exit. A process is preempted or makes a request, then Iris
responds, and then a process (possibly the same) is started again.
The main problem of kernel entry is to save all registers in the kernel
structure which is associated with the thread. In case of the MIPS processor,
there is a simple solution: there are two registers, k0 and k1, which cannot be
used by the thread. So they can be set before starting the thread, and will
still have their values when the kernel is entered again.\footnote{This is not
true, see below.} By pointing one of them to the place to save the data, it
becomes easy to perform the save and restore.
As with the bootstrap process, this must be done in assembly. In this case
this is because the user stack must not be used, and a C function will use the
current stack. It will also mess up some registers before you can save them.
The next problem is how to get the interrupt code at its address. I'll try to
load the thing at address 0x80000000. It seems to work, which is good. Linux
probably has some reason to do things differently, but if this works, it is the
easiest way.
\section{Memory organization}
Now I've reached the point where I need to create some memory structures. To
do that, I first need to decide how to organize the memory. There's one very
simple rule in my system: everyone must pay for what they use. For memory,
this means that a process brings its own memory where Iris can write things
about it. Iris does not need her own allocation system, because she always
works for some process. If the process doesn't provide the memory, the
operation will fail.\footnote{There are some functions with \textit{alloc} in
their name. However, they allocate pieces of memory which is owned by the
calling process. Iris never allocates anything for herself, except during
boot.}
Memory will be organized hierarchically. It belongs to a container, which I
shall call \textit{Memory}. The entire Memory is the property of another
Memory, its parent. This is true for all but one, which is the top level
Memory. The top level Memory owns all memory in the system. Some of it
directly, most of it through other Memories.
Iris will have a list of unclaimed pages. For optimization, she actually
has two lists: one with pages containing only zeroes, and one with pages
containing junk. When idle, the junk pages can be filled with zeroes.
Because Iris starts at address 0, building up the list of pages is very
easy: starting from the first page above the top of the kernel, everything is
free space. Initially, all pages are added to the junk list.
\section{The idle task}
When there is nothing to do, an endless loop should be waiting for interrupts.
This loop is called the idle task. I use it also to exit bootstrapping, by
enabling interrupts after everything is set up as if we're running the idle
task, and then jumping to it.
There are two options for the idle task, again with their own drawbacks. The
idle task can run in kernel mode. This is easy, it doesn't need any paging
machinery then. However, this means that Iris must read-modify-write the
Status register of coprocessor 0, which contains the operating mode, on every
context switch. That's quite an expensive operation for such a critical path.
The other option is to run it in user mode. The drawback there is that it
needs a page directory and a page table. However, since the code is completely
trusted, it may be possible to sneak that in through some unused space between
two interrupt handlers. That means there's no fault when accessing some memory
owned by others (which is a security issue), but the idle task is so trivial
that it can be assumed to run without affecting them.
\section{Intermezzo: some problems}
Some problems came up while working. First, I found that the code sometimes
didn't work and sometimes it did. It seemed that it had problems when the
functions I called became more complex. Looking at the disassembly, it appears
that I didn't fully understand the calling convention used by the compiler.
Appearantly, it always needs to have register t9 set to the called function.
In all compiled code, functions are called as \verb+jalr $t9+. It took quite
some time to figure this out, but setting t9 to the called function in my
assembly code does indeed solve the problem.
I also found that every compiled function starts with setting up gp. This is
complete nonsense, since gp is not changed by any code (and it isn't restored
at the end of a function either). I'll report this as a but to the compiler.
Because it is done for every function, it means a significant performance hit
for any program.
The other problem is that the machine was still doing unexpected things.
Appearantly, u-boot enables interrupts and handles them. This is not very nice
when I'm busy setting up interrupt handlers. So before doing anything else, I
first switch off all interrupts by writing 0 to the Status register of CP0.
This also reminded me that I need to flush the cache, so that I can be sure
everything is correct. For that reason, I need to start at 0xa0000000, not
0x80000000, so that the startup code is not cached. It should be fine to load
Iris at 0x80000000, but jump in at the non-cached location anyway, if I
make sure the initial code, which clears the cache, can handle it. After that,
I jump to the cached region, and everything should be fine. However, at this
moment I first link Iris at the non-cached address, so I don't need to
worry about it.\footnote{Actually, it seems that the cache is working fine, and
I'm using the cached address. They are used for kernel entry in any case.}
Finally, I read in the books that k0 and k1 are in fact normal general purpose
registers. So while they are by convention used for kernel purposes, and
compilers will likely not touch them, Iris can't actually rely on them not
being changed by user code. So I'll need to use a different approach for
saving the processor state. The solution is trivial: use k1 as before, but
first load it from a fixed memory location. To be able to store k1 itself, a
page must be mapped in kseg3 (wired into the tlb), which can then be accessed
with a negative index to \$zero.
At this point, I was completely startled by crashes depending on seemingly
irrelevant changes. After a lot of investigation, I saw that I had forgotten
that mips jumps have a delay slot, which is executed after the jump, before the
first new instruction is executed. I was executing random instructions, which
lead to random behaviour.
\section{Back to the idle task}
With all this out of the way, I continued to implement the idle task. I hoped
to be able to never write to the Status register. However, this is not
possible. The idle task must be in user mode, and it must call wait. That
means it needs the coprocessor 0 usable bit set. This bit may not be set for
normal processes, however, or they would be able to change the tlb and all
protection would be lost. However, writing to the Status register is not a
problem. First of all, it is only needed during a task switch, and they aren't
as frequent as context switches (every entry to the kernel is a context switch,
only when a different task is entered from the kernel than exited to the kernel
is it a task switch). Furthermore, and more importantly, coprocessor 0 is
intgrated into the cpu, and writing to it is actually a very fast operation and
not something to be avoided at all.
So to switch to user mode, I set up the Status register so that it looks like
it's handling an exception, set EPC to the address of the idle task, and use
eret to ``return'' to it.
\section{Timer interrupts}
This worked well. Now I expected to get a timer interrupt soon after jumping
to the idle task. After all, I have set up the compare register, the timer
should be running and I enabled the interrupts. However, nothing happened. I
looked at the contents of the count register, and found that it was 0. This
means that it is not actually counting at all.\footnote{I also checked the
random register, which didn't seem to change either. This is a huge
performance problem, but it is easily solved by changing the random register
manually.} Looking at the Linux sources, they don't use this timer either, but
instead use the cpu-external (but integrated in the chip) timer. The
documentation says that they have a different reason for this than a
non-functional cpu timer. Still, it means it can be used as an alternative.
Having a timer is important for preemptive multitasking: a process needs to be
interrupted in order to be preempted, so there needs to be a periodic interrupt
source.
During testing it is not critical to have a timer interrupt. Without it, the
system can still do cooperative multitasking, and all other aspects of the
system can be tested. So I decided to leave the timer interrupts until I'm
going to write the drivers for the rest of the hardware as well.
\section{Invoke}
So now I need to accept calls from programs and handle them. For this, I need
to decide what such a call looks like. It will need to send a capability to
invoke, and a number of capabilities and numbers as arguments. I chose to send
four capabilities (so five in total) and also four numbers. The way to send
these is by setting registers before making a system call. Similarly, when
Iris returns a message, she sets the registers before returing to the program.
I wrote one file with assembly for receiving interrupts and exceptions
(including system calls) and one file with functions called from this assembly
to do most of the work. For syscall, I call an arch-specific\footnote{I split
off all arch-specific parts into a limited number of files. While I am
currently writing Iris only for the Trendtac, I'm trying to make it easy to
port her to other machines later.} invoke function, which reads the message,
puts it in variables, and calls the real invoke function.
The real invoke function analyzes the called capability: if it is in page 0
(which is used by the interrupt handlers, and cannot hold real capabilities),
it must be a kernel-implemented object. If not, it is a pointer to a Receiver.
Then kernel object calls are handled, and messages to receivers are sent. When
all is done, control is returned to the current process, which may or may not
be the calling process. If it isn't, the processor state is initialized for
the new process by setting the coprocessor 0 usable bit in the Status register
and the asid bits in the EntryHi register of CP0.
\section{Paging}
While implementing user programs, I needed to think about paging as well. When
a TLB miss occurs, the processor must have a fast way to reload it. For this,
page tables are needed. On Intel processors, these need to be in the format
that Intel considered useful. On a mips processor, the programmer can choose
whatever they want. The Intel format is a page containing the
\textit{directory}, 1024 pointers to other pages. Each of those pages contains
1024 pointers to the actual page. That way, 10 bits of the virtual address
come from the directory, 10 bits from the page table, and 12 from the offset
within the page, leading to a total of 32 bits of virtual memory addressing.
On mips, we need 31 bits, because addresses with the upper bit set will always
result in an address error. So using the same format would waste half of the
page directory. However, it is often useful to have address to mapped page
information as well. For this, a shadow page table structure would be needed.
It seems logical to use the upper half of the directory page for the shadow
directory. However, I chose a different approach: I used the directory for
bits 21 to 30 (as opposed to 22 to 31). Since there are still 12 bit
addressable pages, this leaves 9 bits for the page tables. I split every page
table in two, with the data for EntryLo registers in the lower half, and a
pointer to page information in the upper half of the page. This way, my page
tables are smaller, and I waste less space for mostly empty page tables.
To make a TLB refill as fast as possible, I implemented it directly in the
assembly handler. First, I check if k0 and k1 are both zero. If not, I use
the slow handler. If they are, I can use them as temporaries, and simply set
them to zero before returning. Then I read the current directory (which I save
during a task switch), get the proper entry from it, get the page table from
there, get the proper entry from that as well, and put that in the TLB. Having
done that, I reset k0 and k1, and return. No other registers are changed, so
they need not be saved either. If anything unexpected happens (there is no
page table or no page entry at the faulting address), the slow handler is
called, which will fail as well, but it will handle the failure. This is
slightly slower than handling the failure directly, but speed is no issue in
case of such a failure.
While implementing this, I have been searching for a problem for some time. In
the end, I found that the value in the EntryLo registers does not have the bits
at their normal locations, but 6 bits back. I was mapping the wrong page in,
and thus got invalid data when it was being used.
\section{Sharing}
The next big issue is sharing memory. In order to have efficient
communication, it is important to use shared memory. The question is how to
implement it. A Page can be mapped to memory in the address space that owns
it. It can be mapped to multiple locations in that address space. However I
may remove this feature for performance reasons. It doesn't happen much
anyway, and it is always possible to map the same frame (a page in physical
memory) to multiple virtual addresses by creating an multiple Pages.
For sharing, a frame must also be mappable in a different address space. In
that case, an operation must be used which copies or moves the frame from one
Page to another. There is a problem with rights, though: if there is an
operation which allows a frame to be filled into a Page, then the rights of
capabilities to that Page may not be appropriate for the frame. For example,
if I have a frame which I am not allowed to write, and a frame which I am
allowed to write, I should not be able to write to the first frame by
transferring it to the second Page. So some frame rights must be stored in the
Page, and they must be updated during copy and move frame operations.
Move frame is only an optimization. It allows the receiver to request a
personal copy of the data without actually copying anything. The result for
the sender is a Page without a frame. Any mappings it has are remembered, but
until a new frame is requested, no frame will be mapped at the address. A Page
is also able to \textit{forget} its frame, thereby freeing some of its memory
quota (if it stops paying for it as well; a payed-for frame costs quota, and is
guaranteed to be allocatable at any time).
Another optimization is to specify a minimum number of bytes for a page move.
If the page needs to be copied, this reduces the time needed to complete that
operation. The rest of the page should not contain secret data: it is possible
that the entire page is copied, for example if it doesn't need to be copied,
but can be reused.
\section{Copy on write}
Another nice optimization is \textit{copy on write}: a page is shared
read-only, and when a page-fault happens, the kernel will copy the contents, so
that the other owner(s) don't see the changes. For the moment, I don't
implemnt this. I'm not sure if I want it in Iris at all. It can well be
implemented using an exception handler in user space, and may not be used
enough to spend kernel space on. But I can change my mind on that later.
\section{Memory listing}
The last thing to do for now is allowing a memory to be listed. That is,
having a suitably priviledged capability to a Memory should allow a program to
see what's in it. In particular, what objects it holds, and where pages are
mapped. Probably also what messages are in a receiver's queue. For now, I
postponsed the actual implementation of this, but I have reserved the code.
This is possibly the hardest kernel operation to implement, because a list of
items does not have a hard limit on its size. For other operations, it is
possible to return a value in a register, or in a page (which needs to be
provided by the caller). But in this case, that is not guaranteed to be
possible. So I need to think about how to do this.
\section{A name for the kernel}
However, at this point I am publishing the existence of the kernel, and so I
need to give it a name. I like Greek mythology, so I decided to make it a
Greek god. Because the kernel is mostly doing communication between programs,
while the programs do the real work on the system, I thought of Hermes, the
messenger of the gods. However, I don't really like his name, and I want a
logo which is furrier than a winged boot or staff. So I chose Iris, who is
also a messenger of gods, but she has a rainbow symbol. This is much nicer for
creating a logo.
\section{Device drivers}
It's time to do some real testing of the kernel. So I've read the Linux
keyboard driver source, and implemented the same functionality in a boot
thread. During kernel load, several boot threads are started. At first, it is
just this one.
The keyboard of the device is like any other keyboard, except that it doesn't
have a keyboard controller. So the cpu must do this task itself. A keyboard
is built as a matrix of copper wires, organised in rows and columns. Every
intersection is a key. Pressing the key makes a connection between the row and
the column wire. In the Trendtac, there are 8 rows and 17 columns. All of
these lines go to a general purpose input/output pin on the cpu. The keyboard
driver sets 0 volt on each column in turn, and reads the rows, which are set as
pull-up inputs. If they are not connected, the pull-up makes them return 1.
But if the key of the column which is scanned is pressed, the 0 is connected to
the row line and 0 is read out. Thus the entire keyboard can be read.
Linux does all this in kernel space. That means it can access the GPIO ports
in kseg2 (unmapped and uncached physical memory). In user space, this is not
possible. User space programs can only use mapped memory. So the page with
the GPIO ports needs to be mapped to the device driver's address space. For
this, I added an operation to the thread capability. Not because it has
something to do with a thread, but because every process has its own thread
capability, so no special other capability is needed. I'm adding some more
priviledged operations while I'm at it: allocate physical memory to a Page
object is what I need here. Make a thread ``priviledged'', which means it can
use coprocessor 0, and perform these operations. Get a capability for the top
memory. Register an interrupt handler. I think these should be enough, but I
can always add more, because threads don't need so many operations. I also
added a debug operation, which blinks the lock leds. This operation will be
removed once the display is working.
Writing the keyboard driver was as easy as could be expected: I had some
problems with the meaning of the bits in the registers (does 1 mean input or
output?), and for some reason the above scheme was needed and doing the other
way (scanning the rows and reading the columns) didn't work. But for the rest,
it wasn't very troublesome. And I was happy to see that it is indeed possible
to address device memory through the tlb (so using a mapping). Had that not
been possible, then the device drivers would have been forced into the kernel.
The resulting keyboard driver uses maximum cpu time, because I don't have a
timer interrupt yet, and it flashes the leds when a key is pressed or released,
without telling which key it was. The final driver will be much better. Of
course it will send messages for key events instead of flashing the leds. It
will also be interrupt-driven: when no keys are pressed, all columns will be
set to 0, and all rows will be set to input with pull-up enabled and interrupt
on falling edge. Then no scanning is required. When a key is pressed, the
keyboard will be scanned periodically (on the timer interrupt) until no key is
pressed anymore. It is not possible to use an interrupt-driven approach while
a key is pressed, because there is no way to set up the lines such that there
will always be a change when a key is pressed or released. That's not a
problem: scanning doesn't take much time, and when the keyboard is being used,
the machine is active anyway. While no keys are pressed it makes sense to
minimize power consumption, so then the interrupt-driven approach is more
important.
\section{Display driver}
The next thing to write is a display driver. With a keyboard and a display, it
starts to look like a real computer. However, this proved to be a lot harder
than I expected.
First of all, it wasn't entirely clear which part of the Linux driver I needed
to copy. It has support for many displays on all kinds of mips devices, and I
only want support for the hardware in the machine. After some searching, it
seems that the Trendtac uses the ``pmpv1'' settings.
Now the display consists of two parts: the pixels and the backlight. I started
with the easy part, the backlight. It is connected to a pulse-width-modulator
(pwm) of the cpu. This means that the cpu has some logic to make very fast
pulses of well-defined width. Connecting this to a light allows software to
set the intensity of the output. This means the backlight can be dimmed.
That's nice. Or well, it should be. When copying the Linux code, I can switch
the backlight on and off, but the pwm doesn't seem to work. That's the third
counter\footnote{a pwm is implemented using a counter to determine the pulse
width} that doesn't count: the count register, the random register and the pwm.
\section{Clocks}
Because this didn't feel good, I decided to implement the timer interrupt
first. I copied some code for it from Linux and found, as I feared, that it
didn't give any interrupts. I suppose the os timer isn't running either.
However, it wasn't as bad. I simply had a bug in my timer code; the OS timer
does give interrupts. Checks to see the random register also showed that while
it doesn't run as required by the mips specification, it does auto-increment as
part of the \textit{tlbwr} instruction, which is for practical purposes just as
good (but, I suppose, costs less power).
So the only clock that isn't working is the cpu counter. This means that the
operating system timer must be used for timed interrupts, and that works fine.
After rereading the Linux driver for the display, I also found several things I
had done wrong, and after fixing them it did indeed work. The display
controller reads its data from physical memory, which means that the entire
framebuffer needs to be a continuous part of physical memory. I had to create
a new kernel call for this. Like the other priviledged calls, I added it to
the Thread capability.
\section{Debugging made easier}
So far, all debugging had to be done using blinking LEDs. This is slow and
annoying. With a working display, that was no longer needed. I added a simple
($6\cross8$) character set, and implemented a way to let the kernel send
messages which are printed on the screen. Then I changed the response to a
\textit{break} opcode to result in sending a character to the lcd as well. Now
I have a textual log output, which is much better than blinking LEDs.
Shortly after this, I encountered a bug in the kernel allocation routines.
This still needed to be debugged with blinking LEDs, because allocation was
done as part of sending messages to the display driver. This was annoying, but
now that's done as well and the text log can be used.
\section{Keyboard}
The keyboard driver works mostly as I expected it to. I added interrupts on
any change, so that it is quite normal that key changes are detected by
interrupt, which is faster than waiting for a scan. I would like to use
level-triggered interrupts, instead of edge-triggered. However, at the moment
that doesn't seem to work. I don't really care for now, although this may lead
to missed keys, so it is something to fix eventually.
\section{What is a terminal?}
Now's the time to think about more high-level features. One feature I want to
have is that a user has a session manager. This session manager can have
access to the terminal. And it can lose it. And get it again. It gets access
when the user logs in, and loses it when the user logs out. Having access
means being able to use the hardware (display, keyboard, sound, etc.). The
problem is mostly with losing the display. Getting access to the display
happens by mapping the pages into memory. The user can then share these pages,
and it will be impossible to revoke the access.
But there is a simple solution. The session manager itself is part of the
system. It is trusted by the kernel, and will behave. It will do anything the
user asks, as long as the system allows it. Each session manager can have its
own frame buffer. This is even a good idea: it means that user programs will
not have to handle things differently depending on whether the framebuffer is
available: it is always there, it may just not be visible for the user. Then
the rest of the problem is for the user to solve. The user may mess up their
own display if they want. It will not harm the main control display (used by
session managers and the login manager), or displays of other users.
\section{Defining interfaces}
The next programs to write are a \textit{block device} (the mmc and sd card
driver, or else a ramdisk), a file system, the session manager, a keyboard
translator (interpreting modifier keys and implementing key repeat) and some
sort of shell. These are more device \textit{class} interfaces than simply
interfaces for these specific devices. So it's good to design an interface for
the class, which allows other devices of the same class to use the same
interface. Then higher level programs can use both devices without noticing.
\end{document}

BIN
screen.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 45 KiB

1
source/gpio.ccp
View File

@ -1 +0,0 @@
nanonote-gpio.ccp

350
source/gpio.txt
View File

@ -1,350 +0,0 @@
GPIO control:
#define GPIO_BASE 0xB0010000
#define IRQ_GPIO3 25
#define IRQ_GPIO2 26
#define IRQ_GPIO1 27
#define IRQ_GPIO0 28
#define GPIO_IRQ_LOLEVEL 0
#define GPIO_IRQ_HILEVEL 1
#define GPIO_IRQ_FALLEDG 2
#define GPIO_IRQ_RAISEDG 3
// GP ... Registers: one set for each port of 32 pins; total 128 pins means 4 groups. Total size: 4 * 0x30 == 0xc0.
#define GPIO_GPDR(n) (GPIO_BASE + (0x00 + (n)*0x30)) // D: data
#define GPIO_GPDIR(n) (GPIO_BASE + (0x04 + (n)*0x30)) // DI: data in: 0 is input; 1 is output. Disable interrupts on the pin before touching this.
#define GPIO_GPODR(n) (GPIO_BASE + (0x08 + (n)*0x30)) // OD:
#define GPIO_GPPUR(n) (GPIO_BASE + (0x0c + (n)*0x30)) // PU: pull-up (1 is enable)
#define GPIO_GPALR(n) (GPIO_BASE + (0x10 + (n)*0x30)) // AL: alternate lower: per 2 bit; 00 means use as gpio; other values mean use as alternate function
#define GPIO_GPAUR(n) (GPIO_BASE + (0x14 + (n)*0x30)) // AU: alternate upper: same thing, needs 2 registers because it's 2 bits per pin.
#define GPIO_GPIDLR(n) (GPIO_BASE + (0x18 + (n)*0x30)) // IDL: interrupt detect lower: per 2 bit (GPIO_IRQ_*)
#define GPIO_GPIDUR(n) (GPIO_BASE + (0x1c + (n)*0x30)) // IDU: interrupt detect upper: same thing, upper 16 bit
#define GPIO_GPIER(n) (GPIO_BASE + (0x20 + (n)*0x30)) // IE: interrupt enable (0 is disable)
#define GPIO_GPIMR(n) (GPIO_BASE + (0x24 + (n)*0x30)) // IM:
#define GPIO_GPFR(n) (GPIO_BASE + (0x28 + (n)*0x30)) // F: flag: set on interrupt; cleared by user.
#define IRQ_GPIO_0 48
#define NUM_GPIO 128
// Pins for alternate functions:
#define __gpio_as_ssi() \
do { \
REG_GPIO_GPALR(2) &= 0xFC00FFFF; \
REG_GPIO_GPALR(2) |= 0x01550000; \
} while (0)
#define __gpio_as_uart3() \
do { \
REG_GPIO_GPAUR(0) &= 0xFFFF0000; \
REG_GPIO_GPAUR(0) |= 0x00005555; \
} while (0)
#define __gpio_as_uart2() \
do { \
REG_GPIO_GPALR(3) &= 0x3FFFFFFF; \
REG_GPIO_GPALR(3) |= 0x40000000; \
REG_GPIO_GPAUR(3) &= 0xF3FFFFFF; \
REG_GPIO_GPAUR(3) |= 0x04000000; \
} while (0)
#define __gpio_as_uart1() \
do { \
REG_GPIO_GPAUR(0) &= 0xFFF0FFFF; \
REG_GPIO_GPAUR(0) |= 0x00050000; \
} while (0)
#define __gpio_as_uart0() \
do { \
REG_GPIO_GPAUR(3) &= 0x0FFFFFFF; \
REG_GPIO_GPAUR(3) |= 0x50000000; \
} while (0)
#define __gpio_as_scc0() \
do { \
REG_GPIO_GPALR(2) &= 0xFFFFFFCC; \
REG_GPIO_GPALR(2) |= 0x00000011; \
} while (0)
#define __gpio_as_scc1() \
do { \
REG_GPIO_GPALR(2) &= 0xFFFFFF33; \
REG_GPIO_GPALR(2) |= 0x00000044; \
} while (0)
#define __gpio_as_scc() \
do { \
__gpio_as_scc0(); \
__gpio_as_scc1(); \
} while (0)
#define __gpio_as_dma() \
do { \
REG_GPIO_GPALR(0) &= 0x00FFFFFF; \
REG_GPIO_GPALR(0) |= 0x55000000; \
REG_GPIO_GPAUR(0) &= 0xFF0FFFFF; \
REG_GPIO_GPAUR(0) |= 0x00500000; \
} while (0)
#define __gpio_as_msc() \
do { \
REG_GPIO_GPALR(1) &= 0xFFFF000F; \
REG_GPIO_GPALR(1) |= 0x00005550; \
} while (0)
#define __gpio_as_pcmcia() \
do { \
REG_GPIO_GPAUR(2) &= 0xF000FFFF; \
REG_GPIO_GPAUR(2) |= 0x05550000; \
} while (0)
#define __gpio_as_emc(csmask) \
do { \
REG_GPIO_GPALR(2) &= 0x3FFFFFFF; \
REG_GPIO_GPALR(2) |= 0x40000000; \
REG_GPIO_GPAUR(2) &= 0xFFFF0000; \
REG_GPIO_GPAUR(2) |= 0x00005555; \
} while (0)
#define __gpio_as_lcd_slave() \
do { \
REG_GPIO_GPALR(1) &= 0x0000FFFF; \
REG_GPIO_GPALR(1) |= 0x55550000; \
REG_GPIO_GPAUR(1) &= 0x00000000; \
REG_GPIO_GPAUR(1) |= 0x55555555; \
} while (0)
#define __gpio_as_lcd_master() \
do { \
REG_GPIO_GPALR(1) &= 0x0000FFFF; \
REG_GPIO_GPALR(1) |= 0x55550000; \
REG_GPIO_GPAUR(1) &= 0x00000000; \
REG_GPIO_GPAUR(1) |= 0x556A5555; \
} while (0)
#define __gpio_as_usb() \
do { \
REG_GPIO_GPAUR(0) &= 0x00FFFFFF; \
REG_GPIO_GPAUR(0) |= 0x55000000; \
} while (0)
#define __gpio_as_ac97() \
do { \
REG_GPIO_GPALR(2) &= 0xC3FF03FF; \
REG_GPIO_GPALR(2) |= 0x24005400; \
} while (0)
#define __gpio_as_i2s_slave() \
do { \
REG_GPIO_GPALR(2) &= 0xC3FF0CFF; \
REG_GPIO_GPALR(2) |= 0x14005100; \
} while (0)
#define __gpio_as_i2s_master() \
do { \
REG_GPIO_GPALR(2) &= 0xC3FF0CFF; \
REG_GPIO_GPALR(2) |= 0x28005100; \
} while (0)
#define __gpio_as_eth() \
do { \
REG_GPIO_GPAUR(3) &= 0xFC000000; \
REG_GPIO_GPAUR(3) |= 0x01555555; \
} while (0)
#define __gpio_as_pwm() \
do { \
REG_GPIO_GPAUR(2) &= 0x0FFFFFFF; \
REG_GPIO_GPAUR(2) |= 0x50000000; \
} while (0)
#define __gpio_as_ps2() \
do { \
REG_GPIO_GPALR(1) &= 0xFFFFFFF0; \
REG_GPIO_GPALR(1) |= 0x00000005; \
} while (0)
#define __gpio_as_uprt() \
do { \
REG_GPIO_GPALR(1) &= 0x0000000F; \
REG_GPIO_GPALR(1) |= 0x55555550; \
REG_GPIO_GPALR(3) &= 0xC0000000; \
REG_GPIO_GPALR(3) |= 0x15555555; \
} while (0)
#define __gpio_as_cim() \
do { \
REG_GPIO_GPALR(0) &= 0xFF000000; \
REG_GPIO_GPALR(0) |= 0x00555555; \
} while (0)
// Pins on the trendtac:
0.00 keyboard
0.01 keyboard
0.02 keyboard
0.03 keyboard
0.04 keyboard
0.05 keyboard
0.06 keyboard
0.07 keyboard
0.08 keyboard interrupt?
0.09
0.10
0.11
0.12
0.13 touchpad right button
0.14
0.15
0.16 touchpad left button
0.17
0.18
0.19
0.20
0.21
0.22
0.23
0.24
0.25
0.26
0.27
0.28
0.29
0.30
0.31
1.00
1.01
1.02
1.03
1.04
1.05
1.06
1.07
1.08
1.09
1.10
1.11
1.12
1.13
1.14
1.15
1.16
1.17
1.18
1.19
1.20
1.21
1.22
1.23
1.24
1.25
1.26
1.27
1.28
1.29
1.30
1.31
2.00 SPEN: lcd enable
2.01 SPCK: lcd clock
2.02 SPDA: lcd data
2.03 LCD_RET: lcd reset
2.04
2.05
2.06
2.07
2.08
2.09
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
2.19
2.20
2.21
2.22
2.23
2.24
2.25
2.26
2.27
2.28
2.29
2.30 PWM enable (for lcd backlight)
2.31
3.00 keyboard
3.01 keyboard
3.02 keyboard
3.03 keyboard
3.04 keyboard
3.05 keyboard
3.06 keyboard
3.07 keyboard
3.08 keyboard
3.09 keyboard
3.10 keyboard
3.11 keyboard
3.12 keyboard
3.13 keyboard
3.14 keyboard
3.15 keyboard
3.16
3.17
3.18
3.19
3.20
3.21
3.22
3.23
3.24
3.25
3.26
3.27
3.28
3.29 keyboard
3.30
3.31
Devices enabled in linux:
+ __harb_usb0_uhc();
+ __gpio_as_emc();
+ __gpio_as_uart0();
+ __gpio_as_dma();
+ __gpio_as_eth();
+ __gpio_as_usb();
+ __gpio_as_lcd_master();
+#if defined(CONFIG_I2S_AK4642EN)
+//wjx __gpio_as_scc1();
+ __gpio_as_i2s_master(); //wjx
+#endif
+#if defined(CONFIG_I2S_TSC2301) || defined(CONFIG_I2S_TLC320AIC23)
+ __gpio_as_ssi();
+#endif
+ //__gpio_as_ac97();
+#if defined(CONFIG_I2S_TSC2301) || defined(CONFIG_I2S_TLC320AIC23) || defined(CONFIG_I2S_CS42L51)
+ __gpio_as_i2s_slave();
+#endif
+//wjx __gpio_as_cim();
+ __gpio_as_msc();
+
+/* wjx
+ __gpio_as_output(GPIO_LED_EN);
+ __gpio_set_pin(GPIO_LED_EN);
+
+ __gpio_as_output(GPIO_DISP_OFF_N);
+ __gpio_set_pin(GPIO_DISP_OFF_N);
+*/
+ __gpio_as_output(GPIO_PWM0);
+ __gpio_set_pin(GPIO_PWM0);
+
+
+//wjx __gpio_as_input(GPIO_RTC_IRQ);
+ __gpio_as_output(GPIO_USB_CLK_EN);
+ __gpio_set_pin(GPIO_USB_CLK_EN);

6
source/alarm.ccp → userspace/application/alarm.ccp
View File

@ -1,4 +1,5 @@
#pypp 0
// vim: set filetype=cpp : //
#include <iris.hh>
#include <devices.hh>
@ -23,16 +24,15 @@ Iris::Num start ():
Iris::my_parent.provide_capability <Iris::Event> (self)
cap = Iris::my_receiver.create_capability (INTERRUPT)
Iris::my_parent.init_done ()
font.printf ("Press a key to attempt reboot.\n")
while true:
Iris::wait ()
switch Iris::recv.protected_data.l:
case INTERRUPT:
// Interrupt
// RTC alarm interrupt.
if Iris::recv.data[0].l == ~0:
// Not a real interrupt, just an abort notification.
continue
font.printf ("alarm: interrupt\n")
font.printf ("alarm: RTC alarm interrupt\n")
break
case CONTROL:
// Store callback

0
source/ball.ccp → userspace/application/ball.ccp
View File

0
source/booter.ccp → userspace/application/booter.ccp
View File

0
source/bsquare.ccp → userspace/application/bsquare.ccp
View File

0
source/metronome.ccp → userspace/application/metronome.ccp
View File

0
source/test.ccp → userspace/application/test.ccp
View File

5
source/bootinit.ccp → userspace/boot/bootinit.ccp
View File

@ -320,15 +320,10 @@ Iris::Num start ():
Iris::Memory top_memory = Iris::get_top_memory ()
Iris::Directory root = receive_devices ()
root.lock_ro ()
kdebug_line ()
Iris::Block run_block = find (root, ELFRUN_NAME)
kdebug_line ()
Iris::Cap parent_cap = Iris::my_receiver.create_capability (0)
kdebug_line ()
run (run_block, top_memory, parent_cap)
kdebug_line ()
Iris::wait ()
kdebug_line ()
if Iris::recv.data[0].l != Iris::Parent::PROVIDE_CAPABILITY || Iris::recv.data[1].l != Iris::Elfrun::ID:
Iris::panic (0, "elfrun doesn't provide correct capability")
Iris::Cap reply = Iris::get_reply ()

0
source/crt0.ccp → userspace/boot/crt0.ccp
View File

0
source/init.ccp → userspace/boot/init.ccp
View File

8
mkthreadlist → userspace/boot/mkthreadlist
View File

@ -1,4 +1,4 @@
#!/bin/sh
#!/bin/bash
cat << EOF
.globl init_start
.globl thread_start
@ -8,8 +8,8 @@ EOF
for i in "$@" ; do
cat << EOF
$i:
.incbin "fs/$i.elf"
${i##*/}:
.incbin "fs/${i##*/}.elf"
.balign 0x1000
EOF
done
@ -22,7 +22,7 @@ EOF
for i in "$@" ; do
cat << EOF
.word $i
.word ${i##*/}
EOF
done

0
source/charset → userspace/data/charset
View File

0
courier-10+8+32.png → userspace/data/courier-10+8+32.png
View File

Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 1.8 KiB

After

Width:  |  Height:  |  Size: 1.8 KiB

0
courier.xcf → userspace/data/courier.xcf
View File

0
init.config → userspace/data/init.config
View File

0
makefont → userspace/data/makefont
View File

0
source/buffer.ccp → userspace/glue/buffer.ccp
View File

0
source/elfrun.ccp → userspace/glue/elfrun.ccp
View File

0
source/fat.ccp → userspace/glue/fat.ccp
View File

0
source/font.ccp → userspace/glue/font.ccp
View File

0
source/gui.ccp → userspace/glue/gui.ccp
View File

0
source/partition.ccp → userspace/glue/partition.ccp
View File

0
source/usbmassstorage.ccp → userspace/glue/usbmassstorage.ccp
View File

1
userspace/hardware Symbolic link
View File

@ -0,0 +1 @@
nanonote

0
source/boot.ccp → userspace/nanonote/boot.ccp
View File

0
source/buzzer.ccp → userspace/nanonote/buzzer.ccp
View File

0
source/nanonote-gpio.ccp → userspace/nanonote/gpio.ccp
View File

2
source/lcd.ccp → userspace/nanonote/lcd.ccp
View File

@ -20,7 +20,7 @@
#define ARCH
#include "arch.hh"
__asm__ volatile (".section .rodata\n.globl charset\ncharset:\n.incbin \"source/charset.data\"\n.section .text")
__asm__ volatile (".section .rodata\n.globl charset\ncharset:\n.incbin \"source/data/charset.data\"\n.section .text")
extern unsigned char const charset[127-32][8][6]
#define assert(x) do { if (!(x)) { kdebug ("assertion failed " #x); while (true) {} } } while (0)

0
source/nand.ccp → userspace/nanonote/nand.ccp
View File

18
source/rtc.ccp → userspace/nanonote/rtc.ccp
View File

@ -53,6 +53,8 @@ Iris::Num start ():
rtc_set_second (0)
ready ()
rtc_set_alarm_second (0)
ready ()
rtc_set_scratch_pattern (0xbeefface)
ready ()
rtc_disable_alarm ()
ready ()
@ -62,13 +64,11 @@ Iris::Num start ():
ready ()
rtc_disable_1Hz_irq ()
ready ()
rtc_set_hwfcr_val (0)
rtc_set_hwfcr_val (0x1e0)
ready ()
rtc_set_hrcr_val (0)
rtc_set_hrcr_val (0xfe0)
ready ()
rtc_enable_alarm_wakeup ()
ready ()
rtc_set_scratch_pattern (0xbeefface)
rtc_disable_alarm_wakeup ()
Iris::RTC self = Iris::my_receiver.create_capability (1)
Iris::my_parent.provide_capability <Iris::RTC> (self.copy ())
Iris::free_cap (self)
@ -81,6 +81,8 @@ Iris::Num start ():
// Interrupt.
ready ()
rtc_disable_alarm ()
ready ()
rtc_disable_alarm_wakeup ()
if have_interrupt:
interrupt.invoke (0)
Iris::free_cap (interrupt)
@ -118,14 +120,14 @@ Iris::Num start ():
Iris::unregister_interrupt (IRQ_RTC)
ready ()
rtc_disable_alarm ()
ready ()
rtc_disable_alarm_wakeup ()
reply.invoke ()
Iris::free_cap (reply)
case Iris::RTC::SET_ALARM:
Iris::Cap reply = Iris::get_reply ()
Iris::Cap arg = Iris::get_arg ()
unsigned alarm = Iris::recv.data[1].l
ready ()
rtc_clear_alarm_flag ()
if have_interrupt:
Iris::debug ("not registering irq\n")
interrupt.invoke (~0)
@ -141,6 +143,8 @@ Iris::Num start ():
rtc_clear_alarm_flag ()
ready ()
rtc_enable_alarm ()
ready ()
rtc_enable_alarm_wakeup ()
reply.invoke ()
Iris::free_cap (reply)
break

0
source/sdmmc.ccp → userspace/nanonote/sdmmc.ccp
View File

1
source/udc.ccp → userspace/nanonote/udc.ccp
View File

@ -552,7 +552,6 @@ enum pdata:
NAME
Iris::Num start ():
Iris::debug ("udc started")
map_udc ()
map_gpio ()
map_cpm ()

0
source/trendtac-gpio.ccp → userspace/trendtac/trendtac-gpio.ccp
View File