Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

 RDKM team in collaboration with  bringup RDK-B on ARM System Ready reference device and make it available for RDK-B community as a reference for RDK-B          

Mandatory

  • QEMU

  • Raspberry pi 4

  • NXP

Yocto Build Instructions

  • NXP

...

Code Block
titlerdk-next
$ mkdir rdkb-arm
$ cd rdkb-arm
$ repo init -u 'https://github.com/rdkcentral/meta-rdk-bsp-arm/' \
    -m "manifests/rdkb-bsp-arm.xml" \
    -b "develop"
$ repo sync
$ source meta-rdk-bsp-arm/setup-environment
$ bitbake rdk-generic-broadband-image
  • RPI

Code Block
titleBuild Instruction for RPI (rdk-next)
$ mkdir rdkb-arm
$ cd rdkb-arm
$ repo init -u 'https:

Cherry-pick below PRs to have support to WAN interface (erouter0), WebUI and SSH features.

https://github.com/rdkcentral/ethernet-agent/pull/40
https://github.com/rdkcentral/webui/pull/81
https://github.com/rdkcentral/meta-rdk-bsp-arm/pull/' \
    -m "manifests/rdkb53
https://github.com/rdkcentral/meta-rdk-bsp-arm.xml" \
    -b "develop"
$ repo sync
$ MACHINE="raspberrypi64-rdk-broadband" source meta-rdk-bsp-arm/setup-environment
$ bitbake rdk-generic-broadband-image/pull/50

The default ARM build have been updated to support SSH.
PR: https://github.com/rdkcentral/utopia/pull/175


  • QEMU

    RPI


Code Block
titleBuild Instruction for QEMURPI (rdk-next)
$ mkdir rdkb-arm
$ cd rdkb-arm
$ repo init -u 'https://github.com/rdkcentral/meta-rdk-bsp-arm/' \
    -m "manifests/rdkb-bsp-arm.xml" \
    -b "maindevelop"
$ repo sync
$ MACHINE="armefi64raspberrypi64-qemurdk-broadband" source meta-rdk-bsp-arm/setup-environment
$ bitbake rdk-generic-broadband-image

The default ARM build have been updated to include additional features such as  erouter0, Captive Portal and WebUI support.

The required PRs to be cherry-picked

...



Cherry-pick below PRs to have support to WAN interface (erouter0), WebUI and SSH features.

https://github.com/rdkcentral/ethernet-agent/pull/40

...


https://github.com/rdkcentral/webui/pull/81

...


https://github.com/rdkcentral/meta-rdk-bsp-arm/pull/53

...


https://github.com/rdkcentral/meta-rdk-bsp-arm/pull/50

...



The default ARM build have been updated to support SSH.

...


PR:

...

 https://github.com/rdkcentral/utopia/pull/175

...

There are two types of build outputs:

  • The platform firmware, which abstracts the hardware platform in a standard manner (the SystemReady standards).

  • The operating system image, which includes the root filesystem, Linux kernel and boot manager.

    Development images generated by this layer can be used across any machine which has a compatible platform firmware deployed.

The default armefi64-rdk-broadband machine type will generate an operating system image that will be bootable on platforms with SystemReady (EFI) compatible firmware and a platform firmware firmware which can be used with QEMU's arm64 virt machine type.

The following generated binaries (in build-armefi64-rdk-broadband/tmp/deploy/images/armefi64-rdk-broadband/) are relevant:

...

rdk-generic-broadband-image-armefi64-rdk-broadband.wic: Uncompressed operating system image (kernel + rootfs + boot manager)

This image can be booted on a board (or virtual machine) which already has SystemReady compatible firmware

...

rdk-generic-broadband-image-armefi64-rdk-broadband.wic.qcow2: QCOW2 operating system image, best to use with virtual machine programs

  • QEMU

Code Block
titleBuild Instruction for QEMU(rdk-next)
$ mkdir rdkb-arm
$ cd rdkb-arm
$ repo init -u 'https://github.com/rdkcentral/meta-rdk-bsp-arm/' \
    -m "manifests/rdkb-bsp-arm.xml" \
    -b "develop"
