Evaluate automatic firmware builds and report missing/broken things on lab
Open, NormalPublic

Description

Currently the betas we ship come with a manually assembled firmware.

Some team members have created an automated build system that takes source/scripts/etc. from github and other sources and assembles a "Nightly" firmware image:
https://github.com/apertus-open-source-cinema/beta-software
https://gitlab.com/axiom-micro/axiom-firmware

Now someone with fundamental Linux know-how/experience needs to evaluate if the automated build is providing the same functionalities as the current hand assembled image.

Like if all cmv_* tools are available and working, if the scripts to initialize the fpga/drivers are there and loading in the correct order, if the live video output works and things like the live video overlay.

Eventually the automated firmware should provide the same camera functionality as the current hand assembled firmware. Then the next step will be to clean up unnecessary files and rename existing ones so their purpose can more easily be understood.

sebastian created this task.Jul 4 2018, 7:35 PM
sebastian triaged this task as Normal priority.
sebastian added a subscriber: Bertl.Jul 4 2018, 7:38 PM

Note the comments by one of the authors of the new automatic build system today:
http://irc.apertus.org/index.php?day=04&month=07&year=2018#160

anuejn: sgonzalez: se6astian there is already some testing infrastructure in place
anuejn: only the tests are missing ;)
anuejn: the image that is build automated should boot up fine, but the hardware interaction doesn't work
anuejn: we werent able to fix this, because we don't have hardware to test and fix this.
anuejn: it would be great to continue there
anuejn: if i remember correctly, kick.sh doesn't make it through on the image, because of some fuckup with the memory mapped region
Bertl_oO: hmm, what problems are there?
anuejn: the camera hung
anuejn: last ccc we had a camera and investigated a bit but we didnt find a solution
anuejn: i don't remember the problems exactly tho
Bertl_oO: was the FPGA initialized?
anuejn: we tried it, but not sure, whether it worked
anuejn: http://irc.apertus.org/index.php?day=28&month=12&year=2017 and the following day were it
Bertl_oO: because without a proper zynq image kick.sh will just hang the camera
anuejn: bitstream seemed to be properly loaded...
anuejn: anyways, i think this would be a good thing to continue with

more points for the checklist:

  • make sure mimg is installed and the latest version (see above)
  • I would like to start giving firmware releases version numbers (and/or a compile date) so its easier to know what firmware is currently running (is there a newer one? etc.) This should be displayed to the user when booting or when connecting ssh/serial console and for example when doing "uname -a" or compareable on Arch Linux.
  • display a standard disclaimer to the user at boot up or when logging in (ssh/serial): "This device and it's software is provided without warranty of Merchantability or fitness for any particular purpose. apertus° assumes no responsibility or liability for any loss or damage as a result of the use or misuse. USE AT YOUR OWN RISK. You have root access to this system and can potentially brick and damage the hardware from the command line interface - be responsible and when in doubt consult with apertus° before doing anything potentially harmful to your camera." (I am open for rewording this)
sebastian added a subscriber: jatha.Jul 5 2018, 5:51 PM
sebastian added a subscriber: vup.Jul 5 2018, 6:10 PM
vup added a comment.EditedJul 5 2018, 10:29 PM

The git commit hash and the date of the last update of the software (beta-sofware repo) is already displayd at login through /etc/motd. This can be different from the creation commit / date of the firmware, but these can be easily added as well. The standard disclaimer can also be added in the same place.

For a proper version number git tags or a version variable inside the Makefile could be used.

Also all tools get installed with a prefix of axiom- (so for example cmv_snap3 is now axiom-cmv_snap3).

But I think the most important thing would be getting axiom-kick working, as the camera is unusable without that.

sebastian reassigned this task from sergiogonzalez to vup.Feb 18 2019, 10:42 AM
sebastian added a subscriber: sergiogonzalez.

status report please