Maybe Co-Simulation with the gateware simulated in cxxrtl / verilator with qemu would be an interesting approach here

we are much further now and this can be closed imho.

ah i think it is not important, as the bootup process is basically fsbl -> u-boot -> linux.

Do you have foto-documentation of the build process online? And/or footage?
I would love to see your 3d prints and early assembly's :)

Some updates on this front:
Last ccc @vup @leftshift and me decided to build a cheap development version of the Beta.
We wanted to have a cheap camera to be able to develop soft- and hardware for the Beta without the need to invest a lot of money.
Research was done, the cheapest Zynq FPGA development board was found, the cheapest suitable CMOS with okayish documentation was picked and we designed a first Interface PCB to connect the sensor to the FPGA dev board. We build FPGA designs and wrote some software and in the end we had the first still images. The first prototype of the AXIOM micro was built.
However, the initial PCB was quite rough and had major problems (we were doing serious PCB design for the first time in our lives).
This led us to the creation of a second revision, which now is able to shoot moving images, has a proper lens mount and some case.

we could also have multiple clients... ie. one webremote and one cli (in case we are merging the server and the controldaemon).

sorry for being unclear. When writing rest server, i actually didnt think about rest but exposing an interface with webstandarts. we could also replace any rest with websockets.

hm... dont really get, why we would want to disable the rest server / the control daemon seperately. if we dont want to expose http from outside, we could pervent this by binding the rest server to a local adress and do reverse proxying with ligthttpd. in this case disabeling lighttpd would disable the accessibility from outside.

moreover, what is the transport mechanism for the flatbuffers? notwork? unix sockets? files? fifos?

why do we split the control daemon and rest server into two different programs? couldnt the contol daemon directly expose some kind of web compatible api (websockets / rest), the webapp and the cli should use?

maybe move this to the OC git repo, which would make it more likely to be foud by people who want to contribute?

many thanks :)
now, can we finally make this new structure a bit more clear for people coming from github? this would be quite nice. maybe making it clear by putting a readme inside the hardware repo which links to the fileserver and/or to the wiki and clarifies what should go into git and what belongs to the fileserver.

503 is not forbidden but service temporarily not available. maybe gitlab has a temproary outage (they sometimes do ;))

There are some things, that are good to consider, when we build something like this:

• The camera has plenty of resources. When designing something that only works on the parameters, and not on any image data it is almost impossible to design a system that is to imperformant to run on the cam. This means no performance optimisation is needed.
• The software has to work without requiring internet access at all. (in my opinion) I think it would be handy if everything is served from the camera.
• The software should manage the state of the hardware (is the fpga configured? what bitstream should be loaded? what bitstream is loaded? what plugin modules are plugged in?
• New Plugin Modules should be easy to integrate (new bitstrams and new parameter space)
• An open API should be exposed to allow other interfaces (maybe hardware) to be easily developed

As far as the my.apertus.org idea is concerned, it might be worth looking into a scheme that serves unique / registered apertus hostnames on a subdomain with the cert being held on the device.

Yeah you are completely right! Axiom Firmware would be a much better name!
Moreover, I quite like the idea of having repos for each topic (like gateware, web-gui, daemon, configs, ...)

All the PHP is still from the axiom alpha and will be deprecated in favour of the new REST api. (correct me if Im wrong).
Some of your suggestions are already taken care of in the next-gen firmware on github (ie. lighttpd not having sudo rights)

Sounds cool :).
I think we dont need to optimize for speed so caching is not really important (for now).

i think aes256 would be much more practical to use. with otp one would need to store twice the data, which is not very practical in terms of bandwidth and storage price.
Moreover, when crossing borders with footage, one would most likely carry both storage mediums (the footage and the key), which would make the encryption useless. when using aes, we could encrypt the key with a password and therefore keep the footage secure, even if all the storage mediums are confiscated.

what about checkboxes? they can be styled with css, so they look like toggle switches: https://codepen.io/mburnette/pen/LxNxNg

can we make this behaviour default for the nowiki snippets?

another example: https://wiki.apertus.org/index.php/Beta_Power_Board#Calibrating-Voltages
I think, that <nowiki></nowiki> should preserve newlines

I think that having a single point of information is quite valuable. I like the idea of having the code/the design files in the same file tree as the docs, but having the WIki as the only central point is fine for me, too.

Maybe readthedocs would be a better tool choice, because it can create beautiful PDFs, but it can also be viewed and searched online. Moreover, it has a lower entry barrier for contributes. What do you think?

I think, I won't manage to be there for a long time but im happy to join you for some time. Especially if you have a Beta ;)

Error at line 79, file devmem2.c (13) [Permission denied]

I will be there too :)

Closed in favour of T757. If this is wrong, just reopen this task.

Maybe soon: https://www.theregister.co.uk/2017/05/24/intel_thunderbolt_3forall/ :)

reference and close?

So close the other two tasks?

Should the control daemon replace T258 and T723?

Can this be closed?

I think a ubuntu docker container with the required tools installed would be simple to create (this is the current solution for the ci-builds). However, I think, that distributing xilinx tools implys some licensing and export-control related issues. The simplest way to deal with them would be to just ignore those or make the container somehow protected.

When T697 is finished

The original task is done. The mentioned binaries are linked to /user/local/bin as axiom-* by make install

@sebastian could you please remove the URL, as it shouldnt be public ;)

Yes! Just now i created this (https://github.com/apertus-open-source-cinema/beta-software/pull/7) pull Request. If you want to bring the work on this forwards, you could test this (https://gitlab.com/nein/beta-software/-/jobs/38788789/artifacts/download) image and report your findings. edit: bertl is already doing this.