$ repo sync

cherry-pick below PR to have support QEMU Machine conf.
https://github.com/rdkcentral/meta-rdk-bsp-arm/pull/50

$ MACHINE="armefi64-qemu-broadband" source meta-rdk-bsp-arm/setup-environment
$ bitbake rdk-generic-broadband-image

...

u-boot-armefi64-rdk-broadband.bin (linked to u-boot.bin): Reference platform firmware (used with QEMU virt machine)



Cherry-pick below PRs to have support to WAN interface (erouter0), WebUI and SSH features.

https://github.com/rdkcentral/ethernet-agent/pull/40
https://github.com/rdkcentral/webui/pull/81
https://github.com/rdkcentral/meta-rdk-bsp-arm/pull/53


The default ARM build have been updated to support SSH.
PR: https://github.com/rdkcentral/utopia/pull/175


The default ARM build have been updated to include additional features such as  erouter0, Captive Portal and WebUI support.

The required PRs to be cherry-picked

 https://github.com/rdkcentral/ethernet-agent/pull/40
 https://github.com/rdkcentral/webui/pull/81
https://github.com/rdkcentral/meta-rdk-bsp-arm/pull/53
https://github.com/rdkcentral/meta-rdk-bsp-arm/pull/50

The default ARM build have been updated to support SSH.

PR:
https://github.com/rdkcentral/utopia/pull/175

There are two types of build outputs:

  • The platform firmware, which abstracts the hardware platform in a standard manner (the SystemReady standards).

  • The operating system image, which includes the root filesystem, Linux kernel and boot manager.

    Development images generated by this layer can be used across any machine which has a compatible platform firmware deployed.

The default armefi64-rdk-broadband machine type will generate an operating system image that will be bootable on platforms with SystemReady (EFI) compatible firmware and a platform firmware firmware which can be used with QEMU's arm64 virt machine type.

The following generated binaries (in build-armefi64-rdk-broadband/tmp/deploy/images/armefi64-rdk-broadband/) are relevant:

  • rdk-generic-broadband-image-armefi64-rdk-broadband.wic: Uncompressed operating system image (kernel + rootfs + boot manager)

    This image can be booted on a board (or virtual machine) which already has SystemReady compatible firmware

  • rdk-generic-broadband-image-armefi64-rdk-broadband.wic.qcow2: QCOW2 operating system image, best to use with virtual machine programs

  • rdk-generic-broadband-image-armefi64-rdk-broadband.tar.gz: Compressed tar archive of the operating system image (including kernel). This is currently used for system upgrades.

  • u-boot-armefi64-rdk-broadband.bin (linked to u-boot.bin): Reference platform firmware (used with QEMU virt machine)

The generated disk (wic) images are intended for block storage devices, for example, eMMC, SD cards, USB or NVMe storage devices, or emulated types such as virtio-blk.

A production device may use flash (NOR or NAND) devices for storing the system level firmware.

Additional files like Image (Linux kernel Image file), linuxaa64.efi.stub (Kernel EFI stub), systemd-bootaa64.efi (systemd-boot executable) and u-boot-initial-env-armefi64-rdk-broadband (U-Boot "Factory" environment) are also generated by the Yocto build process. These are not needed for normal development and deployment activities.

It is intended that the rdk-generic-broadband-image-armefi64-rdk-broadband.wic is a universal operating system image that will boot on as many real and virtual machines as possible.

(For example, you can write the .wic file onto a USB drive, and move the USB drive between different boards without making any changes)

Where possible, the same Linux kernel, firmware (U-Boot) and other relevant component versions will be used, with a strong preference for "mainline" versions.

Configuring multiconfig for multiple target builds

It is possible to use BitBake's "multiconfig" feature to setup the same build folder for multiple targets at once.

Doing so will save you time and disk space, as most packages between machines defined in this layer are shared.

If you specify MACHINE=all, the setup-environment script will do the necessary setup:

$ MACHINE="all" source meta-rdk-bsp-arm/setup-environment


 You can then run the build cycle for each target:

