RDKM offers an in-house Test suite that facilitates SoCs to get This page provides the details and guidance to the SoC Vendors on how to adopt RDK-B. The porting procedure and the procedures for SoC to get an RDK based Platform up and running is also described in detail.

On this Page :

Before You Begin

Bringing up RDK by SoC - Approach

RDK porting guide to SoC vendors

Before You Begin

RDK License

SoC vendors are advised to get into an agreement with RDK Management LLC to obtain the free license so as to use the complete RDK Code base in their platform. More details about the licenses are available at https://rdkcentral.com/licenses/ . Please email info@rdkcentral.com if you have additional questions about licenses or membership

Bringing up RDK by SoC - Approach

This section will detail the recommended step by step procedure of adopting RDK by a SoC

Product Specifications

The first step to getting a fully functional product is to define the product features and see if they meet the standard requirements. See here to know what are all the features available in RDK-B and can implement based on your requirement. SoC can use this as a guide while engineering the RDK SoC platform.

RDKM On-boarding 

RDKM provides a collaboration zone facility for SoCs to facilitate easier engineering of RDK based devices. The collaboration zone will help SoCs to work with OEMs, RDKM, and any 3rd party along with a common space to develop & integrate, manage and verify the device. The zone includes facilities for code management, a confluence-based RDK Wiki for knowledge management & sharing, a JIRA for tracking activity progress, issues as well as to manage the activities, a test setup to validate devices. The access restrictions implemented will help the collaboration zone to be accessible only for the authorized personnel thereby guarding any sensitive information related to SoC/OEM/Third party.


Roles & Responsibilities

A table explaining the roles & responsibilities of SoC & RDKM in the collaboration zone is given below:


#

Activity

Owner

Remarks

1

SoC Collaboration zone creation


RDKM

RDKM will setup Collaboration space, access restrictions

2

JIRA Project creation

SoC

JIRA project. SoC will be the owner of the JIRA project

3

SoC  meta-layer creation in the collaboration zone

SoC/RDKM

RDKM will create the space and SoC push the code changes

4

Device specific HAL repo creation

SoC

Create necessary device specific HAL implementation for porting RDK into Accelerator

5

Share SoC SDK Artifacts

SoC

Details which SDK version is to be used. RDKM will support the integration with SoC libraries

6

Manifest creation

SoC

Manifest for building the accelerator

7

UI

RDKM/SoC

Comes with pre-integrated UI’s, SoC and RDKM will discuss on the default UI

8

Create RDK build from CMF GIT

SoC/ RDKM

Both teams work together to build Accelerator from CMF

9

Provide Devices to RDKM team

SoC


10

Device flashing instructions/recovery mechanisms

SoC

SoC should share the device flashing instruction

11

Sanity, Functionality Testing & automation tests

RDKM/SoC

RDK Certification Suite

12

Monthly release & tagging

SoC

Monthly tagging and release with stakeholders along with test results

It is expected that SoC has already obtained a license to work with RDKM (If not, SoC can send a mail to support@rdkcentral.com to start off with the discussions).

With this user account, an INFRA ticket can be raised at https://jira.rdkcentral.com to create a collaboration repo. The ticket should contain the details for:

  • Location of collaboration zone
  • Collaboration zone access groups/members

SoC users can sign up at https://wiki.rdkcentral.com/signup.action to create a user account in RDK. For any issues faced, a mail can be sent to support@rdkcentral.com

An INFRA ticket needs to be raised at https://jira.rdkcentral.com with the below details:

  • Collaboration zone/repo name
  • User name and the mail id's of the members to whom the access is needed
  • SoC collaboration zone/repo owner name

For any issues faced, a mail can be sent to support@rdkcentral.com

An INFRA ticket needs to be raised at https://jira.rdkcentral.com to create a JIRA project for SoC. Once approvals are received along with required access restrictions, the project will be created. For any issues faced, a mail can be sent to support@rdkcentral.com

To get a Git repository a request needs to be raised to CMF team using the CMFSUPPORT ticket at https://jira.rdkcentral.com. Once approvals are received along with required access restrictions, the repo will be created. Any changes in merge permissions can be requested in the same ticket. For creating any specific branches in the repo, another ticket in the same CMFSUPPORT can be raised. For any issues faced, a mail can be sent to support@rdkcentral.com

