diff --git a/doc/build-system.txt b/doc/build-system.txt
deleted file mode 100644
index e950b1710..000000000
--- a/doc/build-system.txt
+++ /dev/null
@@ -1,95 +0,0 @@
-/**
- \ingroup tutorials
- \defgroup buildsystem The \os build system
-
- The \os build system is designed to make it easy to compile
- \os applications for either to a hardware platform or into a
- simulation platform by simply supplying different parameters to the
- make command, without having to edit makefiles or modify
- the application code.
-
- The file example project in examples/hello-world/ shows how the
- \os build system works. The hello-world.c application
- can be built into a complete \os system by running make
- in the examples/hello-world/ directory. Running make without
- parameters will build a \os system using the native
- target. The native target is a special \os platform that
- builds an entire \os system as a program that runs on the
- development system. After compiling the application for the
- native target it is possible to run the \os system with
- the application by running the file hello-world.native.
-
- To compile the hello-world application into a stand-alone executable
- that can be loaded into a running \os system, the command
- make hello-world.ce is used. To build an executable file for
- the Sky platform, make TARGET=sky hello-world.sky is run.
-
- To avoid having to type TARGET= every time make is
- run, it is possible to run make TARGET=sky savetarget to
- save the selected target as the default target platform for
- subsequent invocations of make. A file called
- Makefile.target containing the currently saved target is
- saved in the project's directory.
-
- \section buildsystem-makefiles Makefiles used in the \os build system
-
- The \os build system is composed of a number of Makefiles. These
- are:
- - Makefile: the project's makefile, located in the project directory.
- - Makefile.include: the system-wide \os makefile,
- located in the root of the \os source tree.
- - Makefile.\$(TARGET) (where \$(TARGET) is the name of the
- platform that is currently being built): rules for the specific
- platform, located in the platform's subdirectory in the platform/ directory.
- - Makefile.\$(CPU) (where \$(CPU) is the name of the CPU or
- microcontroller architecture used on the platform for which \os
- is built): rules for the CPU architecture, located in the CPU
- architecture's subdirectory in the cpu/ directory.
- - Makefile.\$(MODULE) (where \$(MODULE) is the name of a
- module in the Contiki directory): rules for modules in the
- Contiki directories. Each module might have its own optional makefile.
-
- The Makefile in the project's directory is intentionally simple. It
- specifies where the \os source code resides in the system and
- includes the system-wide Makefile, Makefile.include. The
- project's makefile can also define in the MODULES variable a
- list of modules that should be included in the \os system.
- The Makefile used in the hello-world example project looks like this:
-
- \code
-CONTIKI = ../..
-all: hello-world
-include $(CONTIKI)/Makefile.include
- \endcode
-
- First, the location of the \os source code tree is given by
- defining the CONTIKI variable. Next, the name of the
- application is defined. Finally, the system-wide
- Makefile.include is included.
-
- The Makefile.include contains definitions of the C files of
- the core \os system. Makefile.include always reside in
- the root of the \os source tree. When make is run,
- Makefile.include includes the Makefile.\$(TARGET)
- as well as all makefiles for the modules in the MODULES
- list (which is specified by the project's Makefile).
-
- Makefile.\$(TARGET), which is located in the
- platform/\$(TARGET)/ directory, contains the list of C files that the
- platform adds to the \os system. This list is defined by the
- CONTIKI_TARGET_SOURCEFILES variable. The
- Makefile.\$(TARGET) also includes the
- Makefile.\$(CPU) from the cpu/\$(CPU)/ directory.
-
- The Makefile.\$(CPU) typically contains definitions for the
- C compiler used for the particular CPU. If multiple C compilers are
- used, the Makefile.\$(CPU) can either contain a conditional
- expression that allows different C compilers to be defined, or it can
- be completely overridden by the platform specific makefile
- Makefile.\$(TARGET).
-@{
- */
-
- /**
- @}
- */
diff --git a/doc/code-style.c b/doc/code-style.c
deleted file mode 100644
index 9cfab8963..000000000
--- a/doc/code-style.c
+++ /dev/null
@@ -1,137 +0,0 @@
-/**
- * \defgroup coding-style Coding style
- *
- * This is how a Doxygen module is documented - start with a \defgroup
- * Doxygen keyword at the beginning of the file to define a module,
- * and use the \addtogroup Doxygen keyword in all other files that
- * belong to the same module. Typically, the \defgroup is placed in
- * the .h file and \addtogroup in the .c file.
- *
- * The Contiki source code contains an Uncrustify configuration file,
- * uncrustify.cfg, under tools/code-style and small helper scripts are
- * provided at the same place. Note that this is not a silver bullet -
- * for example, the script does not add separators between functions,
- * nor does it format comments correctly. The script should be treated
- * as an aid in formatting code: first run the formatter on the source
- * code, then manually edit the file.
- *
- * @{
- */
-
-/**
- * \file
- * A brief description of what this file is.
- * \author
- * Adam Dunkels
- *
- * Every file that is part of a documented module has to have
- * a \file block, else it will not show up in the Doxygen
- * "Modules" * section.
- */
-
-/* Single line comments look like this. */
-
-/*
- * Multi-line comments look like this. Comments should prefferably be
- * full sentences, filled to look like real paragraphs.
- */
-
-#include "contiki.h"
-
-/*
- * Make sure that non-global variables are all maked with the static
- * keyword. This keeps the size of the symbol table down.
- */
-static int flag;
-
-/*
- * All variables and functions that are visible outside of the file
- * should have the module name prepended to them. This makes it easy
- * to know where to look for function and variable definitions.
- *
- * Put dividers (a single-line comment consisting only of dashes)
- * between functions.
- */
-/*---------------------------------------------------------------------------*/
-/**
- * \brief Use Doxygen documentation for functions.
- * \param c Briefly describe all parameters.
- * \return Briefly describe the return value.
- * \retval 0 Functions that return a few specified values
- * \retval 1 can use the \retval keyword instead of \return.
- *
- * Put a longer description of what the function does
- * after the preamble of Doxygen keywords.
- *
- * This template should always be used to document
- * functions. The text following the introduction is used
- * as the function's documentation.
- *
- * Function prototypes have the return type on one line,
- * the name and arguments on one line (with no space
- * between the name and the first parenthesis), followed
- * by a single curly bracket on its own line.
- */
-int
-code_style_example_function(char c)
-{
- /*
- * Local variables should always be declared at the start of the
- * function.
- */
- int i; /* Use short variable names for loop
- counters. */
-
- /*
- * There should be no space between keywords and the first
- * parenthesis. There should be spaces around binary operators, no
- * spaces between a unary operator and its operand.
- *
- * Curly brackets following for(), if(), do, and switch() statements
- * should follow the statement on the same line.
- */
- for(i = 0; i < 10; ++i) {
- /*
- * Always use full blocks (curly brackets) after if(), for(), and
- * while() statements, even though the statement is a single line
- * of code. This makes the code easier to read and modifications
- * are less error prone.
- */
- if(i == c) {
- return 1; /* No parentesis around return values. */
- } else { /* The else keyword is placed inbetween
- curly brackers, always on its own line. */
- c++;
- }
- }
-
- /*
- * Indent "case" statement and "default" label by two spaces in "switch"
- * statement.
- */
- switch(c) {
- case 19:
- return 1;
- default:
- break;
- }
-
- return 0;
-}
-/*---------------------------------------------------------------------------*/
-/*
- * Static (non-global) functions do not need Doxygen comments. The
- * name should not be prepended with the module name - doing so would
- * create confusion.
- */
-static void
-an_example_function(void)
-{
-
-}
-/*---------------------------------------------------------------------------*/
-
-/* The following stuff ends the \defgroup block at the beginning of
- the file: */
-
-/** @} */
diff --git a/doc/mainpage.txt b/doc/mainpage.txt
index fba214d42..3a62b4d61 100644
--- a/doc/mainpage.txt
+++ b/doc/mainpage.txt
@@ -2,87 +2,8 @@
\mainpage The \os Operating System
-\os is an operating system for resource-constrained devices in the
-Internet of Things. \os contains a low-power IPv6 communication stack,
-\ref uip "uIP". uIP is a small RFC-compliant TCP/IP stack that makes
-it possible for \os to communicate over the Internet. The system runs
-on a variety of platforms based on energy-efficient architectures such
-as the ARM Cortex-M3 and the Texas Instruments MSP430. The code
-footprint is on the order of a 100 kb, and the memory usage can be
-configured to be as low as 10 kb.
-
-In 2017, \os started as a fork of the Contiki operating system with
-the purpose of making a system focused on standard low-power IPv6
-communication in the IoT. Another important goal is to have a regular
-release cycle and enhanced documentation. Although both systems at the
-beginning have many common interfaces and modules, we expect them to
-diverge considerably in the future.
-
-Most of \os is written in the standard C programming language, with
-the exception of some architecture-specific code that may use compiler
-extensions and assembly language. The source code is available as open
-source with a 3-clause BSD license.
-
-\section mainpage-getting-started Getting started with \os
-
-\os is designed to run on many different \ref platform "platforms". It
-is also possible to compile and build both the \os system and \os
-applications on many different development platforms.
-
-\section mainpage-building Building the \os system and its applications
-
- The \os build system is designed to make it easy to compile
- \os applications for either to a hardware platform or into a
- simulation platform by simply supplying different parameters to the
- make command, without having to edit makefiles or modify
- the application code.
-
-See \ref buildsystem
-
-\section mainpage-tcpip Low-Power IPv6 Networking
-
-One of the main features of \os is a resource-efficient IPv6 network
-stack designed for lossy and low-power networks. The network stack
-comprises protocols such as IPv6, TCP, UDP, DNS, RPL, CoAP, LWM2M, and
-Websockets. Beneath the IPv6 stack, \os supports IEEE 802.15.4
-wireless communication with Time-Slotted Channel Hopping (TSCH).
-
-\sa \ref uip "The uIP TCP/IP stack documentation"
-\sa \ref tcpip "The \os/uIP interface"
-\sa \ref psock "Protosockets library"
-
-\section mainpage-threads Application Development
-
-Applications in \os are implemented using processes, which are based
-on a programming abstraction called Protothreads. Protothreads is
-essentially a lightweight stackless thread-like construct, allowing
-highly efficient context switching.
-
-A process is scheduled by an event-driven kernel after an event has
-been sent to the process, either from the kernel of from another
-process. Such events can be the result of a timer expiring, a sensor
-value changing, or a network packet having been received. Once
-scheduled, each process is responsible for yielding control back to
-the scheduler without executing for too long, which is typically done
-by waiting for an event. Alternatively, applications can also use the
-\ref mt, which supports a more traditional thread model with one stack
-per thread.
-
-\sa \ref process "Processes"
-\sa \ref pt "Protothreads"
-\sa \ref etimer "Event timers"
-\sa \ref ctimer "Callback timers"
-\sa \ref mt "Optional multi-threading"
-
-\section mainpage-lib Libraries
-
-\os provides a set of convenience libraries for common programming
-functionality, including memory management and data structures.
-
-\sa \ref memb "Memory block management"
-\sa \ref heapmem "Heap memory allocator"
-\sa \ref list "Linked list library"
-\sa \ref ringbuf "Ring buffer library"
-\sa \ref trickle-timer "Trickle timer"
+This is the code documentation for \os. More documentation, including
+feature description, tutorials etc, can be found at
+https://github.com/sics-iot/contiki/wiki.
*/
diff --git a/doc/modules.txt b/doc/modules.txt
index fce384f0e..7ece82e8b 100644
--- a/doc/modules.txt
+++ b/doc/modules.txt
@@ -119,12 +119,3 @@ This module contains protothreads, multithreading and processes
This module contains all different timers and clocks in \os
* \ingroup sys
*/
-
-/**
- * \defgroup tutorials Tutorials
-This module contains all \os related tutorials.
-*/
-
-/**
- \example code-style.c
- */