Code Block
titleMulticonfig (rdk-next)
$ MACHINE="all" source meta-rdk-bsp-arm/setup-environment
$ bitbake mc:generic:rdk-generic-broadband-image && \
  bitbake mc:raspberrypi:rdk-generic-broadband-image 
(Due to the way RDK-B components are built, it is not possible to do a "parallel" build for two targets at once, however, you will 
still save a significant amount of time and disk space by using multiconfig builds sequentially)

Build images for each target will be available in tmp/deploy:

$ ls build-armefi64-rdk-broadband/tmp/deploy/images/
armefi64-rdk-broadband
raspberrypi64-rdk-broadband
armefi64-qemu-broadband.

Running the generated image on QEMU

Direct QEMU invocation

You can use the generated wic.qcow2 and u-boot.bin to invoke QEMU directly. This allows you to customize your QEMU setup for your own environment and requirements.

On virtualization capable Arm64 hosts you can use KVM for near-native performance.

You can invoke QEMU like this:

Code Block
titleQEMU invocation
# Create a fresh virtual switch wan feed and LAN clients
sudo ip link add name br-wan-test type bridge
sudo ip link add name br-lan-test type bridge

# Assign both an IPv4 address 
sudo ip addr add <VIRTUAL_WAN_IP>/24 dev br-wan-test # ex: sudo ip addr add 192.168.50.1/24 dev br-wan-test
sudo ip addr add 10.0.0.254/24 dev br-lan-test


# Turn on the virtual switch
sudo ip link set br-wan-test up
sudo ip link set br-lan-test up


#If you are using USB-to-Ethernet adapter to connect LAN clinets
#check interfae name bu using ip link ex; enx000e0987b9ec
sudo ip addr flush dev <interface_name> 


# Physically link your USB adapter into LAN virtual switch
sudo ip link set <interface_name> master br-lan-test
sudo ip link set <interface_name> up

sudo mkdir -p /etc/qemu
echo -e "allow br-wan-test\nallow br-lan-test" | sudo tee /etc/qemu/bridge.conf > /dev/null
sudo chmod 4755 /usr/lib/qemu/qemu-bridge-helper


#Enable Host Routing, NAT
sudo sysctl -w net.ipv4.ip_forward=1
sudo iptables -t nat -F
sudo iptables -t nat -A POSTROUTING -o <your_host_internet_card> -j MASQUERADE
sudo iptables -F FORWARD
sudo iptables -A FORWARD -j ACCEPT




# Start Virtual WAN DHCP Engine
sudo dnsmasq --interface=br-wan-test \
             --dhcp-range=<START_IP>,<END_IP>,<SUBNET_MASK>,12h \
             --dhcp-option=option:router,<GATEWAY_IP> \
             --dhcp-option=option:dns-server,8.8.8.8 \
             --port=0 &


ex:
sudo dnsmasq --interface=br-wan-test \
             --dhcp-range=192.168.50.10,192.168.50.50,255.255.255.0,12h \
             --dhcp-option=option:router,192.168.50.1 \
             --dhcp-option=option:dns-server,8.8.8.8 \
             --port=0 &


# It can be helpful to create a snapshot to quickly revert
# any changes that are made
qemu-img create -f qcow2 -b rdk-generic-broadband-image-armefi64-rdk-broadband.wic.qcow2 -F qcow2 rdk.snapshot.qcow2

# And resize that snapshot to allow space for upgrades
qemu-img resize rdk.snapshot.qcow2 10G
DISK=${DISK:-rdk.snapshot.qcow2}

# Boot

The generated disk (wic) images are intended for block storage devices, for example, eMMC, SD cards, USB or NVMe storage devices, or emulated types such as virtio-blk.

A production device may use flash (NOR or NAND) devices for storing the system level firmware.

Additional files like Image (Linux kernel Image file), linuxaa64.efi.stub (Kernel EFI stub), systemd-bootaa64.efi (systemd-boot executable) and u-boot-initial-env-armefi64-rdk-broadband (U-Boot "Factory" environment) are also generated by the Yocto build process. These are not needed for normal development and deployment activities.