Once the git repo is created, it can be accessed at https://code.rdkcentral.com

An INFRA ticket needs to be raised at https://jira.rdkcentral.com to get access to SDK Artifacts. Once approvals are received along with required access restrictions, the access should be in place. For any issues faced, a mail can be sent to support@rdkcentral.com


Product Engineering

Once the product features are decided, the device engineering can be started. SoC needs to decide on the hardware layout that incorporates components to the target board. The device will be categorized either as a home broadband device or a business gateway.

SoC Platform Firmware

SoC can make use of the below details available to start developing a Yocto build to engineering the device firmware builds based on RDK Yocto build setup.

Yocto Manifests

Yocto based RDK builds are flexible enough to easily accommodate SoC / OEM / MSO / third party changes. The starting point for the Yocto builds is a manifest file. The manifest file is an xml file that contains details of the different open embedded Yocto build layers, meta layers, RDK as well as open-source components that need to be fetched during initial stages ( than during bitbake time ) as well as the URL locations from where the data can be pulled. A set of sample manifests that can be used as a template for developing SoC specific manifests are given below


#

File

Remarks

1

Device Specific Manifest

This is the starting point of the build and is specific to a device/board. If the SoC has only one target device /board, still it is recommended to maintain a different manifest for SoC for keeping it future-proof. Usually, it contains references to other manifest files which will be having a specific set of repos

2

SoC manifest

This manifest contains meta-layer details of SoC and, optionally, some SoC specific repos

3

OE layers manifest

This manifest has details of the basic Yocto Open Embedded layers

4

RDK-B manifest

This manifest can contain meta layers specific to RDK & RDK-B and, for EXTERNALSRC cases, the RDK & RDK-B component repo details too. It might be supplemented with a conf file too

5

Third-Party Apps manifest

This manifest can contain meta layers related to their applications which are chosen by SoC

The default manifest repo in RDKM Git is at https://code.rdkcentral.com/r/#/c/manifests/ . SoC can use the 'collaboration' subsection in this repo to add their platform-specific manifests which will be under collaboration zone restrictions. The location will be https://code.rdkcentral.com/r/collaboration/SoC/<platform>/<platform-manifests>

For more details on getting RDK-B ported to a SoC device, please refer RDK porting guide to SoC vendors .

SoC/OEM meta-layer creation

To match the layered structure of Yocto builds, a SoC-specific layer is used to include SoC changes and additions. Use the yocto-layer create sub-command to create a new general layer.

$ yocto-layer create mylayer

There shall be a separate device (machine) configuration file (.conf) for each device for the particular chip family for which the layer is intended. The general naming terminology for the SoC layer is meta-rdk-SoC-<SoC name>

The device (machine) configuration file shall include the corresponding include (.inc) file to get machine configuration details.


Adding the Machine Configuration File for the new SoC/OEM

To add a machine configuration, you need to add a .conf file with details of the device being added to the conf/machine/ file.

The most important variables to set in this file are as follows:

  • TARGET_ARCH (e.g. "arm")
  • PREFERRED_PROVIDER_virtual/kernel (see below)
  • MACHINE_FEATURES

You might also need these variables:

  • KERNEL_IMAGETYPE (e.g. "zImage")
  • IMAGE_FSTYPES (e.g. "tar.gz")
  • The default configuration is defined in meta-rdk/conf/distro/rdk.conf and it should be overwritten by the machine-specific conf file.

Adding a Kernel for the Machine

The OpenEmbedded build system needs to be able to build a kernel for the machine. We need to either create a new kernel recipe for this machine or extend an existing recipe. We can find several kernel examples in the source

The directory at meta/recipes-kernel/linux that you can use as references. If you are creating a new recipe, the following steps need to be done,

  • Setting up an SRC_URI.
  • Specify any necessary patches
  • Create a configure task that configures the unpacked kernel with a defconfig.

If you are extending an existing kernel, it is usually a matter of adding a suitable defconfig file. The file needs to be added into a location similar to defconfig files used for other machines in a given kernel.

A possible way to do this is by listing the file in the SRC_URI and adding the machine to the expression in COMPATIBLE_MACHINE:

  • COMPATIBLE_MACHINE = '(qemux86|qemumips)'

Adding Recipe for SoC/OEM

