diff --git a/IOCP_README.md b/IOCP_README.md new file mode 100644 index 0000000..b190d3e --- /dev/null +++ b/IOCP_README.md @@ -0,0 +1,229 @@ +
+### Using IOCP + +The I/O Control Program (IOCP) is basically a bootloader, it can operate standalone or as the first stage in booting an application. Depending on the configuration it can provide a low level monitor via the serail +connection for basic memory inspection and bootstrapping. + +At the time of writing the following functionality and memory maps have been defined in the build.sh script and within the parameterisation of the IOCP /zOS /ZPUTA /RTL but any other is possible by adjusting the parameters. + + - Tiny - IOCP is the smallest size possible to boot from SD Card. It is useful for a SoC configuration where there is limited BRAM and the applications loaded from the SD card would potentially run in external RAM. + - Minimum - As per tiny but adds: print IOCP version, interrupt handler, boot message and SD error messages. + - Medium - As per small but adds: command line processor adding the commands below, a timer for auto boot so that it can be disabled before expiry by pressing a key + + | Command | Description | + | ------- | ------------------------------------------ | + | 1 | Boot Application in Application area BRAM | + | 4 | Dump out BRAM (boot) memory | + | 5 | Dump out Stack memory | + | 6 | Dump out application RAM | + | C | Clear Application area of BRAM | + | c | Clear Application RAM | + | d | List the SD Cards directory | + | R | Reset the system and boot as per power on | + | h | Print out help on enabled commands | + | i | Prints version information | + + - Full - As medium but adds additional commands below. + + | Command | Description | + | ------- | ------------------------------------------ | + | 2 | Upload to BRAM application area, in binary format, from serial port | + | 3 | Upload to RAM, in binary format, from serial port | + | i | Print detailed SoC configuration | + + +## Technical Detail + +This section aims to provide some of the inner detail of the IOCP bootloader to date. A lot of this information can be seen in the zOS/ZPUTA documents but the aim is to provide finer detail +on IOCP here. + + +### Memory Organisation + + +##### IOCP Memory Map + + +The IOCP has been defined with 4 possible memory maps depending on the memory model chosen at compile time. The currently defined memory maps for IOCP are as follows:- + + +![IOCP Memory Map](../images/IOCPMemoryMap.png) + + +IOCP can be configured to be the first stage loader for zOS/ZPUTA or any other suitably compiled program or it can be enhanced to be the actual end application. zOS/ZPUTA can also be +compiled 'standalone' such that IOCP isnt needed, booting themselves directly as the power on firmware. + +zOS and ZPUTA can be built to use an SD card where they can have applets (portions of their functionality created as dedicated executables on the SD card) or in the case of ZPUTA, standalone +with all functionality inbuilt. The latter is used when there is limited memory or a set of loadable programs is desired. + +
+ + +## Software Build + +This section shows how to make a basic IOCP build. The start point for building the IOCP (or zOS/ ZPUTA/ Applications) is the 'build.sh' script which contains all the logic required. +This program started off as knowledge dumps and enhanced as the software progressed. It would be nice, eventually, to redesign this script as it is pushing into BASH shell language what +really should be coded in Python or Java, but it works for now in building this software. + + +## Paths + +For ease of reading, the following shortnames refer to the corresponding path in this chapter. + +| Short Name | | +|------------------|----------------------------------------------------------------------------| +| \[\\] | The path where this repository was extracted on your system. | +| \ | \[\\]/zsoft/apps | +| \ | \[\\]/zsoft/common | +| \ | \[\\]/zsoft/libraries | +| \ | \[\\]/zsoft/teensy3 | +| \ | \[\\]/zsoft/include | +| \ | \[\\]/zsoft/startup | +| \ | \[\\]/zsoft/iocp | +| \ | \[\\]/zsoft/zOS | +| \ | \[\\]/zsoft/zputa | +| \ | \[\\]/zsoft/rtl | +| \ | \[\\]/zsoft/docs | +| \ | \[\\]/zsoft/tools | + + +## Tools + +All development has been made under Linux, specifically Debian/Ubuntu. Besides the standard Linux buildchain, the following software is needed. + +| | | +| --------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------- | +[ZPU GCC ToolChain](https://github.com/zylin/zpugcc) | The GCC toolchain for ZPU development. Install into */opt* or similar common area. | +[Arduino](https://www.arduino.cc/en/main/software) | The Arduino development environment, not really needed unless adding features to the K64F version of zOS from the extensive Arduino library. Not really needed, more for reference. | +[Teensyduino](https://www.pjrc.com/teensy/td_download.html) | The Teensy3 Arduino extensions to work with the Teensy3.5 board at the Arduino level. Not really needed, more for reference. | + +IOCP hasnt yet been ported to the K64F as there seems little need for it, but for completeness and reference, the Teensy3.5/K64F the ARM compatible toolchain is stored in the repo within the +build tree. + + +## Build Tree + +The software is organised into the following tree/folders: + +| Folder | Src File | Description | +| ------- | -------- | ------------------------------------------------------------ | +| apps | | The zOS/ZPUTA applications applets tree. These are separate standalone disk based applets which run under zOS/ZPUTA.
All applets for zOS/ZPUTA are stored within this folder. | +| build | | Build tree output suitable for direct copy to an SD card.
The initial bootloader and/or application as selected are compiled directly into a VHDL file for preloading in BRAM in the devices/sysbus/BRAM folder. | +| common | | Common C modules such as Elm Chan's excellent Fat FileSystem. | +| docs | | All documents relevant to this project. | +| libraries | | Code libraries, soon to be populated with umlibc and FreeRTOS | +| rtl | | Register Transfer Level templates and generated files. These files contain the preloaded VHDL definition of a BRAM based RAM/ROM used with the ZPU.| +| teensy3 | | Teensy 3.5 files required for building a K64F processor target. | +| include | | C Include header files. | +| iocp | | A small bootloader/monitor application for initialization of the ZPU. Depending upon configuration this program can either boot an application from SD card or via the Serial Line and also provide basic tools such as memory examination. | +| startup | | Assembler and Linker files for generating ZPU applications. These files are critical for defining how GCC creates and links binary images as well as providing the micro-code for ZPU instructions not implemented in hardware. | +| tools | | Some small tools for converting binary images into VHDL initialization data. | +| zputa | | The ZPU Test Application. This is an application for testing the ZPU and the SoC components. It can either be built as a single image for pre-loading into a BRAM via VHDL or as a standalone application loaded by the IOCP bootloader from an SD card. The services it provides can either be embedded or available on the SD card as applets depending on memory restrictions. | +| zOS | | The z-Operating System. This is a light OS derived from ZPUTA with the aim of providing a framework, both for application building and runtime control, within a ZPU or K64F project. The OS provides disk based services, common hardware access API and additional features to run and service any application built for this enviroment. Applications can be started autonomously or interactively via the serial based VT100 console. | +| | build.sh | Unix shell script to build IOCP, zOS, ZPUTA and Apps for a given design.
![build.sh](../images/build_sh.png) | + + +### Build.sh + +IOCP is built using the 'build.sh' script. This script encapsulates the Makefile system with it's plethora of flags and options. The synopsis of the script is below: +```bash +NAME + build.sh - Shell script to build a ZPU program or OS. + +SYNOPSIS + build.sh [-CIOoMBAsdxh] + +DESCRIPTION + +OPTIONS + -C = Small, Medium, Flex, Evo, K64F - defaults to Evo. + -I = 0 - Full, 1 - Medium, 2 - Minimum, 3 - Tiny (bootstrap only) + -O = zputa, zos + -o = 0 - Standalone, 1 - As app with IOCP Bootloader, + 2 - As app with tiny IOCP Bootloader, 3 - As app in RAM + -M = Max size of the boot ROM/BRAM (needed for setting Stack). + -B = Base address of , default -o == 0 : 0x00000 else 0x01000 + -A = App address of , default 0x0C000 + -N = Required size of heap + -n = Required size of application heap + -S = Required size of stack + -s = Required size of application stack + -a = Maximum size of an app, defaults to (BRAM SIZE - App Start Address - Stack Size) + if the App Start is located within BRAM otherwise defaults to 0x10000. + -d = Debug mode. + -x = Shell trace mode. + -h = This help screen. + +EXAMPLES + build.sh -O zputa -B 0x00000 -A 0x50000 + +EXIT STATUS + 0 The command ran successfully + + >0 An error ocurred. +``` + +Sensible defaults are configured into the script, the overriding flags are described below. + +| Flag            | Description | +| ---------------------------------------------------------------------------------- | ----------- | +| -C \ | The target CPU of the finished image. This flag is necessary As each ZPU has a different configuration and therefore the underlying Make needs to be directed into its choice of startup code and configuration. With the inclusion of the ARM based K64F this flag makes further sense.