It is intended that the rdk-generic-broadband-image-armefi64-rdk-broadband.wic is a universal operating system image that will boot on as many real and virtual machines as possible.

(For example, you can write the .wic file onto a USB drive, and move the USB drive between different boards without making any changes)

Where possible, the same Linux kernel, firmware (U-Boot) and other relevant component versions will be used, with a strong preference for "mainline" versions.

Configuring multiconfig for multiple target builds

It is possible to use BitBake's "multiconfig" feature to setup the same build folder for multiple targets at once.

Doing so will save you time and disk space, as most packages between machines defined in this layer are shared.

If you specify MACHINE=all, the setup-environment script will do the necessary setup:

$ MACHINE="all" source meta-rdk-bsp-arm/setup-environment

...

Code Block
$ bitbake mc:generic:rdk-generic-broadband-image && \
  bitbake mc:raspberrypi:rdk-generic-broadband-image && \
  bitbake mc:armqemu:rdk-generic-broadband-image
(Due to the way RDK-B components are built, it is not possible to do a "parallel" build for two targets at once, however, you will still save a significant amount of time and disk space by using multiconfig builds sequentially)

Build images for each target will be available in tmp/deploy:

$ ls build-armefi64-rdk-broadband/tmp/deploy/images/
armefi64-rdk-broadband
raspberrypi64-rdk-broadband
armefi64-qemu-broadband.

Running the generated image on QEMU

Direct QEMU invocation

You can use the generated wic.qcow2 and u-boot.bin to invoke QEMU directly. This allows you to customize your QEMU setup for your own environment and requirements.

On virtualization capable Arm64 hosts you can use KVM for near-native performance.

You can invoke QEMU like this:

Code Block
titleQEMU invocation
# Copy the QCOW2 image and u-boot.bin from the deploy directory
cp $HOME/rdkb-cmf-arm/build-armefi64-rdk-broadband/tmp/deploy/images/armefi64-rdk-broadband/{rdk-generic-broadband-image-armefi64-rdk-broadband.wic.qcow2,u-boot.bin} .

# It can be helpful to create a snapshot to quickly revert
# any changes that are made
qemu-img create -f qcow2 -b rdk-generic-broadband-image-armefi64-rdk-broadband.wic.qcow2 -F qcow2 rdk.snapshot.qcow2
# And resize that snapshot to allow space for upgrades
qemu-img resize rdk.snapshot.qcow2 10G

DISK=${DISK:-rdk.snapshot.qcow2}
sudo qemu-system-aarch64 -nographic \
    -cpu cortex-a53 -machine virt \
    -bios u-boot.bin \
    -smp 2 -m 1024 \
    -device virtio-rng-pci \
    -hda "${DISK}" \
    -netdev tap,id=testlan -net nic,netdev=testlan \
    -netdev tap,id=testlan2 -net nic,netdev=testlan2 \
    -netdev user,id=testwan -net nic,netdev=testwan \
    -device pci-serial
#using bridge manager:
# ensure /usr/local/libexec/qemu-bridge-helper is present and executable
# provide /usr/local/etc/qemu/bridge.conf:
#     allow br10
#     allow br100

sudo qemu-system-aarch64 -nographic \
    -cpu cortex-a53 -machine virt \
    -bios u-boot.bin  \
    -smp 2 -m 1024  \
    -device virtio-rng-pci  \
    -hda "${DISK}"  \
    -netdev bridge,id=testwan,br=br10br-wan-test \
    -device virtio-net -pci,netdev=testwan,mac=52:54:00:2d:6e:99  \
    -netdev bridge,id=testlan,br=br100br-lan-test \
    -device virtio-net-pci,netdev=testlan,mac=52:54:00:2d:6e:98  \
    -device pci-serial

...

This section provides a summary of patches maintained for the ARM platform under meta-rdk-bsp-arm metalayer.

Component Name No
. of Patches
. of Patches        Status        PR If ANYCorrespond meta layer changes
test-and-diagnostic1

     Ready for testing

