High Level Architecture and Control Flow
The following distinct components can be found in the application:
The following diagram shows the control flow wihtin the application. Please refer the the detailed component description below to understand the transition conditions.
The Boot Manager is always the entry point of the application and based on his evaluation the succeeding control flow will be selected.
Initially the Boot Manager will run a boot check where the following triggers are checked:
- If
runinstalleris specified in recovery.cmdline go into setup mode - If
no-webserveris specified in recovery.cmdline, disable webserver subsequentially - If no installed OS can be detected go into setup mode
- Else boot into default partition
If the Boot Manager goes into setup mode, he will first run the Pre-Setup. Afterwards the Web Server will be started (if it is not disabled by commandline arguments) and the application will await HTTP calls at its REST-API, otherwise a self-explanatory command line interface will be presented. This is only for debugging purposes.
When Pre-Setup is executed, it will first check, if the SD Card was previously formatted according to the NOOBS4IoT specification. If this is not the case, the appropriate scheme will be applied. In case the SD Card's current FAT formatting is unclean an error will be reported and the system cannot proceed.
Afterwards Pre-Setup will remove the commandline argument runinstaller, since this should not be necessary anymore. Finally the networking services will be started and the routine will return to the Boot Manager.
This Web Server is a simple self-written, C-socket based HTTP 1.1 web server implementation. It does not use any multi-threading, which suits this use case very well. Hovewer it provides a dynamic routing interface.
The routes are created within the Boot Manager, where the Web Server is also started. The server provides a straight foward REST-API to control the NOOBS4IoT application and enable remote provisioning.
Upon receiving a request, the respective callback function, defined in the Boot Manager are executed. Depending on the used API, the Install Manager is started.
- InstallManager.h
- InstallManager.cpp
- InstallManager_Utility.cpp
- Object Files, holding parsed information about to-be-installed OS:
The Install Manager expects at least one well formatted OSInfo object, containing at least one PartitionInfo object. The object needs to be valid (based on the valid() call, which will check validity of the OSInfo object and all of its PartitionInfo objects).
Initially it will check each OSInfo and their respective PartitionInfo objects for validity and calculate the space requirements, to check if there is enough space available. Based on this information a partition schema is created, which contains size and label information.
Subsequentially this scheme is written to the SD Card, followed by the acquisition and extraction of each specified tarball of each partition.
Finally the partition_setup.sh script is executed for each OSInfo object (if applicable). Concluding the Install Manager writes the information about the installed OS to the settings partition and returns to the Boot Manager.