The following kind of recipes can be added to SoC/OEM layer. The recipes shall be grouped as described in slide “BSP Reference Layer”

  • recipes (.bb) to build Kernel
  • recipes(.bb)  to build SDK
  • Kernel patches (SoC/OEM specific - if any)
  • SDK patches (SoC/OEM specific - if any)
  • Any SoC/OEM specific scripts or files which need to be installed in RF

Creating packages for building images 

Create a custom package group for the SoC/OEM which shall list all the recipes that are required for this image.

For example, the following recipe can be appended to the broadband package group.

meta-rdk-soc-<soc>/meta-<processor_name>/recipes-core/packagegroups/packagegroup-rdk-ccsp-broadband.bbappend:
RDEPENDS_packagegroup-rdk-ccsp-broadband_append += " \
    ccsp-cr \
    rsync \
    utopia \
    lighttpd \
.
.
.
"


Create a custom image for the required SoC/OEM. For example:

meta-rdk-<soc>/meta-<processor_name>/recipes-core/images/<image>.bb:
IMAGE_INSTALL += " \
    packagegroup-<soc/oem specific packages> \
    "
"

Adding your own custom layer

Use the yocto-layer create sub-command to create a new layer.

$ yocto-layer create newlayer

Add this to ./meta-rdk/conf/bblayers.conf.sample.

Recipes can be placed inside recipes-< > folders. There can be a configuration file inside conf/ for layer-specific configuration and classes folder for keeping information that is useful to share between metadata files.

TDK

RDKM offers an in-house Test suite that facilitates SoCs to get their devices tested for their features.

For more details on TDK refer: TDK-B Documentation

SDK Releases


Once the RDK bring-up in SoC is completed, the vendor needs to plan on the delivery of the software to OEM vendors. This usually happens in 2 ways:

HAL + SDK binary

In this approach will make use of the RDK Artifactory server. Artifactory server is a Repository Manager that functions as a single access point organizing all the binary resources including proprietary libraries, remote artifacts, and other 3rd party resources. It is a secure and restricted server, only collaboration members will have access to this server.

SoC vendor can define a HAL layer, share the source of HAL & yocto meta layer that can be stored in RDK CMF Git repository (which will be shared only to authorized OEM vendors who will work in collaboration with the SoC vendor), share the SDK binary that can be stored in RDK Artifactory (which will be shared only to authorized OEM vendors who will work in collaboration with the SoC vendor) and then publish necessary documentation on how to build the SoC SDK. SoC vendor can use the git/ Artifactory for periodic updates (for releases) or for bug fixes. All the source code, binary and documentation will be strictly access restricted and access will be allowed only for authorized personnel by the SoC vendors.

The artifactory server can be accessed by adding the Artifactory details and login credentials in the .netrc file, just like it is done for normal git repositories. A sample is given below:

machine your.artifactory.host
login YOUR_ARTIFACTORY_USERNAME
password YOUR_PASSWORD_OR_KEY_OR_TOKEN

Complete source code

In this approach, SoC vendor can define a HAL layer, share the source of HAL, yocto meta layer, and SDK source code that can be stored in RDK CMF Git repository( which will be shared only to authorized OEM vendors who will work in collaboration with the SoC vendor )  and then publish necessary documentation on how to build the SoC SDK. SoC vendors can use the git for periodic updates ( for releases ) or for bug fixes. All the source code and documentation will be strictly access restricted and access will be allowed only for authorized personnel by the SoC vendor.

For both approaches, the RDKM collaboration zone will be used with strict access restrictions.

Collaboration with OEMs

After a successful bring-up of RDK on the SoC platform, the next step will be to allow OEMs to work with SoCs to get a device based on the SoC platform. RDKM offers collaboration space for SoCs which would help SoCs to collaborate with OEM and RDK teams (as well as any 3rd party) in their journey to engineering a successful RDK product. RDKM collaboration zone includes features like (but not limited to) CMF facility to maintain build manifests as well as SoC/OEM specific code, SoC SDK artifact storage facility, JIRA & RDK Wiki spaces, integration with Test & Certification suites, monthly & release tagging, etc.

Please refer to RDKM On-boarding for more details on facilities available for SoCs and OEMs as part of the collaboration zone.

In short, it will include:

  • Access restricted Git repositories and Artifactory servers
  • Access restricted Confluence and JIRA spaces for Management and Documentation
  • Access to RDKM support as well as extended documentation
  • Access to test & certification support 



