COMING SOON...
OX 2.0 is coming with a new full-fledged FTL and Near-Data Processing support!

RELEASE
OX 1.4.0 is released. The main feature is supporting pblk target (host FTL) by enabling 
sector-granularity reads. It allows file systems on top of the DFC namespace. It requires 
the linux kernel 4.13 or higher. Please, check the 'pblk: Host-side FTL setup' section.

READ : ~385 MB/s
WRITE: ~298 MB/s

The FPGA 03.01.00 provides a maximum throughtput of 400 MB/s READ and 300 MB/s WRITE.

 - ox-ctrl is a essential-only binary for a production environment. 
 - ox-ctrl-test is a complete binary including all tests and administration mode. 
 - ox-ctrl-volt has Volt Storage Media Manager. An in-memory backend instead of NAND, 
 for testing purposes.
 
 IMPORTANT:
 - rootfs_03.00.00_ox-1.x.sqsh is the rootfs containg ox-ctrl. If you do not use this 
 rootfs, you have to disable  the 'issd-nvme' application that runs automatically by other rootfs.

$ ox-ctrl start (production)
$ ox-ctrl debug (print everything that is going on)
$ ox-ctrl 

$ ox-ctrl-volt start
$ ox-ctrl-volt debug

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash blacklist=nvme mem=8G"

(1) Install the right kernel with user IO support (kernel 4.13 or higher):
  - https://www.kernel.org/
  
(2) Blacklist the nvme driver (not necessary in QEMU. For the DFC, we use an OX-enabled driver);
  
(3) Start OX Controller in the DFC (in QEMU it will be already started). You have to install OX on the DFC before;
  In the DFC console:
  $ ox-ctrl start

(4) Create the bad block tables for all channels. Skip this step if you already did it in your NAND DIMM.
  Follow the 'Bad block table creation' section for details.
  
(5) Build and load the NVMe driver (in QEMU it will be already loaded);
  - https://github.com/ivpi/nvme-driver-DFC
  $ sudo insmod <driver_folder>/nvme-core.ko
  $ sudo insmod <driver_folder>/nvme.ko
  
(6) Check the kernel log, you should see the device registration messages;
  lnvm: Dragon Fire Card NVMe Driver support.
  nvm: registered nvme0n1 [4/2/512/1024/32/8]
  
(7) Check if pblk is compiled and started;
  $ sudo nvme lnvm info
  
(8) Initialize pblk on the DFC namespace;
  $ sudo nvme lnvm create -t pblk -d nvme0n1 -n dfc -b 0 -e 31
  It might take a while. Please check the kernel log for completion.
  
(9) Create a partition table;
  $ sudo fdisk /dev/dfc
  use 'g' for creating a new partition table
  use 'n' for creating a new partition
  use 'w' for writing the changes to storage
 
(10) Format your partition with a file system;
  $ sudo mkfs.ext4 /dev/dfc1
  Check kernel log for completion.

(11) Mount the partition;
  $ sudo mount /dev/dfc1 <mount_folder>

(12) You might need to give permissions to your user;
  $ sudo chown <user>:<user> <mount_folder>
  
(13) Enjoy your new storage device transferring some files to it :)

(1) Install the right kernel with user IO support (kernel 4.11 or higher):
  - https://www.kernel.org/
  
(2) Blacklist the nvme driver (not necessary in QEMU. For the DFC, we use an OX-enabled driver);

(3) Install liblightnvm;
  - http://lightnvm.io/liblightnvm/
  
(4) Start OX Controller in the DFC (in QEMU it will be already started). You have to install OX on the DFC before;
  In the DFC console:
  $ ox-ctrl start

(5) Create the bad block tables for all channels. Skip this step if you already did it in your NAND DIMM.
  Follow the 'Bad block table creation' section for details.
  
(6) Build and load the NVMe driver (in QEMU it will be already loaded);
  - https://github.com/ivpi/nvme-driver-DFC
  $ sudo insmod <driver_folder>/nvme-core.ko
  $ sudo insmod <driver_folder>/nvme.ko
  
(7) Check the kernel log, you should see the device registration messages;
  lnvm: Dragon Fire Card NVMe Driver support.
  nvm: registered nvme0n1 [4/2/512/1024/32/8]
  
