The Single Board Computer Database

Contributing to the database

HackerBoards (Board-DB) database is open source, and external contributions help sustain the quality of its content. The approval of new boards, or changes to existing records, will go through GitLab "merge requests".

License and disclaimer

The HackerBoards database is licensed under the Creative Commons Attribution-ShareAlike 4.0 International License (CC BY-SA 4.0). Restricted usage is permitted but explicit attribution and linking to the original source is required.

We accept no responsibility or liability for any omissions or inaccuracies in the database, and we reserve the right to remove or modify any content at any time. In general, the principle of "use at your own risk" holds true in all parts and subprojects of HackerBoards.

How to help

The HackerBoards database is a community effort, and we welcome contributions from everyone. Also minor corrections (e.g. single incorrect specifications) are very welcome.

To add a new board:

• Fork the database from GitLab (https://gitlab.com/hackerboards/database):

  git clone https://gitlab.com/hackerboards/database.git

• Download the new-board.yaml file from this link if you wish to use it as a starting point for the new board.
• Move the template file to the target folder, that is, following the dataset/{manufacturer}/{product}.yaml structure of the repository.
  If a manufacturer does not exist, feel free to create a new folder for it, as well as its corresponding record in dataset/manufacturer.yaml.
• Populate the columns and fulfill any relationships needed. In a finished file, no default or "TODO" columns should remain. (check out the Glossary of YAML fields below)
• If there are ambiguous specifications that the schema can't address, and that are not solved in the Merge Request thread, use the _notes field to add comments. This can be a multi-line field for readability.
• Remove all remaining guidelines and comments (lines starting with #) from the file after you are done populating it.
• Stage all new file (or files) to the database, and create a new commit. The name of the commit should be either
  

  {manufacturer}/{product}: new board

  for new insertions, or

  {manufacturer}/{product}: {...} 

  for updates or corrections. If you are adding multiple boards, you can use wildcards in the {manufacturer} or {product} parts as long as they are readable, e.g.

  pine64/star64-*: fix wireless specs

  
  
• Proofread all changes, and try to make sure your YAML fields and commit follow the conventions of existing entries. In case you get something wrong, correct your commit through the conventional git commit --amend procedure.
• If you are editing or correcting a board entry, please make sure to link to the original source of the information (e.g. datasheet with the right specification). This avoids doing the same research twice.
• Finally, create a merge request 🎉 . Please try to provide as much information as possible, to avoid too many lengthy rounds of review, and double-check before committing.

The process should be fairly standardized across boards, and the learning curve is very smooth as soon as you get familiar with the YAML glossary.

Discontinuing old boards

To keep the database clean while remaining available as an archive and resource of past products, there is a deprecated flag to indicate boards that are not commercially available or supported anymore.
If you are deprecating a board, please use the deprecated flag in the YAML file, and a commit message of the form

{manufacturer}/{product}: mark as discontinued

Relationships between boards

If relationships between fields exist (see the Relation column in the glossary below), they should be fulfilled in the respective linked file (e.g. dataset/manufacturer.yaml for new manufacturer entries).

This is often as easy as entering the value of the field in the linked YAML, and its respective details, only if that entry does not exist already.

YAML fields glossary

Finally, here is a brief reference of all fields in the YAML schema.

Field	Type	Default	Unit	Relation	Description