...

What

...

SW, HW and credentials you need

• Video Accelerator with final RDK6.1 image on it. This can be Raspberry Pi 4 (RPI4) on which you can flash RDK6.1 final release image.   Note that RPIv3B/3B+ is deprecated, not supported by RDK-M anymore. Tool to flash RDK6.1 rpi image to SD card, example is provided with https://www.balena.io/etcher/ tool. Contact RDK-M if you want to test it on more carrier grade Video Accelerator (with amlogic, broadcom or realtek SoC) with RDK6.1 image
• Your application source code with bitbake recipe. Needs to meet the DAC contract for binary compatibility.
• DAC SDK https://github.com/rdkcentral/meta-dac-sdk to cross compile your application, add dependent libraries in application container AppContainer and package/output your application as oci compliant dac container image.
• As App developer company/entity you will need to request RDK-M DAC support team via support@rdkcentral.com  :
  
  • a login/pswd to register your app and its metadata in RDK-M ASMS instance (ASMS is AppStore Metdata µService and part of DAC cloud setup of RDK-M for Video Accelerators)
  • an associated "Maintainer" identifier (string) to be able to upload/register your app. 
  • credentials for uploading your OCI image to the private RDK OCI container registry. This is not required if you choose to upload it to a public accessible OCI container registry or ask support team to upload it for you.

...

• Insert the SD card back in the RaspberryPi and power up the Pi. Connect the Raspberry Pi to your network with an ethernet cable, and to your TV with a HDMI cable.
• Make sure you can SSH into the Pi as this is important for later. The default user is root with no password
• You should see the RDK Resident GUI application on your TV at bootup (after following some initial setup questions). In section X we explain how to use that resident UI to install existing DAC apps. But first we explain how you can build and publish dac apps 

use DAC SDK and build your first native DAC app

As part of the DAC project, an SDK has been created to make it easier to develop and build oci and DAC compliant containerized applications. The SDK is public, fully open source and uses standard Yocto 3.1 Dunfel Poky environment.

It is available on https://github.com/rdkcentral/meta-dac-sdk

...

The DAC

...

The SDK consists of 

• manifest that will download Yocto Poky environment with all required meta-layers, see manifest content in https://github.com/rdkcentral/meta-dac-sdk/blob/master/manifests/dac-dunfell-manifest.xml
• meta-dac-sdk meta-layer specifically developed to make building of DAC application easy for Appdeveloper.
  • It defined some base parent classes (dac-image-wayland, dac-image-essos, dac-image-base ) App developer can start from (inherit) to define its DAC application container image. AppContainer image as described in 
  • It links the application to DAC GFX abstraction interfaces (gles2, essos, wayland-egl) correctly and configures DAC-RDK abstraction components (eg rialto-client) appropriately.
  • It removes that some integration complexity/specific expertise-need from Appdeveloper because:
    • SDK links the application to DAC abstraction interfaces (gles2, essos, wayland-egl, rialto) correctly and configures these appropriately.
    • A c/c++ application typically depends on several other standard libraries, The SDK automatically adds the correct application dependency tree into the Application Container AppContainer Image
    • As enf At the end of building process the SDK itself generates and outputs an oci compliant Application Container AppContainer image is generated. 
  • It comes with various DAC compliant Application container AppContainer examples. The recipe that defines the Application Container examples are here see the recipes of example AppContainer images at https://github.com/rdkcentral/meta-dac-sdk/tree/master/recipes-example/images Each one of them is a yocto image target that you would can then ask Yocto to build against.  We provided some examples for various Graphics frameworks (Flutter, QT, SDL, directly on wayland, directly on essos). Those also have full open-source opensource reference or hello-world application code provided so App developer can understand how App can use/configure Gfx framework so it will work seamlessly with DAC abstraction interfaces.
• build instructions as per https://github.com/rdkcentral/meta-dac-sdk/blob/master/README.md  It

setup of DAC SDK

build instructions as per https://github.com/rdkcentral/meta-dac-sdk/blob/master/README.md They are copies here but it is best to read the instructions there

...

to be sure they are up to date.

This is the one time "setup" part of the SDK. 

# Createmake buildsure directory
mkdir build; cd build

# that your Linux host has required packages needed for Yocto. 
# These are defined in https://docs.yoctoproject.org/3.1.33/ref-manual/ref-system-requirements.html#required-packages-for-the-build-host
# Create build directory
mkdir build; cd build

# Install 'repo' tool from: https://android.googlesource.com/tools/repo
# following repo commands will download Yocto poky environment and other required meta-layers see manifest of https://github.com/rdkcentral/meta-dac-sdk/blob/master/manifests/dac-dunfell-manifest.xml
repo init -u https://github.com/rdkcentral/meta-dac-sdk/ -m manifests/dac-dunfell-manifest.xml
repo sync --no-clone-bundle -v -j$(getconf _NPROCESSORS_ONLN)

