Building - Documentation

[F5OEO]

Documentation is not updated with current repo.
Providing a generic makefile is generally mandatory for a project.
It is up to the user to know how to cross compile it.
To help, a docker is welcomed or some bash scripts.

[MustBeArt]

I don't understand what you're asking for.

Documentation is not updated with current repo.

Please be specific about what documentation needs to be updated and in what way.

Providing a generic makefile is generally mandatory for a project.

A generic makefile doesn't make any sense for a project like this. The program can only run on Pluto or Pluto-like hardware, and these targets do not come with development tools and Analog Devices doesn't recommend or support doing development on the Pluto, for good reasons. There is no such thing as a generic cross-development environment. Compiling the program for a generic runtime platform like plain Linux is useless, since the registers the program accesses directly are not present on a plain Linux platform.

If you mean something different by "generic makefile" please explain what you want to see.

It is up to the user to know how to cross compile it.

If you mean that it should be up to the user, I completely disagree. On the contrary, it is up to the developer to remove as many obstacles as possible for the user. Providing details about how to set up and use a cross-compilation environment is essential. This is especially true when an essential library (libiio) is essentially frozen in time and requires a specific older version of the development tools.

If, on the other hand, you mean to say that the current documentation on how to cross-compile the program is inadequate, please explain what you'd like to see improved and in what way.

To help, a docker is welcomed or some bash scripts.

Those things are already included, so I guess you mean to say that they are extras that don't substitute for the "generic makefile" you'd prefer.

These things are provided in the hope that they will be useful for others, but with the guarantee that these are the procedures that have been known to work for us. The docker procedure, in particular, is expected to be useful on a broad variety of development systems. I would say that it comes as close as possible to the ideal of a generic make procedure.

[F5OEO]

Reference to msk_test seems not relevant.
As the target is only pluto, why all these instructions to external build out of the firmware ?
As a proper makefile is proposed https://github.com/OpenResearchInstitute/dialogus/blob/f5oeo/Makefile , it is now easy to integrate as a buildroot package.

[MustBeArt]

It's true that msk_test is not the name of what we are building, though it used to be. Now msk_test is to be understood as a placeholder for whatever name we want to use for the binary. The instructions for moving files onto the Pluto for execution are still relevant, if the Dialogus binary is being created separately from the buildroot file hierarchy. Which is what we have been doing so far.

I was not aware of the Buildroot provisions for building and adding packages. After looking at some of the Buildroot documentation, I see that I have some reading to do before I can appreciate exactly what Buildroot can provide. I see that there are several ways to include project-specific packages, for instance.

It is not immediately obvious to me that integrating Dialogus with the pluto_msk buildroot is something we want to do right now. It might be better to use Buildroot's feature to export an SDK so that development of Dialogus can proceed independently of the big pluto_msk build, with fewer dependencies and quicker edit-compile-run turnaround. That's assuming that the toolchain buildroot puts into the SDK is one that meets the requirements. Presumably that would be a very similar toolchain to the one we are using now, so the benefit of switching to a buildroot-created SDK is unclear.

Your Makefile is prettier than mine, thanks for the cleanup. As far as I can tell, it's functionally identical, except for help and downloading of msk_top_regs.h (which I'll have some comments on in your issue 37). Let me know if I've missed some functional changes.

[F5OEO]

"Presumably that would be a very similar toolchain to the one we are using now, so the benefit of switching to a buildroot-created SDK is unclear."

• If we change the toolchain on firmware, you need to adapt and move to the same toochain (in tezuka, I use an other)
• You get rootfs (sysroot) from analog device : that mean that you can't use libraries which could be present i the firmware (for example libfftw)

"It might be better to use Buildroot's feature to export an SDK so that development of Dialogus can proceed independently of the big pluto_msk build, with fewer dependencies and quicker edit-compile-run turnaround"
Exporting the sdk is effectuvely a good solution if you separate completely projects. But you still need the toolchain.

"quicker edit-compile-run turnaround"
Compilation is immediate, no need to run the complete firmware makefile

In sum up :
Git clone pluto_msk and run a make under pluto_msk/firmware (only once)
go under pluto_msk/firmware/buildroot and make prepare-sdk

Now go to your dialogus folder
source pluto_msk/firmware/buildroot/output/host/environment-setup
and make
Et voila !

You can verify that your bin is cross compiled (file dialogus_xx_dirty : ELF 32-bit LSB pie executable, ARM, EABI5 version 1 (SYSV), dynamically linke...)