Linux addin in combination with SigmaStudio

Hi,

Yes, that should be possible. From a system point of view the SHARCs and ARM cores are isolated from each other.

When you design your system you partition the memory between the cores so that they can work independently. 

Peripherals should be considered so that either the ARM core or the SHARC cores are responsible for managing them.

In terms of what runs on each core, it really is your choice.

The ARM core can run Linux, FreeRTOS, uC/OS or bare metal.

The SHARC cores can run FreeRTOS, uC/OS or bare metal.

Sigma studio produces bare metal applications so they can run fine.

If you need to communicate between the cores we have implemented MCAPI under all RTOS/Linux/Bare metal for message passing. DMA can be used for for larger/faster data transfer.

The only caveat is that Sigma studio needs to be run on a Windows host, where as the Linux development is performed on a host PC running Linux.

Regards,

Dave

Thank you for the answer, looking good.

My plan would be to design "bare metal" DSP functions, that would be configurable during runtime, such as modifying crossover frequencies, channel delay settings, etc. If this could be done by talking to the linux side it would be great.

I am completely new to all this. Are there any other, more common ways to change such settings on a DSP bare metal application? I am familiar with Linux, that is it was the first choice for me. But maybe this is not the best way?

BN

No, this sounds like a good approach especially if you want to manipulate the parameters on the SHARC at runtime.

More so if you need features like USB and ethernet as it's all there out of the box with Linux.

We have been putting together a demo similar to this internally. It uses Open Stage Control  (https://openstagecontrol.ammd.net/) to provide a GUI for manipulating audio parameters. I will see what state the code is in and see if we can share some of this with you - note it may take a while as I will need to get the code cleared by legal.
Also note that at this point Open Stage control runs on a host PC not under the EZ-KIT Linux. But that's something we would like to have up and running eventually.

This demo would be fantastic to take a look at, thanks a lot.

I will be waiting eagerly.

BN

A supplementary question:

Now I have the hardware, and I have successfully installed the pre-built linux onto the SD-card.

All is fine except that there is no networking installed on the ARM core, so I have to communicate using the "minicom" terminal from the Ubuntu host. The prebuilt linux image seems very minimalistic. No network, not very practical. Any suggested reading for me how to get the network functional?

I have realized I need to reconfigure and build the linux from source.

However, the build is never completed due to errors.

Also, the manual "linux_add_in_user_guide_1.3.1.pdf" is not completely accurate.

E.g. there is no entry "File system images" in "make menuconfig".

I also realize that this forum may not be the proper one to resolve all this. Any suggestions?

Hello daveG , I'm currently working in a project with SC573 EZ-kit that requires integration between Linux Add-In running on ARM core, and Sigma Studio projects running in SHARC cores, as described by bnilsson . 

• Were you able to implement the demo described above? If the answer is yes, is it possible for you to share source code of that project?
• Is there any existing add-in or library that could be included in a linux CCES project (which would be run from Linux in ARM core) which could be compatible with ADI_SS add-in on Windows CCES (for the apps running on SHARC cores)? Or is the only alternative just to write MCAPI/DMA functions to implement such communication on both sides?

Thank you very much!

Hi,

unfortunately that demo was never completed (changing priorities etc, sorry).

At this point the best approach is to manually control interactions between the ARM running Linux and the SHARC cores.

We are currently in the process of putting out a new beta release of Linux. This will (eventually) contain a new audio framework to assist with passing the data between the cores. On the Linux side the SHARC cores will be seen as virtual Linux devices, and there will be a new dedicated low level audio framework to pass streamed audio to and from the SHARC cores.

We are hoping to have this functionality in place in a beta in the next month or so. Although SC573 may follow shortly after that.

We will post an announcement on the engineer zone forum when the functionality is available in a beta.

Hi daveG , thanks a lot for your response! I'll be looking forward to the announcement in the forum.

I have one more question on the same field. Before manually controlling the interactions between ARM Linux and SHARC, we would like to boot SHARC cores with the Sigma Studio code and params already included in the LDR file. Adding some more detail to the question:

• We are currently booting bare-metal applications (from DXE/LDR Windows CCES generated files)  in the SHARC cores, commanded from Linux, with the SharcLoader utility
• We would like that the CCES applications compiled in Windows, for the SHARC cores, already include Sigma Studio code and params (without yet considering parameters Tuning of course, which will require to write the communication routines)
• In this FAQ there is procedure explained with that goal, but currently may not apply to SC573 and Sigma Studio v4.6 as firmware sections are defined quite different
  • the No_Download_Mode docs suggest commenting sections 1 and 5 of the Sigma Studio generated code, while in the current versions Sigma Studio generated files includes memory organized in a different way
• In the attached image, based on SigmaStudio Host Controller guide, when describing SigmaStudio generated files, the xxx_IC_y.h file includes all data sections ready to be included in a CCES application.
  • Can this be included in the SHARC CCES app? or is it only meant to be included in the ARM Windows CCES app?

What we want basically is that the DXE/LDR Windows CCES generated files for SHARC cores, already includes the parameters and code exported from SigmaStudio, so when booting SHARCS from Linux the schematic starts running rightaway, and we can then proceed to write our communication with the Linux for parameters tuning.

Does it make sense? Or the only way to do this is to load all code and parameters from the ARM core once we have written our communication scheme?

Thanks again for your time and quick response!

Leopoldo

Hi Leopoldo, thanks for the detailed reply. This really helps me understand your use case.

Unfortunately I am not a Sigma Studio expert (yet) so I will need to consult with some of my colleagues on the SigmaStudio specific points.

A few general points that might help you in your progress:

• In your previous e-mail you mentioned using the Linux Add-In for Linux on the ARM core. Can I confirm whether you are using the actual CCES Add-In or the Yocto Linux product?
  We deprecated the Linux add-in several years ago and replaced it with our Yocto Product which is the product that we will support (and update) going forward.
  I strongly recommend using the Yocto product rather than the Linux add-in.
• The Yocto Linux product includes remoteproc support for loading applications to the SHARC cores, we would recommend using this approach. The SharcLoader was developed for the legacy Linux add-in, and while it may work now, I don't know whether it will continue to be compatible with the Yocto Linux product.
• In terms of booting the SHARC cores, it is possible (some work may be required) to have a single loader file stored in flash, usb etc that is used for boot, that contains booting binaries for all three cores. So in the case where you are using Linux on the ARM core, this would be the two SHARC binaries, plus the U-Boot binary all combined. Once the processor loads these images, it will start the ARM core running. The SHARC cores are help in "reset" - waiting for a signal from the ARM core to inform them that it's OK to start execution.
  By adding a small piece of code to U-Boot you can start the SHARC cores executing at any point. Even before Linux has booted.
  One thing to be careful of here is that Linux assumes that it controls and manages any peripherals that it is aware of. Typically this is OK, but there are a few cases where care is required. EG using the TRU or Pinmux. If possible, management of these should be left to the ARM core. If the SHARC cores are going to use a peripheral that is declared in the default Linux image, you might want to consider removing its definition from Linux - to avoid the case where the SHARC core is using a peripheral and Linux boots and accidentally re-initialises that device.
• I will follow up with some of. the Sigma Studio experts on the other points.

Regards,

Dave