RDK porting guide to SoC vendors



The aim of this SoC porting guide is to guide SoC Vendors on how to port RDK to their platforms.

Step 1 : Get a board with Linux and drivers

RDK is based on Yocto Linux. Prior to porting RDK on an SoC, the precondition is to have the SoC platform running on Linux. The Linux version can be a SoC-specific one with kernel hardening and other OS optimizations specific to SoC, as RDK could easily run on top of vendor-specific Linux. SoC should also provide drivers for the other peripherals in the SoC platform, like WiFi, so that the unit can work independently and completely from an SoC point of view.

Step 2 : Move the build to Yocto, compare it to the supported Yocto version of RDK

Once the SoC vendor is ready with its own port of Linux + drivers for the SoC platform, it is time to migrate the platform to Yocto based builds. If the SoC is already having a Yocto based Linux, this step can be skipped. The current Yocto versions supported are Yocto 3.1- Dunfell ( preferred ) as well as Yocto 2.2- Morty ( soon to be deprecated )

Yocto 3.1 Upgradation support the following:

  • Version upgrades for bitbake and other OE components
  • Linux kernel 5.4 or above
  • Extensible SDK

Each component in RDK is a standalone repository with its own individual build tools producing a library or set of binaries. When OE layers are upgraded to the newer versions, necessary changes need to be made in the RDK Yocto meta layers which use these components, to avoid build failures.

Step 3 : Compare and verify the compiler flags used in RDK and in the platform to avoid issues

This is an important step while porting RDK to a new SoC platform. RDK Linux is built with considering particular build flags/features in the target platform( For example, RDK considers hardware floating point in the platform whereas some platforms are on software-based floating point ). SoC vendors need to analyze such flags in RDK and then make a comparison with the existing SoC platform Linux to ensure compatibility or to understand the required modifications in RDK code so as to house the compatibility changes

Specific DISTRO_FEATURES can be added to support the build-time flag for specific platforms. For example : DISTRO_FEATURES_append = " referencepltfm "

Step 4 : Compare the open-source versions used in a platform as different versions will cause problems

Depending on the Yocto version, the RDK build will be working with some particular version of Open source components. This might either be a dependency with the Yocto version compatibility as such or with RDK ( functionality or license issues ). If the SoC Linux has some version dependency on particular open source software and, if it conflicts with the version in RDK, the vendor needs to make required changes to make the open-source version match the RDK requirements as best as possible, by adding required patches in SoC platform 

Check below layers for all open-sourced version packages recipes used in RDK. If multiple recipes with different versions are available, then check for the value of PREFFERED_VERSION_<recipe name> set.

Meta layers : -  meta-openembedded, openembedded-core, meta-rdk-ext, meta-rdk, meta-cmf

Step 5 : Move the RDK recipes to platform Yocto build

For platform-specific recipes, keep them in the SoC meta-layer. While it is a good practice to start afresh with a new manifest for the target platform, a manifest file for a similar featured platform can be used as a starting point too. Check all device-specific repos in the reference manifest, and ensure corresponding device repos are created for this new device as needed, and update the manifest with these updated repos

  • Create artifactory repo for the project with appropriate permissions for vendors. This is used for hosting any binaries required for the project
  • Check-in SoC components - toolchain, SDK, kernel, drivers, etc.. to corresponding SoC Gerrit repos/ artifactory as applicable
  • Populate meta SoC layer with the initial set of changes needed to build a kernel, SoC components, etc.
  • If there is any SoC reference board exists, create a corresponding machine configuration in the SoC layer, and create an image target to be able to build a final image for the reference board. This layer should be separated out within the meta SoC layer from other common SoC, common chip sub-layers which will be usually used by the meta OEM layer as well.
  • Populate meta OEM layer with machine configuration and other bare minimum changes required to generate a target image for OEM board.
  • Machine configuration can be updated with the "NEEDED_BSPLAYERS" field to include required SoC, OEM layers in the build
  • Any unwanted recipes during the early stage of bringing up can be masked using BBMASK if needed.

Step 6: Get a successful build

Add a platform-specific main recipe to create an image.


HAL implementation by SoC


Introduction

RDK-B components are designed to avoid platform or silicon dependencies. Hardware Abstraction Layer (HAL) defines a standard interface for hardware vendors to implement. The HAL layer abstracts the underlying hardware like MOCA, Wi-Fi, etc. through a standard set of APIs defined as part of RDK-B HAL for the respective components. This HAL layer is implemented per platform and the rest of the components can be compiled to run on the new platform without major modifications.