The choices are:
*Small* - An absolute minimum ZPU hardware design with most instructions implemented in microcode.
*Medium* - An interim ZPU design using more hardware and better performance, majority of instructions are embedded in hardware.
*Flex* - A ZPU small based design but with many enhanced features, including the majority of instructions being embedded in hardware.
*Evo* - The latest evolution of the ZPU, all instructions are embedded in hardware, framework to add extended instructions and 2 stage cache to aid performance.
*K64F* - An ARM Cortex-M4 based processor from Freescale.
*Evo is the detault.* | +| -I \ | Set the memory model for the build. The memory models are described above.

The choices are:
*0*- Full
*1* - Medium
*2* - Minimum
*3* - Tiny (bootstrap only).
*Default is set to 3.* | +| -O \ | Set the target operating system.

The choices are:
*zputa* - The ZPU Test Application which also runs on the K64F.
*zos* - The zOS Operating System.
There is no default, if an OS is being built then this flag must be given. | +| -o \ | Set the operating system target model.

The choices are:
*0* - Standalone, the operating system is the startup firmware.
*1* - As app with IOCP Bootloader, the operating system is booted by IOCP from an SD card, IOCP remains memory resident.
*2* - As app with tiny IOCP Bootloader, the operating system is booted from SD card by the smallest IOCP possible, IOCP remains memory resident.
*3* - As app in RAM, the operating system is targetted to be loaded in external (to the FPGA) RAM, either static or dynamic, IOCP remains memory resident in BRAM.
*The default is 2.*
**This flag has no meaning for the K64F target.** | +| -M \ | Specify the maximum size of the boot ROM/BRAM (needed for setting Stack).
**This flag has no meaning on the K64F target.** | +| -B \ | Base address of \.
*default: if -o == 0 : 0x00000 else 0x01000*
**This flag has no meaning on the K64F target.** | +| -A \ | App starting/load address for the given \.
*default 0x0C000 for ZPU, 0x1FFF0000 for K64F* | +| -N \ | Required size of \ heap. The OS and application heaps are currently distinct. Should RTOS be integrated into zOS then this will change. | +| -n \ | Required size of application heap. The application has a seperate heap allocated and is managed by the application. | +| -S \ | Required size of stack. Normally the \ manages the stack which is also used by an application. If the application is considered dangerous then it should be allocated a local stack. | +| -s \ | Required size of application stack. Normally this should not be required as the application shares the \ stack. If the application is dangerous then set this value to allocate a local stack. | +| -a \ | Maximum size of an application.
*defaults to (BRAM SIZE - App Start Address - Stack Size) for the ZPU if the App Start is located within BRAM otherwise defaults to 0x10000, or 0x20030000 - Stack Size - Heap Size - 0x4000 for the K64F. If the App Start is located within BRAM otherwise defaults to 0x10000.* | +| -d | Debug mode. Enable more verbose output on state and decisions made by the script. | +| -x | Shell trace mode. A very low level, line by line trace of shell execution. Only used during debugging. | +| -h | This help screen. | + +
+To build a Tiny memory model IOCP bootloader for the Flex CPU with 32K BRAM and an application loading at 0x1000, you would issue the command: + +```bash +/build.sh -C Flex -I 3 -M 0x8000 -B 0x1000 +``` + +NB: App is a term only used when an \ is deployed, ie. zOS + App, if you build a program to start at 0x1000 and place it onto the SD card as BOOTTINY.ROM then this is considered the bootstrapped program loading at Base Addr, not an application. + +The bootstrapped filename is dependent upon the memory model chosen, this file must be present in the root directory of a FAT32 formatted SD card to be recognised and bootstrapped: +* BOOT.ROM - Memory models: Full, Medium, Minimum. +* TINYBOOT.ROM - Memory models: Tiny. + + + +
+## Credits + +Where I have used or based any component on a 3rd parties design I have included the original authors copyright notice within the headers or given due credit. All 3rd party software, to my knowledge and research, is open source and freely useable, if there is found to be any component with licensing restrictions, it will be removed from this repository and a suitable link/config provided. + + +
+## Licenses + +The original ZPU uses the Free BSD license and such the Evo is also released under FreeBSD. SoC components and other developments written by me are currently licensed using the GPL. 3rd party components maintain their original copyright notices. + +### The FreeBSD license + Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met: + + 1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. + 2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. + + THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE ZPU PROJECT OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + + The views and conclusions contained in the software and documentation are those of the authors and should not be interpreted as representing official policies, either expressed or implied, of the this project. + +### The Gnu Public License v3 + The source and binary files in this project marked as GPL v3 are 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. + + The source files are 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/. + + diff --git a/README.md b/README.md new file mode 100644 index 0000000..1a8984f --- /dev/null +++ b/README.md @@ -0,0 +1,33 @@ +
+zSoft is the collective term for all the applications and operating systems developed for the ZPU processor. Originally the Z stood for ZPU but with the inclusion of additional CPU +architectures, it now means Zeta, the sixth Greek alphabet letter. + +A few months ago the tranZPUterSW project was born as an offshoot from the tranZPUter in order to more rapidly forward the tranZPUter design via software development. This came in the shape +of the Teensy 3.5 development board by [PJRC.com](https://www.pjrc.com/store/teensy35.html) or more importantly the Freescale K64F processor, an ARM Cortex-M4 CPU. Adding this CPU required +quite a few changes to the source code to allow for two (or potentially more) different processing architectures but it makes the z-soft software more useable by 3rd parties should they +wish to use it in their own projects, especially given the plethora of ARM development boards available. + +The zSoft collection currently includes: + +#### zOS +zOS started life as an application to aid in testing the ZPU design as it evolved, originally given the name ZPUTA (ZPU Testing Application). Some of the FPGA development boards I had been +working with had limited memory (BRAM) and the application had to be made configurable to size it according to available memory. Once an SD card had been added into the hardware SoC, the +application advanced to become more of an Operating System on par with CPM/MSDOS storing applications on disk rather than being built into the application. Thus was born the idea for zOS, +take ZPUTA, strip it down of unnecessary testing code and create an OS to be used at the core of the tranZPUter, tranZPUterSW, ZPU and Sharp MZ Emulator projects. + +I am currently looking at blending in an RTOS to provide missing features such as scheduling but that is for another day, especially given the restriction which the ZPU GCC +compiler places on the project, ie C++98/C99 specifications! + +#### ZPUTA +ZPUTA was the original test application which evolved into an OS and was split to form zOS. It will still carry on with its original purpose and provide functionality not available in +zOS specifically useable for testing. It also has the capability of being built as a single program with most of the application applet functionality within it and so is useful in +environments where there is no SD card. zOS will over time become more a refined OS for my own projects and ZPUTA will continue on for CPU/hardware testing. + +#### IOCP +Prior to ZPUTA, I created a bootstrap program called the IOCP (I/O Control Program) which operated at the lowest hardware levels and was able to boot more sophisticated programs, ie. ZPUTA. +The IOCP is size sensitive and was designed to bootstrap from any memory device and by including an SD card and the [Petit FatFS](http://elm-chan.org/fsw/ff/00index_p.html) it is able to +bootstrap off an SD card. IOCP was originally used to bootstrap ZPUTA, aiding development speed by just copying a ZPUTA kernel onto an SD card when a change was made but eventually I included +the low level code into ZPUTA and it was able to boot as the primary software without needing IOCP. IOCP still remains within the project to boot any application not needing ZPUTA or zOS +level of sophistication. + +The following sections, selected on the navigation bar to the left, describe zOS, ZPUTA, IOCP and all the Application applets at their current states of evolution. diff --git a/ZOS_README.md b/ZOS_README.md new file mode 100644 index 0000000..9ed9c87 --- /dev/null +++ b/ZOS_README.md @@ -0,0 +1,612 @@ +
+ +### zOS + +zOS is a spin-off from the ZPUTA test application which was created to verify ZPU Evo and SoC operations. ZPUTA evolved as different FPGA's were included in the ZPU Evo scope and it became +clear that it had to be more advanced due to limited resources. Once ZPUTA had evolved into something of a level of sophistication akin to an OS, it was split and zOS was born. + +Originally the ZPUTA/zOS developments only targetted the ZPU architecture and they had two primary methods of execution: + +* as an application booted by IOCP, +* standalone booted as the ZPU Evo startup firmware. + +The mode is chosen in the configuration and functionality is identical. When booted as an application by IOCP, zOS is stored on an SD card and loaded at boot time. When 'standalone' +zOS is stored in the onboard Flash (or preconfigure BRAM acting as ROM). + +More recently, zOS was ported to the ARM Cortex-M4 architecture for use with the Freescale K64F on the tranZPUterSW project. As the K64F is a fixed architecture CPU / SoC only one +method of execution exists, 'standalone', it is stored in the onboard Flash and started when the CPU powers up. + +In zOS, all non-OS functionality is stored as applications on an SD Card. If an SD Card isnt present then it is better to use ZPUTA as it has the ability to cater for limited FPGA BRAM +resources as all functionality of ZPUTA can be enabled/disabled within the primary loaded image. + +To operate, zOS requires a serial connection (physical or usb-virtual) with preferably an ANSI/VT100 terminal emulator package connected to it. The requirement for an ANSI/VT100 terminal +emulation package is to allow commands such as the editor or readline to function correctly. A dumb serial terminal will work fine but at reduced application functionality. If no serial +connection is available or an interactive OS is not needed, just the ability to boot an application on power up, then the IOCP would be the better choice (albeit not yet ported to the K64F). + +## Using the OS + +Throughout my career I have used or designed systems where you had live interaction with the end product to either monitor, change the logic flow according to market changes or fix problems +real-time. This has normally been through an embedded command processor using the TCP client-server interconnect. The benefits of this approach are enormous and done correctly mitigate +security risks. Companies such as Reuters and TibCO use this technique (ie. their 'Hawk' product) and I have crafted it into my own developments such as the trade execution and pricing module +I wrote at Morgan Stanley and the Options trading system at Chase Manhattan with great effect. + +When working on some of my projects in this repository it has always been at the forefront of my thoughts that I wanted a similar environment, even on an embedded system with limited +resources, where I could monitor, change or fix on the fly. This thought started off with the IOCP which has basic monitoring, uploading and execution functionality and was further +enhanced when I started writing ZPUTA with its enhanced functionality and external applications. Time scheduling, at least a basic level will soon be implemented which will allow an embedded +application driving the hardware to run as required yet still leave processing resource to run the OS and provide services to a connected user/developer. The projects dont have a network +stack as most dev boards I've used dont have ethernet which limites connectivity to the serial line. The advantage of asynchronous serial communications is it is simple and can be connected +to a terminal on nearly every PC, either direct via a USB adapter or via RS-232. I could implement SLIP but keeping it simple at this level is my preferred alternative. So long as you can +connect a serial line between the dev board hosting zOS and a PC you can use it's functionality. + +The OS interface has been written keeping in mind that only a serial text based terminal is available. Some components such as the Editor need more advanced capabilities and to this end +the venerable VT100 emulation was chosen as a suitable candidate (which means you need a VT100 emulator sat in front of the serial line in order to use the Editor). Interaction is keyboard +and text based, (no nice GUI interfaces!) with the sections below providing information needed to use the interface. + + +### Command Line + +The first introduction to the OS is a sign-on message which details the CPU, version etc and issues a prompt for command input, ie: + +![zOS Startup Screen](../images/zOS_Startup.png) + +Interaction with the OS is no different than say MSDOS, you enter a command and get a response. The only difference is that it is within an embedded system not a full blown PC. + +The zOS command line is not a shell interpreter just a basic text interface provided for the issuing of built-in commands or commands stored on the SD card. It does include a cutdown readline +capability with history to aid in command entering and retrieval and generally follows the GNU readline functionality, the recognised keys at the command line are: + +| Key | Action | +| --- | ------- | +| CTRL-A | Go to start of line. | +| CTRL-B | Move cursor one position to the left. | +| CTRL-C | Abort current line and return CTRL-C to calling application. | +| CTRL-D | Not defined in shell, passed to running application. | +| CTRL-E | Go to end of line. | +| CTRL-F | Move cursor one position to the right. | +| CTRL-K | Clear the line. | +| CTRL-N | Recall next historized command. | +| CTRL-P | Recall previous historized command. | +| HOME | Go to start of line. | +| END | Go to end of line. | +| INSERT | Not yet defined. | +| DEL | Delete character under cursor. | +| BACKSPACE | Delete character to left of cursor. | +| PGUP | Not defined in shell, passed to running application. | +| PGDOWN | Not defined in shell, passed to running application. | +| ARROW UP | Recall previous historized command. | +| ARROW DOWN | Recall next historized command. | +| ARROW RIGHT | Move cursor one position to the right. | +| ARROW LEFT | Move cursor one position to the left. | + +The readline mechanism also recognises a few internal commands, namely: + +| Command | Action | +| ------- | ------ | +| !\ | Recall and execute given historised command identified by \. | +| hist\[ory\] | List the history buffer. | + + +### Applications + +The applications currently provided by zOS reside on an SD card and are summarised below. For more detailed information +please refer to the Application section (on the left navigation bar) or the Application README file. + + - #### Disk IO Commands + + | Command | Parameters | Description | + | ------- | ------------------------------------- | ----------------------------------------------- | + | ddump | \[ \] | Dump a sector | + | dinit* | \ \[\] | Initialize disk | + | dstat* | \ | Show disk status | + | dioctl* | \ | ioctl(CTRL_SYNC) | + + - #### Disk Buffer Commands + + | Command | Parameters | Description | + | ------- | ------------------------------------- | ----------------------------------------------- | + | bdump | \ | Dump buffer | + | bedit | \ \[\] ... | Edit buffer | + | bfill | \ | Fill buffer | + | blen | \ | Set read/write length for fread/fwrite command | + | bread | \ \ \[\] | Read into buffer | + | bwrite | \ \ \[\] | Write buffer to disk | + + - #### Filesystem Commands + + | Command | Parameters | Description | + | ------- | ------------------------------------- | ----------------------------------------------- | + | falloc | \ \ | Allocate ctg blks to file | + | fattr | \ \ \ | Change object attribute | + | fcat | \ | Output file contents | + | fcd | \ | Change current directory | + | fclose | | Close the open file | + | fconcat | \ \ \ | Concatenate 2 files | + | fcp | \ \ | Copy a file | + | fdel | \ | Delete an object | + | fdir | \[\] | Show a directory | + | fdrive | \ | Change current drive | + | fdump | \ \[\] | Dump a file contents as hex | + | fexec* | \ \ \ \ | Load and execute file | + | finit* | \ \[\] | Force init the volume | + | finspect | \ | Read part of file and examine | + | flabel | \