RDK Resources
[*RDK Preferred*]
Code Management Facility
RDK Forums
[RDK Conferences]
RDK Support
Archives
Papers & Presentations Archive
This Page is under Development
The Broadcom VideoCore 4 (present in the Raspberry Pi) contains a OpenGL ES 2.0-compatible 3D engine called V3D, and a highly configurable display output pipeline that supports HDMI, DSI, DPI, and Composite TV output. The 3D engine also has an interface for submitting arbitrary compute shader-style jobs using the same shader processor as is used for vertex and fragment shaders in GLES 2.0. Closed source graphics stack runs on VC4 GPU and talks to V3D and display component. Vc4 uses mesa instead of userland for graphics. Mesa is an open source software implementation of OpenGl, Vulkan and other graphics API specification. Mesa translates these specifications to vendor specific graphics hardware drivers.
Current RPI structure uses userland to send OpenGL commands to GPU/VPU through VCHIQ. One of the major drawback of current approach is OpenMax IL for 64 bit is not officially supported. VCHIQ also needs changes for supporting 64 bit architecture.
The build procedure is as follows:
|
---|
Image is flashed to SD card before inserting to RPI board.
Command to flash the image
Generated image has to be flashed to an SD card using this command in local PC:
$ sudo dd if=<path to ImageName.rpi-sdimg> of=<path to SD card space> bs=4M
Ex: $ sudo dd if=rdk-generic-hybrid-thunder-image_default_20200302130659.rootfs.rpi-sdimg of=/dev/sdc bs=4M |
---|
The SD card is then inserted to the Raspberry Pi board and booted to check for containers created. The Raspberry Pi board is connected to the PC via a USB to serial converter and the logs can be checked in console or can be connected via HDMI cable to a TV and logs will be shown in the terminal
Describe the specific system function or feature in detail and depict graphically by including screen prints and descriptive narrative as appropriate. Ensure each screen print is captioned and has an associated tag providing appropriate alternative text
Follow the above for sub feature / use cases
<Identify the error messages that a user may receive and the likely cause(s) and/or possible corrective actions for the error>
<If applicable, describe any special circumstances, actions, exceptions, etc., that should be considered for troubleshooting.>