The HAL in RDK-B Architecture section gives an overview of CCSP framework's Hardware Abstraction Layer.

HAL can be common-HAL or component-specific-HAL. Components may define a component specific HAL to hardware drivers, that are only used by that component

Component Specific HAL

  • HAL APIs will be available in the CMF repo path: "../rdkb/components/opensource/ccsp/hal/source/"
  • PandM HAL Integration (back-end) Layer is also known as component specific HAL.
  • This layer makes call to underlying Linux system calls/commands, third party modules, open source modules and other CCSP components to execute the requests.
  • This layer will be more component specific and will be providing APIs to CCSP so as to manage a particular hardware module of the system.
  • Following are some of the  component specific  HALs available in "../rdkb/components/opensource/ccsp/hal/source/" path.
    • Wifi  
    • MoCA
    • MTA Agent
    • CM   
    • Ethernet Switch
    • DHCPv4C
    • Virtual LAN
    • Firewall
    • DPoE
    • Bluetooth
    • MSO_Management
    • Voice
    • WAN
    • TR69_TLV

Wi-Fi HAL 

       All HAL functions prototypes and structure definitions are available in wifi_hal.h file.

  • WI-fI HAL is used for the RDK-Broadband Wifi radio hardware abstraction layer.
  • Latest version of RDKB supports 300+ Wi-Fi HAL API’s.
  • Based on how Wi-Fi vendor exposes their driver capabilities in user space, the HAL API’s can be implemented in wifi_hal.c
  • Some of the APIs are : 
    1. wifi_getRadioChannelStats
    2. wifi_getRadioChannelStats2
    3. wifi_getApAssociatedDeviceRxStatsResult
    4. wifi_getApAssociatedDeviceTxStatsResult
    5. wifi_getApAssociatedDeviceTidStatsResult
    6. wifi_getApAssociatedDeviceStats
    7. wifi_getHalVersion
    8. wifi_factoryReset
    9. wifi_factoryResetRadios
    10. wifi_factoryResetRadio
    11. wifi_setLED
    12. wifi_init
    13. wifi_reset
    14. wifi_down
    15. wifi_createInitialConfigFiles
    16. wifi_getRadioCountryCode
    17. wifi_setRadioCountryCode
    18. wifi_pushCountryCode
    19. wifi_getATMCapable
    20. wifi_setATMEnable

  • To see the API specification of WI-fI HAL please refer - Wi-Fi HAL APIs

MOCA HAL

All HAL functions prototypes and structure definitions are available in moca_hal.h file.

  • MoCA HAL is used for the RDK-Broadband MoCA hardware abstraction layer.
  • An abstraction layer, mainly for interacting with MoCA driver.
  • The APIs are : 
    1. moca_GetIfConfig
    2. moca_SetIfConfig
    3. moca_IfGetDynamicInfo
    4. moca_IfGetStaticInfo
    5. moca_IfGetStats
    6. moca_GetNumAssociatedDevices
    7. moca_IfGetExtCounter
    8. moca_IfGetExtAggrCounter
    9. moca_GetMocaCPEs
    10. moca_GetAssociatedDevices
    11. moca_FreqMaskToValue
    12. moca_HardwareEquipped
    13. moca_GetFullMeshRates
    14. moca_GetFlowStatistics
    15. moca_GetResetCount
    16. moca_setIfAcaConfig
    17. moca_getIfAcaConfig
    18. moca_cancelIfAca
    19. moca_getIfAcaStatus
    20. moca_getIfScmod
  • To see the API specification of MoCA HAL please refer - MoCA HAL APIs

MTA HAL