. ./oe-init-build-env
cp ../.repo/manifests/manifests/bblayers.conf conf/
# to build for ARM 32bit
echo 'MACHINE = "raspberrypi4"' >> conf/local.conf

If everything worked, the SDK is now set up and ready for use. You only need to run

...

above steps the first time you set up the SDK. For subsequent uses, you only need to run the following command to configure the build environment:

cd build
. ./oe-init-build-env

Below is a demonstration on how you use the SDK to build Youtube-cobalt as DAC application  

same video is also available on Youtube 'https://www.youtube.com/watch?v=Ie7fQy5HTlc   

Parent DAC SDK images 

The meta-dac-sdk layer defined several DAC image bbclasses App developer can start from ("inherit" in yocto terminology) to define its DAC application container image.

Following oci compliant base image types are defined with SDK and you can inherit/extend :

• dac-image-base - for DAC application that run as system service without graphics output or user input. It inherits image-oci.bbclass from yocto meta-virtualization layer
• dac-image-wayland - for DAC application that are using OpenGL ES2 as Graphics rendering API and Wayland-egl protocol to setup EGL graphics surface and for key-input
• dac-image-qt - for DAC application that are using QT5  framework

• dac-image-essos - for DAC application that are using OpenGLES2 as Graphics rendering API and Firebolt ® Essos to setup EGL graphics surface and for key-input

Now you can proceed with building your AppContainer image

build your AppContainer image in SDK

You ask Yocto to build specific DAC AppContainer image by invoking "bitbake <Recipename_AppContainer> "

Before making your own AppContainer image, you can try out the SDK by building one of existing example AppContainer images coming with the SDK and usually already available on RDK-M DAC cloud

# Now you can build the "DAC AppContainer image" of your choice. 
# Note that you need to have associated yocto image recipe defined in meta-layer and use that as <your yocto image target>
# as per example image recipes in https://github.com/rdkcentral/meta-dac-sdk/tree/master/recipes-example/images
# use bitbake <your yocto image target> to build the associated dac AppContainer.
# below commands build dac AppContainer examples coming with SDK
bitbake dac-image-wayland-egl-test
bitbake dac-image-wayland-egl-test-input
bitbake dac-image-essos-sample
bitbake dac-image-essos-egl
bitbake dac-image-qt-test
bitbake dac-image-shell
bitbake dac-image-flutter-slide-puzzle
bitbake dac-image-chocolate-doom
bitbake dac-image-cobalt
bitbake dac-image-glmark2

# Or build them all at once
bitbake dac-image-wayland-egl-test dac-image-wayland-egl-test-input dac-image-essos-sample dac-image-essos-egl dac-image-qt-test dac-image-shell dac-image-flutter-slide-puzzle dac-image-glmark2

Once the build has succeed you can find your AppContainer image in yocto deploy directory. You will find several files there. The files with symbolic links to files with "oci-image.tar" suffix in the name are the real oci, dobby, dac compliant AppContainer images. Those are the ones you will then need to use in next step (upload to Container registry in cloud)

cd tmp/deploy/images/raspberrypi4/

 
# Note that you need to have associated yocto image recipe defined in meta-layer and use that as <your yocto image target>
# as per example image recipes in https://github.com/rdkcentral/meta-dac-sdk/tree/master/recipes-example/images
# use bitbake <your yocto image target> to build the associated dac AppContainer.
# below commands build dac AppContainer examples coming with SDK
bitbake dac-image-wayland-egl-test
bitbake dac-image-wayland-egl-test-input
bitbake dac-image-essos-sample
bitbake dac-image-essos-egl
bitbake dac-image-qt-test
bitbake dac-image-shell
bitbake dac-image-flutter-slide-puzzle
bitbake dac-image-chocolate-doom
bitbake dac-image-cobalt
bitbake dac-image-glmark2

# Or build them all at once
bitbake dac-image-wayland-egl-test dac-image-wayland-egl-test-input dac-image-essos-sample dac-image-essos-egl dac-image-qt-test dac-image-shell dac-image-flutter-slide-puzzle dac-image-glmark2

Below video is a demonstration on how you use the SDK to build Youtube-cobalt as DAC application  

same video is also available on Youtube 'https://www.youtube.com/watch?v=Ie7fQy5HTlc   

Next section explains how you can create your own AppContainer image

AppContainer image recipes, hierarchy, application only recipe and appmetadata json 

To create and build your own oci, dobby, dac complaint AppContainer image as Appdeveloper, you need to create the following necessary yocto recipes and files :

• Application BitBake recipe. applicationname.bb This recipe defines:
  
  • Where the application sources are located
  • How to build the application
  • directory where/how to install binaries of the application and its resources
  • What other components and libraries it is dependent on and need to be installed together with the application
  • Note this Application Bitbake recipe is different/ is NOT the AppContainer BitBake recipe described next

