#Dusk Deployments

This is a list of Dusk OS configurations for specific machines. Dusk OS doesn't do any kind of auto-probing, so you have to know your hardware and adjust configuration appropriately. You can use this repository as an inspiration for your own deployments.

If you have a deployment that isn't an exact copycat of something that is already in there, please send it to me, I'll merge it in. The more the merrier.

#Separation of concerns

The idea behind this separate repository is to avoid polluting Dusk OS's code with the myriad of possible configurations for a given system and have a "bazaar" of configurations here. Configurations are something that you'll want to maintain personally, but it's much easier to build a configuration if you have a wide selection of examples to choose from.

What we do want in Dusk OS directly are tools to work with specific machines. A machine running Dusk OS and having its whole fs directory should have all as many tools as possible to work with specific machines.

In short, configurations come in here, tools stay in Dusk OS.

#The case of the Raspberry Pi

Raspberry Pi need opaque firmware on their boot partitions. Generally, if you have a Raspberry Pi, you have those bootcode.bin and start.elf file, but it's possible that you don't. So if you don't have them handy, it's nice that Dusk comes with it. But where should it go, Dusk OS or Dusk Deployments?

On the one hand, if you're stuck with only a machine running Dusk OS and a Raspberry Pi with no firmware file, you need those files to deploy Dusk OS. So on the first look, they should go in Dusk OS.

But on the other hand, these files are deeply tied to the machine. If you have one without the other, you have a broken machine. Should Dusk OS also carry backup dumps of PC BIOS ROM in case you have a machine with a corrupted BIOS? I don't think so.

Therefore, these files live in Dusk Deployments.

#Code duplication

All configurations committed here have been tested on their target machine. There isn't supposed to be any broken configuration in this repo, only configurations targeting older Dusk releases.

The broad idea behind this repo is that testing configurations on real hardware is time consuming. We want to minimize dependency chains, as in "I need to test that thing on hardware X Y and Z before I can mark it as correct".

Therefore, we allow different configurations to target different Dusk releases. When we happen to dust off a particular hardware, we "bump" the release.

This design also forces us to minimize code reuse and accept code duplication. If we share code between two configurations, it also means that we will need to update and test them together.

For some configurations that are very close to each other, such as pc-piix and pc-bios, we do share. But most of the time, we will just copy and paste configurations around to minimize coupling.

#Usage

Each deployment has its own directory with its own Makefile which targets a specific version of Dusk, that is, the last version this hardware has been tested as "correct" on.

To build a deployment configuration, you need:

• a C compiler
• Make (BSD or GNU)
• A way to fetch a file from http: either curl, wget, or BSD's ftp.
• mtools (for some targets)

Dusk OS has the ability to copy itself into a FAT without external tooling, but some of the makefiles in this repo don't bother using this capability and use mtools instead as its an easier fit with POSIX makefiles.

To build a deployment, you first need to download and unpack the appropriate Dusk versions at the right places. The getdusk.sh script will do so for all Dusk versions needed by all deployment configurations of this repository.

Therefore, the first thing you want to do when you first use this repository, or when you update it, is to be at the root of the project and do:

./getdusk.sh

Then, cd into the directory and run make. This should yield an image which you can deploy on your target media.

Each subdirectory has a README with hardware and deployment details.

#Emulation

Some targets can readily emulated via QEMU. Such target indicate (QEMU) next to their name in the list below. In such target, in addition to the regular make target, you can also run make emul to launch QEMU with the right parameters to run it.

#Bleeding edge

If you want to deploy "bleeding edge" Dusk, that is, a commit from the repo that has a significant diff from the latest versioned release, there's a good chance that the code in this repo won't work properly because it's not in sync with changes in Dusk.

When I develop Dusk, I very often try it on real machines and when I do, I maintain changes in this repo that I don't commit "officially" because I want to tie these deployments here to stable versions as much as possible.

If you're not me, however, it might be challenging to figure out the changes that you need to do to be in sync with bleeding edge. To give you a clue, I maintain a "wip" branch where there's always a single commit that I constantly amend. It's my current "side changes" branch, which will become real commits when I make the Dusk release.

#Deployment list

#i386

• pc-bios: Barebone PC and BIOS diagnostic tools (QEMU)
• pc-piix: PC of the "PIIX" architecture (QEMU)
• pc-floppy: Example floppy PC deployment (QEMU)
• hp-mini-2103070: HP Mini 210-3070
• pcengine-alix: PC Engine's Alix board
• zenith-datasystems-8574: Zenith Datasystems laptop ZIN-8574-QS

#ARM

• rpi: Raspberry Pi (Model 1, 2, 3) (QEMU)
• pine64: Pine A64 LTS (WIP)
• a64-olinuxino: A64-OLinuXino (WIP)