All HAL functions prototypes and structure definitions are available in mta_hal.h file. An MTA can deliver Home Phone service in addition to High Speed Internet.

  • MTA HAL used for the RDK-Broadband hardware abstraction layer for Cable Modem.
  • An abstraction layer, implemented to interact with MTA device.
  • mta_hal.c file provides the function call prototypes and structure definitions used for the MTA hardware abstraction layer.
  • Some of the APIs are : 
    1. mta_hal_InitDB
    2. mta_hal_GetDHCPInfo
    3. mta_hal_LineTableGetNumberOfEntries
    4. mta_hal_LineTableGetEntry
    5. mta_hal_TriggerDiagnostics
    6. mta_hal_GetServiceFlow
    7. mta_hal_DectGetEnable
    8. mta_hal_DectSetEnable.
    9. mta_hal_DectGetRegistrationMode
    10. mta_hal_DectSetRegistrationMode
    11. mta_hal_DectDeregisterDectHandset
    12. mta_hal_GetCalls
    13. mta_hal_GetDect
    14. mta_hal_GetDectPIN
    15. mta_hal_SetDectPIN
    16. mta_hal_GetHandsets
    17. mta_hal_GetCALLP
    18. mta_hal_GetDSXLogs
    19. mta_hal_GetDSXLogEnable
    20. mta_hal_SetDSXLogEnable
  • To see the API specification of MTA HAL please refer - MTA HAL APIs 

CM HAL

All HAL functions prototypes and structure definitions are available in cm_hal.h file.

  • CM HAL is used for the RDK-Broadband hardware abstraction layer for Cable Modem.
  • It provides interface that cable modem software developers can use to interface to RDK-B.
  • Some of the APIs are : 
    1. cm_hal_InitDB
    2. docsis_InitDS
    3. docsis_InitUS
    4. docsis_getCMStatus
    5. docsis_GetDSChannel
    6. docsis_GetUsStatus
    7. docsis_GetUSChannel
    8. docsis_GetDOCSISInfo
    9. docsis_GetNumOfActiveTxChannels
    10. docsis_GetNumOfActiveRxChannels
    11. docsis_GetErrorCodewords
    12. docsis_SetMddIpModeOverride
    13. docsis_GetMddIpModeOverride
    14. docsis_GetUSChannelId
    15. docsis_SetUSChannelId
    16. docsis_GetDownFreq
    17. docsis_SetStartFreq
    18. docsis_GetDocsisEventLogItems
    19. cm_hal_GetDHCPInfo
    20. cm_hal_GetCPEList
  • To see the API specification of CM HAL please refer - CM HAL APIs

Ethernet Switch HAL 

All HAL functions prototypes and structure definitions are available in ccsp_hal_ethsw.h file.

  • It provides implementation for Ethernet Switch Control.
  • Based on how vendor exposes their driver capabilities in user space, the HAL API’s can be implemented in hal-ethsw-generic/git/source/ethsw/ccsp_hal_ethsw.c
  • The APIs are : 
    1. CcspHalEthSwInit
    2. CcspHalEthSwGetPortStatus
    3. CcspHalEthSwGetPortCfg
    4. CcspHalEthSwSetPortCfg
    5. CcspHalEthSwGetPortAdminStatus
    6. CcspHalEthSwSetPortAdminStatus
    7. CcspHalEthSwSetAgingSpeed 
    8. CcspHalEthSwLocatePortByMacAddress
    9. CcspHalExtSw_getAssociatedDevice
    10. CcspHalExtSw_ethAssociatedDevice_callback_register
    11. CcspHalExtSw_getEthWanEnable
    12. CcspHalExtSw_setEthWanEnable
    13. CcspHalExtSw_getEthWanPort 
    14. CcspHalExtSw_setEthWanPort 
    15. GWP_RegisterEthWan_Callback 
    16. GWP_GetEthWanLinkStatus
    17. GWP_GetEthWanInterfaceName

DHCPv4C HAL 

All HAL functions prototypes and structure definitions are available in dhcpv4c_api.h file.

  • DHCPv4C HAL is used for the RDK-B DHCPv4 Client Status abstraction layer.
  • DHCPv4C HAL API's functionality should be implemented by OEMs.
  • dhcpv4c_api.c provides the function call prototypes and structure definitions used for the RDK-Broadband DHCPv4 Client Status abstraction layer.
  • Some of the APIs are : 
    1. dhcpv4c_get_ert_lease_time
    2. dhcpv4c_get_ert_remain_lease_time
    3. dhcpv4c_get_ert_remain_renew_time
    4. dhcpv4c_get_ert_remain_rebind_time
    5. dhcpv4c_get_ert_config_attempts
    6. dhcpv4c_get_ert_ifname
    7. dhcpv4c_get_ert_fsm_state
    8. dhcpv4c_get_ert_ip_addr
    9. dhcpv4c_get_ert_mask
    10. dhcpv4c_get_ert_gw
    11. dhcpv4c_get_ert_dns_svrs
    12. dhcpv4c_get_ert_dhcp_svr
    13. dhcpv4c_get_ecm_lease_time
    14. dhcpv4c_get_ecm_remain_lease_time
    15. dhcpv4c_get_ecm_remain_renew_time
    16. dhcpv4c_get_ecm_remain_rebind_time
    17. dhcpv4c_get_ecm_config_attempts
    18. dhcpv4c_get_ecm_ifname
    19. dhcpv4c_get_ecm_fsm_state
    20. dhcpv4c_get_ecm_ip_addr
  • To see the API specification of DHCPv4C HAL please refer - DHCPv4C HAL APIs