• The oci complaint AppContainer BitBake image recipe.  dac-image-applicationname.bb This recipe defines : 
  • what pre-defined DAC container Image bbclasses it inherits, next section explains these  (you must inherit one of them), see  explained in next section and defines:
    
  • Which application should be installed inside the OCI Image (see IMAGE_INSTALL of Application Bitbake recipe name)
  • What is the executable binary to start inside the Container, the entry point of the Application
  • What is the associated appmetadata.json file associated with this ApplciationContainer Image
  • What additional ENV variables should be set for application
• Associated appmetadata.json file, contains additional information and requirements for the DAC AppContainer (eg if App requires persistent storage). Currently quite loosely defined, can be improved. examples in dir https://github.com/rdkcentral/meta-dac-sdk/tree/master/recipes-example/images/metadatas

This is visualized in the diagram belowSee their links and hierarchy of inheritance visualized in diagram below  

To create new oci, dobby, dac compliant Application Container image, you have to define as developer:

• Application BitBake recipe. This recipe define:
  
  • Where the application sources are located
  • How to build the application
  • directory where/how to install binaries of the application and its resources
  • What other components and libraries it is dependent on and need to be installed together with the application

• The oci complaint ApplicationContainer BitBake recipe. This recipe inherit one of pre-defined DAC container Image classes and defines:
  
  • Which application should be installed inside the OCI Image (see IMAGE_INSTALL of Application Bitbake recipe name)
  • What is an the executable binary to start inside the Container, the entry point of the Application
  • What is 
  • What additional ENV variables should be set for application
• Associated appmetadata.json, contains additional information and requirements for the DAC Application Container (eg if App requires persistent storage). Currently quite loosely defined, can be improved. examples in dir https://github.com/rdkcentral/meta-dac-sdk/tree/master/recipes-example/images/metadatas

To ease life of Appdeveloper (remove some integration complexity/expertise) meta-dac-sdk layer defined several DAC image bbclasses App developer can inherit and use as starting point for its own AppContainer image. 

Several types/bbclasses are defined. The application developer must choose the one appropriate for its envisaged use case and must inherit one in its AppContainer recipe

Following oci, dobby, dac compliant base image types are defined with SDK and you can inherit/extend :

• dac-image-base - for DAC application that run as system service without graphics output or user input. It inherits image-oci.bbclass from yocto meta-virtualization layer
• dac-image-wayland - for DAC application that are using OpenGL ES2 as Graphics rendering API and Wayland-egl protocol to setup EGL graphics surface and for key-input
• dac-image-qt - for DAC application that are using QT5  framework

• dac-image-essos - for DAC application that are using OpenGLES2 as Graphics rendering API and Firebolt ® Essos to setup EGL graphics surface and for key-input

See their links and hierarchy of inheritance visualized in diagram below  This is visualised in the diagram below

Publish your DAC app to RDK-M DAC cloud

Once you have built your oci, dobby, dac compliant Application Container AppContainer image with DAC SDK, you can publish it to RDK-M DAC cloud.

...

• step1 is to publish your oci, dobby, dac compliant ApplicationContainer AppContainer image to an oci container registry in the cloud. This is a standard cloud component that allows to upload container images (docker push), store them there persistently and download them (docker pull). This oci-registry is the binary exchange point to share your application binary with RDK-M and various RDK operators. 
• step2 : register your application with appropriate metadata in RDK-M DAC cloud system setup for RDK Video Accelerators. There is microservice called ASMS (AppStore Metadata Service) that offers API that allows Application Maintainers to register their app with appropriate metadata. Once registered this will add you app to the DAC App catalog for RDK-M Video Accelerators (VA) and you will be able to discover your App in the Resident UI of all RDK6.1 Video Accelerators and as user/tester of VA you can then choose to install it on any RDK6.1 VA and once installed you can run it. In the background the RDK-M instance of the DAC cloud system will automatically fetch your oci-ApplicationContainer AppContainer image, create bundle of it for the specific Video Accelerator Hardware (SoC/OEM), encrypt (optionally) and make it available for Video Accelerator to download and store securely. 

...

• the private RDK OCI container registry setup and maintained by RDK-M DAC cloud team, being "public.ecr.aws/a0v6o9z7".  You can request RDK-M DAC cloud support team (who TBD, ad interim Piotr S or Stefan V or BartC ) to upload your oci image there with version tag you specified or you can do it yourselves following the practical Instructions & tools described below. You will need credentials/account for accessing this registry, which you can request via email to piotr.serafin@consult.red or bcatrysse@libertylgobal.com. (When there is time/money this credential creation process should be improved and autosetup as part of registering as New Application maintainer in RDK DAC cloud system or Firebolt Connect system.  
• any of public accessible OCI container registries on the internet. Requirement The requirement is that the container registry supports OCI container format, that the container itself is uploaded & stored in the OCIcontainer image format (so not in docker format) and is public fetchable/accessible (read only, without any user/login) from RDK DAC cloud system. Note that in this approach your application binary is publicly accessible, not all application providers will agree with that and those will need to use the private RDK oci container registry approach explained above.

...