https://github.com/rdkcentral/test-and-diagnostic/pull/203
1

utopia12      Ready for testinghttps://github.com/rdkcentral/utopia/pull/312
rdk-wifi-hal
4
4     FROZENhttps://github.com/rdkcentral/rdk-wifi-hal/pull/701
ccsp-common-library9     Ready for testing

https://github.com/rdkcentral/common-library/pull/65



ccsp-eth-agent4
ccsp-one-wifi2unified-wifi-mesh1ccsp-p-and-m3ccsp-dhcp-mgr1linux-backports_6.63linux-yocto-5.155parodus1recipes-devtools10

Features working in ARM system ready build

...

Y

...

Y

...

N

...

Y

...

Y

...

in latest builds, its not working.

...

N

...

N

...

Y

...

in latest builds, its not working(NXP).

     Ready for testinghttps://github.com/rdkcentral/ethernet-agent/pull/64
ccsp-one-wifi2     Ready for testingNA
unified-wifi-mesh1    yet to

ccsp-p-and-m3    Ready for testingNA
ccsp-dhcp-mgr1    Ready for testingNA

ARM Platform – Feature Implementation Status

...

IPv6

...

Y

...

Y

...

Cellular

...

N

...

RNDIS

...

WebPA

...

USP-PA(oktopus)

...

USB Detection

...

Parental Control

...

Port Forwarding

...

Log-Upload & Telemetry

...

DAC

...

Log-Rotation

ARM Platform – Feature Implementation Status

S.NoFeaturesCompletedIn Review In ProgressNot started1IPv6

        check mark button 

2Cellular       
S.NoFeaturesCompletedIn Review In ProgressNot started

Features working in ARM system ready builds

     Comments
     Qemu Raspberry pi 4   NXP
1WANcheck mark button 


 YesYesYes
2LAN check mark button 


YesYesYes
3WiFicheck mark button 


NoYes
4IPv6check mark button 



Yes

Yes


5Cellular
check mark button                  
3


No

Yes

Sim is on enabling state in RPI always.

 6RNDIS
        
check mark button                           

Yes

4

Yes


 7WebPA
        check mark button5
check mark button 



Yes

Yes


 8
USP-PA(oktopus)
     
check mark button 
check mark button

         
6


Yes

Yes

Observing delay in DMCLI responce in RPI.

 9Parental Control
     
check mark button 
check mark button

                   
7

Yes

Yes


 10Port Forwarding
        check mark button8
check mark button 



Yes

Yes


 11Port Triggering
        check mark button
check mark button 



Yes

Yes


 12USB Detection
        check mark button10
check mark button 



Yes

Yes


 13DAC
 

check mark button 
  check mark button
        

Yes

11

Yes


 14
 Log-Upload & Telemetry
   

check mark button 
check mark button
         

Yes

Yes

12


 15
Multiprofile

check mark button 
    check mark button

      

Yes

Yes

13


 16
Selfheal
     



check mark button 
check mark button
14




17 Test and Diagnostic
 



check mark button 
   check mark button
15




 18
Log-Rotation

check mark button 
    check mark button       16



YesYes
 19RFC
     



check mark button 
check mark button
17




 20
Telco-Voice



check mark button 
     check mark button
18




 21WPS
     



check mark button 
check mark button
19




 22
WebConfig

check mark button 
    check mark button       20



yesyes
 23ACS
     



check mark button 
check mark button
21




 24SNMP


check mark button 
     check mark button
22




 25
Firmware Upgrade
     



check mark button 
check mark button
23




 26
eSDK
 



check mark button 
   check mark button
24




 27
Populate-SDK
     



check mark button 
check mark button




Note:
This list represents features that are either not yet supported or require additional integration and validation on the ARM platform.

...

  1. On RPI (ARM) platform, WiFi interfaces are not created/visible.
  2. Unable to connect clients on ARM Qemu
  3. .
  4. Cellular feature support on RPI (ARM).
  5. On RPI (ARM) delay on the DM's response.

...