VLAN HAL

All HAL functions prototypes and structure definitions are available in vlan_hal.h file.

  • VLAN HAL is or the RDK-B Broadband VLAN abstraction layer.
  • VLAN HAL layer is intended to support VLAN drivers through the System Calls.
  • The APIs are : 
    1. vlan_hal_addGroup
    2. vlan_hal_delGroup
    3. vlan_hal_addInterface
    4. vlan_hal_delInterface
    5. vlan_hal_printGroup
    6. vlan_hal_printAllGroup
    7. vlan_hal_delete_all_Interfaces
    8. _is_this_group_available_in_linux_bridge
    9. _is_this_interface_available_in_linux_bridge
    10. _is_this_interface_available_in_given_linux_bridge
    11. _get_shell_outputbuffer
    12. insert_VLAN_ConfigEntry
    13. delete_VLAN_ConfigEntry
    14. get_vlanId_for_GroupName
    15. print_all_vlanId_Configuration
  • To see the API specification of VLAN HAL please refer - VLAN HAL APIs

Firewall HAL

All HAL functions prototypes and structure definitions are available in hal_firewall.h file.

  • This module is responsible for setting firewall rules like port forwarding, port triggering Parental control etc.
  • Some of the APIs are : 
    1. firewall_service_init
    2. firewall_service_start
    3. firewall_service_restart
    4. firewall_service_stop
    5. firewall_service_close
    6. GetHttpPortValue
    7. Wan2lan_log_deletion_setup
    8. Wan2lan_log_insertion_setup
    9. GettingWanIP_remotemgmt_deletion_logsetup
    10. GettingWanIP_remotemgmt_insertion_logsetup
    11. DeleteRemoteManagementIptablesRules
    12. AddRemoteManagementIptablesRules
    13. DisablingHttps
    14. EnablingHttps
    15. DisablingHttp
    16. EnablingHttp
    17. SetHttpPort
    18. SetHttpsPort
    19. RemoteManagementiptableRulessetoperation
    20. BasicRouting_Wan2Lan_SetupConnection

DPOE HAL

All HAL functions prototypes and structure definitions are available in dpoe_hal.h file.

  • DPOE HAL is used for the RDK-Broadband DPoE hardware abstraction layer as per the DPoE-SP-OAMv1.0-I08-140807 specification.
  • Some of the APIs are : 
    1. dpoe_getOnuId
    2. dpoe_getFirmwareInfo
    3. dpoe_getEponChipInfo
    4. dpoe_getManufacturerInfo
    5. dpoe_getNumberOfNetworkPorts
    6. dpoe_getNumberOfS1Interfaces
    7. dpoe_getOnuPacketBufferCapabilities
    8. dpoe_getOamFrameRate
    9. dpoe_getLlidForwardingState
    10. dpoe_getDeviceSysDescrInfo
    11. dpoe_getMaxLogicalLinks
    12. dpoe_setResetOnu
    13. dpoe_getStaticMacTable
    14. dpoe_getEponMode
    15. dpoe_getDynamicMacAddressAgeLimit
    16. dpoe_getDynamicMacLearningTableSize
    17. dpoe_getDynamicMacTable
    18. dpoe_getStaticMacTable
    19. dpoe_getMacLearningAggregateLimit
    20. dpoe_getOnuLinkStatistics
  • To see the API specification of DPOE HAL please refer - DPOE HAL APIs

Bluetooth HAL

All HAL functions prototypes and structure definitions are available in bt_hal.h file.

  • The APIs are : 
    1. ble_Enable
    2. ble_GetStatus
  • To see the API specification of Bluetooth HAL please refer - Bluetooth HAL APIs