(8) Run the tests with the tool (https://github.com/DFC-OpenSource/fox), or use liblightnvm as you wish.

========================================
        Image           Version                
 ========================================
    PBL                   03.00.01
    DPC                   03.00.00
    MC                    03.00.00
    Kernel                05.00.00
    U-boot                03.00.00
    rootfs                03:00:00
    CPLD_NIC              A12 
    CPLD_SSD              A02 
    FPGA                  03.01.00

LS2085 Dragon Fire Card (soon LS2088);
2 NAND DIMM modules installed in the slots M1 and M3 of the storage card.

      - Media managers: NAND, DDR, etc.
      - Flash Translation Layers + LightNVM raw FTL support
      - Interconnect handler: PCIe, network fabric, etc.
      - NVMe queues and tail/head doorbells
      - NVMe, LightNVM and Fabric(not implemented) command parser
      - RDMA handler(not implemented): RoCE, InfiniBand, etc.

      Media managers (MMGR): Identifies the non-volatile memory, and registers a channel
        abstraction with its geometry to be available to the stack. Media managers
        implement read/write/erase commands to specific pages and blocks. OX may have
        several media managers exposing channels from different sources.
        
      Flash Translation Layers (FTL): Manages MMGR channels, accepts IO commands (a
        command may have several pages) and sends page-level commands to the media
        managers. It implements responsibilities such as WL, L2P, GC, BB and ECC. Several
        FTLs may run within OX and be responsible to manage different MMGR channels.

      Interconnect handlers (ICH): Communication between controller and host. This layer
        implements responsibilities such as NVMe register mapping and MSI interruptions. It
        gathers data from the host and sends it to the command parser layer.
        
      NVMe queue support: Read/write NVMe registers mapped by the ICH, manage admin/
        IO NVMe queue(s) and perform the DMA data transfer if FPGA does not provide it.
        
      Command parsers: Parses commands from the ICH and call the right FTL
        instance to handle it.

   1 - Full scan (Erase, write full, read full, compare buffers) - RECOMMENDED. Might take a long time
           - Backup the channel data before. ALL DATA WILL BE LOST.
           
   2 - Fast scan (Only erase the blocks) - Fast creation, but can have omitted bad blocks.
           - Backup the channel data before. ALL DATA WILL BE LOST.
           
   3 - Emergency table (Creates an empty bad block table without erasing blocks) - Very fast and the channel is not erased.
           - If you can't make a backup of your channel, use this option for initializing OX, however, all blocks will be
              marked as good. You should use the DFC in read-only state if you create an emergency bad block table.

Use 'start' to run the controller with standard settings.

Use 'debug' to run the controller in debug mode (verbose).

Use 'null' to run the controller as a null device. No data transfer is performed, OX will complete all 
I/Os succesfully. This mode is useful for testing the NVMe queues.

Use 'null-debug' to run the controller as a null device and show the debug information in the screen.

*** OX Controller ***
 
 An OpenChannel SSD Controller

 Available commands:
  start            Start controller with standard configuration
  debug            Start controller and print Admin/IO commands
  test             Start controller, run tests and close
  admin            Execute specific tasks within the controller
  null             Start controller with Null IOs (NVMe queue tests)
  null-debug       Null IOs and print Admin/IO commands
 
 Initial release developed by Ivan L. Picoli, the red-eagle


  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

Report bugs to Ivan L. Picoli <ivpi@itu.dk>

Use this command to run tests, it will start the controller, run the tests and
close the controller.

 Examples:
  Show all available set of tests + subtests:
    ox-ctrl test -l

  Run all available tests:
    ox-ctrl test -a

  Run a specific test set:
    ox-ctrl test -s <set_name>

  Run a specific subtest:
    ox-ctrl test -s <set_name> -t <subtest_name>

  -a, --all[=run_all]        Use to run all tests.
  -l, --list[=list]          Show available tests.
  -s, --set=test_set         Test set name. <char>
  -t, --test=test            Subtest name. <char>
  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.

Report bugs to Ivan L. Picoli <ivpi@itu.dk>.

Use this command to run specific tasks within the controller.

 Examples:
  Show all available Admin tasks:
    ox-ctrl admin -l

  Run a specific admin task:
    ox-ctrl admin -t <task_name>

  -l, --list[=list]          Show available admin tasks.
  -t, --task=admin_task      Admin task to be executed. <char>
  -?, --help                 Give this help list
      --usage                Give a short usage message
  -V, --version              Print program version

Mandatory or optional arguments to long options are also mandatory or optional
for any corresponding short options.

Report bugs to Ivan L. Picoli <ivpi@itu.dk>.

OX Controller ADMIN
 
Available OX Admin Tasks: 

  - 'erase-blk': erase specific blocks.
     eg. ox-ctrl-test admin -t erase-blk (follow instructions within command)

  - 'create-bbt': creates a new bad block table for a specific channel.
     eg. ox-ctrl-test admin -t create-bbt (follow instructions within command)

Besides the DFC, OX is extensible to other devices through the layer registration interface. In order to
use OX in other platforms, it is needed to develop the follow layers:

- Interconnect handler: Here you map the NVMe registers according your platform, or make a Fabrics interconnection.
- Media Manager: Here is the channel abstraction for the non-volatile memory, to be used by the other OX layers.
- FTL: The same FTL can be used in any platform, but you can develop a new one and register it within the OX core.