From 48976e48e7e34df746914e9f0b19ea59285975f0 Mon Sep 17 00:00:00 2001
From: Armin Luntzer <armin.luntzer@univie.ac.at>
Date: Wed, 23 Sep 2020 12:30:01 +0200
Subject: [PATCH] finally rename LeanOS -> (Vienna) Flight OS
---
.gitignore | 2 +-
.../OS/architecture/architectural_design.tex | 44 ++++----
Documentation/OS/paplan/paplan.tex | 26 ++---
.../OS/requirements/software_requirements.tex | 106 +++++++++---------
Documentation/OS/shared/bibliography.bib | 24 ++--
Documentation/OS/testplan/testplan.tex | 46 ++++----
Documentation/OS/testreport/testreport.tex | 26 ++---
.../testspecification/testspecification.tex | 24 ++--
Documentation/OS/usermanual/usermanual.tex | 28 ++---
Documentation/doxygen/Doxyfile | 2 +-
Documentation/doxygen/doxy-boot.js | 2 +-
Kconfig | 2 +-
Makefile | 82 +++++++-------
.../sparc/kernel/{leanos.lds => flightos.lds} | 0
dsp/xentium/Makefile | 2 +-
gr712_demo-config | 2 +-
gr740_demo-config | 2 +-
scripts/{link-leanos.sh => link-flightos.sh} | 102 ++++++++---------
tools/testing/hwtests/application/README | 2 +-
tools/testing/hwtests/application/config | 2 +-
.../testing/hwtests/application/config-gr740 | 2 +-
tools/testing/hwtests/application/grmon_cmds | 2 +-
.../hwtests/xen_proc_net/.run_test.sh.swp | Bin 12288 -> 12292 bytes
tools/testing/hwtests/xen_proc_net/README | 2 +-
tools/testing/hwtests/xen_proc_net/config | 2 +-
.../testing/hwtests/xen_proc_net/run_test.sh | 2 +-
26 files changed, 268 insertions(+), 268 deletions(-)
rename arch/sparc/kernel/{leanos.lds => flightos.lds} (100%)
rename scripts/{link-leanos.sh => link-flightos.sh} (72%)
diff --git a/.gitignore b/.gitignore
index 32fda73..ef4a074 100644
--- a/.gitignore
+++ b/.gitignore
@@ -50,7 +50,7 @@ modules.builtin
#
/tags
/TAGS
-/leanos
+/flightos
/System.map
/Module.markers
diff --git a/Documentation/OS/architecture/architectural_design.tex b/Documentation/OS/architecture/architectural_design.tex
index cf26c42..1bbfc89 100644
--- a/Documentation/OS/architecture/architectural_design.tex
+++ b/Documentation/OS/architecture/architectural_design.tex
@@ -1,7 +1,7 @@
\title{Architectural Design Document}
-\def \documentid {LEANOS-UVIE-ADD-001}
+\def \documentid {FLIGHTOS-UVIE-ADD-001}
\date{Issue 1.0, June 1, 2017}
\newcommand\affil[1]{\textsuperscript#1}
@@ -65,8 +65,8 @@
\section{Purpose of the Document}
This document specifies the software architecture for the operating system
-kernel LeanOS. This document targets developers, testers and advanced users of
-LeanOS. It is assumed that the reader is familiar with the user requirements
+kernel FlightOS. This document targets developers, testers and advanced users of
+FlightOS. It is assumed that the reader is familiar with the user requirements
and/or the software user manual. \\
@@ -79,7 +79,7 @@ found in Annex F of ECSS-E-ST-40C \cite{ECSS40C}.
The architectural design aims to be at a high degree of encapsulation, with a
comparatively restricted number of system call interfaces to user space.
-The user \gls{API} of LeanOS will orient itself to \gls{POSIX} standards where
+The user \gls{API} of FlightOS will orient itself to \gls{POSIX} standards where
applicable. Extra functionality that is typically found in supporting
C libraries is part of the user space and must be implemented accordingly.
@@ -105,12 +105,12 @@ C libraries is part of the user space and must be implemented accordingly.
\begin{figure}[htb]
\begin{center}
\includegraphics[width=0.4\columnwidth]{images/OS_fundamental_architecture}
- \caption{The fundamental architecture of LeanOS}
+ \caption{The fundamental architecture of FlightOS}
\label{fig:fundamental_architecture}
\end{center}
\end{figure}
-The fundamental architecture of LeanOS is shown in
+The fundamental architecture of FlightOS is shown in
\fig{fig:fundamental_architecture}. At the top is the user space, where user
applications are set up and executed. The C library is part of the user space.
It provides the system call interface that connects the user to kernel space
@@ -120,7 +120,7 @@ space. Here, the tasks of the operating system kernel are executed.
Kernel space can be further divided into three gross layers. At the top is the
system call interface, which implements any I/O functionality to the user space.
Below the system call interface is the architecture-independent kernel code.
-While LeanOS is not designed with a high degree of portability in mind, it is
+While FlightOS is not designed with a high degree of portability in mind, it is
nonetheless sensible not to mix hardware dependent code into layers that run
on abstract functional concepts. On the lowest level sits the
architecture-dependent code, which forms what is typically called a \gls{BSP}.
@@ -129,13 +129,13 @@ This code serves as platform-specific glue to the underlying hardware.
\section{Software Dynamic Architecture}
-LeanOS itself has no real time requirements. It does offer real time support for
+FlightOS itself has no real time requirements. It does offer real time support for
threads in both kernel and user space, these are however specific to the
implementation of user space code or drivers/modules.
\section{Software Behaviour}
-The behaviour of LeanOS is configuration-dependent. Usually, the kernel will
+The behaviour of FlightOS is configuration-dependent. Usually, the kernel will
configure itself and the hardware, followed by user space initialisation.
Without user space, all actions by the drivers or other subcomponents will be
@@ -147,13 +147,13 @@ drivers will usually ignore their inputs and drop all received.
\section{Interfaces Context}
-The internal and external software interfaces of LeanOS are described as part
+The internal and external software interfaces of FlightOS are described as part
of its source code in Doxygen markup, from which a document can be generated.
\section{Long Lifetime Software}
-LeanOS is designed with the \gls{SSDP} as a target platform. To allow re-use
-and adaptation to new hardware, the software components of LeanOS are designed
+FlightOS is designed with the \gls{SSDP} as a target platform. To allow re-use
+and adaptation to new hardware, the software components of FlightOS are designed
to be modular. Unless neeeded for particular drivers, all hardware access is
abstracted into a separate layer as much as possible, so improved portability
is ensured.
@@ -161,7 +161,7 @@ is ensured.
\section{Memory and CPU Budget}
-LeanOS is designed to work within the constraints of the \gls{SSDP} hardware
+FlightOS is designed to work within the constraints of the \gls{SSDP} hardware
specification. Care is taken to minimise overheads, but run time needs of the
user ultimately define memory and CPU usage of the operating system.
@@ -171,7 +171,7 @@ user ultimately define memory and CPU usage of the operating system.
The high level design of software functionality is done with the help of
\emph{yEd}, which is a general-purpose diagramming program supporting the
creation of UML, flowcharts and entitiy relationship diagrams.
-LeanOS is written primarily in C, hence certain restrictions apply in the use of
+FlightOS is written primarily in C, hence certain restrictions apply in the use of
UML, which is mainly used of object oriented programming languages such as C++.
\\
@@ -180,16 +180,16 @@ or communication between components. The detailed internal functional design of
a component is left to the implementation and is described as part of the
version dependent issue of the source code. This is done to ensure that a
certain amount of flexibility is present in the implementation and changes that
-do not affect the fundamental design architecture of LeanOS can be applied
+do not affect the fundamental design architecture of FlightOS can be applied
quickly and efficiently, since it is foremost a tool to the user with the
purpose of creating a run-time, not a product implementing a well constrained
task.\\
-The Linux kernel coding style is applied to all C code in LeanOS. Its use is
+The Linux kernel coding style is applied to all C code in FlightOS. Its use is
enforced by the \emph{checkpatch.pl} utility found in the Linux kernel source
tree.\\
-No external software packages are reused in the implementation of LeanOS.
+No external software packages are reused in the implementation of FlightOS.
\chapter{Software Design}
@@ -198,7 +198,7 @@ No external software packages are reused in the implementation of LeanOS.
\section{General}
-The purpose of LeanOS is to create an operating system that is easy to use and on
+The purpose of FlightOS is to create an operating system that is easy to use and on
point with regard to the features of the target platform. Still, it is designed
to be flexible enough that the operating system kernel may be used with other
(\gls{LEON3}) platforms. One of its distinguishing features is its focus on
@@ -226,7 +226,7 @@ matrix.
\begin{figure}[htb]
\begin{center}
\includegraphics[width=\columnwidth]{../requirements/images/OS_logical}
- \caption{The architectural model of LeanOS. Here, the "hardware" layer
+ \caption{The architectural model of FlightOS. Here, the "hardware" layer
represents both the hardware and the hardware abstraction layer of
the software.}
\label{fig:logical_model}
@@ -234,7 +234,7 @@ matrix.
\end{figure}
-In LeanOS, the \gls{SSDP} hardware is accessed in multiple layers of
+In FlightOS, the \gls{SSDP} hardware is accessed in multiple layers of
abstraction (see \fig{fig:logical_model}). Typical \gls{CPU} tasks such as
thread/task management and timer operation are used as part of the operating
system kernel and are also accessible by user applications via a system call
@@ -255,7 +255,7 @@ modes or usage statistics may be exported by individual components for external
\design{GEN-0001}%
{Boot}{%
-This is the hardware entry point of LeanOS. The boot procedure sets up and
+This is the hardware entry point of FlightOS. The boot procedure sets up and
configures the \gls{LEON3-FT} processor for operation, initialises a minimum set of
needed hardware devices and memories as well as the initial system stack.
}%
@@ -281,7 +281,7 @@ system call or sysctl interfaces.
{In order to operate a \gls{SPARC} v8 \gls{CPU} properly, a trap table must be
configured, in particular to handle register window under and overflow traps if
used with regular \gls{GCC} code generation for the target platform.
-LeanOS configures a callback system for interrupt traps that can later be used
+FlightOS configures a callback system for interrupt traps that can later be used
to install custom handlers, for example as part of driver modules.\newline
Interrupt statistics are exported via the system control interface.
diff --git a/Documentation/OS/paplan/paplan.tex b/Documentation/OS/paplan/paplan.tex
index 2d4ef8a..b78e4c7 100644
--- a/Documentation/OS/paplan/paplan.tex
+++ b/Documentation/OS/paplan/paplan.tex
@@ -1,7 +1,7 @@
\title{Product Quality Assurance Plan}
-\def \documentid {LEANOS-UVIE-PAQ-001}
+\def \documentid {FLIGHTOS-UVIE-PAQ-001}
\date{Issue 1.0, June 01, 2017}
\newcommand\affil[1]{\textsuperscript#1}
@@ -61,12 +61,12 @@
This document describes the \gls{SQA} activities that will be
-performed in the development of the the operating system kernel LeanOS.
-The document is applicable for all versions of LeanOS and and shall be updated
+performed in the development of the the operating system kernel FlightOS.
+The document is applicable for all versions of FlightOS and and shall be updated
as needed.\\
\noindent
-LeanOS targets the \gls{SSDP}, and to a lesser extent, its
+FlightOS targets the \gls{SSDP}, and to a lesser extent, its
compatible predecessor, the \gls{MPPB} v2.x \cite{MPPB}.
It is intended to be used in unmanned space applications of (at least)
Software Criticality Level C. \\
@@ -98,11 +98,11 @@ processing platform, a novel approach was needed concerning the management of
system resources, \gls{DMA} mechanics and \gls{DSP} program design for best
efficiency and turnover rates. Consequently, \gls{UVIE} developed an experimental
operating system to stably drive the \gls{DSP} cores and the \gls{MPPB} close
-to its performance limit. LeanOS is a development based on this operating system
+to its performance limit. FlightOS is a development based on this operating system
concept.\\
\noindent
-Further details on LeanOS may be found in \cite{ssdpOS}.
+Further details on FlightOS may be found in \cite{ssdpOS}.
\chapter{Software Product Assurance Programme Implementation}
@@ -119,7 +119,7 @@ Further details on LeanOS may be found in \cite{ssdpOS}.
\end{figure}
\noindent
-The \gls{SQA} organisation (\fig{fig:sw_dev_org}) for the development of LeanOS
+The \gls{SQA} organisation (\fig{fig:sw_dev_org}) for the development of FlightOS
is commensurate to the scope and size of the working group dedicated to
\gls{FSW} development at the Department of Astrophysics of the University of
Vienna.\\
@@ -234,18 +234,18 @@ software application are identified:
\end{multicols}
\noindent
-Functionality is explicitly covered in the \gls{SRS}\cite{leanosSRS}. Similarly,
+Functionality is explicitly covered in the \gls{SRS}\cite{flightosSRS}. Similarly,
the \gls{SRS} also covers maintainability, safety and security requirements, as
well as efficiency.\\
\noindent
Reliability is covered implicitly through the requirements formulated in the
-\gls{TP}\cite{leanosTP} and \gls{TS}\cite{leanosTS}. which are designed to
+\gls{TP}\cite{flightosTP} and \gls{TS}\cite{flightosTS}. which are designed to
to demonstrate the ability of the software to satisfy its requirements within
its operational domain.\\
\noindent
-Usability is not formally relevant for LeanOS, but rather implied by software
+Usability is not formally relevant for FlightOS, but rather implied by software
design and its intended application.\\
\noindent
@@ -333,7 +333,7 @@ No special quality measures are defined for operations or maintenance.
\noindent
For the software development life cycle, the \emph{Agile} model (\fig{fig:agile_sw})
-is selected to be used for the development of LeanOS.
+is selected to be used for the development of FlightOS.
This model keeps the initial planning and analysis on a very high level that
is just detailed enough to outline the scope of the project. The development
process is a series of iterations, in which a feature is taken from start to
@@ -358,12 +358,12 @@ when staffing.
\section{Project plans}
-A \glsdesc{TP} is given in \cite{leanosTP}.
+A \glsdesc{TP} is given in \cite{flightosTP}.
\section{Software dependability and safety}
-LeanOS is intended to be used in unmanned space
+FlightOS is intended to be used in unmanned space
applications of (at least) Software Criticality Level C. However, \gls{FDIR}
analyses and derived measures as well as the particular configuration of
the operating system to be used are highly dependent on the use case and must
diff --git a/Documentation/OS/requirements/software_requirements.tex b/Documentation/OS/requirements/software_requirements.tex
index 1c7a2db..1cfea3a 100644
--- a/Documentation/OS/requirements/software_requirements.tex
+++ b/Documentation/OS/requirements/software_requirements.tex
@@ -1,7 +1,7 @@
\title{Software Requirements Specification}
-\def \documentid {LEANOS-UVIE-SRS-001}
+\def \documentid {FLIGHTOS-UVIE-SRS-001}
\date{Issue 1.0, June 1, 2017}
\newcommand\affil[1]{\textsuperscript#1}
@@ -65,7 +65,7 @@
\section{Purpose of the Document}
This document specifies the software requirements for the operating system
-kernel LeanOS. LeanOS targets the \gls{SSDP}, and to a lesser extent, its
+kernel FlightOS. FlightOS targets the \gls{SSDP}, and to a lesser extent, its
compatible predecessor, the \gls{MPPB} v2.x \cite{MPPB}.
It is intended to be used in unmanned space applications of (at least)
Software Criticality Level C. Readers must be familiar with the basic concepts
@@ -77,7 +77,7 @@ specifications found in Annex D of ECSS-E-ST-40C \cite{ECSS40C}.
\section{Scope of the Software}
-LeanOS is a lightweight operating system targeting the particular
+FlightOS is a lightweight operating system targeting the particular
characteristics of the \gls{SSDP} and is focused on driving the \gls{NoC} and
its attached \gls{Xentium} \gls{DSP} cores.
@@ -106,7 +106,7 @@ processing platform, a novel approach was needed concerning the management of
system resources, \gls{DMA} mechanics and \gls{DSP} program design for best
efficiency and turnover rates. Consequently, \gls{UVIE} developed an experimental
operating system to stably drive the \gls{DSP} cores and the \gls{MPPB} close
-to its performance limit. LeanOS is a development based on this operating system
+to its performance limit. FlightOS is a development based on this operating system
concept. Along with its intended functionality, it provides full software test
coverage, example applications and good documentation that supports all aspects
of the software.
@@ -114,13 +114,13 @@ of the software.
\section{Environmental considerations}
-LeanOS is will support the \gls{SSDP} and also support the
+FlightOS is will support the \gls{SSDP} and also support the
\gls{MPPB} v2.x. Ultimately, this does allow reuse of the operating system core
for \gls{LEON2} and \gls{LEON3} based platforms with minor adaptations.
Even though the \gls{SSDP} does not contain a multi-core \gls{LEON3} processor,
-\gls{SMP} support will be prepared in LeanOS, as this will likely change with
+\gls{SMP} support will be prepared in FlightOS, as this will likely change with
newer versions of the \gls{SSDP}.
-LeanOS is released under an open source license, so compatible development tools should
+FlightOS is released under an open source license, so compatible development tools should
be available under such licenses as well. Note that it might still be necessary
to use a commercial product to target particular configurations or proprietary
hardware functionality.
@@ -128,12 +128,12 @@ hardware functionality.
\section{Relation to other systems}
-LeanOS is a stand-alone software product.
+FlightOS is a stand-alone software product.
\section{Constraints}
-LeanOS primarily targets the \gls{SSDP}, which effectively limits the hardware
+FlightOS primarily targets the \gls{SSDP}, which effectively limits the hardware
support to the characteristics of this platform. \\
\noindent
The source code is written in C and if required, \gls{SPARC} v8 compatible
@@ -149,17 +149,17 @@ programming languages designed for that purpose.
%\begin{figure}[ht]
%\begin{center}
% \includegraphics{images/OS_fundamental_architecture}
-% \caption{The fundamental architecture of LeanOS.}
+% \caption{The fundamental architecture of FlightOS.}
% %\label{fig:blackbody_curves}
%\end{center}
%\end{figure}
\requirement{GEN-0001} {No external dependencies}{%
-LeanOS shall not make use of external libraries, including C-runtime libraries.
+FlightOS shall not make use of external libraries, including C-runtime libraries.
}{}%
\requirement{GEN-0002} {Custom libc functionality}{%
-LeanOS shall, as part of its code-base and as needed, provide its own
+FlightOS shall, as part of its code-base and as needed, provide its own
implementations of typical C-libary functions with an \gls{API} conforming to
their \gls{POSIX} definitions.
}{%
@@ -167,7 +167,7 @@ The collection of these functions can also form the base or a subset of a
C libary to be used by applications.}%
\requirement{GEN-0003} {Application libc usage}{%
-LeanOS shall optionally call a function that initialises a C-library on startup.
+FlightOS shall optionally call a function that initialises a C-library on startup.
It is up to the user to define and link the implementation of this function and
the according C-library.
}{%
@@ -195,31 +195,31 @@ before execution.
% }
\requirement{GEN-0004} {Fatal Error Management}{%
-If a non-recoverable error state is detected in LeanOS, it shall optionally
+If a non-recoverable error state is detected in FlightOS, it shall optionally
call an error handling routine provided by the user before issuing a reboot.
-LeanOS shall provide a directive to register such a function.
+FlightOS shall provide a directive to register such a function.
}{%
This gives the user the possiblity to perform a clean shutdown of critical
tasks in their particular environment.}%
\requirement{GEN-0006} {Core runtime}{%
-In its basic configuration, LeanOS shall restrict itself to the initialisation
+In its basic configuration, FlightOS shall restrict itself to the initialisation
of its core services on a single processor, thereby configuring traps, memories
and timers. All other services or device drivers shall be configured and added
via the build system.
}{}%
\requirement{GEN-0601} {Error Logging}{%
-LeanOS shall maintain an error message log that is readable by the user.
+FlightOS shall maintain an error message log that is readable by the user.
}{}%
\requirement{GEN-0602} {Coding Style}{%
-LeanOS code shall use the Linux kernel coding style. Source files and patches
+FlightOS code shall use the Linux kernel coding style. Source files and patches
shall be checked using the checkpatch.pl utility found in the Linux kernel
source tree.
}{%
-A major point of LeanOS is that it does not only come with an open source
+A major point of FlightOS is that it does not only come with an open source
license, but should ideally only use tools that are distributable under a
similar license. The Linux kernel is used in billions of devices word-wide,
its coding style is hence arguably well-suited for use in successful software.
@@ -229,38 +229,38 @@ its coding style is hence arguably well-suited for use in successful software.
\section{Functional Requirements}
\requirement{FUN-0007} {SMP Support}{%
-LeanOS shall be able to run on a multi-core configuration of a LEON3 processor.
+FlightOS shall be able to run on a multi-core configuration of a LEON3 processor.
}{}%
\requirement{FUN-0803} {MMU Support}{%
-LeanOS shall support the use of the MMU of the LEON3 processor.
+FlightOS shall support the use of the MMU of the LEON3 processor.
}{}%
\requirement{FUN-0008} {Supervisor Mode}{%
-The LeanOS kernel shall execute with the SPARC supervisor mode enabled.
+The FlightOS kernel shall execute with the SPARC supervisor mode enabled.
Application code shall run with supervisor mode disabled.
}{}%
\requirement{FUN-0011} {Timing}{%
-LeanOS shall provide access to typical time keeping, time taking and delay
+FlightOS shall provide access to typical time keeping, time taking and delay
timing functionality expected by an operating system.
}{}%
\requirement{FUN-0012} {Task Support}{%
-LeanOS shall provide means to create new tasks.
+FlightOS shall provide means to create new tasks.
}{}%
\requirement{FUN-0013} {Task priorities and deadlines}{%
-LeanOS shall support the assignment of a priority and a deadline to a task.
+FlightOS shall support the assignment of a priority and a deadline to a task.
}{}%
\requirement{FUN-0014} {Task scheduling}{%
-LeanOS shall offer a fixed priority scheduler with priority inversion handling.
+FlightOS shall offer a fixed priority scheduler with priority inversion handling.
}{}%
\goal{FUN-0015} {Other schedulers}{%
-LeanOS should offer an Earliest Deadline First scheduler supporting priority
+FlightOS should offer an Earliest Deadline First scheduler supporting priority
execution in overload conditions.
}{%
@@ -270,7 +270,7 @@ threads in conditions where the total load unexpectedly would exceed 100\%.
}%
\requirement{FUN-0016} {Kernel Ticks}{%
-LeanOS shall operate in tickless (non-periodic) timed wakeup mode by default.
+FlightOS shall operate in tickless (non-periodic) timed wakeup mode by default.
}{%
Tickless timing avoids unnecessary wake-ups of the CPU if no task is running
and improves performance by only switching to kernel mode from regular tasks
@@ -278,7 +278,7 @@ when absolutely necessary.
}%
\requirement{FUN-0017} {Tickless Timing}{%
-LeanOS timing functionality shall be able to operate in tickless mode, where
+FlightOS timing functionality shall be able to operate in tickless mode, where
a queue of wakeup times is maintained and a hardware timer is used in such a way
that its next underflow (resulting in an interrupt) is programmed to coincide
with the next wakeup time. New wakeup times shall be inserted into the queue as
@@ -287,26 +287,26 @@ be readjusted accordingly.
}{}%
\requirement{FUN-0019} {Semaphores and Mutexes}{%
-LeanOS shall provide semaphores and mutexes as part of its task functionality.
+FlightOS shall provide semaphores and mutexes as part of its task functionality.
Task priorities shall be protected by the priority ceiling protocol.
}{}%
\requirement{FUN-0020} {Tasks and \gls{SMP}}{%
-LeanOS shall support task migration between \glspl{CPU} and track and ensure
+FlightOS shall support task migration between \glspl{CPU} and track and ensure
atomicity of related functions (e.g. mutexes) across multiple processors.
}{}%
\requirement{FUN-0021} {Message Queues}{%
-LeanOS shall support message queues for inter-process communication.
+FlightOS shall support message queues for inter-process communication.
Atomicity of queues shall be ensured across multiple processors.
}{}%
\requirement{FUN-0022} {Kernel Modules}{%
-LeanOS shall offer loadable module support infrastructure.
+FlightOS shall offer loadable module support infrastructure.
}{}%
\requirement{FUN-0804} {Kernel-Userspace Initialisation}{%
-LeanOS shall offer a configurable initialisation point that executes a
+FlightOS shall offer a configurable initialisation point that executes a
user-space setup procedure.\\
@@ -315,7 +315,7 @@ This is the point where the application software is loaded.%
}%
\requirement{FUN-0023} {System Control Interface}{%
-LeanOS shall offer a way for drivers or other functional modules to export
+FlightOS shall offer a way for drivers or other functional modules to export
configuration or state variables into a logical tree maintained by
the operating system. This logical tree shall be accessible by other modules and
the user as a character-based interface.
@@ -325,7 +325,7 @@ get or set configuration states or system statistics.
}%
\requirement{FUN-0024} {Binary System Control Interface}{%
-LeanOS shall offer the possibility to install binary exchange nodes within the
+FlightOS shall offer the possibility to install binary exchange nodes within the
System Control Interface tree that may be used for larger amouts of binary data.
The binary format shall be defined by the creator of the node. Any users of the
node shall be responsible to read or write in the correct format expected by the
@@ -337,15 +337,15 @@ some calibration data.
}%
\goal{FUN-0025} {Device Drivers}{%
-LeanOS should come with device drivers for all hardware functionality of the SSDP.
+FlightOS should come with device drivers for all hardware functionality of the SSDP.
}{}%
\requirement{FUN-0026} {Xentium Scheduler}{%
-LeanOS shall offer a way to define and load Xentium data processing code.
+FlightOS shall offer a way to define and load Xentium data processing code.
}{}%
\requirement{FUN-0027} {Xentium Data Buffers}{%
-LeanOS shall provide packet-driven meta-data buffers to Xentium programs that
+FlightOS shall provide packet-driven meta-data buffers to Xentium programs that
can link to arbitrary data sets and routing tables that define the path of
a data packet through a series of Xentium program nodes.
}{%
@@ -356,14 +356,14 @@ which represents their individual ``processing chain''.}%
\section{Performance Requirements}
\requirement{GEN-0009} {Traps/Interrupts}{%
-LeanOS trap entry and exit code shall not exceed 500 instructions.
+FlightOS trap entry and exit code shall not exceed 500 instructions.
}{%
This does not include the callback functions for a trap or interrupt
service routine.
}%
\requirement{GEN-0018} {Deferred saving of \gls{FPU} registers}{%
-In trap mode, LeanOS shall defer saving of \gls{FPU} registers until it is
+In trap mode, FlightOS shall defer saving of \gls{FPU} registers until it is
accessed.\\
@@ -384,7 +384,7 @@ acting as a signalling function.
}%
\requirement{GEN-0028} {Real-Time Thread Support}{%
-LeanOS shall offer support for a class of real time threads that may also
+FlightOS shall offer support for a class of real time threads that may also
preempt the operating sytem with the exception of \glspl{ISR}.
}{%
Some application real time tasks may be so timing sensitive, that even
@@ -394,7 +394,7 @@ operating system code must be preemptible to guarantee a timely response.
\section{Interface Requirements}
\requirement{GEN-2001} {Interface Documentation}{%
-The internal and external interfaces of LeanOS shall be described as part
+The internal and external interfaces of FlightOS shall be described as part
of its source code in Doxygen markup.\\
}{
@@ -415,7 +415,7 @@ No operational requirements have been identified.
\section{Resources Requirements}
\requirement{GEN-0101} {Target Platform}{%
-LeanOS shall execute on the \gls{SSDP}, in particular the \gls{LEON3-FT}
+FlightOS shall execute on the \gls{SSDP}, in particular the \gls{LEON3-FT}
processor of the platform. It should also execute on the \gls{MPPB} v2.x.
}{}%
@@ -424,7 +424,7 @@ processor of the platform. It should also execute on the \gls{MPPB} v2.x.
\requirement{GEN-0801}{Modular Design}{%
-All components of LeanOS shall be written such that a particular component does
+All components of FlightOS shall be written such that a particular component does
contain its intended functionality as much as possible.
}{
If something is mostly self-contained, it is easier to modify and re-use in
@@ -461,7 +461,7 @@ No security or privacy requirements have been identified.
\section{Software Quality Requirements}
\goal{GEN-0201} {Product Metrics}{%
-LeanOS should have a cyclomatic complexity of at most 15 and a nesting level of
+FlightOS should have a cyclomatic complexity of at most 15 and a nesting level of
at most 6 per function. Each function shall have a single exit point for the
nominal case.
}{}%
@@ -490,7 +490,7 @@ the latter.
}%
\requirement{GEN-0402} {Correctable Traps}{%
-LeanOS shall provide handlers for correctable traps caused by kernel or user
+FlightOS shall provide handlers for correctable traps caused by kernel or user
code and either correctly execute the desired operation (e.g. unaligned access)
or replace the result with a default value (e.g. divison by zero) and skip the
offending code instruction to continue.
@@ -498,7 +498,7 @@ offending code instruction to continue.
}
\requirement{GEN-0403} {Trap Error Reporting}{%
-LeanOS shall make an entry into its error message log when a trap event occurs,
+FlightOS shall make an entry into its error message log when a trap event occurs,
describing the nature and source of the trap.
}{
}
@@ -508,7 +508,7 @@ describing the nature and source of the trap.
\section{Software Configuration and Delivery Requirements}
\requirement{GEN-0005} {Build configuration}{%
-LeanOS shall make use of the Linux Kernel Build System (kbuild) for its
+FlightOS shall make use of the Linux Kernel Build System (kbuild) for its
configuration.
}{}%
@@ -536,7 +536,7 @@ in a Software Qualification Test Plan for each requirement.
\requirement{GEN-1002} {Qualification Testing}{%
SW qualification testing shall be performed with various configurations of
-LeanOS.
+FlightOS.
}{}%
@@ -556,7 +556,7 @@ LeanOS.
The requirements in this document are both user and system requirements.
Traces from design and test to the software requirements are given in the
-respective documents. \cite{leanosADD} \cite{leanosTS}
+respective documents. \cite{flightosADD} \cite{flightosTS}
\chapter{Logical Model Description}
@@ -564,14 +564,14 @@ respective documents. \cite{leanosADD} \cite{leanosTS}
\begin{figure}[htb]
\begin{center}
\includegraphics[width=\columnwidth]{images/OS_logical}
- \caption{The logical model of LeanOS. Here, the "hardware" layer
+ \caption{The logical model of FlightOS. Here, the "hardware" layer
represents both the hardware and the hardware abstraction layer of
the software.}
\label{fig:logical_model}
\end{center}
\end{figure}
-In LeanOS, the \gls{SSDP} hardware is accessed in multiple layers of
+In FlightOS, the \gls{SSDP} hardware is accessed in multiple layers of
abstraction (see \fig{fig:logical_model}). Typical \gls{CPU} tasks such as thread/task
management and timer operation are used as part of the operating system kernel
and are also accessible by user applications via a system call interface.
diff --git a/Documentation/OS/shared/bibliography.bib b/Documentation/OS/shared/bibliography.bib
index 25e001c..ca869ff 100644
--- a/Documentation/OS/shared/bibliography.bib
+++ b/Documentation/OS/shared/bibliography.bib
@@ -46,43 +46,43 @@
year = "2016",
}
-@book{leanosPQA,
- title = "LeanOS Product Quality Assurance Plan",
+@book{flightosPQA,
+ title = "FlightOS Product Quality Assurance Plan",
organization = "University of Vienna",
year = "2017",
version = "1.0",
}
-@book{leanosSRS,
- title = "LeanOS Software Requirements Specification",
+@book{flightosSRS,
+ title = "FlightOS Software Requirements Specification",
organization = "University of Vienna",
year = "2017",
version = "1.0",
}
-@book{leanosADD,
- title = "LeanOS Architectural Design Document",
+@book{flightosADD,
+ title = "FlightOS Architectural Design Document",
organization = "University of Vienna",
year = "2017",
version = "1.0",
}
-@book{leanosTP,
- title = "LeanOS Test Plan",
+@book{flightosTP,
+ title = "FlightOS Test Plan",
organization = "University of Vienna",
year = "2017",
version = "1.0",
}
-@book{leanosTS,
- title = {LeanOS Test Specification},
+@book{flightosTS,
+ title = {FlightOS Test Specification},
organization = "University of Vienna",
year = "2017",
version = "1.0",
}
-@book{leanosUM,
- title = {LeanOS User Manual},
+@book{flightosUM,
+ title = {FlightOS User Manual},
organization = "University of Vienna",
year = "2017",
version = "1.0",
diff --git a/Documentation/OS/testplan/testplan.tex b/Documentation/OS/testplan/testplan.tex
index 7fabf0b..4840cf5 100644
--- a/Documentation/OS/testplan/testplan.tex
+++ b/Documentation/OS/testplan/testplan.tex
@@ -1,7 +1,7 @@
\title{Test Plan}
-\def \documentid {LEANOS-UVIE-TP-001}
+\def \documentid {FLIGHTOS-UVIE-TP-001}
\date{Issue 1.0, June 1, 2017}
\newcommand\affil[1]{\textsuperscript#1}
@@ -72,7 +72,7 @@
\begin{figure}[htb]
\begin{center}
\includegraphics[width=\columnwidth]{../requirements/images/OS_logical}
- \caption{The logical model of LeanOS. Here, the "hardware" layer
+ \caption{The logical model of FlightOS. Here, the "hardware" layer
represents both the hardware and the hardware abstraction layer of
the software.}
\label{fig:logical_model}
@@ -80,11 +80,11 @@
\end{figure}
\noindent
-LeanOS\cite{ssdpOS}\cite{leanosADD}\cite{leanosSRS} is an operating system specifically
+FlightOS\cite{ssdpOS}\cite{flightosADD}\cite{flightosSRS} is an operating system specifically
designed to support hardware devices with drivers and data processing on the
\gls{Xentium} \glspl{DSP} of the \gls{SSDP}.\\
-In LeanOS, the \gls{SSDP} hardware is accessed in multiple layers of
+In FlightOS, the \gls{SSDP} hardware is accessed in multiple layers of
abstraction (see \fig{fig:logical_model}). Typical \gls{CPU} tasks such as
thread/task management and timer operation are used as part of the operating
system kernel and are also accessible by user applications via a system call
@@ -98,13 +98,13 @@ hardware modes or usage statistics may be exported by individual components for
external (user) access. \\
\noindent
-The compliance of LeanOS with its requirements and its operational environment
+The compliance of FlightOS with its requirements and its operational environment
are partially verified by testing.
\section{Purpose of the Document}
-This document defines test procedures for the LeanOS operating system.
+This document defines test procedures for the FlightOS operating system.
In particular, it defines the:
\begin{itemize}
\item types of tests
@@ -116,7 +116,7 @@ In particular, it defines the:
\section{Incremental Testing}
-LeanOS is not envisaged to be implemented in one final form. Instead, it is
+FlightOS is not envisaged to be implemented in one final form. Instead, it is
marked with version numbers for each release. This means that testing is
version-dependent and is be applied in increments by executing a sub-set of
tests only as modifications are made.
@@ -140,7 +140,7 @@ configuration files so the proper build may generated.\\
\requirement{IUT-0001} {Hardware constraints}{%
The test plan specified by the present requirements shall apply to all parts %
-of LeanOS.
+of FlightOS.
}{}
@@ -175,7 +175,7 @@ the operational constraints applicable to the hardware used in the tests.%
\chapter{Types of Tests}
In order to satisfy the verification and validation needs of the test campaign,
-the following types of tests are defined for LeanOS:
+the following types of tests are defined for FlightOS:
\begin{itemize}
\item unit and integration tests
\item hardware-software tests
@@ -184,7 +184,7 @@ the following types of tests are defined for LeanOS:
\section {Unit and Integration Tests}
-LeanOS is developed as a collection of individual, interacting components.
+FlightOS is developed as a collection of individual, interacting components.
A unit test verifies the behaviour of a single component, while an integration
test verifies the behaviour of a number of interacting components. \\
@@ -196,9 +196,9 @@ hardware platform.\\
\\
\requirement{UIT-0001} {Unit/Integ. Tests}{%
-Unit and Integration Tests shall be defined and executed for LeanOS components.
+Unit and Integration Tests shall be defined and executed for FlightOS components.
}{Tests can make use of the modified \emph{kselftest} framework provided %
-in the LeanOS source tree.
+in the FlightOS source tree.
}%
\requirement{UIT-0002} {Test Suite}{%
@@ -209,7 +209,7 @@ A unit and integration test suite shall be provided as a set of applications.
A single mechanism shall be provided that automatically runs all unit and %
integration tests in sequence.\\
}{
-The \emph{kselftest} framework in the LeanOS source tree provides a %
+The \emph{kselftest} framework in the FlightOS source tree provides a %
\emph{Makefile} setup that can be used for this purpose.}%
\requirement{UIT-0004} {Test Results}{%
@@ -233,7 +233,7 @@ this category.\\
\\
\requirement{HST-0001} {Hardware Tests}{%
-Hardware-software tests shall be defined and executed for LeanOS components %
+Hardware-software tests shall be defined and executed for FlightOS components %
with the objective of verifying the behaviour of components which directly %
interact with the relevant target hardware.%
}{}
@@ -258,18 +258,18 @@ using the \emph{git bisect run \ldots} functionality.}%
\section {Acceptance Tests}
Acceptance tests are performed by the user on the integrated processing unit.
-Their objective is to exercise the selected LeanOS configuration while running
-in its operational environment. The operational environment for LeanOS is
+Their objective is to exercise the selected FlightOS configuration while running
+in its operational environment. The operational environment for FlightOS is
defined by the user according to their use case.\\
\requirement{ACT-0001} {Acceptance Tests}{%
-Acceptance tests and their procedures shall be defined and executed for LeanOS.
+Acceptance tests and their procedures shall be defined and executed for FlightOS.
}{}
\requirement{ACT-0002} {Use Cases}{%
-The configuration and operational environment for an acceptance test of LeanOS
+The configuration and operational environment for an acceptance test of FlightOS
shall be defined by the user according to their use case.
}{}
@@ -278,7 +278,7 @@ shall be defined by the user according to their use case.
\chapter{Test Environments}
-Test beds in which LeanOS tests are performed:
+Test beds in which FlightOS tests are performed:
\begin{itemize}
\item general-purpose platform for regular unit and integration tests
@@ -308,7 +308,7 @@ The test environment for unit and integration tests is shown in
\fig{fig:unittest}.\\
\noindent
-The item under test is either one or a set of components of LeanOS. If needed,
+The item under test is either one or a set of components of FlightOS. If needed,
stub and mockup functions, which simulate the expected behaviour of external
dependcies, are defined to create a representative environment in which the item
under test is running.\\
@@ -352,15 +352,15 @@ deviations are acceptable, provided a justification is given.\\
\\
\requirement{SCC-0001} {Statement Coverage}{%
-Unit and integration tests shall offer full statement coverage for LeanOS code.%
+Unit and integration tests shall offer full statement coverage for FlightOS code.%
}{}%
\requirement{SCC-0002} {Decision Coverage}{%
-Unit and integration tests shall offer full decision coverage for LeanOS code.%
+Unit and integration tests shall offer full decision coverage for FlightOS code.%
}{}%
\requirement{SCC-0003} {Condition Coverage}{%
-Unit and integration tests shall offer full condition coverage for LeanOS code.%
+Unit and integration tests shall offer full condition coverage for FlightOS code.%
}{}%
\requirement{SCC-0004} {Reduced Coverage}{%
diff --git a/Documentation/OS/testreport/testreport.tex b/Documentation/OS/testreport/testreport.tex
index 2885382..a35ea57 100644
--- a/Documentation/OS/testreport/testreport.tex
+++ b/Documentation/OS/testreport/testreport.tex
@@ -1,7 +1,7 @@
\title{Test Report}
-\def \documentid {LEANOS-UVIE-TR-001}
+\def \documentid {FLIGHTOS-UVIE-TR-001}
\date{Issue 1.0, June 1, 2017}
\newcommand\affil[1]{\textsuperscript#1}
@@ -59,12 +59,12 @@
\section{Purpose of the Document}
-In this document, results of tests specified in \cite{leanosTS} are recorded.
+In this document, results of tests specified in \cite{flightosTS} are recorded.
\section{Incremental Testing}
-LeanOS is not envisaged to be implemented in one final form. Instead, it is
+FlightOS is not envisaged to be implemented in one final form. Instead, it is
marked with version numbers for each release. This means that testing is
version-dependent and is applied in increments by executing all available tests
as modifications are made. This is reflected in the dates, version
@@ -96,7 +96,7 @@ listed in each individual test report.
This test verifies the implementation of the \gls{Xentium} Processing Network
implementation on the \gls{MPPB} by generating a series of processing tasks and
running them through the network. This test also represents an integrated test
-of LeanOS.
+of FlightOS.
\subsection*{Overview of the Procedure}
@@ -104,7 +104,7 @@ This test is executed on a \gls{MPPB} v2.x hardware model. Once the test
environment is set up, the build configuration is prepared and the test itself
is executed and evaluated automatically by starting the \emph{bash} script
\emph{run\_test.sh}. It may be found in the
-\mbox{\emph{tools/testing/hwtests/xen\_proc\_net}} subdirectory of the LeanOS
+\mbox{\emph{tools/testing/hwtests/xen\_proc\_net}} subdirectory of the FlightOS
source tree.
@@ -113,7 +113,7 @@ source tree.
The following preparations must be made in order to carry out the test:
\begin{itemize}
- \item checkout of the LeanOS source tree
+ \item checkout of the FlightOS source tree
\item \gls{MPPB}/\gls{Xentium} toolchain location in shell \emph{PATH}
\item \emph{grmon} ver. 1.x configured and in shell \emph{PATH}
\item \gls{MPPB} v2.x connected to PC via DEBUG UART and powered on
@@ -201,22 +201,22 @@ scripts/kconfig/conf --silentoldconfig Kconfig
HOSTCC samples/proc_chain/proc_chain_demo.o
HOSTLD samples/proc_chain/proc_chain_demo
LD samples/built-in.o
- LD leanos.o
-make[1]: Nothing to be done for 'leanos.o'.
+ LD flightos.o
+make[1]: Nothing to be done for 'flightos.o'.
GEN .version
KSYM .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.o
- LD leanos
+ LD flightos
SYSMAP System.map
Building modules, stage 2.
MODPOST 0 modules
Embedding module image, stage 3.
- LD leanos.o
-make[1]: Nothing to be done for 'leanos.o'.
+ LD flightos.o
+make[1]: Nothing to be done for 'flightos.o'.
GEN .version
KSYM .tmp_kallsyms1.o
KSYM .tmp_kallsyms2.o
- LD leanos
+ LD flightos
SYSMAP System.map
GRMON LEON debug monitor v1.1.61 professional version
@@ -246,7 +246,7 @@ make[1]: Nothing to be done for 'leanos.o'.
Use command 'info sys' to print a detailed report of attached cores
-grlib> load leanos
+grlib> load flightos
section: .text at 0x40000000, size 96592 bytes
downloading: 96592
section: .data at 0x40017950, size 81572 bytes
diff --git a/Documentation/OS/testspecification/testspecification.tex b/Documentation/OS/testspecification/testspecification.tex
index 9268deb..c678f51 100644
--- a/Documentation/OS/testspecification/testspecification.tex
+++ b/Documentation/OS/testspecification/testspecification.tex
@@ -1,7 +1,7 @@
\title{Test Specification}
-\def \documentid {LEANOS-UVIE-TS-001}
+\def \documentid {FLIGHTOS-UVIE-TS-001}
\date{Issue 1.0, May 1, 2016}
\newcommand\affil[1]{\textsuperscript#1}
@@ -66,8 +66,8 @@
\section{Purpose of the Document}
-The test plan for the the LeanOS operating system is defined in
-\cite{leanosTP}.\\
+The test plan for the the FlightOS operating system is defined in
+\cite{flightosTP}.\\
\\
\noindent
@@ -75,7 +75,7 @@ This test plan includes tests where the integrated operating
system is subjected to tests in its operational environment.\\
\noindent
-This document specifies the acceptance tests for LeanOS.\\
+This document specifies the acceptance tests for FlightOS.\\
\noindent
A test is specified by defining the:
@@ -152,7 +152,7 @@ can be detected by an external test program such as \emph{git bisect}.
\design{UIT-0006}
{Test Suite}{%
All unit and integration tests, along with stub and mockup functions are stored
-in the LeanOS source tree directory \mbox{\emph{tools/testing/unittest/}}.
+in the FlightOS source tree directory \mbox{\emph{tools/testing/unittest/}}.
}%
{\meetsreq{UIT-0002, UITE-0001}}{}
@@ -174,7 +174,7 @@ executes the test on the target hardware. %
\design{HST-0002}
{Test Suite}{%
-All hardware-software tests are stored in the LeanOS source
+All hardware-software tests are stored in the FlightOS source
tree directory \mbox{\emph{tools/testing/hwtests/}}.%
}%
{\meetsreq{HST-0002}}{}
@@ -200,7 +200,7 @@ can be detected by an external test program such as \emph{git bisect}.
{Code Coverage}{%
Statement, decision and condition coverage is determined via \emph{gcov}.
A \emph{make} target \emph{coverage\_test} is available in the \emph{Makefile}
-of the unit test directory of the LeanOS source tree.
+of the unit test directory of the FlightOS source tree.
Human-readable reports are placed in the respective subdirectories for each
individual unit test.
}%
@@ -218,7 +218,7 @@ Any acceptance test procedures are defined in chapter
\design{ACT-0002}
{\hspace{0pt} Acceptance Test Use Cases}{%
-The configuration and operational environment of LeanOS is defined for each
+The configuration and operational environment of FlightOS is defined for each
acceptance test of an identified use case.
}%
{\meetsreq{ACT-0002}}{}
@@ -267,14 +267,14 @@ step (if applicable).\\
\includegraphics[width=1.0\columnwidth]{../usermanual/images/task_network}
\caption{Tasks in the processing network propagate according to the
operational code identifiers in their processing task list.
- For details, see \cite{leanosUM}.}
+ For details, see \cite{flightosUM}.}
\label{fig:task_network}
\end{center}
\end{figure}
This is an integrated test of the \gls{Xentium} Processing Network
(see \fig{fig:task_network}). It loads a set of \gls{Xentium} program kernels in the
-Xentium driver of LeanOS, which are then used to apply processing operations on
+Xentium driver of FlightOS, which are then used to apply processing operations on
a series of input tasks to simulate a processing pipeline.\\
\noindent
@@ -313,12 +313,12 @@ a success.\\
\testrow{PRE}{ }{Ensure connection of \gls{MPPB} to test control host via serial %
cable on DEBUG UART to virtual device \emph{/dev/ttyS0} %
on the host platform.}{}%
-\testrow{PRE}{ }{A checkout of the LeanOS source directory.}{}%
+\testrow{PRE}{ }{A checkout of the FlightOS source directory.}{}%
\testrow{PRE}{ }{\gls{MPPB}/\gls{Xentium} toolchain installed and configured}{}%
\testrow{STP}{1}{Ensure that the \gls{MPPB} is powered and reset.}{}%
\testrow{STP}{2}{Execute test script in the %
\mbox{\emph{tools/testing/hwtests/xen\_proc\_net}} %
- subdirectory of the LeanOS source tree.}{}%
+ subdirectory of the FlightOS source tree.}{}%
\testrow{STP}{3}{Verify that the program image is built.}{}%
\testrow{STP}{4}{Verify that the program image is uploaded to the \gls{MPPB} %
via \emph{grmon}}{}%
diff --git a/Documentation/OS/usermanual/usermanual.tex b/Documentation/OS/usermanual/usermanual.tex
index 13d4c3d..12ecd8d 100644
--- a/Documentation/OS/usermanual/usermanual.tex
+++ b/Documentation/OS/usermanual/usermanual.tex
@@ -1,5 +1,5 @@
\title{User Manual}
-\def \documentid {LEANOS-UVIE-UM-001}
+\def \documentid {FLIGHTOS-UVIE-UM-001}
\date{Issue 1.0, June 1, 2017}
\newcommand\affil[1]{\textsuperscript#1}
@@ -70,8 +70,8 @@
\section{Purpose of the Document}
-This document gives an overview on how to use the LeanOS operating system with
-regard to Xentium processing. An overview of the structure of LeanOS will be
+This document gives an overview on how to use the FlightOS operating system with
+regard to Xentium processing. An overview of the structure of FlightOS will be
given, detailed information relevant to system programming must however be
looked up in the in-line documentation of the source files.
@@ -99,11 +99,11 @@ sources that depend on the implementation of certain interfaces by the former.
While this means that any architecture could be supported, the only
currently implemented hardware architecture is \gls{SPARC} v8.
-%%\section {How to get LeanOS}
+%%\section {How to get FlightOS}
\section {Build Requirements}
-In order to build LeanOS, make sure you have set up your environment variables
+In order to build FlightOS, make sure you have set up your environment variables
to point to the compilers to be used. You will need at least a cross-compiler
for the \gls{SPARC} platform (i.e. BCC from Gaisler or SPARC GCC from RECORE)
and a \gls{GCC} compiler for your host platform. In addition, you will
@@ -116,7 +116,7 @@ environment.
\section {Build System}
-LeanOS uses an adaptation of the Linux kernel's Kbuild system. For details on
+FlightOS uses an adaptation of the Linux kernel's Kbuild system. For details on
how to use it, you may refer to related documentation found online. \\
\noindent
@@ -126,7 +126,7 @@ To launch the configuration interface, simply issue
$ make menuconfig
\end{lstlisting}
\noindent
-on your shell prompt from the top-level LeanOS directory. If you prefer a
+on your shell prompt from the top-level FlightOS directory. If you prefer a
graphical interface, you may use:
\begin{lstlisting}[language=bash]
@@ -153,7 +153,7 @@ To build a kernel image, you can now issue
\noindent
on your command line. The build process will produce an executable ELF binary
-named \emph{leanos} which you can then run on your target system using your
+named \emph{flightos} which you can then run on your target system using your
preferred method, e.g. via grmon.
@@ -186,7 +186,7 @@ subdirectory.
\section {Xentium Processing Demo}
-To build a LeanOS kernel that demonstrates a Xentium processing network setup,
+To build a FlightOS kernel that demonstrates a Xentium processing network setup,
select \emph{Enable System-On-Chip configurations}, then configure your CPU and
board type (LEON2/3, MPPB/SSDP). In the submenu \emph{System-on-Chip
drivers}, enable the \emph{NoC 2D DMA driver} and \emph{Xentium processing
@@ -213,7 +213,7 @@ subdirectories.
\section {Features Overview}
The following will give you a concise overview of some of the currently
-implemented features of LeanOS that distinguish it from other operating
+implemented features of FlightOS that distinguish it from other operating
systems in its class.
\subsection {Memory Management}
@@ -243,7 +243,7 @@ arbitrary data, e.g. calibration files.
\subsection {Xentium and NoC support}
-LeanOS supports the Network-on-Chip and its core features (such as the DMA)
+FlightOS supports the Network-on-Chip and its core features (such as the DMA)
found in the \gls{SSDP} and the \gls{MPPB}. A major focus is the integration
of the \gls{Xentium} \glspl{DSP} into a processing network that can be used to
create arbitrary pipelines on a per-task-packet basis (see below).
@@ -315,7 +315,7 @@ subdirectory.
-\chapter{Processing Networks in LeanOS}
+\chapter{Processing Networks in FlightOS}
\section{Overview}
@@ -1223,10 +1223,10 @@ FastIntFixedRampFitBuffer:
\appendix
-\chapter {Changes from NGAPP to LeanOS Xentium Processing Concept}
+\chapter {Changes from NGAPP to FlightOS Xentium Processing Concept}
The following sections look at the major differences between the NGAPP and
-LeanOS concepts.
+FlightOS concepts.
\section {Processing Chain}
diff --git a/Documentation/doxygen/Doxyfile b/Documentation/doxygen/Doxyfile
index 04d1daf..a28b56d 100644
--- a/Documentation/doxygen/Doxyfile
+++ b/Documentation/doxygen/Doxyfile
@@ -32,7 +32,7 @@ DOXYFILE_ENCODING = UTF-8
# title of most generated pages and in a few other places.
# The default value is: My Project.
-PROJECT_NAME = "LeanOS"
+PROJECT_NAME = "FlightOS"
# The PROJECT_NUMBER tag can be used to enter a project or revision number. This
# could be handy for archiving the generated documentation or if some version
diff --git a/Documentation/doxygen/doxy-boot.js b/Documentation/doxygen/doxy-boot.js
index f377c65..b62db99 100644
--- a/Documentation/doxygen/doxy-boot.js
+++ b/Documentation/doxygen/doxy-boot.js
@@ -4,7 +4,7 @@ $( document ).ready(function() {
$("div.title").addClass("h1");
$('li > a[href="index.html"] > span').before("<i class='fa fa-cog'></i> ");
- $('li > a[href="index.html"] > span').text("LeanOS");
+ $('li > a[href="index.html"] > span').text("FlightOS");
$('li > a[href="modules.html"] > span').before("<i class='fa fa-square'></i> ");
$('li > a[href="namespaces.html"] > span').before("<i class='fa fa-bars'></i> ");
$('li > a[href="annotated.html"] > span').before("<i class='fa fa-list-ul'></i> ");
diff --git a/Kconfig b/Kconfig
index 623eb7e..6cacdc2 100644
--- a/Kconfig
+++ b/Kconfig
@@ -2,7 +2,7 @@
# For a description of the syntax of this configuration file,
# see Documentation/kbuild/kconfig-language.txt.
#
-mainmenu "LeanOS Configuration"
+mainmenu "FlightOS Configuration"
config SRCARCH
string
diff --git a/Makefile b/Makefile
index 70a15ef..f54e37a 100644
--- a/Makefile
+++ b/Makefile
@@ -39,7 +39,7 @@ unexport GREP_OPTIONS
# their own directory. If in some directory we have a dependency on
# a file in another dir (which doesn't happen often, but it's often
# unavoidable when linking the built-in.o targets which finally
-# turn into leanos), we will call a sub make in that other dir, and
+# turn into flightos), we will call a sub make in that other dir, and
# after that we are sure that everything which is in that other dir
# is now up to date.
#
@@ -416,7 +416,7 @@ config: scripts_basic outputmakefile FORCE
else
# ===========================================================================
-# Build targets only - this includes leanos, arch specific targets, clean
+# Build targets only - this includes flightos, arch specific targets, clean
# targets and others. In general all targets except *config targets.
# Additional helpers built in scripts/
@@ -454,8 +454,8 @@ endif # $(dot-config)
# The all: target is the default when no target is given on the
# command line.
# This allow a user to issue only 'make' to build the application
-# Defaults to leanos, but the arch makefile usually adds further targets
-all: leanos
+# Defaults to flightos, but the arch makefile usually adds further targets
+all: flightos
# The arch Makefile can set ARCH_{CPP,A,C}FLAGS to override the default
# values of the respective KBUILD_* variables
@@ -585,7 +585,7 @@ KBUILD_CFLAGS += $(ARCH_CFLAGS) $(KCFLAGS)
# set in the environment
# Also any assignments in arch/$(ARCH)/Makefile take precedence over
# this default value
-export KBUILD_IMAGE ?= leanos
+export KBUILD_IMAGE ?= flightos
#
# INSTALL_PATH specifies where to place the updated kernel and system map
@@ -602,40 +602,40 @@ xentium-$(CONFIG_BUILD_XEN_KERNELS) := dsp/
-include arch/$(ARCH)/Makefile
-leanos-dirs := $(patsubst %/,%,$(filter %/, \
+flightos-dirs := $(patsubst %/,%,$(filter %/, \
$(init-y) \
$(core-y) \
$(kernel-y) \
$(libs-y)) \
$(xentium-y))
#
-leanos-core := $(patsubst %/, %/built-in.o, $(core-y))
-leanos-kernel := $(patsubst %/, %/built-in.o, $(kernel-y))
-leanos-init := $(patsubst %/, %/built-in.o, $(init-y))
-leanos-libs := $(patsubst %/, %/lib.a, $(libs-y))
+flightos-core := $(patsubst %/, %/built-in.o, $(core-y))
+flightos-kernel := $(patsubst %/, %/built-in.o, $(kernel-y))
+flightos-init := $(patsubst %/, %/built-in.o, $(init-y))
+flightos-libs := $(patsubst %/, %/lib.a, $(libs-y))
-# Externally visible symbols (used by link-leanos.sh)
-export KBUILD_LEANOS_INIT := $(leanos-init)
-export KBUILD_LEANOS_MAIN := $(leanos-core) $(leanos-kernel) $(leanos-libs)
+# Externally visible symbols (used by link-flightos.sh)
+export KBUILD_FLIGHTOS_INIT := $(flightos-init)
+export KBUILD_FLIGHTOS_MAIN := $(flightos-core) $(flightos-kernel) $(flightos-libs)
export KBUILD_LDS := arch/$(SRCARCH)/kernel/kernel.lds
-export LDFLAGS_leanos
+export LDFLAGS_flightos
-leanos-deps := $(KBUILD_LDS) $(KBUILD_LEANOS_INIT) $(KBUILD_LEANOS_MAIN)
+flightos-deps := $(KBUILD_LDS) $(KBUILD_FLIGHTOS_INIT) $(KBUILD_FLIGHTOS_MAIN)
-quiet_cmd_leanos = LD $@
- cmd_leanos = $(CC) $(LDFLAGS) -o $@ \
- -Wl,--start-group $(leanos-deps) -Wl,--end-group
+quiet_cmd_flightos = LD $@
+ cmd_flightos = $(CC) $(LDFLAGS) -o $@ \
+ -Wl,--start-group $(flightos-deps) -Wl,--end-group
-PHONY += leanos_prereq
-leanos_prereq: $(leanos-deps) FORCE
+PHONY += flightos_prereq
+flightos_prereq: $(flightos-deps) FORCE
ifdef CONFIG_TRIM_UNUSED_KSYMS
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh \
- "$(MAKE) -f $(srctree)/Makefile leanos"
+ "$(MAKE) -f $(srctree)/Makefile flightos"
endif
# standalone target for easier testing
@@ -643,32 +643,32 @@ include/generated/autoksyms.h: FORCE
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/adjust_autoksyms.sh true
# Final link of vmlinux with optional arch pass after final link
- cmd_link-leanos = \
- $(CONFIG_SHELL) $< $(LD) $(LDFLAGS) $(LDFLAGS_leanos);
+ cmd_link-flightos = \
+ $(CONFIG_SHELL) $< $(LD) $(LDFLAGS) $(LDFLAGS_flightos);
-leanos: leanos_prereq
- $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-leanos.sh
+flightos: flightos_prereq
+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-flightos.sh
# Build samples along the rest of the kernel
ifdef CONFIG_SAMPLES
-leanos-dirs += samples
+flightos-dirs += samples
endif
# The actual objects are generated when descending,
# make sure no implicit rule kicks in
-$(sort $(leanos-deps)): $(leanos-dirs) ;
+$(sort $(flightos-deps)): $(flightos-dirs) ;
-# Handle descending into subdirectories listed in $(leanos-dirs)
+# Handle descending into subdirectories listed in $(flightos-dirs)
# Preset locale variables to speed up the build process. Limit locale
# tweaks to this spot to avoid wrong language settings when running
# make menuconfig etc.
# Error messages still appears in the original language
-PHONY += $(leanos-dirs)
-$(leanos-dirs): prepare scripts
+PHONY += $(flightos-dirs)
+$(flightos-dirs): prepare scripts
$(Q)$(MAKE) $(build)=$@
@@ -717,7 +717,7 @@ prepare: prepare0
define filechk_version.h
(echo \#define LEAONS_VERSION_CODE $(shell \
expr $(VERSION) \* 65536 + 0$(PATCHLEVEL) \* 256 + 0$(SUBLEVEL)); \
- echo '#define LEANOS_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
+ echo '#define FLIGHTOS_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))';)
endef
$(version_h): $(srctree)/Makefile FORCE
@@ -760,12 +760,12 @@ endif
# using awk while concatenating to the final file.
PHONY += modules
-modules: $(leanos-dirs) $(if $(KBUILD_BUILTIN),leanos) modules.builtin
- $(Q)$(AWK) '!x[$$0]++' $(leanos-dirs:%=$(objtree)/%/modules.order) > $(objtree)/modules.order
+modules: $(flightos-dirs) $(if $(KBUILD_BUILTIN),flightos) modules.builtin
+ $(Q)$(AWK) '!x[$$0]++' $(flightos-dirs:%=$(objtree)/%/modules.order) > $(objtree)/modules.order
@$(kecho) ' Building modules, stage 2.';
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
-modules.builtin: $(leanos-dirs:%=%/modules.builtin)
+modules.builtin: $(flightos-dirs:%=%/modules.builtin)
$(Q)$(AWK) '!x[$$0]++' $^ > $(objtree)/modules.builtin
%/modules.builtin: include/config/auto.conf
@@ -775,7 +775,7 @@ modules.builtin: $(leanos-dirs:%=%/modules.builtin)
PHONY += modules_embed_image
modules_embed_image: modules
@$(kecho) ' Embedding module image, stage 3.';
- $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-leanos.sh embed
+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-flightos.sh embed
# Target to prepare building external modules
@@ -839,7 +839,7 @@ endif # CONFIG_MODULES
# Directories & files removed with 'make clean'
CLEAN_DIRS += $(MODVERDIR)
-CLEAN_FILES += leanos
+CLEAN_FILES += flightos
# Directories & files removed with 'make mrproper'
MRPROPER_DIRS += include/config include/generated .tmp_objdiff
@@ -852,16 +852,16 @@ MRPROPER_FILES += .config .config.old .version .old_version \
#
clean: rm-dirs := $(CLEAN_DIRS)
clean: rm-files := $(CLEAN_FILES)
-clean-dirs := $(addprefix _clean_, . $(leanos-dirs))
+clean-dirs := $(addprefix _clean_, . $(flightos-dirs))
-leanosclean:
- $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-leanos.sh clean
+flightosclean:
+ $(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-flightos.sh clean
PHONY += $(clean-dirs) clean archclean
$(clean-dirs):
$(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@)
-clean: $(clean-dirs) leanosclean
+clean: $(clean-dirs) flightosclean
$(call cmd,rmdirs)
$(call cmd,rmfiles)
@find . $(RCS_FIND_IGNORE) \
@@ -916,7 +916,7 @@ help:
@echo ''
@echo 'Other generic targets:'
@echo ' all - Build all targets marked with [*]'
- @echo '* leanos - Build the application'
+ @echo '* flightos - Build the application'
@echo ' dir/ - Build all files in dir and below'
@echo ' dir/file.[ois] - Build specified target only'
@echo ' dir/file.lst - Build specified mixed source/assembly target only'
diff --git a/arch/sparc/kernel/leanos.lds b/arch/sparc/kernel/flightos.lds
similarity index 100%
rename from arch/sparc/kernel/leanos.lds
rename to arch/sparc/kernel/flightos.lds
diff --git a/dsp/xentium/Makefile b/dsp/xentium/Makefile
index 66c26c6..7314a58 100644
--- a/dsp/xentium/Makefile
+++ b/dsp/xentium/Makefile
@@ -2,7 +2,7 @@
#
# Xentium kernels are built as executables, with library functions
# explicitly listed as object dependencies. The executables are later collected
-# in scripts/link-leanos.sh and added to the embedded AR image.
+# in scripts/link-flightos.sh and added to the embedded AR image.
#
# The address of the .text section for the first xentium kernel is determined
# by the confiuration in dsp/xentium/sysroot/lib/default.ld, all subsequent
diff --git a/gr712_demo-config b/gr712_demo-config
index 335d68e..c36a494 100644
--- a/gr712_demo-config
+++ b/gr712_demo-config
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# LeanOS Configuration
+# FlightOS Configuration
#
#
diff --git a/gr740_demo-config b/gr740_demo-config
index 554f224..c709bc2 100644
--- a/gr740_demo-config
+++ b/gr740_demo-config
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# FlighOS Configuration
+# FlightOS Configuration
#
#
diff --git a/scripts/link-leanos.sh b/scripts/link-flightos.sh
similarity index 72%
rename from scripts/link-leanos.sh
rename to scripts/link-flightos.sh
index 5e818b2..86fcce4 100755
--- a/scripts/link-leanos.sh
+++ b/scripts/link-flightos.sh
@@ -1,27 +1,27 @@
#!/bin/sh
#
-# link leanos
+# link flightos
#
-# leanos is linked from the objects selected by $(KBUILD_LEANOS_INIT) and
-# $(KBUILD_LEANOS_MAIN). Most are built-in.o files from top-level directories
+# flightos is linked from the objects selected by $(KBUILD_FLIGHTOS_INIT) and
+# $(KBUILD_FLIGHTOS_MAIN). Most are built-in.o files from top-level directories
# in the kernel tree, others are specified in arch/$(ARCH)/Makefile.
-# Ordering when linking is important, and $(KBUILD_LEANOS_INIT) must be first.
+# Ordering when linking is important, and $(KBUILD_FLIGHTOS_INIT) must be first.
#
-# leanos
+# flightos
# ^
# |
-# +-< $(KBUILD_LEANOS_INIT)
+# +-< $(KBUILD_FLIGHTOS_INIT)
# | +--< init/version.o + more
# |
-# +--< $(KBUILD_LEANOS_MAIN)
+# +--< $(KBUILD_FLIGHTOS_MAIN)
# | +--< drivers/built-in.o mm/built-in.o + more
# |
# +-< ${kallsymso} (see description in KALLSYMS section)
#
-# leanos version (uname -v) cannot be updated during normal
+# flightos version (uname -v) cannot be updated during normal
# descending-into-subdirs phase since we do not yet know if we need to
-# update leanos.
-# Therefore this step is delayed until just before final link of leanos.
+# update flightos.
+# Therefore this step is delayed until just before final link of flightos.
#
# System.map is generated to document addresses of all kernel symbols
@@ -38,7 +38,7 @@ info()
}
# Thin archive build here makes a final archive with
-# symbol table and indexes from leanos objects, which can be
+# symbol table and indexes from flightos objects, which can be
# used as input to linker.
#
# Traditional incremental style of link does not require this step
@@ -51,12 +51,12 @@ archive_builtin()
info AR built-in.o
rm -f built-in.o;
${AR} rcsT${KBUILD_ARFLAGS} built-in.o \
- ${KBUILD_LEANOS_INIT} \
- ${KBUILD_LEANOS_MAIN}
+ ${KBUILD_FLIGHTOS_INIT} \
+ ${KBUILD_FLIGHTOS_MAIN}
fi
}
-# Link of leanos.o used for section mismatch analysis
+# Link of flightos.o used for section mismatch analysis
# ${1} output file
modpost_link()
{
@@ -65,19 +65,19 @@ modpost_link()
if [ -n "${CONFIG_THIN_ARCHIVES}" ]; then
objects="--whole-archive built-in.o"
else
- objects="${KBUILD_LEANOS_INIT} \
+ objects="${KBUILD_FLIGHTOS_INIT} \
--start-group \
- ${KBUILD_LEANOS_MAIN} \
+ ${KBUILD_FLIGHTOS_MAIN} \
--end-group"
fi
${LD} ${LDFLAGS} -r -o ${1} ${objects}
}
-# Link of leanos
+# Link of flightos
# ${1} - optional extra .o files
# ${2} - output file
# ${3} - extra flags
-leanos_link()
+flightos_link()
{
local lds="${objtree}/${KBUILD_LDS}"
@@ -85,13 +85,13 @@ leanos_link()
# if we link against the (BCC) libc, we'll just
# call $CC instead of LD
if [ -n "${CONFIG_TARGET_COMPILER_BOOT_CODE}" ]; then
- ${CC} ${LDFLAGS} ${LDFLAGS_leanos} ${3} -o ${2} \
- ${KBUILD_LEANOS_INIT} ${KBUILD_LEANOS_MAIN} ${1}
+ ${CC} ${LDFLAGS} ${LDFLAGS_flightos} ${3} -o ${2} \
+ ${KBUILD_FLIGHTOS_INIT} ${KBUILD_FLIGHTOS_MAIN} ${1}
fi
if [ -n "${CONFIG_ARCH_CUSTOM_BOOT_CODE}" ]; then
- ${LD} ${LDFLAGS} ${LDFLAGS_leanos} ${3} -o ${2} \
- -T ${lds} ${KBUILD_LEANOS_INIT} ${KBUILD_LEANOS_MAIN} \
+ ${LD} ${LDFLAGS} ${LDFLAGS_flightos} ${3} -o ${2} \
+ -T ${lds} ${KBUILD_FLIGHTOS_INIT} ${KBUILD_FLIGHTOS_MAIN} \
${1}
fi
@@ -150,11 +150,11 @@ cleanup()
rm -f .tmp_System.map
rm -f .tmp_kallsyms*
rm -f .tmp_version
- rm -f .tmp_leanos*
+ rm -f .tmp_flightos*
rm -f built-in.o
rm -f System.map
- rm -f leanos
- rm -f leanos.o
+ rm -f flightos
+ rm -f flightos.o
}
on_exit()
@@ -197,12 +197,12 @@ esac
archive_builtin
-#link leanos.o
-info LD leanos.o
-modpost_link leanos.o
+#link flightos.o
+info LD flightos.o
+modpost_link flightos.o
-# modpost leanos.o to check for section mismatches
-${MAKE} -f "${srctree}/scripts/Makefile.modpost" leanos.o
+# modpost flightos.o to check for section mismatches
+${MAKE} -f "${srctree}/scripts/Makefile.modpost" flightos.o
# Update version
info GEN .version
@@ -218,64 +218,64 @@ fi;
${MAKE} -f "${srctree}/scripts/Makefile.build" obj=init GCC_PLUGINS_CFLAGS="${GCC_PLUGINS_CFLAGS}"
kallsymso=""
-kallsyms_leanos=""
+kallsyms_flightos=""
if [ -n "${CONFIG_KALLSYMS}" ]; then
# kallsyms support
- # Generate section listing all symbols and add it into leanos
+ # Generate section listing all symbols and add it into flightos
# It's a three step process:
- # 1) Link .tmp_leanos1 so it has all symbols and sections,
+ # 1) Link .tmp_flightos1 so it has all symbols and sections,
# but __kallsyms is empty.
# Running kallsyms on that gives us .tmp_kallsyms1.o with
# the right size
- # 2) Link .tmp_leanos2 so it now has a __kallsyms section of
+ # 2) Link .tmp_flightos2 so it now has a __kallsyms section of
# the right size, but due to the added section, some
# addresses have shifted.
# From here, we generate a correct .tmp_kallsyms2.o
# 2a) We may use an extra pass as this has been necessary to
# woraround some alignment related bugs.
# KALLSYMS_EXTRA_PASS=1 is used to trigger this.
- # 3) The correct ${kallsymso} is linked into the final leanos.
+ # 3) The correct ${kallsymso} is linked into the final flightos.
#
- # a) Verify that the System.map from leanos matches the map from
+ # a) Verify that the System.map from flightos matches the map from
# ${kallsymso}.
kallsymso=.tmp_kallsyms2.o
- kallsyms_leanos=.tmp_leanos2
+ kallsyms_flightos=.tmp_flightos2
# step 1
- leanos_link "" .tmp_leanos1
- kallsyms .tmp_leanos1 .tmp_kallsyms1.o
+ flightos_link "" .tmp_flightos1
+ kallsyms .tmp_flightos1 .tmp_kallsyms1.o
# step 2
- leanos_link .tmp_kallsyms1.o .tmp_leanos2
- kallsyms .tmp_leanos2 .tmp_kallsyms2.o
+ flightos_link .tmp_kallsyms1.o .tmp_flightos2
+ kallsyms .tmp_flightos2 .tmp_kallsyms2.o
# step 2a
if [ -n "${KALLSYMS_EXTRA_PASS}" ]; then
kallsymso=.tmp_kallsyms3.o
- kallsyms_leanos=.tmp_leanos3
+ kallsyms_flightos=.tmp_flightos3
- leanos_link .tmp_kallsyms2.o .tmp_leanos3
+ flightos_link .tmp_kallsyms2.o .tmp_flightos3
- kallsyms .tmp_leanos3 .tmp_kallsyms3.o
+ kallsyms .tmp_flightos3 .tmp_kallsyms3.o
fi
fi
-info LD leanos
-leanos_link "${kallsymso}" leanos
+info LD flightos
+flightos_link "${kallsymso}" flightos
if [ -n "${CONFIG_BUILDTIME_EXTABLE_SORT}" ]; then
- info SORTEX leanos
- sortextable leanos
+ info SORTEX flightos
+ sortextable flightos
fi
info SYSMAP System.map
-mksysmap leanos System.map
+mksysmap flightos System.map
# step a (see comment above)
if [ -n "${CONFIG_KALLSYMS}" ]; then
- mksysmap ${kallsyms_leanos} .tmp_System.map
+ mksysmap ${kallsyms_flightos} .tmp_System.map
if ! cmp -s System.map .tmp_System.map; then
echo >&2 Inconsistent kallsyms data
@@ -313,7 +313,7 @@ if [ "$1" = "embed" ]; then
"${CONFIG_EMBED_APPLICATION}"
- leanos_link "${kallsymso}" leanos "${embedflags}"
+ flightos_link "${kallsymso}" flightos "${embedflags}"
exit
fi
diff --git a/tools/testing/hwtests/application/README b/tools/testing/hwtests/application/README
index 3e3fe3c..5bd3fce 100644
--- a/tools/testing/hwtests/application/README
+++ b/tools/testing/hwtests/application/README
@@ -21,6 +21,6 @@ Prerequisites:
Notes:
======
-The current .config of LeanOS will be overwritten and the image will
+The current .config of FlightOS will be overwritten and the image will
be rebuilt.
diff --git a/tools/testing/hwtests/application/config b/tools/testing/hwtests/application/config
index 7dbd6f6..87a898c 100644
--- a/tools/testing/hwtests/application/config
+++ b/tools/testing/hwtests/application/config
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# LeanOS Configuration
+# FlightOS Configuration
#
#
diff --git a/tools/testing/hwtests/application/config-gr740 b/tools/testing/hwtests/application/config-gr740
index f93fa6c..9d9c7a8 100644
--- a/tools/testing/hwtests/application/config-gr740
+++ b/tools/testing/hwtests/application/config-gr740
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# LeanOS Configuration
+# FlightOS Configuration
#
#
diff --git a/tools/testing/hwtests/application/grmon_cmds b/tools/testing/hwtests/application/grmon_cmds
index 05f292d..fdea887 100644
--- a/tools/testing/hwtests/application/grmon_cmds
+++ b/tools/testing/hwtests/application/grmon_cmds
@@ -1,3 +1,3 @@
-load leanos
+load flightos
run
quit
diff --git a/tools/testing/hwtests/xen_proc_net/.run_test.sh.swp b/tools/testing/hwtests/xen_proc_net/.run_test.sh.swp
index 6336c7ea0b8a8162f80d0c701f1df316ccbfb101..38ebf9f2e8537ffaf57c533b14f69faa8d9c801f 100644
GIT binary patch
delta 28
gcmZojXi1n*&gPbrnVwOyv3k26TN;=-*-ZZw0H%=(hX4Qo
delta 24
fcmZokXh@h)&f=4rn76TZyB<qUYGU4GEB#Xddb<hD
diff --git a/tools/testing/hwtests/xen_proc_net/README b/tools/testing/hwtests/xen_proc_net/README
index 4bbc3f8..1006c66 100644
--- a/tools/testing/hwtests/xen_proc_net/README
+++ b/tools/testing/hwtests/xen_proc_net/README
@@ -30,6 +30,6 @@ Prerequisites:
Notes:
======
-The current .config of LeanOS will be overwritten and the image will
+The current .config of FlightOS will be overwritten and the image will
be rebuilt.
diff --git a/tools/testing/hwtests/xen_proc_net/config b/tools/testing/hwtests/xen_proc_net/config
index bc04635..db6cffa 100644
--- a/tools/testing/hwtests/xen_proc_net/config
+++ b/tools/testing/hwtests/xen_proc_net/config
@@ -1,6 +1,6 @@
#
# Automatically generated file; DO NOT EDIT.
-# LeanOS Configuration
+# FlightOS Configuration
#
#
diff --git a/tools/testing/hwtests/xen_proc_net/run_test.sh b/tools/testing/hwtests/xen_proc_net/run_test.sh
index dd8b4e4..002b866 100755
--- a/tools/testing/hwtests/xen_proc_net/run_test.sh
+++ b/tools/testing/hwtests/xen_proc_net/run_test.sh
@@ -13,7 +13,7 @@ make || exit 1
timeout 120 bash -c \
- "printf \"load leanos\nrun\nquit\" |\
+ "printf \"load flightos\nrun\nquit\" |\
grmon -leon2 -u -uart /dev/ttyS0 |\
tee /dev/tty |\
grep SUCCESS &> /dev/null"
--
GitLab