MSO Management HAL

All HAL functions prototypes and structure definitions are available in mso_mgmt_hal.h file.

  • MSO Management HAL is used for the RDK-Broadband hardware abstraction layer for MSO Management.
  • The APIs are : 
    1. mso_pwd_ret_status mso_validatepwd
    2. mso_set_pod_seed
    3. mso_get_pod_seed
  • To see the API specification of MSO Management HAL please refer - MSO Management HAL APIs

Voice HAL

All HAL functions prototypes and structure definitions are available in voice_hal.h file.

  • Voice HAL is used for the RDK-Broadband hardware abstraction layer for VoIP.
  • Some of the APIs are : 
    1. voice_hal_Init
    2. voice_hal_InitDB
    3. voice_hal_Deinit
    4. voice_hal_DeinitDB
    5. voice_hal_setVoiceProcessState
    6. voice_hal_getVoiceProcessState
    7. voice_hal_getVoiceProcessStatus
    8. voice_hal_getConfigSoftwareVersion
    9. voice_hal_getCountProfiles
    10. voice_hal_getServiceVersion
    11. voice_hal_getCountServices
    12. voice_hal_getCountLines
    13. voice_hal_getCountPhyInterfaces
    14. voice_hal_setIpAddressFamily
    15. voice_hal_getBoundIfName
    16. voice_hal_setBoundIfName
    17. voice_hal_setIpAddressFamily
    18. voice_hal_getIpAddressFamily
    19. voice_hal_setLinkState
    20. voice_hal_setIpWanAddress
  • To see the API specification of Voice HAL please refer - Voice HAL APIs

WAN HAL

All HAL functions prototypes and structure definitions are available in  wan_hal.h file.

  • The APIs are : 
    1. wan_hal_Init
    2. wan_hal_SetSelfHealConfig 
    3. wan_hal_SetWanConnectionEnable
    4. wan_hal_SetSelfHealConfig
    5. wan_hal_GetWanOEUpstreamCurrRate
    6. wan_hal_GetWanOEDownstreamCurrRate 
    7. wan_hal_SetQoSConfiguration
    8. wan_hal_RestartWanService
  • To see the API specification of WAN HAL please refer - WAN HAL APIs

TR69_TLV HAL

All HAL functions prototypes and structure definitions are available in Tr69_Tlv.h file.

  • Telemetry Key fields and data fields are stored in the database as TLV (Tag, Length, Value)
  1. Tag - uniquely identifies the field.
  2. Length - gives the size (in number of bytes) of the data associated with the field.
  3. Value - contains the actual data associated with the field stored in network byte ordering.

Common HAL

  •  A common HAL provides the necessary abstraction to all the CCSP components to interface with other common hardware components.
  • Eg : Platform HAL

Platform HAL

  • Platform HAL is an abstraction layer, implemented to interact with cable modem device for getting the hardware specific details such as Firmware Name, Boot loader Version, etc.
  • This HAL layer is intended to support platform drivers
  • platform_hal.c file provides the function call prototypes and structure definitions used for the platform hardware abstraction layer
  • Some of the APIs are :
  1. platform_hal_GetDeviceConfigStatus
  2. platform_hal_GetTelnetEnable
  3. platform_hal_GetSSHEnable
  4. platform_hal_SetSSHEnable
  5. platform_hal_GetSNMPEnable
  6. platform_hal_SetSNMPEnable
  7. platform_hal_GetSerialNumber
  8. platform_hal_GetWebUITimeout
  9. platform_hal_SetWebUITimeout
  10. platform_hal_GetWebAccessLevel
  11. platform_hal_SetWebAccessLevel
  12. platform_hal_PandMDBInit
  13. platform_hal_DocsisParamsDBInit
  14. platform_hal_GetModelName
  15.  platform_hal_GetFirmwareName
  16. platform_hal_GetHardwareVersion
  17. platform_hal_GetSoftwareVersion
  18.  platform_hal_GetBootloaderVersion
  19. platform_hal_GetBaseMacAddress
  20. platform_hal_GetHardware

To see the API specification of Platform HAL please refer - Platform HAL APIs 







  • No labels

DISCLAIMER: Please note that the use of the RDK Wiki is subject to its Privacy Policy & Terms of Use. In addition, this Wiki may be accessed by all RDK licensees and their contractors.