Documentation

Development - How to contribute

1. Introduction

Since CRUX-ARM is formed by a small team we are always open to new contributions, suggestions and/or ideas. But there are some steps you need to go through before we can accept your contributions:

• be familiarized with CRUX and/or Linux and have some technical skills
• have a compatible attitude with the rest of the team

There are many areas you can contribute. You can offer support to others via IRC or Mailing Lists, help with flyspray for managing tickets and bugs, or even contribute to the development releases.

If you just want to contribute with some donors to us, please visit this page.

2. How can I help?

Thanks for asking. Let's find a place for you!

First you should join our community. :

• Subscribe to our mailing lists (here)
• Join us on IRC: You can talk to us directly in #crux-arm channel at irc.freenode.org
• Anyways you can email us directly to devel at crux-arm dot nu

3. Contribute a new supported device

To add a new supported device first take a look to our list (here) and be sure is not supported yet.
You should contact with us and provide detailed information about the new device and the plans you have. Then we'll see if we can support that device, and if so automatically we'll add the device to our WIP list (Work In Progress devices). Now you can start working.

To support a device you will need:

• Compatible Linux Kernel.
  Nowadays there are many ARM devices supported by the Linux kernel. If your device runs Android basically there is a kernel for it and probably you can get kernel sources to compile your own. Other times you may find that the kernel is a binary and/or propietary image, so that access to the sources will be closed.
  In both cases you'll have one requirement marked by our glibc package (read last release notes for more details) since the kernel version must be greater than the version enabled in glibc.
  • if there is a kernel source ready to be built with crosstools (current toolchain repository), contacting us (mailing lists preferable) and sending all the needed info (Makefile, config and sources) could be the best way to create a repo for that device's kernel. If it's not a vanilla kernel or if it's based on upstream git development, snapshots are used and uploaded to the server contacting any of the developers. We'll finish building a freshly kernel with all reported information and device's contributor will be notified to test it and finally it'll be placed on the server.
  • if there is only a binary kernel image, it should be documented in device's documentation
• Device Bootloader.
  A boot loader is a computer program that loads the main operating system. Since ARM devices exist in many different forms and products, each device may need a different bootloader from other. You should investigate what stuff requires your device and which boot media can be used: SD, uSD or CF cards, USB storage, SSD, etc. and the preparation required such as partitions, etc.
  • if it's based on uboot, and there is a way to generate uImage from zImage, it can be added to current bootloader repo. Sending by any available way a patch for current version would be the best option to add it (mailing lists preferable to keep track on who is working on something)
  • if it's based on a prebuilt image, a binary or there are extra files, it should be documented in device's documentation.

Once you complete the requeriments listed below, you can try CRUX-ARM.

Download a release from our page (here) that fit your needs (probably generic, the one without a device sufix which means there isn't any kind of optimization) and place all the stuff in your boot media as required.

Once booted the generic release, you need to get genericrootfs-extras (you can get all the needed files from http://resources.crux-arm.nu/files/devel-test/VERSION) to get a set of ports (core ports from CRUX current version tag and core-arm ports updated to newer versions) to maintain all optimized releases homogeneous with the generic release, and then, rebuild all ports got from order-VERSION-stage1 which will make a first pass to all core ports and next one order-VERSION-stage2 which will build again the entire core ports without toolchain related ports.