Firmware: Difference between revisions
No edit summary |
No edit summary |
||
Line 129: | Line 129: | ||
'''How do I port to other OSes''' | '''How do I port to other OSes''' | ||
There is nothing stopping the firmware working with non Linux based OSes providing a driver exists or can be written for that OS. The main area for potential optimisation in porting to another OS is aligning the IPC (Inter processor Communication) mechanism to the audio driver flow for that OS. Sound Open Firmware has IPC optimised for the ALSA driver flow, but it's easy enough to reuse this IPC on other OSes or add a completely new IPC for the OS of your choice. The IPC ABI is defined in src/include/uapi/ and the IPC IO logic lives in src/ipc/. | |||
The current upstream IPC uses a memory mapped doorbell and mailbox to pass messages between the host and DSP. Non memory mapped IO (like I2C) can also be supported by adding new doorbell and mailbox driver in your platform code. | The current upstream IPC uses a memory mapped doorbell and mailbox to pass messages between the host and DSP. Non memory mapped IO (like I2C) can also be supported by adding new doorbell and mailbox driver in your platform code. | ||
'''What audio components are supported''' | '''What audio components are supported''' | ||
Firmware currently supports mixers, volume, DAIs and Host PCMs in the upstream code base. More components are in progress... | |||
'''How do I create my own pipelines''' | '''How do I create my own pipelines''' | ||
The current upstream supports creating statically defined pipelines in src/audio/static-pipeline.c. This default pipeline can be changed in this file and in the driver to match any new pipeline topology. | |||
Dynamic pipeline topology will be supported upstream soon. This will allow pipelines to be defined at run time in the firmware and driver by using the alsa topology framework. |
Revision as of 13:54, 10 October 2016
Sound Open Firmware
Sound Open Firmware is an open source audio DSP firmware and SDK intended to provide a generic audio firmware infrastructure and development tools to the community. The firmware is BSD licensed and is platform and architecture agnostic. The SDK is also open source and provides a toolchain, debugger, emulator and firmware image creation tools.
The firmware and SDK currently support the Cadence Xtensa architecture and the Intel Baytrail and Cherrytrail platforms. The current firmware audio features include multiple PCMs with gain controls and mixers.
There is a developer mailing list at http://alsa-project.org/mailman/listinfo/sound-open-firmware.
This page is currently work in progress so please expect frequent updates and corrections.
Installing the SDK
1. Install the firmware image tools.
These tools are used to convert ELF binaries into the file format used by the kernel drivers when loading the firmware.
git clone git://git.alsa-project.org:sound-open-firmware-tools.git soft.git cd soft.git ./autogen.sh ./configure make make install
This will install the 'rimage' and 'rmbox' tools which are used for firmware image creation and firmware debugging respectively.
2. Build and install the GCC xtensa cross compiler toolchain using Crosstool-NG.
A cross toolchain is required to build firmware binaries on x86. Please note that the xtensa GCC compiler does not build optmised Xtensa binaries (i.e. no automatic SIMD or media instructions generated without hand coding assembler). Cadence does provide a free download of their optimising compiler toolchain for the Baytrail target here (todo add link). A modified crosstool-NG is used to build the cross toolchain.
git clone https://github.com/01org/osadsp-crosstool-ng.git ct-ng.git cd ct-ng.git
Build crosstool-NG
./bootstrap ./configure --prefix=`pwd` make make install
Now build the xtensa cross compiler.
./ct-ng xtensa-byt-elf ./ct-ng build
Finally add the Xtensa cross compiler to your PATH.
PATH=$PWD/builds/xtensa-byt-elf/bin:$PATH
Todo: We are missing some headers like stdint.h from cross gcc tarball. Add note on adding them.
3. Get the firmware source code.
The firmware source code is hosted using git on alsa-project.org
git clone git://git.alsa-project.org:sound-open-firmware.git sof.git cd sof.git ./configure --with-arch=xtensa --with-platform=baytrail --with-tool-dir=~/path/to/xtensa/gcc/xtensa-byt-elf --host=xtensa-byt-elf make make bin
This will create a binary firmware image in src/arch/xtensa/ called reef-byt.ri. This image can now be copied to /lib/firmware/intel where it will be loaded by the Baytrail audio DSP driver.
4. Get the Linux driver updates.
This firmware requires some driver updates and they can be found here :-
git://git.kernel.org/pub/scm/linux/kernel/git/lrg/asoc.git #topic/reef-v4.8
TODO: add instructions to enable the correct kconfig options
5. Optional. Build the Qemu DSP emulator from source.
Qemu needs some extra patches to support heterogeneous virtualization of the guest x86 OS and xtensa firmware. We are using the latest qemu-2.7 release with the support for heterogeneous virtualization and audio DSP hardware on top.
sudo apt-get install libgtk-3-dev libsdl-dev libspice-protocol-dev libspice-server-dev libusb-1.0-0-dev libusbredirhost-dev libtool-bin iasl valgrind texinfo virt-manager kvm libvirt-bin virtinst git clone https://github.com/01org/osadsp-qemu.git cd osadsp-qemu.git ./configure --prefix=. --target-list=xtensa-softmmu,x86_64-softmmu --enable-gtk --enable-sdl --enable-spice --audio-drv-list=alsa --enable-libusb --enable-usb-redir --enable-coroutine-pool --disable-opengl --enable-fdt make
Please do not install this version of Qemu as it will overwrite your distro version of Qemu.
Running the Firmware
TODO
Firmware Architecture
TODO
Driver Architecture
TODO
Using the Qemu DSP emulator
TODO
Debugging Firmware
TODO
FAQ
What license does the firmware and SDK use ?
The firmware is released using a standard BSD license with some parts MIT. The SDK is GPL.
What architectures are supported
Sound Open Firmware currently supports the Cadence/Tensilica Xtensa audio DSP architecture and ISA.
What platforms are supported
Sound Open Firmware currently support the Intel Baytrail and Cherrytrail based platforms. This includes devices like the Minnowboard MAX and the ASUS T100 laptop, but should also include any Baytrail or Cherrytrail based devices that have the audio DSP enabled in the BIOS.
How do I add support for DSP architecture X
It's straight forward enough to add support for a new DSP architecture. New architectures usually require support for that architecture in the GNU toolchain, although other toolchains can be used too. It also helps to have qemu support for the architecture in order to provide an emulator.
The main work in adding the new architecture is duplicating and porting the src/arch directory to your new architecture. The code in the architecture directory mainly deals with architecture abstraction and initialisation of any architecture IP like MMU, IRQs, caches alongside providing optimised version of common C functions (memcpy, memset, etc) for that architecture. Adding a new architecture also usually means adding a new host platform too.
How do I add support for host platform X
Adding a new host platform is a lot simpler than adding a new DSP architecture. A new host platform consists of adding a new src/platform/ directory, together with mappings for memory, IRQs, GPIOs and peripheral devices in the DSP memory space. New drivers may also have to be added (e.g. for DMA, I2S) to the drivers directory.
How do I port to other OSes
There is nothing stopping the firmware working with non Linux based OSes providing a driver exists or can be written for that OS. The main area for potential optimisation in porting to another OS is aligning the IPC (Inter processor Communication) mechanism to the audio driver flow for that OS. Sound Open Firmware has IPC optimised for the ALSA driver flow, but it's easy enough to reuse this IPC on other OSes or add a completely new IPC for the OS of your choice. The IPC ABI is defined in src/include/uapi/ and the IPC IO logic lives in src/ipc/.
The current upstream IPC uses a memory mapped doorbell and mailbox to pass messages between the host and DSP. Non memory mapped IO (like I2C) can also be supported by adding new doorbell and mailbox driver in your platform code.
What audio components are supported
Firmware currently supports mixers, volume, DAIs and Host PCMs in the upstream code base. More components are in progress...
How do I create my own pipelines
The current upstream supports creating statically defined pipelines in src/audio/static-pipeline.c. This default pipeline can be changed in this file and in the driver to match any new pipeline topology.
Dynamic pipeline topology will be supported upstream soon. This will allow pipelines to be defined at run time in the firmware and driver by using the alsa topology framework.