ProventusNova DeveloperWiki - User contributions [en]

Linux RAM Layout Visualizer Script

2026-02-20T16:22:03Z

Andres:

__TOC__

== Overview ==
'''mempix''' is a lightweight bash utility designed to visualize physical memory allocation and real-time occupancy. It maps the data from <code>/proc/iomem</code> and correlates it with global memory statistics from <code>/proc/meminfo</code> to provide a per-block visual "pixel map."

It is specifically optimized for both '''embedded Yocto environments''' (like the MediaTek Genio 720) and '''standard Desktop Linux''' (Ubuntu/Debian).

== Features ==
* '''Visual Occupancy:''' A 12-character progress bar showing used vs. free space within each RAM block.
* '''Threshold Marker:''' A red marker (|) indicating the exact transition point between used and free memory.
* '''Unit Intelligence:''' Automatically scales between KB, MB, and GB based on block size.
* '''Hardware Mapping:''' Identifies non-RAM regions (PCIe, GPU, Reserved) that are "locked" by hardware.
* '''Universal Compatibility:''' Uses POSIX-compliant math and standard escape codes for serial consoles.

== Map Legend ==
{| class="wikitable"
! Symbol !! Color !! Meaning
|-
| <code>###</code> || Green || '''Used System RAM''': Memory currently occupied by the kernel or processes.
|-
| <code>---</code> || Cyan || '''Free System RAM''': Available memory within that physical address range.
|-
| <code>|</code> || Red || '''Occupancy Marker''': The specific boundary of current memory pressure.
|-
| <code>...</code> || Red || '''Reserved/IO''': Non-system RAM (MMIO, GPU, Reserved by Firmware).
|}

== Usage ==
=== Standard Run ===
On Yocto (root), run directly. On Ubuntu, use sudo:
<pre>
sudo ./mempix.sh
</pre>

=== Real-time Monitoring ===
To watch memory blocks change live as processes open/close:
<pre>
watch -c sudo ./mempix.sh
</pre>

== Source Code ==
Save the following code as <code>mempix.sh</code>:

<syntaxhighlight lang="bash" line>
#!/bin/bash

IOMEM="/proc/iomem"
MEMINFO="/proc/meminfo"

# --- PERMISSION CHECK ---
# Try to actually read one line. If empty, the kernel is masking the data.
CHECK_READ=$(head -n 1 "$IOMEM" 2>/dev/null)
if [ -z "$CHECK_READ" ]; then
echo -e "\033[31mError: Cannot read physical addresses from $IOMEM.\033[0m"
echo "If on Ubuntu, you must run this script with sudo."
exit 1
fi

# 1. Get Global Stats
T_MEM_KB=$(grep MemTotal "$MEMINFO" | awk '{print $2}')
F_MEM_KB=$(grep MemFree "$MEMINFO" | awk '{print $2}')
OCC_RATIO=$(awk "BEGIN {print 1 - ($F_MEM_KB/$T_MEM_KB)}")
FREE_RATIO=$(awk "BEGIN {print $F_MEM_KB/$T_MEM_KB}")

format_matched() {
local val_mb="$1"
local target_unit="$2"
local is_small=$(awk "BEGIN {if ($val_mb < 0.1) print 1; else print 0}")
if [ "$is_small" -eq 1 ]; then
awk "BEGIN {printf \"%.1f KB\", $val_mb * 1024}"
elif [ "$target_unit" == "GB" ]; then
awk "BEGIN {printf \"%.2f GB\", $val_mb / 1024}"
else
awk "BEGIN {printf \"%.1f MB\", $val_mb}"
fi
}

# --- LEGEND ---
echo -e "\033[1mMAP LEGEND:\033[0m"
echo -e "\033[32m###\033[0m : Used System RAM \033[1;31m|\033[0m : Occupancy Marker"
echo -e "\033[36m---\033[0m : Free System RAM \033[31m...\033[0m : Reserved/Hardware/IO"
echo ""

echo -e "\033[1mPHYSICAL BLOCK ANALYSIS\033[0m"
printf "%-12s | %-12s | %-18s | %-12s | %s\n" "ADDRESS" "PIXEL MAP" "FREE (MATCHED)" "TOTAL SIZE" "LABEL"
echo "---------------------------------------------------------------------------------------------------"

# Clean input and iterate
grep -E "System RAM|Kernel|reserved|pcie|gpu" "$IOMEM" | sed 's/^[ ]*//' | while read -r line; do
ADDR=$(echo "$line" | cut -d' ' -f1)
LABEL=$(echo "$line" | cut -d':' -f2- | xargs)
S_HEX=$(echo "$ADDR" | cut -d'-' -f1)
E_HEX=$(echo "$ADDR" | cut -d'-' -f2)

# Validate Hex
if [[ ! $S_HEX =~ ^[0-9a-fA-F]+$ ]]; then continue; fi

S_DEC=$(printf "%d" "0x$S_HEX" 2>/dev/null)
E_DEC=$(printf "%d" "0x$E_HEX" 2>/dev/null)
SIZE_MB=$(awk "BEGIN {print ($E_DEC - $S_DEC + 1) / 1048576}")

UNIT="MB"; [ $(awk "BEGIN {if ($SIZE_MB >= 1024) print 1; else print 0}") -eq 1 ] && UNIT="GB"

if [[ "$LABEL" == "System RAM" ]]; then
FREE_MB=$(awk "BEGIN {print $SIZE_MB * $FREE_RATIO}")
P_FREE=$(awk "BEGIN {printf \"%.1f%%\", $FREE_RATIO * 100}")
U_CH=$(awk "BEGIN {val = 12 * $OCC_RATIO; printf \"%.0f\", (val<1 && val>0)?1:val}")
[ "$U_CH" -gt 12 ] && U_CH=12
F_CH=$((12 - U_CH))

if [ "$U_CH" -gt 0 ]; then
BAR_USED=$(printf "%$((U_CH-1))s" | tr ' ' '#')
MARKER="\033[1;31m|\033[0m"
BAR_FREE=$(printf "%${F_CH}s" | tr ' ' '-')
PIX="\033[32m${BAR_USED}${MARKER}\033[36m${BAR_FREE}\033[0m"
else
PIX="\033[36m------------\033[0m"
fi
STR_FREE=$(format_matched "$FREE_MB" "$UNIT")
STR_TOTAL=$(format_matched "$SIZE_MB" "$UNIT")
else
PIX="\033[31m............\033[0m"
P_FREE="0.0%"
STR_FREE=$(format_matched 0 "$UNIT")
STR_TOTAL=$(format_matched "$SIZE_MB" "$UNIT")
fi

printf "0x%08s | %b | %-18s | %-12s | %s\n" "$S_HEX" "$PIX" "$P_FREE ($STR_FREE)" "$STR_TOTAL" "$LABEL"
done
</syntaxhighlight>

== Troubleshooting ==
=== Error: Cannot read physical addresses ===
If you see this error, it means the Kernel is masking <code>/proc/iomem</code> for security.
* '''Desktop:''' Ensure you are using <code>sudo</code>.
* '''Embedded:''' Ensure you are logged in as a user with root privileges.

{{Footer}}

[[Category:Tools]]
[[Category:Linux Kernel]]
[[Category:Debugging]]

Linux RAM Layout Visualizer Script

2026-02-20T16:21:22Z

Andres:

__TOC__

== Overview ==
'''mempix''' is a lightweight bash utility designed to visualize physical memory allocation and real-time occupancy. It maps the data from <code>/proc/iomem</code> and correlates it with global memory statistics from <code>/proc/meminfo</code> to provide a per-block visual "pixel map."

It is specifically optimized for both '''embedded Yocto environments''' (like the MediaTek Genio 720) and '''standard Desktop Linux''' (Ubuntu/Debian).

== Features ==
* '''Visual Occupancy:''' A 12-character progress bar showing used vs. free space within each RAM block.
* '''Threshold Marker:''' A red marker (|) indicating the exact transition point between used and free memory.
* '''Unit Intelligence:''' Automatically scales between KB, MB, and GB based on block size.
* '''Hardware Mapping:''' Identifies non-RAM regions (PCIe, GPU, Reserved) that are "locked" by hardware.
* '''Universal Compatibility:''' Uses POSIX-compliant math and standard escape codes for serial consoles.

== Map Legend ==
{| class="wikitable"
! Symbol !! Color !! Meaning
|-
| <code>###</code> || Green || '''Used System RAM''': Memory currently occupied by the kernel or processes.
|-
| <code>---</code> || Cyan || '''Free System RAM''': Available memory within that physical address range.
|-
| <code>|</code> || Red || '''Occupancy Marker''': The specific boundary of current memory pressure.
|-
| <code>...</code> || Red || '''Reserved/IO''': Non-system RAM (MMIO, GPU, Reserved by Firmware).
|}

== Usage ==
=== Standard Run ===
On Yocto (root), run directly. On Ubuntu, use sudo:
<pre>
sudo ./mempix.sh
</pre>

=== Real-time Monitoring ===
To watch memory blocks change live as processes open/close:
<pre>
watch -c sudo ./mempix.sh
</pre>

== Source Code ==
Save the following code as <code>mempix.sh</code>:

<syntaxhighlight lang="bash" line>
#!/bin/bash

IOMEM="/proc/iomem"
MEMINFO="/proc/meminfo"

# --- PERMISSION CHECK ---
# Try to actually read one line. If empty, the kernel is masking the data.
CHECK_READ=$(head -n 1 "$IOMEM" 2>/dev/null)
if [ -z "$CHECK_READ" ]; then
echo -e "\033[31mError: Cannot read physical addresses from $IOMEM.\033[0m"
echo "If on Ubuntu, you must run this script with sudo."
exit 1
fi

# 1. Get Global Stats
T_MEM_KB=$(grep MemTotal "$MEMINFO" | awk '{print $2}')
F_MEM_KB=$(grep MemFree "$MEMINFO" | awk '{print $2}')
OCC_RATIO=$(awk "BEGIN {print 1 - ($F_MEM_KB/$T_MEM_KB)}")
FREE_RATIO=$(awk "BEGIN {print $F_MEM_KB/$T_MEM_KB}")

format_matched() {
local val_mb="$1"
local target_unit="$2"
local is_small=$(awk "BEGIN {if ($val_mb < 0.1) print 1; else print 0}")
if [ "$is_small" -eq 1 ]; then
awk "BEGIN {printf \"%.1f KB\", $val_mb * 1024}"
elif [ "$target_unit" == "GB" ]; then
awk "BEGIN {printf \"%.2f GB\", $val_mb / 1024}"
else
awk "BEGIN {printf \"%.1f MB\", $val_mb}"
fi
}

# --- LEGEND ---
echo -e "\033[1mMAP LEGEND:\033[0m"
echo -e "\033[32m###\033[0m : Used System RAM \033[1;31m|\033[0m : Occupancy Marker"
echo -e "\033[36m---\033[0m : Free System RAM \033[31m...\033[0m : Reserved/Hardware/IO"
echo ""

echo -e "\033[1mPHYSICAL BLOCK ANALYSIS\033[0m"
printf "%-12s | %-12s | %-18s | %-12s | %s\n" "ADDRESS" "PIXEL MAP" "FREE (MATCHED)" "TOTAL SIZE" "LABEL"
echo "---------------------------------------------------------------------------------------------------"

# Clean input and iterate
grep -E "System RAM|Kernel|reserved|pcie|gpu" "$IOMEM" | sed 's/^[ ]*//' | while read -r line; do
ADDR=$(echo "$line" | cut -d' ' -f1)
LABEL=$(echo "$line" | cut -d':' -f2- | xargs)
S_HEX=$(echo "$ADDR" | cut -d'-' -f1)
E_HEX=$(echo "$ADDR" | cut -d'-' -f2)

# Validate Hex
if [[ ! $S_HEX =~ ^[0-9a-fA-F]+$ ]]; then continue; fi

S_DEC=$(printf "%d" "0x$S_HEX" 2>/dev/null)
E_DEC=$(printf "%d" "0x$E_HEX" 2>/dev/null)
SIZE_MB=$(awk "BEGIN {print ($E_DEC - $S_DEC + 1) / 1048576}")

UNIT="MB"; [ $(awk "BEGIN {if ($SIZE_MB >= 1024) print 1; else print 0}") -eq 1 ] && UNIT="GB"

if [[ "$LABEL" == "System RAM" ]]; then
FREE_MB=$(awk "BEGIN {print $SIZE_MB * $FREE_RATIO}")
P_FREE=$(awk "BEGIN {printf \"%.1f%%\", $FREE_RATIO * 100}")
U_CH=$(awk "BEGIN {val = 12 * $OCC_RATIO; printf \"%.0f\", (val<1 && val>0)?1:val}")
[ "$U_CH" -gt 12 ] && U_CH=12
F_CH=$((12 - U_CH))

if [ "$U_CH" -gt 0 ]; then
BAR_USED=$(printf "%$((U_CH-1))s" | tr ' ' '#')
MARKER="\033[1;31m|\033[0m"
BAR_FREE=$(printf "%${F_CH}s" | tr ' ' '-')
PIX="\033[32m${BAR_USED}${MARKER}\033[36m${BAR_FREE}\033[0m"
else
PIX="\033[36m------------\033[0m"
fi
STR_FREE=$(format_matched "$FREE_MB" "$UNIT")
STR_TOTAL=$(format_matched "$SIZE_MB" "$UNIT")
else
PIX="\033[31m............\033[0m"
P_FREE="0.0%"
STR_FREE=$(format_matched 0 "$UNIT")
STR_TOTAL=$(format_matched "$SIZE_MB" "$UNIT")
fi

printf "0x%08s | %b | %-18s | %-12s | %s\n" "$S_HEX" "$PIX" "$P_FREE ($STR_FREE)" "$STR_TOTAL" "$LABEL"
done
</syntaxhighlight>

== Troubleshooting ==
=== Error: Cannot read physical addresses ===
If you see this error, it means the Kernel is masking <code>/proc/iomem</code> for security.
* '''Desktop:''' Ensure you are using <code>sudo</code>.
* '''Embedded:''' Ensure you are logged in as a user with root privileges.

[[Category:Tools]]
[[Category:Linux Kernel]]
[[Category:Debugging]]

Linux RAM Layout Visualizer Script

2026-02-20T16:17:47Z

Andres:

__TOC__

== Overview ==
'''mempix''' is a lightweight bash utility designed to visualize physical memory allocation and real-time occupancy. It maps the data from <code>/proc/iomem</code> and correlates it with global memory statistics from <code>/proc/meminfo</code> to provide a per-block visual "pixel map."

It is specifically optimized for both '''embedded Yocto environments''' (like the MediaTek Genio 720) and '''standard Desktop Linux''' (Ubuntu/Debian).

== Features ==
* '''Visual Occupancy:''' A 12-character progress bar showing used vs. free space within each RAM block.
* '''Threshold Marker:''' A red marker (|) indicating the exact transition point between used and free memory.
* '''Unit Intelligence:''' Automatically scales between KB, MB, and GB based on block size.
* '''Hardware Mapping:''' Identifies non-RAM regions (PCIe, GPU, Reserved) that are "locked" by hardware.
* '''Universal Compatibility:''' Uses POSIX-compliant math and standard escape codes for serial consoles.

== Map Legend ==
{| class="wikitable"
! Symbol !! Color !! Meaning
|-
| <code>###</code> || Green || '''Used System RAM''': Memory currently occupied by the kernel or processes.
|-
| <code>---</code> || Cyan || '''Free System RAM''': Available memory within that physical address range.
|-
| <code>|</code> || Red || '''Occupancy Marker''': The specific boundary of current memory pressure.
|-
| <code>...</code> || Red || '''Reserved/IO''': Non-system RAM (MMIO, GPU, Reserved by Firmware).
|}

== Usage ==
=== Standard Run ===
On Yocto (root), run directly. On Ubuntu, use sudo:
<pre>
sudo ./mempix.sh
</pre>

=== Real-time Monitoring ===
To watch memory blocks change live as processes open/close:
<pre>
watch -c sudo ./mempix.sh
</pre>

== Source Code ==
Save the following code as <code>mempix.sh</code>:

<syntaxhighlight lang="bash" line>
#!/bin/bash

IOMEM="/proc/iomem"
MEMINFO="/proc/meminfo"

# --- PERMISSION CHECK ---
# Try to actually read one line. If empty, the kernel is masking the data.
CHECK_READ=$(head -n 1 "$IOMEM" 2>/dev/null)
if [ -z "$CHECK_READ" ]; then
echo -e "\033[31mError: Cannot read physical addresses from $IOMEM.\033[0m"
echo "If on Ubuntu, you must run this script with sudo."
exit 1
fi

# 1. Get Global Stats
T_MEM_KB=$(grep MemTotal "$MEMINFO" | awk '{print $2}')
F_MEM_KB=$(grep MemFree "$MEMINFO" | awk '{print $2}')
OCC_RATIO=$(awk "BEGIN {print 1 - ($F_MEM_KB/$T_MEM_KB)}")
FREE_RATIO=$(awk "BEGIN {print $F_MEM_KB/$T_MEM_KB}")

format_matched() {
local val_mb="$1"
local target_unit="$2"
local is_small=$(awk "BEGIN {if ($val_mb < 0.1) print 1; else print 0}")
if [ "$is_small" -eq 1 ]; then
awk "BEGIN {printf \"%.1f KB\", $val_mb * 1024}"
elif [ "$target_unit" == "GB" ]; then
awk "BEGIN {printf \"%.2f GB\", $val_mb / 1024}"
else
awk "BEGIN {printf \"%.1f MB\", $val_mb}"
fi
}

# --- LEGEND ---
echo -e "\033[1mMAP LEGEND:\033[0m"
echo -e "\033[32m###\033[0m : Used System RAM \033[1;31m|\033[0m : Occupancy Marker"
echo -e "\033[36m---\033[0m : Free System RAM \033[31m...\033[0m : Reserved/Hardware/IO"
echo ""

echo -e "\033[1mPHYSICAL BLOCK ANALYSIS\033[0m"
printf "%-12s | %-12s | %-18s | %-12s | %s\n" "ADDRESS" "PIXEL MAP" "FREE (MATCHED)" "TOTAL SIZE" "LABEL"
echo "---------------------------------------------------------------------------------------------------"

# Clean input and iterate
grep -E "System RAM|Kernel|reserved|pcie|gpu" "$IOMEM" | sed 's/^[ ]*//' | while read -r line; do
ADDR=$(echo "$line" | cut -d' ' -f1)
LABEL=$(echo "$line" | cut -d':' -f2- | xargs)
S_HEX=$(echo "$ADDR" | cut -d'-' -f1)
E_HEX=$(echo "$ADDR" | cut -d'-' -f2)

# Validate Hex
if [[ ! $S_HEX =~ ^[0-9a-fA-F]+$ ]]; then continue; fi

S_DEC=$(printf "%d" "0x$S_HEX" 2>/dev/null)
E_DEC=$(printf "%d" "0x$E_HEX" 2>/dev/null)
SIZE_MB=$(awk "BEGIN {print ($E_DEC - $S_DEC + 1) / 1048576}")

UNIT="MB"; [ $(awk "BEGIN {if ($SIZE_MB >= 1024) print 1; else print 0}") -eq 1 ] && UNIT="GB"

if [[ "$LABEL" == "System RAM" ]]; then
FREE_MB=$(awk "BEGIN {print $SIZE_MB * $FREE_RATIO}")
P_FREE=$(awk "BEGIN {printf \"%.1f%%\", $FREE_RATIO * 100}")
U_CH=$(awk "BEGIN {val = 12 * $OCC_RATIO; printf \"%.0f\", (val<1 && val>0)?1:val}")
[ "$U_CH" -gt 12 ] && U_CH=12
F_CH=$((12 - U_CH))

if [ "$U_CH" -gt 0 ]; then
BAR_USED=$(printf "%$((U_CH-1))s" | tr ' ' '#')
MARKER="\033[1;31m|\033[0m"
BAR_FREE=$(printf "%${F_CH}s" | tr ' ' '-')
PIX="\033[32m${BAR_USED}${MARKER}\033[36m${BAR_FREE}\033[0m"
else
PIX="\033[36m------------\033[0m"
fi
STR_FREE=$(format_matched "$FREE_MB" "$UNIT")
STR_TOTAL=$(format_matched "$SIZE_MB" "$UNIT")
else
PIX="\033[31m............\033[0m"
P_FREE="0.0%"
STR_FREE=$(format_matched 0 "$UNIT")
STR_TOTAL=$(format_matched "$SIZE_MB" "$UNIT")
fi

printf "0x%08s | %b | %-18s | %-12s | %s\n" "$S_HEX" "$PIX" "$P_FREE ($STR_FREE)" "$STR_TOTAL" "$LABEL"
done
</syntaxhighlight>

== Troubleshooting ==
=== Error: Cannot read physical addresses ===
If you see this error, it means the Kernel is masking <code>/proc/iomem</code> for security.
* '''Desktop:''' Ensure you are using <code>sudo</code>.
* '''Embedded:''' Ensure you are logged in as a user with root privileges.

[[Category:Tools]]
[[Category:Linux Kernel]]
[[Category:Debugging]]

Linux RAM Layout Visualizer Script

2026-02-20T16:15:28Z

Andres: Created page with "__TOC__ == Overview == '''mempix''' is a lightweight bash utility designed to visualize physical memory allocation and real-time occupancy. It maps the data from {{Code|/proc/iomem}} and correlates it with global memory statistics from {{Code|/proc/meminfo}} to provide a per-block visual "pixel map." It is specifically optimized for both '''embedded Yocto environments''' (like the MediaTek Genio 720) and '''standard Desktop Linux''' (Ubuntu/Debian). == Features == * '..."

__TOC__

== Overview ==
'''mempix''' is a lightweight bash utility designed to visualize physical memory allocation and real-time occupancy. It maps the data from {{Code|/proc/iomem}} and correlates it with global memory statistics from {{Code|/proc/meminfo}} to provide a per-block visual "pixel map."

It is specifically optimized for both '''embedded Yocto environments''' (like the MediaTek Genio 720) and '''standard Desktop Linux''' (Ubuntu/Debian).

== Features ==
* '''Visual Occupancy:''' A 12-character progress bar showing used vs. free space within each RAM block.
* '''Threshold Marker:''' A red marker ({{Color|red||}}) indicating the exact transition point between used and free memory.
* '''Unit Intelligence:''' Automatically scales between KB, MB, and GB based on block size.
* '''Hardware Mapping:''' Identifies non-RAM regions (PCIe, GPU, Reserved) that are "locked" by hardware.
* '''Universal Compatibility:''' Uses POSIX-compliant math and standard escape codes for serial consoles.

== Map Legend ==
{| class="wikitable"
! Symbol !! Color !! Meaning
|-
| {{Code|###}} || {{Color|green|Green}} || '''Used System RAM''': Memory currently occupied by the kernel or processes.
|-
| {{Code|---}} || {{Color|cyan|Cyan}} || '''Free System RAM''': Available memory within that physical address range.
|-
| {{Code||}} || {{Color|red|Red}} || '''Occupancy Marker''': The specific boundary of current memory pressure.
|-
| {{Code|...}} || {{Color|red|Red}} || '''Reserved/IO''': Non-system RAM (MMIO, GPU, Reserved by Firmware).
|}

== Usage ==
=== Standard Run ===
On Yocto (root), run directly. On Ubuntu, use sudo:
<pre>
sudo ./mempix.sh
</pre>

=== Real-time Monitoring ===
To watch memory blocks change live as processes open/close:
<pre>
watch -c sudo ./mempix.sh
</pre>

== Source Code ==
Save the following code as {{Code|mempix.sh}}:

<syntaxhighlight lang="bash" line>
#!/bin/bash

IOMEM="/proc/iomem"
MEMINFO="/proc/meminfo"

# --- PERMISSION CHECK ---
# Try to actually read one line. If empty, the kernel is masking the data.
CHECK_READ=$(head -n 1 "$IOMEM" 2>/dev/null)
if [ -z "$CHECK_READ" ]; then
echo -e "\033[31mError: Cannot read physical addresses from $IOMEM.\033[0m"
echo "If on Ubuntu, you must run this script with sudo."
exit 1
fi

# 1. Get Global Stats
T_MEM_KB=$(grep MemTotal "$MEMINFO" | awk '{print $2}')
F_MEM_KB=$(grep MemFree "$MEMINFO" | awk '{print $2}')
OCC_RATIO=$(awk "BEGIN {print 1 - ($F_MEM_KB/$T_MEM_KB)}")
FREE_RATIO=$(awk "BEGIN {print $F_MEM_KB/$T_MEM_KB}")

format_matched() {
local val_mb="$1"
local target_unit="$2"
local is_small=$(awk "BEGIN {if ($val_mb < 0.1) print 1; else print 0}")
if [ "$is_small" -eq 1 ]; then
awk "BEGIN {printf \"%.1f KB\", $val_mb * 1024}"
elif [ "$target_unit" == "GB" ]; then
awk "BEGIN {printf \"%.2f GB\", $val_mb / 1024}"
else
awk "BEGIN {printf \"%.1f MB\", $val_mb}"
fi
}

# --- LEGEND ---
echo -e "\033[1mMAP LEGEND:\033[0m"
echo -e "\033[32m###\033[0m : Used System RAM \033[1;31m|\033[0m : Occupancy Marker"
echo -e "\033[36m---\033[0m : Free System RAM \033[31m...\033[0m : Reserved/Hardware/IO"
echo ""

echo -e "\033[1mPHYSICAL BLOCK ANALYSIS\033[0m"
printf "%-12s | %-12s | %-18s | %-12s | %s\n" "ADDRESS" "PIXEL MAP" "FREE (MATCHED)" "TOTAL SIZE" "LABEL"
echo "---------------------------------------------------------------------------------------------------"

# Clean input and iterate
grep -E "System RAM|Kernel|reserved|pcie|gpu" "$IOMEM" | sed 's/^[ ]*//' | while read -r line; do
ADDR=$(echo "$line" | cut -d' ' -f1)
LABEL=$(echo "$line" | cut -d':' -f2- | xargs)
S_HEX=$(echo "$ADDR" | cut -d'-' -f1)
E_HEX=$(echo "$ADDR" | cut -d'-' -f2)

# Validate Hex
if [[ ! $S_HEX =~ ^[0-9a-fA-F]+$ ]]; then continue; fi

S_DEC=$(printf "%d" "0x$S_HEX" 2>/dev/null)
E_DEC=$(printf "%d" "0x$E_HEX" 2>/dev/null)
SIZE_MB=$(awk "BEGIN {print ($E_DEC - $S_DEC + 1) / 1048576}")

UNIT="MB"; [ $(awk "BEGIN {if ($SIZE_MB >= 1024) print 1; else print 0}") -eq 1 ] && UNIT="GB"

if [[ "$LABEL" == "System RAM" ]]; then
FREE_MB=$(awk "BEGIN {print $SIZE_MB * $FREE_RATIO}")
P_FREE=$(awk "BEGIN {printf \"%.1f%%\", $FREE_RATIO * 100}")
U_CH=$(awk "BEGIN {val = 12 * $OCC_RATIO; printf \"%.0f\", (val<1 && val>0)?1:val}")
[ "$U_CH" -gt 12 ] && U_CH=12
F_CH=$((12 - U_CH))

if [ "$U_CH" -gt 0 ]; then
BAR_USED=$(printf "%$((U_CH-1))s" | tr ' ' '#')
MARKER="\033[1;31m|\033[0m"
BAR_FREE=$(printf "%${F_CH}s" | tr ' ' '-')
PIX="\033[32m${BAR_USED}${MARKER}\033[36m${BAR_FREE}\033[0m"
else
PIX="\033[36m------------\033[0m"
fi
STR_FREE=$(format_matched "$FREE_MB" "$UNIT")
STR_TOTAL=$(format_matched "$SIZE_MB" "$UNIT")
else
PIX="\033[31m............\033[0m"
P_FREE="0.0%"
STR_FREE=$(format_matched 0 "$UNIT")
STR_TOTAL=$(format_matched "$SIZE_MB" "$UNIT")
fi

printf "0x%08s | %b | %-18s | %-12s | %s\n" "$S_HEX" "$PIX" "$P_FREE ($STR_FREE)" "$STR_TOTAL" "$LABEL"
done
</syntaxhighlight>

== Troubleshooting ==
=== Error: Cannot read physical addresses ===
If you see this error, it means the Kernel is masking {{Code|/proc/iomem}} for security.
* '''Desktop:''' Ensure you are using {{Code|sudo}}.
* '''Embedded:''' Ensure you are logged in as a user with root privileges.

[[Category:Tools]]
[[Category:Linux Kernel]]
[[Category:Debugging]]

Template:Footer

2026-02-05T18:26:58Z

Andres: /* Need Further Support? */

= Need Further Support? =

'''📞 Book Consultation Call:''' [https://proventusnova.com/#home-contact Show Calendar!]

'''📩 Contact Via Email:''' [mailto:support@proventusnova.com support@proventusnova.com]

'''🌐 Visit Our Website:''' [https://proventusnova.com ProventusNova.com]

Get started with PDDL on NVIDIA Jetson

2026-02-05T00:31:41Z

Andres: Created page with "__TOC__ == Project Overview: Symbolic AI Planning on NVIDIA Jetson == This project demonstrates the implementation of '''Symbolic AI Planning''' on an NVIDIA Jetson (ARM64) using '''PDDL''' (Planning Domain Definition Language). Unlike traditional machine learning, this approach focuses on deterministic logic and reasoning to solve complex multi-step tasks. === 🛠️ Environment Setup === Because the Jetson uses an ARM64 architecture, traditional x86 planners (like..."

__TOC__

== Project Overview: Symbolic AI Planning on NVIDIA Jetson ==

This project demonstrates the implementation of '''Symbolic AI Planning''' on an NVIDIA Jetson (ARM64) using '''PDDL''' (Planning Domain Definition Language). Unlike traditional machine learning, this approach focuses on deterministic logic and reasoning to solve complex multi-step tasks.

=== 🛠️ Environment Setup ===
Because the Jetson uses an ARM64 architecture, traditional x86 planners (like those found in planutils) often fail. We utilize a native Python approach for maximum compatibility.

* '''Hardware:''' NVIDIA Jetson (Nano/Xavier/Orin)
* '''OS:''' Ubuntu 20.04/22.04 LTS
* '''Language:''' Python 3.10+
* '''Library:''' [https://github.com/aibasel/pyperplan Pyperplan] (Pure Python PDDL Planner)

==== Installation ====
<syntaxhighlight lang="bash">
# Install the planner
pip install pyperplan
</syntaxhighlight>

---

== 📋 The Logistics Domain ==
The domain defines the "physics" of our world. We use `:typing` to categorize objects for the planner.

=== Domain Code (logistics_domain.pddl) ===
<syntaxhighlight lang="pddl">
(define (domain logistics)
(:requirements :strips :typing)

(:types location truck package)

(:predicates
(at ?obj ?loc)
(in ?p ?t)
)

(:action drive
:parameters (?t - truck ?from - location ?to - location)
:precondition (and (at ?t ?from))
:effect (and (at ?t ?to) (not (at ?t ?from)))
)

(:action load
:parameters (?p - package ?t - truck ?l - location)
:precondition (and (at ?p ?l) (at ?t ?l))
:effect (and (in ?p ?t) (not (at ?p ?l)))
)

(:action unload
:parameters (?p - package ?t - truck ?l - location)
:precondition (and (in ?p ?t) (at ?t ?l))
:effect (and (at ?p ?l) (not (in ?p ?t)))
)
)
</syntaxhighlight>

---

== 📍 The Problem Definition ==
The problem defines the specific starting state and the desired goal.

=== Problem Code (logistics_problem.pddl) ===
<syntaxhighlight lang="pddl">
(define (problem delivery-task)
(:domain logistics)

(:objects
warehouse hospital post_office - location
truck1 - truck
meds food - package
)

(:init
(at truck1 warehouse)
(at meds warehouse)
(at food warehouse)
)

(:goal (and
(at meds hospital)
(at food post_office)
))
)
</syntaxhighlight>

---

== 🚀 Execution & Results ==
Run the following command in the Jetson terminal:

<syntaxhighlight lang="bash">
pyperplan logistics_domain.pddl logistics_problem.pddl
</syntaxhighlight>

=== Expected Output ===
The planner uses Breadth-First Search (BFS) to find the shortest path.
* '''Search Time:''' ~0.00092s
* '''Nodes Expanded:''' 42
* '''Plan Length:''' 6 steps

The generated plan is saved to <code>logistics_problem.pddl.soln</code>.

---

== ⚠️ Troubleshooting & Lessons Learned ==
* '''Architecture Conflicts:''' Avoid using <code>planutils</code> or <code>up-tamer</code> on Jetson as they rely on x86 pre-compiled binaries or Apptainer images that lack ARM64 support.
* '''Typing Requirement:''' Ensure <code>(:requirements :typing)</code> is declared in the domain if using typed objects (e.g., <code>- location</code>), otherwise, Pyperplan will throw a <code>SemanticError</code>.
* '''Validation:''' If <code>validate</code> is missing from PATH, the plan still runs but cannot be formally verified by the software.

[[Category:Robotics]] [[Category:Artificial Intelligence]] [[Category:Jetson]]

Fixing ARM Compute Library Fetch Error 24 02 Yocto

2025-11-15T01:32:05Z

Andres: Created page with "== ⚠️ Fixing Yocto Fetch Error: arm-compute-library 24.02 (Wrong Git Branch) == This page documents a specific fetch error encountered during a Yocto build when retrieving the source code for the '''ARM Compute Library''' recipe version 24.02, and provides the fix using a '''.bbappend''' file. === The Error Message === The Yocto build fails during the '''do_fetch''' task for the ''arm-compute-library-24.02'' recipe, indicating that the required commit cannot be foun..."

== ⚠️ Fixing Yocto Fetch Error: arm-compute-library 24.02 (Wrong Git Branch) ==
This page documents a specific fetch error encountered during a Yocto build when retrieving the source code for the '''ARM Compute Library''' recipe version 24.02, and provides the fix using a '''.bbappend''' file.

=== The Error Message ===
The Yocto build fails during the '''do_fetch''' task for the ''arm-compute-library-24.02'' recipe, indicating that the required commit cannot be found in the default branch:
<pre>
WARNING: arm-compute-library-24.02-r0 do_fetch: Failed to fetch URL git://github.com/ARM-software/ComputeLibrary.git;protocol=https;branch=main;name=arm-compute-library, attempting MIRRORS if available
ERROR: arm-compute-library-24.02-r0 do_fetch: Fetcher failure: Unable to find revision bc89a0b690200750040770bda0981f4a37b389c4 in branch main even from upstream
ERROR: arm-compute-library-24.02-r0 do_fetch: Bitbake Fetcher Error: FetchError('Unable to fetch URL from any source.', 'git://github.com/ARM-software/ComputeLibrary.git;protocol=https;branch=main;name=arm-compute-library')
</pre>

=== Root Cause Analysis ===
The specific Git commit hash (`bc89a0b690200750040770bda0981f4a37b389c4`) required by the recipe has been moved on the upstream repository. It no longer resides in the expected '''main''' branch, but has been relocated to the '''archived-releases''' branch. Consequently, the BitBake fetcher, looking only in ''main'', fails to locate the source code.

=== 💡 The Solution: Overriding the Branch with a `.bbappend` ===
The issue is resolved by creating an '''arm-compute-library_24.02.bbappend''' file in your custom meta-layer to explicitly override the default source Uniform Resource Identifier (URI) and point it to the correct Git branch.

==== Step 1: Create the `.bbappend` File ====
Place the override file within the following path structure in your custom meta-layer (e.g., in a directory named `meta-pn-mtk`):
<pre>
<YOUR_CUSTOM_META_LAYER>/recipes-armnn/arm-compute-library/arm-compute-library_24.02.bbappend
</pre>

==== Step 2: Add the Override Content ====
Populate the '''arm-compute-library_24.02.bbappend''' file with the following content. This configuration changes the source branch to '''archived-releases''' while ensuring the correct '''SRCREV''' (commit hash) is used.

<pre>
SRC_URI = "git://github.com/ARM-software/ComputeLibrary.git;protocol=https;branch=archived-releases;name=arm-compute-library \
file://0001-enable-yocto-build.patch \
file://0001-Remove-unknown-variables-treated-as-error.patch \
file://0001-Prefer-to-use-libmali-as-the-provider-of-OpenCL.patch \
file://0001-remove-clUpdateMutableCommandsKHR-reference.patch \
"

SRCREV = "bc89a0b690200750040770bda0981f4a37b389c4"
</pre>
* '''<code>SRC_URI</code>''': The URL parameter is modified to specify '''<code>branch=archived-releases</code>'''.
* '''<code>SRCREV</code>''': The exact commit hash is retained to fetch the desired version of the library.

After adding this file, BitBake will use the new branch setting, allowing the source code fetch to succeed on the next build attempt.

How to NVIDIA Jetson Orin Nano UART Console

2025-08-04T14:40:27Z

Andres: Created page with "= How to Connect to NVIDIA Jetson Orin Nano UART Console = This guide explains how to connect to the UART serial console of the NVIDIA Jetson Orin Nano Developer Kit using a TTL-to-USB adapter. This is useful for accessing boot logs, debugging early kernel messages, or interacting with the board when other interfaces are unavailable. == Requirements == * NVIDIA Jetson Orin Nano Developer Kit * TTL-to-USB Serial Adapter (e.g., based on CP2102, CH340, or FT232) * Jumper..."

= How to Connect to NVIDIA Jetson Orin Nano UART Console =

This guide explains how to connect to the UART serial console of the NVIDIA Jetson Orin Nano Developer Kit using a TTL-to-USB adapter. This is useful for accessing boot logs, debugging early kernel messages, or interacting with the board when other interfaces are unavailable.

== Requirements ==

* NVIDIA Jetson Orin Nano Developer Kit
* TTL-to-USB Serial Adapter (e.g., based on CP2102, CH340, or FT232)
* Jumper wires (Female-to-Female)
* A host computer running Linux or macOS
* Serial terminal software: '''screen''' or '''minicom'''

== NVIDIA Jetson Orin Nano UART Pinout and Wiring ==

Connect the TTL-to-USB adapter to the 40-pin GPIO header of the Jetson Orin Nano as follows:

{| class="wikitable"
|+ UART Pinout (J41 Header on Orin Nano)
! Pin Number !! Signal !! Description !! TTL Adapter Wire
|-
| 8 || UART_TX || Transmit from Jetson || Connect to RXD on adapter
|-
| 10 || UART_RX || Receive into Jetson || Connect to TXD on adapter
|-
| 14 || GND || Ground || Connect to GND on adapter
|}

== Step-by-Step Instructions ==

=== 1. Connect Hardware ===
# Power off the Jetson Orin Nano.
# Connect jumper wires as described in the table above.
# Plug the TTL-to-USB adapter into your computer.

=== 2. Identify the Serial Device ===
On your host machine, run:

<pre>
ls /dev/ttyUSB*
</pre>

You should see something like '''/dev/ttyUSB0'''. This is the serial device you'll use.

== Using screen ==

=== Install screen ===
<pre>
sudo apt update
sudo apt install screen
</pre>

=== Start Serial Console ===
Replace '''/dev/ttyUSB0''' with your actual device:

<pre>
screen /dev/ttyUSB0 115200
</pre>

To exit '''screen''', press:
<pre>
Ctrl + A, then K, then press Y to confirm
</pre>

== Using minicom ==

=== Install minicom ===
<pre>
sudo apt update
sudo apt install minicom
</pre>

=== Configure minicom ===
First, run:

<pre>
sudo minicom -s
</pre>

Navigate to **Serial port setup** and set:
* **Serial device**: `/dev/ttyUSB0`
* **Bps/Par/Bits**: `115200 8N1`
* **Hardware Flow Control**: **No**
* **Software Flow Control**: **No**

Save settings and exit.

=== Start Serial Console ===
After configuration:

<pre>
sudo minicom
</pre>

To exit '''minicom''', press:
<pre>
Ctrl + A, then X
</pre>

== Boot Log Output ==

Once connected, power on the Jetson Orin Nano. You should see U-Boot and Linux boot messages in your terminal window. This console can be used to log in if graphical access is unavailable.

== Troubleshooting ==

* Make sure your TTL-to-USB adapter is recognized by the OS ('''dmesg | grep ttyUSB''')
* Verify correct TX/RX wiring (cross them)
* Use only one terminal program at a time (minicom or screen)
* Ensure baud rate is set to '''115200'''

{{Footer}}

How to Enable OpenCL Support in OpenCV for MediaTek Yocto Platforms

2025-07-24T13:58:35Z

Andres: /* How to Enable OpenCL Support in OpenCV for MediaTek Yocto Platforms */

How to Enable OpenCL Support in OpenCV for MediaTek Yocto Platforms

2025-07-24T13:54:05Z

Andres: Created page with "= How to Enable OpenCL Support in OpenCV for MediaTek Yocto Platforms = This guide explains how to add OpenCL support to OpenCV in a Yocto-based BSP for MediaTek Genio or similar platforms by modifying the OpenCV recipe through a `.bbappend` file. == 🧠 Prerequisites == Before proceeding, make sure you have: * A working Yocto Project build setup for your MediaTek Genio or similar platform. * A custom meta-layer (e.g. <code>meta-yourlayer</code>) where you can place..."

= How to Enable OpenCL Support in OpenCV for MediaTek Yocto Platforms =

This guide explains how to add OpenCL support to OpenCV in a Yocto-based BSP for MediaTek Genio or similar platforms by modifying the OpenCV recipe through a `.bbappend` file.

== 🧠 Prerequisites ==

Before proceeding, make sure you have:
* A working Yocto Project build setup for your MediaTek Genio or similar platform.
* A custom meta-layer (e.g. <code>meta-yourlayer</code>) where you can place `.bbappend` files.
* Basic knowledge of BitBake and Yocto layer structure.

== 🧩 Step 1: Locate the Base Recipe ==

OpenCV is typically provided by `meta-openembedded`:

<syntaxhighlight lang="text">
meta-oe/recipes-support/opencv/opencv_4.5.5.bb
</syntaxhighlight>

We will extend this recipe with a `.bbappend` in your custom layer.

== 🛠️ Step 2: Create the .bbappend File ==

Create the following directory structure in your custom layer:

<syntaxhighlight lang="text">
meta-yourlayer/
└── recipes-support/
└── opencv/
└── opencv_4.5.5.bbappend
</syntaxhighlight>

== 🧾 Step 3: Enable OpenCL via PACKAGECONFIG ==

Edit <code>opencv_4.5.5.bbappend</code> and add:

<syntaxhighlight lang="bitbake">
# Enable OpenCL in OpenCV build
PACKAGECONFIG:append = " opencl"
</syntaxhighlight>

This appends <code>opencl</code> to the build configuration options, enabling OpenCL support during the CMake configuration.

== ✅ Step 4: Rebuild OpenCV ==

To apply the changes, clean and rebuild OpenCV:

<syntaxhighlight lang="bash">
bitbake -c clean opencv
bitbake opencv
</syntaxhighlight>

== 🔍 Step 5: Verify OpenCL Support ==

Once built, verify that OpenCL support is present. You can inspect OpenCV with:

<syntaxhighlight lang="bash">
ldd /usr/bin/opencv_version
</syntaxhighlight>

Or use a Python snippet:

<syntaxhighlight lang="python">
import cv2
print(cv2.ocl.haveOpenCL())
print(cv2.ocl.useOpenCL())
</syntaxhighlight>

== 🧩 Troubleshooting ==

* Ensure your platform supports OpenCL (e.g. Genio 1200 with Mali GPU).
* Confirm that OpenCL headers and runtime (e.g., <code>ocl-icd</code> or <code>libopencl</code>) are available in your image.
* If the OpenCL option is ignored, double-check that the <code>PACKAGECONFIG</code> is not being overridden elsewhere.

== 📚 References ==

* [OpenCV Official Website](https://opencv.org/)
* [Yocto Project Documentation](https://docs.yoctoproject.org/)
* [MediaTek Genio SDK](https://www.mediatek.com/iot/opensource/genio)

== 🛟 Need Help? ==

Need help integrating OpenCV and OpenCL on your custom Yocto build?

💡 Contact [ProventusNova](https://proventusnova.com/contact-us) — we help teams customize BSPs, accelerate embedded AI development, and get production-ready faster.

How to Run GStreamer in a Docker Container

2025-07-23T20:11:56Z

Andres: Created page with "= How to Run GStreamer in Docker = This tutorial shows you how to install and use '''GStreamer''' inside a '''Docker container''' on '''Ubuntu 22.04'''. We'll build a minimal Docker image with support for '''x264enc''', then run a simple test pipeline to encode video to an MP4 file. == Step 1: Create a Dockerfile with GStreamer and x264enc == Create a file named <code>Dockerfile</code> with the following contents: <syntaxhighlight lang="dockerfile"> FROM ubuntu:22.04..."

= How to Run GStreamer in Docker =

This tutorial shows you how to install and use '''GStreamer''' inside a '''Docker container''' on '''Ubuntu 22.04'''. We'll build a minimal Docker image with support for '''x264enc''', then run a simple test pipeline to encode video to an MP4 file.

== Step 1: Create a Dockerfile with GStreamer and x264enc ==

Create a file named <code>Dockerfile</code> with the following contents:

<syntaxhighlight lang="dockerfile">
FROM ubuntu:22.04

ENV DEBIAN_FRONTEND=noninteractive

# Install GStreamer with x264 support and minimal required tools
RUN apt-get update && apt-get install -y \
libgstreamer1.0-dev \
libgstreamer-plugins-base1.0-dev \
libgstreamer-plugins-bad1.0-dev \
gstreamer1.0-plugins-base \
gstreamer1.0-plugins-good \
gstreamer1.0-plugins-bad \
gstreamer1.0-plugins-ugly \
gstreamer1.0-libav \
gstreamer1.0-tools \
gstreamer1.0-x \
gstreamer1.0-alsa \
gstreamer1.0-gl \
gstreamer1.0-gtk3 \
gstreamer1.0-qt5 \
gstreamer1.0-pulseaudio \
libx264-dev \
&& rm -rf /var/lib/apt/lists/*

CMD [ "tail", "-F", "/dev/null" ]
</syntaxhighlight>

This Dockerfile installs a complete GStreamer stack along with the necessary packages to support <code>x264enc</code>, allowing you to encode H.264 video streams.

== Step 2: Build the Docker image ==

Use the following command to build the Docker image and tag it as <code>gstreamer-test</code>:

<syntaxhighlight lang="bash">
docker build -t gstreamer-test .
</syntaxhighlight>

== Step 3: Start the GStreamer container in the background ==

Run the container in detached mode and give it a name:

<syntaxhighlight lang="bash">
docker run -d --name gstreamer-test gstreamer-test
</syntaxhighlight>

== Step 4: Run a sample GStreamer pipeline inside the container ==

Use the following GStreamer command to generate a test video, encode it with x264, and save it as an MP4 file:

<syntaxhighlight lang="bash">
gst-launch-1.0 videotestsrc num-buffers=300 is-live=true ! video/x-raw,width=640,height=480,framerate=30/1 ! x264enc ! mp4mux ! filesink location=output.mp4
</syntaxhighlight>

This will create a short 10-second video called <code>output.mp4</code> using GStreamer's built-in <code>videotestsrc</code> source.

== Step 5: Exit the container ==

After the pipeline finishes, you can exit the container shell:

<syntaxhighlight lang="bash">
exit
</syntaxhighlight>

== Step 6: Copy the video output to the host system ==

Transfer the generated MP4 file from the container to your local system:

<syntaxhighlight lang="bash">
docker cp gstreamer-test:/output.mp4 ./output.mp4
</syntaxhighlight>

== Step 7: Preview the video on your host machine ==

Open <code>output.mp4</code> with any media player that supports MP4 and H.264, such as VLC or your system's default video player.

== Conclusion ==

You've successfully created a Dockerized GStreamer environment with x264 encoding support. This is useful for rapid prototyping of pipelines, isolated testing, or running GStreamer apps on systems without native installations.

For more GStreamer examples, pipeline debugging tips, or Docker use cases in embedded systems, explore our other tutorials.

{{Footer}}

Create custom Yocto meta layer for MediaTek G510 board

2025-06-25T17:23:46Z

Andres:

=Introduction=

This wiki will provide a detailed guide on how to create a custom Yocto meta-layer for a MediaTek Genio 510 board.

=Pre-requisites=
1. The host machine must have the following requirements:
*At least 90GB of space
*At least 8GB RAM
*Host OS must be a supported Linux distribution. (To see supported Linux Distributions, click [https://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions supported distributions])

2. The following packages must be present in the host machine:
<syntaxhighlight lang="bash">
apt install build-essential chrpath cpio debianutils diffstat file gawk gcc git iputils-ping libacl1 liblz4-tool locales python3 python3-git python3-jinja2 python3-pexpect python3-pip python3-subunit socat texinfo unzip wget xz-utils zstd
</syntaxhighlight>

=Create Base Meta-Layer=

This section contains steps to create the base custom meta-layer. 
Creating a layer can be done manually or automatically via bitbake. 
After completion, the custom base meta-layer will contain the following parts:

* Custom layer configuration
* Custom distro configuration
* Custom machine
* Custom config template files
* Custom image recipe

==Manually create layer==

===Step 1. Add base layer.conf file===

The layer configuration file provides Yocto with the configuration for the custom meta-layer.
It shall be stored in a directory called '''conf''' inside the base meta-layer directory, and it shall be named layer.conf.
According to the [https://docs.yoctoproject.org/dev/dev-manual/layers.html Yocto documentation] it is recommended to start from an existing layer.conf file from a different meta-layer and change it according to the custom requirements.

For instance, here is an example of how the directory structure should look after creating the layer.conf file.

<syntaxhighlight lang="bash">
meta-pn-mtk/
├── conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

An example layer.conf file based on [https://gitlab.com/mediatek/aiot/rity/meta-rity/-/blob/rity-scarthgap-v25.0/meta-rity-demo/conf/layer.conf MediaTek RITY meta-rity-demo] is shown in the following code snipped.

<syntaxhighlight lang="bash">
# We have a conf and classes directory, add to BBPATH
BBPATH .= ":${LAYERDIR}"

# We have recipes-* directories, add to BBFILES
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "pn-mtk"
BBFILE_PATTERN_pn-mtk = "^${LAYERDIR}/"
BBFILE_PRIORITY_pn-mtk = "9"

# This should only be incremented on significant changes that will
# cause compatibility issues with other layers
LAYERVERSION_pn-mtk = "1"

LAYERDEPENDS_pn-mtk = " \
core \
mediatek-bsp \
mediatek-tsn \
mediatek-bluedroid \
mediatek-demo \
multimedia-layer \
openembedded-layer \
networking-layer \
meta-python \
"

LAYERSERIES_COMPAT_pn-mtk = "scarthgap"

</syntaxhighlight>

===Step 2. Add base distro config===

In order to add the initial distro configuration, it is necessary to create distro configuration file inside the '''meta-layer/conf/distro''' directory.

Here is an example of how the directory structure should look like:

<syntaxhighlight lang="bash">
meta-pn-mtk/
├── conf
│ ├── distro
│ │ └── pn-mtk.conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

The same as with the layer.conf, it is easier to start with an existing distro configuration file and modify it in order to fit the project requirements. For example, the following corresponds to a distro configuration file based on the [https://gitlab.com/mediatek/aiot/rity/meta-rity/-/blob/rity-scarthgap-v25.0/meta-rity-demo/conf/distro/rity-demo.conf MediaTek meta-rity-demo]:

<syntaxhighlight lang="bash">
require conf/distro/rity.inc

DISTRO = "pn-mtk"
DISTRO_NAME = "PN MTK Layer"

INIT_MANAGER = "systemd"

DISTRO_FEATURES:append = " pipewire demo pam fwupdate expand-rootfs btf"
DISTRO_FEATURES_FILTER_NATIVESDK:append = " wayland"
VIRTUAL-RUNTIME_vim = "vim"

# Mount /var/log/ in persistence storage,
# so it is possible to keep journalctl logs.
VOLATILE_LOG_DIR = "0"

PACKAGECONFIG:append:pn-weston-init = " no-idle-timeout"

PACKAGE_CLASSES ?= "package_deb"
PACKAGE_FEED_URIS ?= "http://192.168.96.20:9876"
EXTRA_IMAGE_FEATURES:append = " package-management "

</syntaxhighlight>

===Step 3. Add base machine===

This step might not be required, if there is already a machine that can be used from a different meta-layer.
However, it is still recommended to create a custom machine configuration based on that machine in order to keep better order of the machine used in the custom Yocto build.

To create a custom machine, it is necessary to add a machine.conf file in the '''meta-layer/conf/machine''' directory.
For example, this is how the directory structure should look when adding a new machine to the custom meta-layer:

<syntaxhighlight lang="bash">
meta-pn-mtk/
├── conf
│ ├── distro
│ │ └── pn-mtk.conf
│ ├── layer.conf
│ └── machine
│ └── mtk-g510.conf
└── README.md
</syntaxhighlight>

And, as a reference, here is a custom machine based on [https://gitlab.com/mediatek/aiot/rity/meta-mediatek-bsp/-/blob/rity-scarthgap-v25.0/conf/machine/mt8370-evk.conf MediaTek meta-mediatek-bsp mt8370-evk.conf] machine.

<syntaxhighlight lang="bash">
require conf/machine/include/mt8370.inc
require conf/machine/include/mt7921.inc

# Kernel
KERNEL_DEVICETREE = "mediatek/mt8370-genio-510-evk.dtb"

# U-Boot
UBOOT_MACHINE = "genio_510_evk_defconfig"

# libdram
LIBDRAM_BOARD_NAME = "genio-700-evk"

# OP-TEE
OPTEE_DRAM_SIZE = "0x100000000"

# LK
LK_BOARD_NAME = "genio-510-evk"

MACHINE_FEATURES:append = " alsa bluetooth pci usbgadget usbhost wifi tsn uc-fde"

MACHINEOVERRIDES =. "mt8370-evk:genio-510-evk:"

# onsemi-firmware
ONSEMI_BOARD_NAME = "MediaTek_Genio"
MACHINE_EXTRA_RRECOMMENDS:append = " \
onsemi-firmware-ap1302-ar0430 \
onsemi-firmware-ap1302-ar0830 \
"

# Drivers for external I2C device
MACHINE_EXTRA_RRECOMMENDS:append = " \
ite-it6510-driver \
lontium-lt6911-driver \
"

</syntaxhighlight>

===Step 4. Add initial config template files===

Bitbake will require 2 configuration files for building an image:

'''bblayers.conf''': This file contains information about the location of the required meta-layers for the project.

'''local.conf''': This file contains general build configuration for bitbake. For instance, in this file it is possible to determine where to store downloads, cache and even which package management configuration to use.

Now, in order to simplify the configuration of a custom Yocto build, it is possible to include template configuration files on the custom meta-layer. This practice is encouraged in order to increase build repeatability.

These 2 files are generally created inside '''meta-layer/conf/templates/template-name'''.
For reference, this is how the directory structure would look like after the files are created:

<syntaxhighlight lang="bash">
meta-pn-mtk/
├── conf
│ ├── distro
│ │ └── pn-mtk.conf
│ ├── layer.conf
│ ├── machine
│ │ └── mtk-g510.conf
│ └── templates
│ └── default
│ ├── bblayers.conf.sample
│ └── local.conf.sample
└── README.md
</syntaxhighlight>

Here is an example of a custom bblayers.conf.sample file based on [https://gitlab.com/mediatek/aiot/rity/meta-rity/-/blob/rity-scarthgap-v25.0/meta/conf/templates/default/bblayers.conf.sample MediaTek meta-rity]:

<syntaxhighlight lang="bash">
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
##OEROOT##/meta \
##OEROOT##/meta-poky \
##OEROOT##/meta-yocto-bsp \
##OEROOT##/../meta-arm/meta-arm \
##OEROOT##/../meta-arm/meta-arm-toolchain \
##OEROOT##/../meta-clang \
##OEROOT##/../meta-mediatek-bsp \
##OEROOT##/../meta-mediatek-tsn \
##OEROOT##/../meta-mediatek-bluedroid \
##OEROOT##/../meta-mediatek-demo \
##OEROOT##/../meta-nn \
##OEROOT##/../meta-security \
##OEROOT##/../meta-openembedded/meta-multimedia \
##OEROOT##/../meta-openembedded/meta-networking \
##OEROOT##/../meta-openembedded/meta-oe \
##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-openembedded/meta-perl \
##OEROOT##/../meta-rity/meta \
##OEROOT##/../meta-rity/meta-rity-bringup \
##OEROOT##/../meta-rity/meta-rity-demo \
##OEROOT##/../../../meta-pn-mtk \
"

</syntaxhighlight>

And, this is an example of a custom local.conf.sample file based on [https://gitlab.com/mediatek/aiot/rity/meta-rity/-/blob/rity-scarthgap-v25.0/meta/conf/templates/default/local.conf.sample MediaTek meta-rity]:

<syntaxhighlight lang="bash">
# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
##OEROOT##/meta \
##OEROOT##/meta-poky \
##OEROOT##/meta-yocto-bsp \
##OEROOT##/../meta-arm/meta-arm \
##OEROOT##/../meta-arm/meta-arm-toolchain \
##OEROOT##/../meta-clang \
##OEROOT##/../meta-mediatek-bsp \
##OEROOT##/../meta-mediatek-tsn \
##OEROOT##/../meta-mediatek-bluedroid \
##OEROOT##/../meta-mediatek-demo \
##OEROOT##/../meta-nn \
##OEROOT##/../meta-security \
##OEROOT##/../meta-openembedded/meta-multimedia \
##OEROOT##/../meta-openembedded/meta-networking \
##OEROOT##/../meta-openembedded/meta-oe \
##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-openembedded/meta-perl \
##OEROOT##/../meta-rity/meta \
##OEROOT##/../meta-rity/meta-rity-bringup \
##OEROOT##/../meta-rity/meta-rity-demo \
##OEROOT##/../../../meta-pn-mtk \
"

</syntaxhighlight>

===Step 5. Add base image recipe===

In order to create a custom image, it is necessary to add a custom image recipe file.
This file is usually added inside the '''meta-layer/recipes-layer/images''' directory.

For example:

<syntaxhighlight lang="bash">
meta-pn-mtk/
├── conf
│ ├── distro
│ │ └── pn-mtk.conf
│ ├── layer.conf
│ ├── machine
│ │ └── mtk-g510.conf
│ └── templates
│ └── default
│ ├── bblayers.conf.sample
│ └── local.conf.sample
├── README.md
└── recipes-pn-mtk
└── images
└── pn-mtk-image-base.bb
</syntaxhighlight>

Once again, a custom image recipe can be based on another image recipe. And, it can also import other image recipes in order to include their base configurations.

As reference, the following image recipe was based on [https://gitlab.com/mediatek/aiot/rity/meta-rity/-/blob/rity-scarthgap-v25.0/meta-rity-demo/recipes-demo/images/rity-demo-image.bb MediaTek meta-rity rity-demo-image recipe]:

<syntaxhighlight lang="bash">
require rity-bsp-image.bb

DESCRIPTION = "PN MTK Demo Image"

#FIXME: Removed pkggroups
IMAGE_INSTALL += "\
packagegroup-rity-graphics \
rity-demo-opencl \
python3-pip \
python3-opencv \
opkg \
benchmark-suite \
ltp \
stress-scripts \
packagegroup-rity-ai-ml \
"

IMAGE_INSTALL:append:genio-510 = " \
packagegroup-rity-tsn \
"

</syntaxhighlight>

{{Footer}}

How to create a custom yocto meta layer

2025-06-14T18:45:55Z

Andres: /* Pre-requisites */

=Introduction=

This wiki will provide a detailed guide on how to create a custom Yocto meta-layer.

=Pre-requisites=
1. The host machine must have the following requirements:
*At least 90GB of space
*At least 8GB RAM
*Host OS must be a supported Linux distribution. (To see supported Linux Distributions, click [https://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions supported distributions])

2. The following packages must be present in the host machine:
<syntaxhighlight lang="bash">
apt install build-essential chrpath cpio debianutils diffstat file gawk gcc git iputils-ping libacl1 liblz4-tool locales python3 python3-git python3-jinja2 python3-pexpect python3-pip python3-subunit socat texinfo unzip wget xz-utils zstd
</syntaxhighlight>

=Create Base Meta-Layer=

This section contains steps to create the base custom meta-layer. 
Creating a layer can be done manually or automatically via bitbake. 
After completion, the custom base meta-layer will contain the following parts:

* Custom layer configuration
* Custom distro configuration
* Custom machine
* Custom config template files
* Custom image recipe

==Manually create layer==

===Step 1. Add base layer.conf file===

The layer configuration file provides Yocto with the configuration for the custom meta-layer.
It shall be stored in a directory called '''conf''' inside the base meta-layer directory, and it shall be named layer.conf.
According to the [https://docs.yoctoproject.org/dev/dev-manual/layers.html Yocto documentation] it is recommended to start from an existing layer.conf file from a different meta-layer and change it according to the custom requirements.

For instance, here is an example of how the directory structure should look after creating the layer.conf file.

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

An example layer.conf file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/layer.conf NVIDIA OE4T tegra_demo_distro] is shown in the following code snipped.

<syntaxhighlight lang="bash">
BBPATH =. "${LAYERDIR}:"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILES_DYNAMIC += "swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bb \
swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "proventusnova"
BBFILE_PATTERN_proventusnova = "^${LAYERDIR}/"
BBFILE_PRIORITY_proventusnova = "50"

LAYERVERSION_proventusnova = "4"
LAYERSERIES_COMPAT_proventusnova = "scarthgap"

# This is used by the tegra-distro-sanity bbclass
# to identify the distro layer directory during
# bblayers checks.
TD_DISTRO_LAYERDIR = "${LAYERDIR}"

</syntaxhighlight>

===Step 2. Add base distro config===

In order to add the initial distro configuration, it is necessary to create distro configuration file inside the '''meta-layer/conf/distro''' directory.

Here is an example of how the directory structure should look like:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

The same as with the layer.conf, it is easier to start with an existing distro configuration file and modify it in order to fit the project requirements. For example, the following corresponds to a distro configuration file based on the [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/distro/tegrademo.conf NVIDIA tegra_demo_distro]:

<syntaxhighlight lang="bash">
DISTRO = "proventusnova"
DISTRO_NAME = "ProventusNova Custom Distro"
DISTRO_VERSION_BASE = "1.0"
DISTRO_VERSION = "${DISTRO_VERSION_BASE}+snapshot-${METADATA_REVISION}"
DISTRO_CODENAME = "proventusnova"
SDK_VENDOR = "-proventusnova"
SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${METADATA_REVISION}','snapshot')}"
SDK_VERSION[vardepvalue] = "${SDK_VERSION}"

MAINTAINER = "ProventusNova team <support@proventusnova.com>"

TARGET_VENDOR = "-proventusnova"

# New ${DISTRO}-<version> setting for sanity checks.
# Increment version number (and the corresponding
# setting int the template bblayers.conf.sample file)
# each time the layer settings are changed.
REQUIRED_PROVENTUSNOVA_BBLAYERS_CONF_VERSION = "${DISTRO}-1"

LOCALCONF_VERSION = "2"

PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES = "largefile opengl ptest multiarch wayland vulkan systemd pam virtualization usrmerge"

DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES}"

# Jetson platforms do not use linux-yocto, but for QEMU testing
# align with the poky distro.
PREFERRED_VERSION_linux-yocto ?= "5.19%"
PREFERRED_VERSION_linux-yocto-rt ?= "5.19%"

SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"

TCLIBCAPPEND = ""

PACKAGE_CLASSES ?= "package_rpm"

SANITY_TESTED_DISTROS ?= " \
ubuntu-20.04 \n \
ubuntu-22.04 \n \
ubuntu-24.04 \n \
"

# Most NVIDIA-supplied services expect systemd
INIT_MANAGER = "systemd"

require conf/distro/include/no-static-libs.inc
require conf/distro/include/yocto-uninative.inc
require conf/distro/include/security_flags.inc
INHERIT += "uninative"

LICENSE_FLAGS_ACCEPTED += "commercial_faad2 commercial_x264"

</syntaxhighlight>

===Step 3. Add base machine===

This step might not be required, if there is already a machine that can be used from a different meta-layer.
However, it is still recommended to create a custom machine configuration based on that machine in order to keep better order of the machine used in the custom Yocto build.

To create a custom machine, it is necessary to add a machine.conf file in the '''meta-layer/conf/machine''' directory.
For example, this is how the directory structure should look when adding a new machine to the custom meta-layer:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ └── machine
│ └── proventusnova-jetson-orin-nx-16-devkit.conf
└── README.md
</syntaxhighlight>

And, as a reference, here is a custom machine based on [https://github.com/OE4T/meta-tegra/blob/scarthgap/conf/machine/p3509-a02-p3767-0000.conf NVIDIA meta-tegra p3509-a02-p3767-0000] machine.

<syntaxhighlight lang="bash">
#@TYPE: Machine
#@NAME: Nvidia Jetson Orin NX 16GB (P3767-0000)
#@DESCRIPTION: Nvidia Jetson Orin NX 16GB module in P3509 carrier

TEGRA_FLASHVAR_PINMUX_CONFIG ?= "tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi"
TEGRA_FLASHVAR_PMC_CONFIG ?= "tegra234-mb1-bct-padvoltage-p3767-hdmi-a03.dtsi"
TEGRA_PLUGIN_MANAGER_OVERLAYS ?= "tegra234-carveouts.dtbo tegra-optee.dtbo tegra234-p3768-0000+p3767-0000-dynamic.dtbo tegra234-dcb-p3767-0000-hdmi.dtbo"
TEGRA_DCE_OVERLAY ?= "tegra234-dcb-p3767-0000-hdmi.dtbo"

require conf/machine/include/orin-nx.inc

</syntaxhighlight>

===Step 4. Add initial config template files===

Bitbake will require 2 configuration files for building an image:

'''bblayers.conf''': This file contains information about the location of the required meta-layers for the project.

'''local.conf''': This file contains general build configuration for bitbake. For instance, in this file it is possible to determine where to store downloads, cache and even which package management configuration to use.

Now, in order to simplify the configuration of a custom Yocto build, it is possible to include template configuration files on the custom meta-layer. This practice is encouraged in order to increase build repeatability.

These 2 files are generally created inside '''meta-layer/conf/templates/template-name'''.
For reference, this is how the directory structure would look like after the files are created:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ └── proventusnova
│ ├── bblayers.conf.sample
│ └── local.conf.sample
└── README.md
</syntaxhighlight>

Here is an example of a custom bblayers.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/bblayers.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
# Version of layers configuration, specific to
# each defined distro in the repository.
# Format: ${DISTRO}-<version>
TD_BBLAYERS_CONF_VERSION = "proventusnova-1"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
##OEROOT##/meta \
##OEROOT##/../meta-tegra \
##OEROOT##/../meta-tegra-community \
##OEROOT##/../meta-virtualization \
##OEROOT##/../meta-openembedded/meta-oe \
##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-openembedded/meta-networking \
##OEROOT##/../meta-openembedded/meta-filesystems \
"

</syntaxhighlight>

And, this is an example of a custom local.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/local.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
#
# Machine Selection
#
MACHINE ??= "proventusnova-jetson-orin-nx-16-devkit.conf"

#
# Where to place downloads
#
DL_DIR ?= "${TOPDIR}/../downloads"

#
# Where to place shared-state files
#
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"

#
# Where to place the build output
#
TMPDIR = "${TOPDIR}/tmp"

#
# Default policy (distro) config
#
DISTRO ?= "proventusnova"

#
# Package Management configuration
#
PACKAGE_CLASSES ?= "package_deb"

#
# SDK target architecture
#
SDKMACHINE ?= "x86_64"

#
# Extra image configuration defaults
#
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

#
# Additional image features
#
USER_CLASSES ?= "buildstats"

#
# Interactive shell configuration
#
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
HALT,${TMPDIR},100M,1K \
HALT,${DL_DIR},100M,1K \
HALT,${SSTATE_DIR},100M,1K \
HALT,/tmp,10M,1K"

#
# Qemu configuration
#
PACKAGECONFIG:append:pn-qemu-system-native = " sdl"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated.
CONF_VERSION = "2"

</syntaxhighlight>

===Step 5. Add base image recipe===

In order to create a custom image, it is necessary to add a custom image recipe file.
This file is usually added inside the '''meta-layer/recipes-layer/images''' directory.

For example:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ ├── bblayers.conf.sample
│ └── local.conf.sample
├── README.md
└── recipes-proventusnova
└── images
└── proventusnova-image-base.bb
</syntaxhighlight>

Once again, a custom image recipe can be based on another image recipe. And, it can also import other image recipes in order to include their base configurations.

As reference, the following image recipe was based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/recipes-demo/images/demo-image-base.bb NVIDIA tegra-demo-distro demo-image-base recipe]:

<syntaxhighlight lang="bash">
DESCRIPTION = "ProventusNova base image"
LICENSE = "CLOSED"

inherit core-image

IMAGE_FEATURES += "ssh-server-openssh debug-tweaks"

CORE_IMAGE_BASE_INSTALL += "systemd"
TOOLCHAIN_HOST_TASK += "nativesdk-packagegroup-cuda-sdk-host"

inherit nopackages

</syntaxhighlight>

==Create layer via bitbake==

===Step 1. Create custom layer===

Run the following command to create a custom layer
<syntaxhighlight lang="bash">
bitbake-layers create-layer meta-proventusnova
</syntaxhighlight>

This should automatically create a meta-proventusnova folder with the following structure
<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ └──layer.conf
├── COPYING.MIT
├── recipes-example
│ └── example
│ └──example_0.1.bb
└── README.md

</syntaxhighlight>

===Step 2. Add custom layer===
Next is to add the custom layer to the project. 
Run the following command to add the custom layer
<syntaxhighlight lang="bash">
bitbake-layers add-layer meta-proventusnova
</syntaxhighlight>

This should add the meta-proventusnova to the build/conf/bblayers.conf file or where you set the build directory.

{{Footer}}

How to create a custom yocto meta layer

2025-06-14T18:45:27Z

Andres: /* Introduction */

=Introduction=

This wiki will provide a detailed guide on how to create a custom Yocto meta-layer.

=Pre-requisites=
1. The host machine must have the following requirements:
*At least 90GB of space
*At least 8GB RAM
*Host OS must be a supported Linux distribution. (To see supported Linux Distributions, click [https://docs.yoctoproject.org/ref-manual/system-requirements.html#supported-linux-distributions supported distributions])

2. The following packages must be present in the host machine:
<syntaxhighlight lang="bash">
apt install build-essential chrpath cpio debianutils diffstat file gawk gcc git iputils-ping libacl1 liblz4-tool locales python3 python3-git python3-jinja2 python3-pexpect python3-pip python3-subunit socat texinfo unzip wget xz-utils zstd
</syntaxhighlight>

3. Get the latest copy of the [https://github.com/yoctoproject/poky Poky repository].
<syntaxhighlight lang="bash">
git clone git://git.yoctoproject.org/poky
</syntaxhighlight>

=Create Base Meta-Layer=

This section contains steps to create the base custom meta-layer. 
Creating a layer can be done manually or automatically via bitbake. 
After completion, the custom base meta-layer will contain the following parts:

* Custom layer configuration
* Custom distro configuration
* Custom machine
* Custom config template files
* Custom image recipe

==Manually create layer==

===Step 1. Add base layer.conf file===

The layer configuration file provides Yocto with the configuration for the custom meta-layer.
It shall be stored in a directory called '''conf''' inside the base meta-layer directory, and it shall be named layer.conf.
According to the [https://docs.yoctoproject.org/dev/dev-manual/layers.html Yocto documentation] it is recommended to start from an existing layer.conf file from a different meta-layer and change it according to the custom requirements.

For instance, here is an example of how the directory structure should look after creating the layer.conf file.

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

An example layer.conf file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/layer.conf NVIDIA OE4T tegra_demo_distro] is shown in the following code snipped.

<syntaxhighlight lang="bash">
BBPATH =. "${LAYERDIR}:"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILES_DYNAMIC += "swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bb \
swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "proventusnova"
BBFILE_PATTERN_proventusnova = "^${LAYERDIR}/"
BBFILE_PRIORITY_proventusnova = "50"

LAYERVERSION_proventusnova = "4"
LAYERSERIES_COMPAT_proventusnova = "scarthgap"

# This is used by the tegra-distro-sanity bbclass
# to identify the distro layer directory during
# bblayers checks.
TD_DISTRO_LAYERDIR = "${LAYERDIR}"

</syntaxhighlight>

===Step 2. Add base distro config===

In order to add the initial distro configuration, it is necessary to create distro configuration file inside the '''meta-layer/conf/distro''' directory.

Here is an example of how the directory structure should look like:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

The same as with the layer.conf, it is easier to start with an existing distro configuration file and modify it in order to fit the project requirements. For example, the following corresponds to a distro configuration file based on the [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/distro/tegrademo.conf NVIDIA tegra_demo_distro]:

<syntaxhighlight lang="bash">
DISTRO = "proventusnova"
DISTRO_NAME = "ProventusNova Custom Distro"
DISTRO_VERSION_BASE = "1.0"
DISTRO_VERSION = "${DISTRO_VERSION_BASE}+snapshot-${METADATA_REVISION}"
DISTRO_CODENAME = "proventusnova"
SDK_VENDOR = "-proventusnova"
SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${METADATA_REVISION}','snapshot')}"
SDK_VERSION[vardepvalue] = "${SDK_VERSION}"

MAINTAINER = "ProventusNova team <support@proventusnova.com>"

TARGET_VENDOR = "-proventusnova"

# New ${DISTRO}-<version> setting for sanity checks.
# Increment version number (and the corresponding
# setting int the template bblayers.conf.sample file)
# each time the layer settings are changed.
REQUIRED_PROVENTUSNOVA_BBLAYERS_CONF_VERSION = "${DISTRO}-1"

LOCALCONF_VERSION = "2"

PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES = "largefile opengl ptest multiarch wayland vulkan systemd pam virtualization usrmerge"

DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES}"

# Jetson platforms do not use linux-yocto, but for QEMU testing
# align with the poky distro.
PREFERRED_VERSION_linux-yocto ?= "5.19%"
PREFERRED_VERSION_linux-yocto-rt ?= "5.19%"

SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"

TCLIBCAPPEND = ""

PACKAGE_CLASSES ?= "package_rpm"

SANITY_TESTED_DISTROS ?= " \
ubuntu-20.04 \n \
ubuntu-22.04 \n \
ubuntu-24.04 \n \
"

# Most NVIDIA-supplied services expect systemd
INIT_MANAGER = "systemd"

require conf/distro/include/no-static-libs.inc
require conf/distro/include/yocto-uninative.inc
require conf/distro/include/security_flags.inc
INHERIT += "uninative"

LICENSE_FLAGS_ACCEPTED += "commercial_faad2 commercial_x264"

</syntaxhighlight>

===Step 3. Add base machine===

This step might not be required, if there is already a machine that can be used from a different meta-layer.
However, it is still recommended to create a custom machine configuration based on that machine in order to keep better order of the machine used in the custom Yocto build.

To create a custom machine, it is necessary to add a machine.conf file in the '''meta-layer/conf/machine''' directory.
For example, this is how the directory structure should look when adding a new machine to the custom meta-layer:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ └── machine
│ └── proventusnova-jetson-orin-nx-16-devkit.conf
└── README.md
</syntaxhighlight>

And, as a reference, here is a custom machine based on [https://github.com/OE4T/meta-tegra/blob/scarthgap/conf/machine/p3509-a02-p3767-0000.conf NVIDIA meta-tegra p3509-a02-p3767-0000] machine.

<syntaxhighlight lang="bash">
#@TYPE: Machine
#@NAME: Nvidia Jetson Orin NX 16GB (P3767-0000)
#@DESCRIPTION: Nvidia Jetson Orin NX 16GB module in P3509 carrier

TEGRA_FLASHVAR_PINMUX_CONFIG ?= "tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi"
TEGRA_FLASHVAR_PMC_CONFIG ?= "tegra234-mb1-bct-padvoltage-p3767-hdmi-a03.dtsi"
TEGRA_PLUGIN_MANAGER_OVERLAYS ?= "tegra234-carveouts.dtbo tegra-optee.dtbo tegra234-p3768-0000+p3767-0000-dynamic.dtbo tegra234-dcb-p3767-0000-hdmi.dtbo"
TEGRA_DCE_OVERLAY ?= "tegra234-dcb-p3767-0000-hdmi.dtbo"

require conf/machine/include/orin-nx.inc

</syntaxhighlight>

===Step 4. Add initial config template files===

Bitbake will require 2 configuration files for building an image:

'''bblayers.conf''': This file contains information about the location of the required meta-layers for the project.

'''local.conf''': This file contains general build configuration for bitbake. For instance, in this file it is possible to determine where to store downloads, cache and even which package management configuration to use.

Now, in order to simplify the configuration of a custom Yocto build, it is possible to include template configuration files on the custom meta-layer. This practice is encouraged in order to increase build repeatability.

These 2 files are generally created inside '''meta-layer/conf/templates/template-name'''.
For reference, this is how the directory structure would look like after the files are created:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ └── proventusnova
│ ├── bblayers.conf.sample
│ └── local.conf.sample
└── README.md
</syntaxhighlight>

Here is an example of a custom bblayers.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/bblayers.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
# Version of layers configuration, specific to
# each defined distro in the repository.
# Format: ${DISTRO}-<version>
TD_BBLAYERS_CONF_VERSION = "proventusnova-1"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
##OEROOT##/meta \
##OEROOT##/../meta-tegra \
##OEROOT##/../meta-tegra-community \
##OEROOT##/../meta-virtualization \
##OEROOT##/../meta-openembedded/meta-oe \
##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-openembedded/meta-networking \
##OEROOT##/../meta-openembedded/meta-filesystems \
"

</syntaxhighlight>

And, this is an example of a custom local.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/local.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
#
# Machine Selection
#
MACHINE ??= "proventusnova-jetson-orin-nx-16-devkit.conf"

#
# Where to place downloads
#
DL_DIR ?= "${TOPDIR}/../downloads"

#
# Where to place shared-state files
#
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"

#
# Where to place the build output
#
TMPDIR = "${TOPDIR}/tmp"

#
# Default policy (distro) config
#
DISTRO ?= "proventusnova"

#
# Package Management configuration
#
PACKAGE_CLASSES ?= "package_deb"

#
# SDK target architecture
#
SDKMACHINE ?= "x86_64"

#
# Extra image configuration defaults
#
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

#
# Additional image features
#
USER_CLASSES ?= "buildstats"

#
# Interactive shell configuration
#
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
HALT,${TMPDIR},100M,1K \
HALT,${DL_DIR},100M,1K \
HALT,${SSTATE_DIR},100M,1K \
HALT,/tmp,10M,1K"

#
# Qemu configuration
#
PACKAGECONFIG:append:pn-qemu-system-native = " sdl"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated.
CONF_VERSION = "2"

</syntaxhighlight>

===Step 5. Add base image recipe===

In order to create a custom image, it is necessary to add a custom image recipe file.
This file is usually added inside the '''meta-layer/recipes-layer/images''' directory.

For example:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ ├── bblayers.conf.sample
│ └── local.conf.sample
├── README.md
└── recipes-proventusnova
└── images
└── proventusnova-image-base.bb
</syntaxhighlight>

Once again, a custom image recipe can be based on another image recipe. And, it can also import other image recipes in order to include their base configurations.

As reference, the following image recipe was based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/recipes-demo/images/demo-image-base.bb NVIDIA tegra-demo-distro demo-image-base recipe]:

<syntaxhighlight lang="bash">
DESCRIPTION = "ProventusNova base image"
LICENSE = "CLOSED"

inherit core-image

IMAGE_FEATURES += "ssh-server-openssh debug-tweaks"

CORE_IMAGE_BASE_INSTALL += "systemd"
TOOLCHAIN_HOST_TASK += "nativesdk-packagegroup-cuda-sdk-host"

inherit nopackages

</syntaxhighlight>

==Create layer via bitbake==

===Step 1. Create custom layer===

Run the following command to create a custom layer
<syntaxhighlight lang="bash">
bitbake-layers create-layer meta-proventusnova
</syntaxhighlight>

This should automatically create a meta-proventusnova folder with the following structure
<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ └──layer.conf
├── COPYING.MIT
├── recipes-example
│ └── example
│ └──example_0.1.bb
└── README.md

</syntaxhighlight>

===Step 2. Add custom layer===
Next is to add the custom layer to the project. 
Run the following command to add the custom layer
<syntaxhighlight lang="bash">
bitbake-layers add-layer meta-proventusnova
</syntaxhighlight>

This should add the meta-proventusnova to the build/conf/bblayers.conf file or where you set the build directory.

{{Footer}}

Template:Footer

2025-06-09T00:20:38Z

Andres: /* 🏗 Customized Technology Solutions for Your Business */

= Need Further Support? =

'''📞 Book Consultation Call:''' [https://proventusnova.com/contact-us/ Show Calendar!]

'''📩 Contact Via Email:''' [mailto:support@proventusnova.com support@proventusnova.com]

'''🌐 Visit Our Website:''' [https://proventusnova.com ProventusNova.com]

Https://www.google.com/How to start camera stream on boot with systemd service NVIDIA Jetson tutorial

2025-06-08T22:38:27Z

Andres: Created page with "=How to start camera stream on boot with systemd service – NVIDIA Jetson Tutorial= This tutorial demonstrates how to automatically launch a Python-based camera streaming application on boot using a <code>systemd</code> service on NVIDIA Jetson devices. == Prerequisites == * NVIDIA Jetson board (e.g., Orin NX, Nano, Xavier) * Your custom Python GStreamer/WebRTC camera application * Access to the terminal and root privileges == Step 1: Prepare the Python Script == E..."

=How to start camera stream on boot with systemd service – NVIDIA Jetson Tutorial=

This tutorial demonstrates how to automatically launch a Python-based camera streaming application on boot using a <code>systemd</code> service on NVIDIA Jetson devices.

== Prerequisites ==

* NVIDIA Jetson board (e.g., Orin NX, Nano, Xavier)
* Your custom Python GStreamer/WebRTC camera application
* Access to the terminal and root privileges

== Step 1: Prepare the Python Script ==

Ensure your Python streaming script is available on the Jetson device. Below is the exact script used in this tutorial <code>camera_stream.py</code>:

'''Note:''' Make sure to set the correct IP address for the device that will be consuming the stream. In this case '''10.42.0.1''' is used.

<syntaxhighlight lang="python">
#!/usr/bin/env python3

import gi
import signal
import sys

gi.require_version('Gst', '1.0')
gi.require_version('GLib', '2.0')
from gi.repository import Gst, GLib

Gst.init(None)
loop = GLib.MainLoop()

def on_message(bus, message, loop):
msg_type = message.type

if msg_type == Gst.MessageType.ERROR:
err, debug = message.parse_error()
print(f"Error: {err}, Debug: {debug}")
loop.quit()

def signal_handler(sig, frame):
print("Interrupt received, stopping pipeline...")
loop.quit()

# Handle SIGINT (Ctrl+C) and SIGTERM (systemd stop)
signal.signal(signal.SIGINT, signal_handler)
signal.signal(signal.SIGTERM, signal_handler)

pipeline = Gst.parse_launch(
"nvarguscamerasrc sensor-id=0 ! "
"nvv4l2h264enc bitrate=4000000 ! "
"h264parse ! rtph264pay config-interval=1 pt=96 ! "
"udpsink host=10.42.0.1 port=5000"
)

bus = pipeline.get_bus()
bus.add_signal_watch()
bus.connect("message", on_message, loop)

pipeline.set_state(Gst.State.PLAYING)

try:
print("Pipeline started. Streaming...")
loop.run()
finally:
print("Shutting down pipeline.")
pipeline.set_state(Gst.State.NULL)
bus.remove_signal_watch()

</syntaxhighlight>

Save this as <code>/usr/local/bin/camera_stream.py</code>.

Make sure all required GStreamer plugins are installed and working. You can test this script manually before proceeding.

<syntaxhighlight lang="bash">
python3 /usr/local/bin/camera_stream.py
</syntaxhighlight>

== Step 2: Create a systemd Service File ==

Use the following <code>systemd</code> unit file to run the Python script at boot:

<syntaxhighlight lang="ini">
[Unit]
Description=Jetson camera UDP stream on boot
After=nvargus-daemon.service
Requires=nvargus-daemon.service

[Service]
ExecStart=/usr/bin/python3 /usr/local/bin/camera_stream.py
Restart=on-failure
StandardOutput=journal
StandardError=journal
</syntaxhighlight>

Save this file as <code>/etc/systemd/system/camera-stream.service</code>.

== Step 3: Enable and Start the Service ==

To enable and start the service on boot, run the following commands:

<syntaxhighlight lang="bash">
sudo systemctl daemon-reload
sudo systemctl enable camera-stream.service
sudo systemctl start camera-stream.service
</syntaxhighlight>

To check the service status:

<syntaxhighlight lang="bash">
systemctl status camera-stream.service
</syntaxhighlight>

To view logs:

<syntaxhighlight lang="bash">
journalctl -u camera-stream.service
</syntaxhighlight>

== Step 4: Testing auto camera stream feature ==

In order to test this feature, run the following GStreamer pipeline on the device that will preview the camera stream put by the NVIDIA Jetson device.

<syntaxhighlight lang="bash">
gst-launch-1.0 -v udpsrc port=5000 ! application/x-rtp, encoding-name=H264, payload=96 ! rtph264depay ! avdec_h264 ! videoconvert ! autovideosink
</syntaxhighlight>

Then, reboot or power-cycle the board.

Finally, make sure that the stream is shown as expected on the client device.

{{Footer}}

How to Build a Video Capture Application Using GStreamer and OpenCV in Python

2025-03-23T23:18:25Z

Andres: Created page with "= How to Build a Video Capture Application Using GStreamer and OpenCV in Python = This guide explains how to create a basic video capture application using **GStreamer** and **OpenCV** in Python. The application captures video from a camera using GStreamer and processes it with OpenCV. == Full Script == For those who just want the code, here is the complete script: <syntaxhighlight lang="python"> import gi import cv2 import numpy as np import sys gi.require_version("..."

= How to Build a Video Capture Application Using GStreamer and OpenCV in Python =

This guide explains how to create a basic video capture application using **GStreamer** and **OpenCV** in Python. The application captures video from a camera using GStreamer and processes it with OpenCV.

== Full Script ==
For those who just want the code, here is the complete script:

<syntaxhighlight lang="python">
import gi
import cv2
import numpy as np
import sys

gi.require_version("Gst", "1.0")
gi.require_version("GLib", "2.0")
from gi.repository import Gst, GLib

class Camera:
def __init__(self, width=640, height=480, fps=30):
"""Initialize the GStreamer pipeline and elements."""
Gst.init(None) # Initialize GStreamer

self.width = width
self.height = height
self.fps = fps
self.frame = None # Placeholder for the latest frame
self.running = True # Flag to track if the loop should run

# Define GStreamer pipeline
self.pipeline_str = (
f"v4l2src device=/dev/video6 ! "
f"image/jpeg, width={self.width}, height={self.height}, framerate={self.fps}/1 ! "
"jpegdec ! "
"videoconvert ! "
"videoscale ! "
f"video/x-raw,format=BGR,width={self.width},height={self.height} ! "
"appsink name=sink emit-signals=true max-buffers=1 drop=true"
)

# Create pipeline
self.pipeline = Gst.parse_launch(self.pipeline_str)
self.appsink = self.pipeline.get_by_name("sink")

if not self.appsink:
print("Error: Could not find appsink element.")
sys.exit(1)

# Connect new-sample signal
self.appsink.connect("new-sample", self.on_new_sample)

# Start pipeline
self.pipeline.set_state(Gst.State.PLAYING)

# Start GLib main loop
self.loop = GLib.MainLoop()

# Add a timer to update OpenCV display
GLib.timeout_add(30, self.update_display)

def on_new_sample(self, sink):
"""Callback function for processing new samples."""
sample = sink.emit("pull-sample")
if sample is None:
return Gst.FlowReturn.ERROR

buffer = sample.get_buffer()
success, map_info = buffer.map(Gst.MapFlags.READ)
if not success:
return Gst.FlowReturn.ERROR

# Convert buffer to NumPy array
frame_data = np.frombuffer(map_info.data, dtype=np.uint8)
buffer.unmap(map_info)

try:
self.frame = frame_data.reshape((self.height, self.width, 3))
except ValueError:
print("Frame size mismatch, skipping frame.")

return Gst.FlowReturn.OK

def update_display(self):
"""Update OpenCV display and check if the window is closed."""
if self.frame is not None:
cv2.imshow("GStreamer Video", self.frame)

# Check if OpenCV window is closed
if cv2.getWindowProperty("GStreamer Video", cv2.WND_PROP_VISIBLE) < 1:
self.stop()
return False # Stop updating

if cv2.waitKey(1) & 0xFF == ord("q"):
self.stop()
return False # Stop updating

return True # Continue updating

def start(self):
"""Run the GStreamer pipeline loop."""
try:
self.loop.run()
except KeyboardInterrupt:
self.stop()

def stop(self):
"""Stop the GStreamer pipeline and cleanup."""
if self.running:
self.running = False
print("Stopping camera...")
self.pipeline.set_state(Gst.State.NULL)
cv2.destroyAllWindows()
self.loop.quit()

if __name__ == "__main__":
camera = Camera(width=640, height=480, fps=30)
camera.start()
</syntaxhighlight>

== Step-by-Step Guide ==

=== 1. Install Dependencies ===
Before running the script, make sure you have the required dependencies installed.

Run the following command to install them:
<syntaxhighlight lang="bash">
pip install opencv-python numpy pygobject
sudo apt install gstreamer1.0-tools gstreamer1.0-plugins-base gstreamer1.0-plugins-good
</syntaxhighlight>

=== 2. Understand the GStreamer Pipeline ===
The script uses the following GStreamer pipeline:

<syntaxhighlight lang="bash">
v4l2src device=/dev/video6 ! image/jpeg, width=640, height=480, framerate=30/1 !
jpegdec ! videoconvert ! videoscale ! video/x-raw,format=BGR,width=640,height=480 ! appsink
</syntaxhighlight>

- **v4l2src** → Captures video from a device (e.g., `/dev/video6`).
- **jpegdec** → Decodes JPEG frames.
- **videoconvert** → Converts to a format compatible with OpenCV.
- **appsink** → Sends frames to OpenCV for further processing.

=== 3. Run the Script ===
Save the script as `camera.py` and run it:
<syntaxhighlight lang="bash">
python camera.py
</syntaxhighlight>
Press **'q'** or close the OpenCV window to stop the program.

=== 4. Modify for Your Camera ===
- To use a different camera, change the `device=/dev/video6` in the script.
- Modify `width`, `height`, and `fps` in the `Camera` class.

== FAQ ==

=== How can I change the camera source? ===
Modify the `v4l2src` device in the pipeline:
<syntaxhighlight lang="python">
self.pipeline_str = "v4l2src device=/dev/video0 ! ..."
</syntaxhighlight>
Use `/dev/video0`, `/dev/video1`, etc., depending on your setup.

=== Why is the video not displaying? ===
Possible issues:
1. **Camera is in use** → Close other applications using the camera.
2. **Wrong device path** → Check available devices using:
<syntaxhighlight lang="bash">
v4l2-ctl --list-devices
</syntaxhighlight>
3. **Missing dependencies** → Ensure all required GStreamer plugins are installed.

=== How do I exit the application? ===
Press **'q'** or close the OpenCV window to stop the script.

=== How can I improve performance? ===
- Reduce `width` and `height` for better speed.
- Set `drop=true` in `appsink` to avoid frame buffering delays.

== Conclusion ==
You've now built a basic **video capture application** using **GStreamer** and **OpenCV** in Python! 🚀
Modify the script to suit your needs, such as adding **filters**, **recording**, or **streaming**.

If you have any questions, feel free to ask in the comments. Happy coding! 🎥🖥️

How to create a custom yocto meta layer

2025-03-11T22:12:20Z

Andres: /* Step 2. Add base distro config */

=Introduction=

This wiki will provide a detailed guide on how to create a custom Yocto meta-layer.

==Create Base Meta-Layer==

This section contains steps to create the base custom meta-layer.
After completion, the custom base meta-layer will contain the following parts:

* Custom layer configuration
* Custom distro configuration
* Custom machine
* Custom config template files
* Custom image recipe

===Step 1. Add base layer.conf file===

The layer configuration file provides Yocto with the configuration for the custom meta-layer.
It shall be stored in a directory called '''conf''' inside the base meta-layer directory, and it shall be named layer.conf.
According to the [https://docs.yoctoproject.org/dev/dev-manual/layers.html Yocto documentation] it is recommended to start from an existing layer.conf file from a different meta-layer and change it according to the custom requirements.

For instance, here is an example of how the directory structure should look after creating the layer.conf file.

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

An example layer.conf file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/layer.conf NVIDIA OE4T tegra_demo_distro] is shown in the following code snipped.

<syntaxhighlight lang="bash">
BBPATH =. "${LAYERDIR}:"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILES_DYNAMIC += "swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bb \
swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "proventusnova"
BBFILE_PATTERN_proventusnova = "^${LAYERDIR}/"
BBFILE_PRIORITY_proventusnova = "50"

LAYERVERSION_proventusnova = "4"
LAYERSERIES_COMPAT_proventusnova = "scarthgap"

# This is used by the tegra-distro-sanity bbclass
# to identify the distro layer directory during
# bblayers checks.
TD_DISTRO_LAYERDIR = "${LAYERDIR}"

</syntaxhighlight>

===Step 2. Add base distro config===

In order to add the initial distro configuration, it is necessary to create distro configuration file inside the '''meta-layer/conf/distro''' directory.

Here is an example of how the directory structure should look like:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

The same as with the layer.conf, it is easier to start with an existing distro configuration file and modify it in order to fit the project requirements. For example, the following corresponds to a distro configuration file based on the [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/distro/tegrademo.conf NVIDIA tegra_demo_distro]:

<syntaxhighlight lang="bash">
DISTRO = "proventusnova"
DISTRO_NAME = "ProventusNova Custom Distro"
DISTRO_VERSION_BASE = "1.0"
DISTRO_VERSION = "${DISTRO_VERSION_BASE}+snapshot-${METADATA_REVISION}"
DISTRO_CODENAME = "proventusnova"
SDK_VENDOR = "-proventusnova"
SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${METADATA_REVISION}','snapshot')}"
SDK_VERSION[vardepvalue] = "${SDK_VERSION}"

MAINTAINER = "ProventusNova team <support@proventusnova.com>"

TARGET_VENDOR = "-proventusnova"

# New ${DISTRO}-<version> setting for sanity checks.
# Increment version number (and the corresponding
# setting int the template bblayers.conf.sample file)
# each time the layer settings are changed.
REQUIRED_PROVENTUSNOVA_BBLAYERS_CONF_VERSION = "${DISTRO}-1"

LOCALCONF_VERSION = "2"

PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES = "largefile opengl ptest multiarch wayland vulkan systemd pam virtualization usrmerge"

DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES}"

# Jetson platforms do not use linux-yocto, but for QEMU testing
# align with the poky distro.
PREFERRED_VERSION_linux-yocto ?= "5.19%"
PREFERRED_VERSION_linux-yocto-rt ?= "5.19%"

SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"

TCLIBCAPPEND = ""

PACKAGE_CLASSES ?= "package_rpm"

SANITY_TESTED_DISTROS ?= " \
ubuntu-20.04 \n \
ubuntu-22.04 \n \
ubuntu-24.04 \n \
"

# Most NVIDIA-supplied services expect systemd
INIT_MANAGER = "systemd"

require conf/distro/include/no-static-libs.inc
require conf/distro/include/yocto-uninative.inc
require conf/distro/include/security_flags.inc
INHERIT += "uninative"

LICENSE_FLAGS_ACCEPTED += "commercial_faad2 commercial_x264"

</syntaxhighlight>

===Step 3. Add base machine===

This step might not be required, if there is already a machine that can be used from a different meta-layer.
However, it is still recommended to create a custom machine configuration based on that machine in order to keep better order of the machine used in the custom Yocto build.

To create a custom machine, it is necessary to add a machine.conf file in the '''meta-layer/conf/machine''' directory.
For example, this is how the directory structure should look when adding a new machine to the custom meta-layer:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ └── machine
│ └── proventusnova-jetson-orin-nx-16-devkit.conf
└── README.md
</syntaxhighlight>

And, as a reference, here is a custom machine based on [https://github.com/OE4T/meta-tegra/blob/scarthgap/conf/machine/p3509-a02-p3767-0000.conf NVIDIA meta-tegra p3509-a02-p3767-0000] machine.

<syntaxhighlight lang="bash">
#@TYPE: Machine
#@NAME: Nvidia Jetson Orin NX 16GB (P3767-0000)
#@DESCRIPTION: Nvidia Jetson Orin NX 16GB module in P3509 carrier

TEGRA_FLASHVAR_PINMUX_CONFIG ?= "tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi"
TEGRA_FLASHVAR_PMC_CONFIG ?= "tegra234-mb1-bct-padvoltage-p3767-hdmi-a03.dtsi"
TEGRA_PLUGIN_MANAGER_OVERLAYS ?= "tegra234-carveouts.dtbo tegra-optee.dtbo tegra234-p3768-0000+p3767-0000-dynamic.dtbo tegra234-dcb-p3767-0000-hdmi.dtbo"
TEGRA_DCE_OVERLAY ?= "tegra234-dcb-p3767-0000-hdmi.dtbo"

require conf/machine/include/orin-nx.inc

</syntaxhighlight>

===Step 4. Add initial config template files===

Bitbake will require 2 configuration files for building an image:

'''bblayers.conf''': This file contains information about the location of the required meta-layers for the project.

'''local.conf''': This file contains general build configuration for bitbake. For instance, in this file it is possible to determine where to store downloads, cache and even which package management configuration to use.

Now, in order to simplify the configuration of a custom Yocto build, it is possible to include template configuration files on the custom meta-layer. This practice is encouraged in order to increase build repeatability.

These 2 files are generally created inside '''meta-layer/conf/templates/template-name'''.
For reference, this is how the directory structure would look like after the files are created:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ └── proventusnova
│ ├── bblayers.conf.sample
│ └── local.conf.sample
└── README.md
</syntaxhighlight>

Here is an example of a custom bblayers.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/bblayers.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
# Version of layers configuration, specific to
# each defined distro in the repository.
# Format: ${DISTRO}-<version>
TD_BBLAYERS_CONF_VERSION = "proventusnova-1"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
##OEROOT##/meta \
##OEROOT##/../meta-tegra \
##OEROOT##/../meta-tegra-community \
##OEROOT##/../meta-virtualization \
##OEROOT##/../meta-openembedded/meta-oe \
##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-openembedded/meta-networking \
##OEROOT##/../meta-openembedded/meta-filesystems \
"

</syntaxhighlight>

And, this is an example of a custom local.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/local.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
#
# Machine Selection
#
MACHINE ??= "proventusnova-jetson-orin-nx-16-devkit.conf"

#
# Where to place downloads
#
DL_DIR ?= "${TOPDIR}/../downloads"

#
# Where to place shared-state files
#
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"

#
# Where to place the build output
#
TMPDIR = "${TOPDIR}/tmp"

#
# Default policy (distro) config
#
DISTRO ?= "proventusnova"

#
# Package Management configuration
#
PACKAGE_CLASSES ?= "package_deb"

#
# SDK target architecture
#
SDKMACHINE ?= "x86_64"

#
# Extra image configuration defaults
#
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

#
# Additional image features
#
USER_CLASSES ?= "buildstats"

#
# Interactive shell configuration
#
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
HALT,${TMPDIR},100M,1K \
HALT,${DL_DIR},100M,1K \
HALT,${SSTATE_DIR},100M,1K \
HALT,/tmp,10M,1K"

#
# Qemu configuration
#
PACKAGECONFIG:append:pn-qemu-system-native = " sdl"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated.
CONF_VERSION = "2"

</syntaxhighlight>

===Step 5. Add base image recipe===

In order to create a custom image, it is necessary to add a custom image recipe file.
This file is usually added inside the '''meta-layer/recipes-layer/images''' directory.

For example:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ ├── bblayers.conf.sample
│ └── local.conf.sample
├── README.md
└── recipes-proventusnova
└── images
└── proventusnova-image-base.bb
</syntaxhighlight>

Once again, a custom image recipe can be based on another image recipe. And, it can also import other image recipes in order to include their base configurations.

As reference, the following image recipe was based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/recipes-demo/images/demo-image-base.bb NVIDIA tegra-demo-distro demo-image-base recipe]:

<syntaxhighlight lang="bash">
DESCRIPTION = "ProventusNova base image"
LICENSE = "CLOSED"

inherit core-image

IMAGE_FEATURES += "ssh-server-openssh debug-tweaks"

CORE_IMAGE_BASE_INSTALL += "systemd"
TOOLCHAIN_HOST_TASK += "nativesdk-packagegroup-cuda-sdk-host"

inherit nopackages

</syntaxhighlight>

How to create a custom yocto meta layer

2025-03-11T22:12:04Z

Andres: /* Step 4. Add initial config template files */

=Introduction=

This wiki will provide a detailed guide on how to create a custom Yocto meta-layer.

==Create Base Meta-Layer==

This section contains steps to create the base custom meta-layer.
After completion, the custom base meta-layer will contain the following parts:

* Custom layer configuration
* Custom distro configuration
* Custom machine
* Custom config template files
* Custom image recipe

===Step 1. Add base layer.conf file===

The layer configuration file provides Yocto with the configuration for the custom meta-layer.
It shall be stored in a directory called '''conf''' inside the base meta-layer directory, and it shall be named layer.conf.
According to the [https://docs.yoctoproject.org/dev/dev-manual/layers.html Yocto documentation] it is recommended to start from an existing layer.conf file from a different meta-layer and change it according to the custom requirements.

For instance, here is an example of how the directory structure should look after creating the layer.conf file.

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

An example layer.conf file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/layer.conf NVIDIA OE4T tegra_demo_distro] is shown in the following code snipped.

<syntaxhighlight lang="bash">
BBPATH =. "${LAYERDIR}:"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILES_DYNAMIC += "swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bb \
swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "proventusnova"
BBFILE_PATTERN_proventusnova = "^${LAYERDIR}/"
BBFILE_PRIORITY_proventusnova = "50"

LAYERVERSION_proventusnova = "4"
LAYERSERIES_COMPAT_proventusnova = "scarthgap"

# This is used by the tegra-distro-sanity bbclass
# to identify the distro layer directory during
# bblayers checks.
TD_DISTRO_LAYERDIR = "${LAYERDIR}"

</syntaxhighlight>

===Step 2. Add base distro config===

In order to add the initial distro configuration, it is necessary to create distro configuration file inside the '''meta-layer/conf/distro''' directory.

Here is an example of how the directory structure should look like:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

The same as with the layer.conf, it is easier to start with an existing distro configuration file and modify it in order to fit the project requirements. For example, the following corresponds to a distro configuration file based on the [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/distro/tegrademo.conf NVIDIA tegra_demo_distro]:

<syntaxhighlight lang="bash">
DISTRO = "proventusnova"
DISTRO_NAME = "ProventusNova Custom Distro"
DISTRO_VERSION_BASE = "1.0"
DISTRO_VERSION = "${DISTRO_VERSION_BASE}+snapshot-${METADATA_REVISION}"
DISTRO_CODENAME = "proventusnova"
SDK_VENDOR = "-proventusnova"
SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${METADATA_REVISION}','snapshot')}"
SDK_VERSION[vardepvalue] = "${SDK_VERSION}"

MAINTAINER = "ProventusNova team <support@proventusnova.com>"

TARGET_VENDOR = "-proventusnova"

# New ${DISTRO}-<version> setting for sanity checks.
# Increment version number (and the corresponding
# setting int the template bblayers.conf.sample file)
# each time the layer settings are changed.
REQUIRED_PROVENTUSNOVA_BBLAYERS_CONF_VERSION = "${DISTRO}-1"

LOCALCONF_VERSION = "2"

PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES = "largefile opengl ptest multiarch wayland vulkan systemd pam virtualization usrmerge"

DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES}"

# Jetson platforms do not use linux-yocto, but for QEMU testing
# align with the poky distro.
PREFERRED_VERSION_linux-yocto ?= "5.19%"
PREFERRED_VERSION_linux-yocto-rt ?= "5.19%"

SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"

TCLIBCAPPEND = ""

PACKAGE_CLASSES ?= "package_rpm"

SANITY_TESTED_DISTROS ?= " \
ubuntu-20.04 \n \
ubuntu-22.04 \n \
ubuntu-24.04 \n \
"

# Most NVIDIA-supplied services expect systemd
INIT_MANAGER = "systemd"

require conf/distro/include/no-static-libs.inc
require conf/distro/include/yocto-uninative.inc
require conf/distro/include/security_flags.inc
INHERIT += "uninative"

LICENSE_FLAGS_ACCEPTED += "commercial_faad2 commercial_x264"

USE_REDUNDANT_FLASH_LAYOUT_DEFAULT ?= "1"

INHERIT += "tegra-support-sanity"
ESDK_CLASS_INHERIT_DISABLE:append = " tegra-support-sanity"

BB_SIGNATURE_HANDLER ?= "OEEquivHash"
BB_HASHSERVE ??= "auto"

</syntaxhighlight>

===Step 3. Add base machine===

This step might not be required, if there is already a machine that can be used from a different meta-layer.
However, it is still recommended to create a custom machine configuration based on that machine in order to keep better order of the machine used in the custom Yocto build.

To create a custom machine, it is necessary to add a machine.conf file in the '''meta-layer/conf/machine''' directory.
For example, this is how the directory structure should look when adding a new machine to the custom meta-layer:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ └── machine
│ └── proventusnova-jetson-orin-nx-16-devkit.conf
└── README.md
</syntaxhighlight>

And, as a reference, here is a custom machine based on [https://github.com/OE4T/meta-tegra/blob/scarthgap/conf/machine/p3509-a02-p3767-0000.conf NVIDIA meta-tegra p3509-a02-p3767-0000] machine.

<syntaxhighlight lang="bash">
#@TYPE: Machine
#@NAME: Nvidia Jetson Orin NX 16GB (P3767-0000)
#@DESCRIPTION: Nvidia Jetson Orin NX 16GB module in P3509 carrier

TEGRA_FLASHVAR_PINMUX_CONFIG ?= "tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi"
TEGRA_FLASHVAR_PMC_CONFIG ?= "tegra234-mb1-bct-padvoltage-p3767-hdmi-a03.dtsi"
TEGRA_PLUGIN_MANAGER_OVERLAYS ?= "tegra234-carveouts.dtbo tegra-optee.dtbo tegra234-p3768-0000+p3767-0000-dynamic.dtbo tegra234-dcb-p3767-0000-hdmi.dtbo"
TEGRA_DCE_OVERLAY ?= "tegra234-dcb-p3767-0000-hdmi.dtbo"

require conf/machine/include/orin-nx.inc

</syntaxhighlight>

===Step 4. Add initial config template files===

Bitbake will require 2 configuration files for building an image:

'''bblayers.conf''': This file contains information about the location of the required meta-layers for the project.

'''local.conf''': This file contains general build configuration for bitbake. For instance, in this file it is possible to determine where to store downloads, cache and even which package management configuration to use.

Now, in order to simplify the configuration of a custom Yocto build, it is possible to include template configuration files on the custom meta-layer. This practice is encouraged in order to increase build repeatability.

These 2 files are generally created inside '''meta-layer/conf/templates/template-name'''.
For reference, this is how the directory structure would look like after the files are created:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ └── proventusnova
│ ├── bblayers.conf.sample
│ └── local.conf.sample
└── README.md
</syntaxhighlight>

Here is an example of a custom bblayers.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/bblayers.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
# Version of layers configuration, specific to
# each defined distro in the repository.
# Format: ${DISTRO}-<version>
TD_BBLAYERS_CONF_VERSION = "proventusnova-1"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
##OEROOT##/meta \
##OEROOT##/../meta-tegra \
##OEROOT##/../meta-tegra-community \
##OEROOT##/../meta-virtualization \
##OEROOT##/../meta-openembedded/meta-oe \
##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-openembedded/meta-networking \
##OEROOT##/../meta-openembedded/meta-filesystems \
"

</syntaxhighlight>

And, this is an example of a custom local.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/local.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
#
# Machine Selection
#
MACHINE ??= "proventusnova-jetson-orin-nx-16-devkit.conf"

#
# Where to place downloads
#
DL_DIR ?= "${TOPDIR}/../downloads"

#
# Where to place shared-state files
#
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"

#
# Where to place the build output
#
TMPDIR = "${TOPDIR}/tmp"

#
# Default policy (distro) config
#
DISTRO ?= "proventusnova"

#
# Package Management configuration
#
PACKAGE_CLASSES ?= "package_deb"

#
# SDK target architecture
#
SDKMACHINE ?= "x86_64"

#
# Extra image configuration defaults
#
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

#
# Additional image features
#
USER_CLASSES ?= "buildstats"

#
# Interactive shell configuration
#
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
HALT,${TMPDIR},100M,1K \
HALT,${DL_DIR},100M,1K \
HALT,${SSTATE_DIR},100M,1K \
HALT,/tmp,10M,1K"

#
# Qemu configuration
#
PACKAGECONFIG:append:pn-qemu-system-native = " sdl"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated.
CONF_VERSION = "2"

</syntaxhighlight>

===Step 5. Add base image recipe===

In order to create a custom image, it is necessary to add a custom image recipe file.
This file is usually added inside the '''meta-layer/recipes-layer/images''' directory.

For example:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ ├── bblayers.conf.sample
│ └── local.conf.sample
├── README.md
└── recipes-proventusnova
└── images
└── proventusnova-image-base.bb
</syntaxhighlight>

Once again, a custom image recipe can be based on another image recipe. And, it can also import other image recipes in order to include their base configurations.

As reference, the following image recipe was based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/recipes-demo/images/demo-image-base.bb NVIDIA tegra-demo-distro demo-image-base recipe]:

<syntaxhighlight lang="bash">
DESCRIPTION = "ProventusNova base image"
LICENSE = "CLOSED"

inherit core-image

IMAGE_FEATURES += "ssh-server-openssh debug-tweaks"

CORE_IMAGE_BASE_INSTALL += "systemd"
TOOLCHAIN_HOST_TASK += "nativesdk-packagegroup-cuda-sdk-host"

inherit nopackages

</syntaxhighlight>

How to create a custom yocto meta layer

2025-03-11T20:28:22Z

Andres: /* Step 4. Add initial config template files */

=Introduction=

This wiki will provide a detailed guide on how to create a custom Yocto meta-layer.

==Create Base Meta-Layer==

This section contains steps to create the base custom meta-layer.
After completion, the custom base meta-layer will contain the following parts:

* Custom layer configuration
* Custom distro configuration
* Custom machine
* Custom config template files
* Custom image recipe

===Step 1. Add base layer.conf file===

The layer configuration file provides Yocto with the configuration for the custom meta-layer.
It shall be stored in a directory called '''conf''' inside the base meta-layer directory, and it shall be named layer.conf.
According to the [https://docs.yoctoproject.org/dev/dev-manual/layers.html Yocto documentation] it is recommended to start from an existing layer.conf file from a different meta-layer and change it according to the custom requirements.

For instance, here is an example of how the directory structure should look after creating the layer.conf file.

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

An example layer.conf file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/layer.conf NVIDIA OE4T tegra_demo_distro] is shown in the following code snipped.

<syntaxhighlight lang="bash">
BBPATH =. "${LAYERDIR}:"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILES_DYNAMIC += "swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bb \
swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "proventusnova"
BBFILE_PATTERN_proventusnova = "^${LAYERDIR}/"
BBFILE_PRIORITY_proventusnova = "50"

LAYERVERSION_proventusnova = "4"
LAYERSERIES_COMPAT_proventusnova = "scarthgap"

# This is used by the tegra-distro-sanity bbclass
# to identify the distro layer directory during
# bblayers checks.
TD_DISTRO_LAYERDIR = "${LAYERDIR}"

</syntaxhighlight>

===Step 2. Add base distro config===

In order to add the initial distro configuration, it is necessary to create distro configuration file inside the '''meta-layer/conf/distro''' directory.

Here is an example of how the directory structure should look like:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

The same as with the layer.conf, it is easier to start with an existing distro configuration file and modify it in order to fit the project requirements. For example, the following corresponds to a distro configuration file based on the [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/distro/tegrademo.conf NVIDIA tegra_demo_distro]:

<syntaxhighlight lang="bash">
DISTRO = "proventusnova"
DISTRO_NAME = "ProventusNova Custom Distro"
DISTRO_VERSION_BASE = "1.0"
DISTRO_VERSION = "${DISTRO_VERSION_BASE}+snapshot-${METADATA_REVISION}"
DISTRO_CODENAME = "proventusnova"
SDK_VENDOR = "-proventusnova"
SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${METADATA_REVISION}','snapshot')}"
SDK_VERSION[vardepvalue] = "${SDK_VERSION}"

MAINTAINER = "ProventusNova team <support@proventusnova.com>"

TARGET_VENDOR = "-proventusnova"

# New ${DISTRO}-<version> setting for sanity checks.
# Increment version number (and the corresponding
# setting int the template bblayers.conf.sample file)
# each time the layer settings are changed.
REQUIRED_PROVENTUSNOVA_BBLAYERS_CONF_VERSION = "${DISTRO}-1"

LOCALCONF_VERSION = "2"

PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES = "largefile opengl ptest multiarch wayland vulkan systemd pam virtualization usrmerge"

DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES}"

# Jetson platforms do not use linux-yocto, but for QEMU testing
# align with the poky distro.
PREFERRED_VERSION_linux-yocto ?= "5.19%"
PREFERRED_VERSION_linux-yocto-rt ?= "5.19%"

SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"

TCLIBCAPPEND = ""

PACKAGE_CLASSES ?= "package_rpm"

SANITY_TESTED_DISTROS ?= " \
ubuntu-20.04 \n \
ubuntu-22.04 \n \
ubuntu-24.04 \n \
"

# Most NVIDIA-supplied services expect systemd
INIT_MANAGER = "systemd"

require conf/distro/include/no-static-libs.inc
require conf/distro/include/yocto-uninative.inc
require conf/distro/include/security_flags.inc
INHERIT += "uninative"

LICENSE_FLAGS_ACCEPTED += "commercial_faad2 commercial_x264"

USE_REDUNDANT_FLASH_LAYOUT_DEFAULT ?= "1"

INHERIT += "tegra-support-sanity"
ESDK_CLASS_INHERIT_DISABLE:append = " tegra-support-sanity"

BB_SIGNATURE_HANDLER ?= "OEEquivHash"
BB_HASHSERVE ??= "auto"

</syntaxhighlight>

===Step 3. Add base machine===

This step might not be required, if there is already a machine that can be used from a different meta-layer.
However, it is still recommended to create a custom machine configuration based on that machine in order to keep better order of the machine used in the custom Yocto build.

To create a custom machine, it is necessary to add a machine.conf file in the '''meta-layer/conf/machine''' directory.
For example, this is how the directory structure should look when adding a new machine to the custom meta-layer:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ └── machine
│ └── proventusnova-jetson-orin-nx-16-devkit.conf
└── README.md
</syntaxhighlight>

And, as a reference, here is a custom machine based on [https://github.com/OE4T/meta-tegra/blob/scarthgap/conf/machine/p3509-a02-p3767-0000.conf NVIDIA meta-tegra p3509-a02-p3767-0000] machine.

<syntaxhighlight lang="bash">
#@TYPE: Machine
#@NAME: Nvidia Jetson Orin NX 16GB (P3767-0000)
#@DESCRIPTION: Nvidia Jetson Orin NX 16GB module in P3509 carrier

TEGRA_FLASHVAR_PINMUX_CONFIG ?= "tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi"
TEGRA_FLASHVAR_PMC_CONFIG ?= "tegra234-mb1-bct-padvoltage-p3767-hdmi-a03.dtsi"
TEGRA_PLUGIN_MANAGER_OVERLAYS ?= "tegra234-carveouts.dtbo tegra-optee.dtbo tegra234-p3768-0000+p3767-0000-dynamic.dtbo tegra234-dcb-p3767-0000-hdmi.dtbo"
TEGRA_DCE_OVERLAY ?= "tegra234-dcb-p3767-0000-hdmi.dtbo"

require conf/machine/include/orin-nx.inc

</syntaxhighlight>

===Step 4. Add initial config template files===

Bitbake will require 2 configuration files for building an image:

'''bblayers.conf''': This file contains information about the location of the required meta-layers for the project.

'''local.conf''': This file contains general build configuration for bitbake. For instance, in this file it is possible to determine where to store downloads, cache and even which package management configuration to use.

Now, in order to simplify the configuration of a custom Yocto build, it is possible to include template configuration files on the custom meta-layer. This practice is encouraged in order to increase build repeatability.

These 2 files are generally created inside '''meta-layer/conf/templates/template-name'''.
For reference, this is how the directory structure would look like after the files are created:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ └── proventusnova
│ ├── bblayers.conf.sample
│ └── local.conf.sample
└── README.md
</syntaxhighlight>

Here is an example of a custom bblayers.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/bblayers.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
# Version of layers configuration, specific to
# each defined distro in the repository.
# Format: ${DISTRO}-<version>
TD_BBLAYERS_CONF_VERSION = "proventusnova-1"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
##OEROOT##/meta \
##OEROOT##/../meta-tegra \
##OEROOT##/../meta-tegra-community \
##OEROOT##/../meta-virtualization \
##OEROOT##/../meta-openembedded/meta-oe \
##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-openembedded/meta-networking \
##OEROOT##/../meta-openembedded/meta-filesystems \
"

</syntaxhighlight>

And, this is an example of a custom local.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/local.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
#
# Machine Selection
#
MACHINE ??= "proventusnova-jetson-orin-nx-16-devkit.conf"

#
# Where to place downloads
#
DL_DIR ?= "${TOPDIR}/../downloads"

#
# Where to place shared-state files
#
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"

#
# Where to place the build output
#
TMPDIR = "${TOPDIR}/tmp"

#
# Default policy (distro) config
#
DISTRO ?= "proventusnova"

#
# Package Management configuration
#
PACKAGE_CLASSES ?= "package_deb"

#
# SDK target architecture
#
SDKMACHINE ?= "x86_64"

#
# Extra image configuration defaults
#
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

#
# Additional image features
#
USER_CLASSES ?= "buildstats"

#
# Interactive shell configuration
#
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
HALT,${TMPDIR},100M,1K \
HALT,${DL_DIR},100M,1K \
HALT,${SSTATE_DIR},100M,1K \
HALT,/tmp,10M,1K"

#
# Qemu configuration
#
PACKAGECONFIG:append:pn-qemu-system-native = " sdl"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated.
CONF_VERSION = "1"

</syntaxhighlight>

===Step 5. Add base image recipe===

In order to create a custom image, it is necessary to add a custom image recipe file.
This file is usually added inside the '''meta-layer/recipes-layer/images''' directory.

For example:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ ├── bblayers.conf.sample
│ └── local.conf.sample
├── README.md
└── recipes-proventusnova
└── images
└── proventusnova-image-base.bb
</syntaxhighlight>

Once again, a custom image recipe can be based on another image recipe. And, it can also import other image recipes in order to include their base configurations.

As reference, the following image recipe was based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/recipes-demo/images/demo-image-base.bb NVIDIA tegra-demo-distro demo-image-base recipe]:

<syntaxhighlight lang="bash">
DESCRIPTION = "ProventusNova base image"
LICENSE = "CLOSED"

inherit core-image

IMAGE_FEATURES += "ssh-server-openssh debug-tweaks"

CORE_IMAGE_BASE_INSTALL += "systemd"
TOOLCHAIN_HOST_TASK += "nativesdk-packagegroup-cuda-sdk-host"

inherit nopackages

</syntaxhighlight>

How to create a custom yocto meta layer

2025-03-11T19:39:39Z

Andres: /* Step 5. Add base image recipe */

=Introduction=

This wiki will provide a detailed guide on how to create a custom Yocto meta-layer.

==Create Base Meta-Layer==

This section contains steps to create the base custom meta-layer.
After completion, the custom base meta-layer will contain the following parts:

* Custom layer configuration
* Custom distro configuration
* Custom machine
* Custom config template files
* Custom image recipe

===Step 1. Add base layer.conf file===

The layer configuration file provides Yocto with the configuration for the custom meta-layer.
It shall be stored in a directory called '''conf''' inside the base meta-layer directory, and it shall be named layer.conf.
According to the [https://docs.yoctoproject.org/dev/dev-manual/layers.html Yocto documentation] it is recommended to start from an existing layer.conf file from a different meta-layer and change it according to the custom requirements.

For instance, here is an example of how the directory structure should look after creating the layer.conf file.

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

An example layer.conf file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/layer.conf NVIDIA OE4T tegra_demo_distro] is shown in the following code snipped.

<syntaxhighlight lang="bash">
BBPATH =. "${LAYERDIR}:"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILES_DYNAMIC += "swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bb \
swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "proventusnova"
BBFILE_PATTERN_proventusnova = "^${LAYERDIR}/"
BBFILE_PRIORITY_proventusnova = "50"

LAYERVERSION_proventusnova = "4"
LAYERSERIES_COMPAT_proventusnova = "scarthgap"

# This is used by the tegra-distro-sanity bbclass
# to identify the distro layer directory during
# bblayers checks.
TD_DISTRO_LAYERDIR = "${LAYERDIR}"

</syntaxhighlight>

===Step 2. Add base distro config===

In order to add the initial distro configuration, it is necessary to create distro configuration file inside the '''meta-layer/conf/distro''' directory.

Here is an example of how the directory structure should look like:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

The same as with the layer.conf, it is easier to start with an existing distro configuration file and modify it in order to fit the project requirements. For example, the following corresponds to a distro configuration file based on the [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/distro/tegrademo.conf NVIDIA tegra_demo_distro]:

<syntaxhighlight lang="bash">
DISTRO = "proventusnova"
DISTRO_NAME = "ProventusNova Custom Distro"
DISTRO_VERSION_BASE = "1.0"
DISTRO_VERSION = "${DISTRO_VERSION_BASE}+snapshot-${METADATA_REVISION}"
DISTRO_CODENAME = "proventusnova"
SDK_VENDOR = "-proventusnova"
SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${METADATA_REVISION}','snapshot')}"
SDK_VERSION[vardepvalue] = "${SDK_VERSION}"

MAINTAINER = "ProventusNova team <support@proventusnova.com>"

TARGET_VENDOR = "-proventusnova"

# New ${DISTRO}-<version> setting for sanity checks.
# Increment version number (and the corresponding
# setting int the template bblayers.conf.sample file)
# each time the layer settings are changed.
REQUIRED_PROVENTUSNOVA_BBLAYERS_CONF_VERSION = "${DISTRO}-1"

LOCALCONF_VERSION = "2"

PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES = "largefile opengl ptest multiarch wayland vulkan systemd pam virtualization usrmerge"

DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES}"

# Jetson platforms do not use linux-yocto, but for QEMU testing
# align with the poky distro.
PREFERRED_VERSION_linux-yocto ?= "5.19%"
PREFERRED_VERSION_linux-yocto-rt ?= "5.19%"

SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"

TCLIBCAPPEND = ""

PACKAGE_CLASSES ?= "package_rpm"

SANITY_TESTED_DISTROS ?= " \
ubuntu-20.04 \n \
ubuntu-22.04 \n \
ubuntu-24.04 \n \
"

# Most NVIDIA-supplied services expect systemd
INIT_MANAGER = "systemd"

require conf/distro/include/no-static-libs.inc
require conf/distro/include/yocto-uninative.inc
require conf/distro/include/security_flags.inc
INHERIT += "uninative"

LICENSE_FLAGS_ACCEPTED += "commercial_faad2 commercial_x264"

USE_REDUNDANT_FLASH_LAYOUT_DEFAULT ?= "1"

INHERIT += "tegra-support-sanity"
ESDK_CLASS_INHERIT_DISABLE:append = " tegra-support-sanity"

BB_SIGNATURE_HANDLER ?= "OEEquivHash"
BB_HASHSERVE ??= "auto"

</syntaxhighlight>

===Step 3. Add base machine===

This step might not be required, if there is already a machine that can be used from a different meta-layer.
However, it is still recommended to create a custom machine configuration based on that machine in order to keep better order of the machine used in the custom Yocto build.

To create a custom machine, it is necessary to add a machine.conf file in the '''meta-layer/conf/machine''' directory.
For example, this is how the directory structure should look when adding a new machine to the custom meta-layer:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ └── machine
│ └── proventusnova-jetson-orin-nx-16-devkit.conf
└── README.md
</syntaxhighlight>

And, as a reference, here is a custom machine based on [https://github.com/OE4T/meta-tegra/blob/scarthgap/conf/machine/p3509-a02-p3767-0000.conf NVIDIA meta-tegra p3509-a02-p3767-0000] machine.

<syntaxhighlight lang="bash">
#@TYPE: Machine
#@NAME: Nvidia Jetson Orin NX 16GB (P3767-0000)
#@DESCRIPTION: Nvidia Jetson Orin NX 16GB module in P3509 carrier

TEGRA_FLASHVAR_PINMUX_CONFIG ?= "tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi"
TEGRA_FLASHVAR_PMC_CONFIG ?= "tegra234-mb1-bct-padvoltage-p3767-hdmi-a03.dtsi"
TEGRA_PLUGIN_MANAGER_OVERLAYS ?= "tegra234-carveouts.dtbo tegra-optee.dtbo tegra234-p3768-0000+p3767-0000-dynamic.dtbo tegra234-dcb-p3767-0000-hdmi.dtbo"
TEGRA_DCE_OVERLAY ?= "tegra234-dcb-p3767-0000-hdmi.dtbo"

require conf/machine/include/orin-nx.inc

</syntaxhighlight>

===Step 4. Add initial config template files===

Bitbake will require 2 configuration files for building an image:

'''bblayers.conf''': This file contains information about the location of the required meta-layers for the project.

'''local.conf''': This file contains general build configuration for bitbake. For instance, in this file it is possible to determine where to store downloads, cache and even which package management configuration to use.

Now, in order to simplify the configuration of a custom Yocto build, it is possible to include template configuration files on the custom meta-layer. This practice is encouraged in order to increase build repeatability.

These 2 files are generally created inside '''meta-layer/conf/templates'''.
For reference, this is how the directory structure would look like after the files are created:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ ├── bblayers.conf.sample
│ └── local.conf.sample
└── README.md
</syntaxhighlight>

Here is an example of a custom bblayers.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/bblayers.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
# Version of layers configuration, specific to
# each defined distro in the repository.
# Format: ${DISTRO}-<version>
TD_BBLAYERS_CONF_VERSION = "proventusnova-1"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
##OEROOT##/meta \
##OEROOT##/../meta-tegra \
##OEROOT##/../meta-tegra-community \
##OEROOT##/../meta-virtualization \
##OEROOT##/../meta-openembedded/meta-oe \
##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-openembedded/meta-networking \
##OEROOT##/../meta-openembedded/meta-filesystems \
"

</syntaxhighlight>

And, this is an example of a custom local.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/local.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
#
# Machine Selection
#
MACHINE ??= "proventusnova-jetson-orin-nx-16-devkit.conf"

#
# Where to place downloads
#
DL_DIR ?= "${TOPDIR}/../downloads"

#
# Where to place shared-state files
#
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"

#
# Where to place the build output
#
TMPDIR = "${TOPDIR}/tmp"

#
# Default policy (distro) config
#
DISTRO ?= "proventusnova"

#
# Package Management configuration
#
PACKAGE_CLASSES ?= "package_deb"

#
# SDK target architecture
#
SDKMACHINE ?= "x86_64"

#
# Extra image configuration defaults
#
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

#
# Additional image features
#
USER_CLASSES ?= "buildstats"

#
# Interactive shell configuration
#
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
HALT,${TMPDIR},100M,1K \
HALT,${DL_DIR},100M,1K \
HALT,${SSTATE_DIR},100M,1K \
HALT,/tmp,10M,1K"

#
# Qemu configuration
#
PACKAGECONFIG:append:pn-qemu-system-native = " sdl"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated.
CONF_VERSION = "1"

</syntaxhighlight>

===Step 5. Add base image recipe===

In order to create a custom image, it is necessary to add a custom image recipe file.
This file is usually added inside the '''meta-layer/recipes-layer/images''' directory.

For example:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ ├── bblayers.conf.sample
│ └── local.conf.sample
├── README.md
└── recipes-proventusnova
└── images
└── proventusnova-image-base.bb
</syntaxhighlight>

Once again, a custom image recipe can be based on another image recipe. And, it can also import other image recipes in order to include their base configurations.

As reference, the following image recipe was based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/recipes-demo/images/demo-image-base.bb NVIDIA tegra-demo-distro demo-image-base recipe]:

<syntaxhighlight lang="bash">
DESCRIPTION = "ProventusNova base image"
LICENSE = "CLOSED"

inherit core-image

IMAGE_FEATURES += "ssh-server-openssh debug-tweaks"

CORE_IMAGE_BASE_INSTALL += "systemd"
TOOLCHAIN_HOST_TASK += "nativesdk-packagegroup-cuda-sdk-host"

inherit nopackages

</syntaxhighlight>

How to create a custom yocto meta layer

2025-03-11T19:24:43Z

Andres: /* Step 4. Add initial config template files */

=Introduction=

This wiki will provide a detailed guide on how to create a custom Yocto meta-layer.

==Create Base Meta-Layer==

This section contains steps to create the base custom meta-layer.
After completion, the custom base meta-layer will contain the following parts:

* Custom layer configuration
* Custom distro configuration
* Custom machine
* Custom config template files
* Custom image recipe

===Step 1. Add base layer.conf file===

The layer configuration file provides Yocto with the configuration for the custom meta-layer.
It shall be stored in a directory called '''conf''' inside the base meta-layer directory, and it shall be named layer.conf.
According to the [https://docs.yoctoproject.org/dev/dev-manual/layers.html Yocto documentation] it is recommended to start from an existing layer.conf file from a different meta-layer and change it according to the custom requirements.

For instance, here is an example of how the directory structure should look after creating the layer.conf file.

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

An example layer.conf file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/layer.conf NVIDIA OE4T tegra_demo_distro] is shown in the following code snipped.

<syntaxhighlight lang="bash">
BBPATH =. "${LAYERDIR}:"
BBFILES += "${LAYERDIR}/recipes-*/*/*.bb ${LAYERDIR}/recipes-*/*/*.bbappend"
BBFILES_DYNAMIC += "swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bb \
swupdate:${LAYERDIR}/dynamic-layers/meta-swupdate/recipes-*/*/*.bbappend"

BBFILE_COLLECTIONS += "proventusnova"
BBFILE_PATTERN_proventusnova = "^${LAYERDIR}/"
BBFILE_PRIORITY_proventusnova = "50"

LAYERVERSION_proventusnova = "4"
LAYERSERIES_COMPAT_proventusnova = "scarthgap"

# This is used by the tegra-distro-sanity bbclass
# to identify the distro layer directory during
# bblayers checks.
TD_DISTRO_LAYERDIR = "${LAYERDIR}"

</syntaxhighlight>

===Step 2. Add base distro config===

In order to add the initial distro configuration, it is necessary to create distro configuration file inside the '''meta-layer/conf/distro''' directory.

Here is an example of how the directory structure should look like:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ └── layer.conf
└── README.md
</syntaxhighlight>

The same as with the layer.conf, it is easier to start with an existing distro configuration file and modify it in order to fit the project requirements. For example, the following corresponds to a distro configuration file based on the [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/distro/tegrademo.conf NVIDIA tegra_demo_distro]:

<syntaxhighlight lang="bash">
DISTRO = "proventusnova"
DISTRO_NAME = "ProventusNova Custom Distro"
DISTRO_VERSION_BASE = "1.0"
DISTRO_VERSION = "${DISTRO_VERSION_BASE}+snapshot-${METADATA_REVISION}"
DISTRO_CODENAME = "proventusnova"
SDK_VENDOR = "-proventusnova"
SDK_VERSION := "${@'${DISTRO_VERSION}'.replace('snapshot-${METADATA_REVISION}','snapshot')}"
SDK_VERSION[vardepvalue] = "${SDK_VERSION}"

MAINTAINER = "ProventusNova team <support@proventusnova.com>"

TARGET_VENDOR = "-proventusnova"

# New ${DISTRO}-<version> setting for sanity checks.
# Increment version number (and the corresponding
# setting int the template bblayers.conf.sample file)
# each time the layer settings are changed.
REQUIRED_PROVENTUSNOVA_BBLAYERS_CONF_VERSION = "${DISTRO}-1"

LOCALCONF_VERSION = "2"

PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES = "largefile opengl ptest multiarch wayland vulkan systemd pam virtualization usrmerge"

DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT} ${PROVENTUSNOVA_DEFAULT_DISTRO_FEATURES}"

# Jetson platforms do not use linux-yocto, but for QEMU testing
# align with the poky distro.
PREFERRED_VERSION_linux-yocto ?= "5.19%"
PREFERRED_VERSION_linux-yocto-rt ?= "5.19%"

SDK_NAME = "${DISTRO}-${TCLIBC}-${SDKMACHINE}-${IMAGE_BASENAME}-${TUNE_PKGARCH}-${MACHINE}"
SDKPATHINSTALL = "/opt/${DISTRO}/${SDK_VERSION}"

TCLIBCAPPEND = ""

PACKAGE_CLASSES ?= "package_rpm"

SANITY_TESTED_DISTROS ?= " \
ubuntu-20.04 \n \
ubuntu-22.04 \n \
ubuntu-24.04 \n \
"

# Most NVIDIA-supplied services expect systemd
INIT_MANAGER = "systemd"

require conf/distro/include/no-static-libs.inc
require conf/distro/include/yocto-uninative.inc
require conf/distro/include/security_flags.inc
INHERIT += "uninative"

LICENSE_FLAGS_ACCEPTED += "commercial_faad2 commercial_x264"

USE_REDUNDANT_FLASH_LAYOUT_DEFAULT ?= "1"

INHERIT += "tegra-support-sanity"
ESDK_CLASS_INHERIT_DISABLE:append = " tegra-support-sanity"

BB_SIGNATURE_HANDLER ?= "OEEquivHash"
BB_HASHSERVE ??= "auto"

</syntaxhighlight>

===Step 3. Add base machine===

This step might not be required, if there is already a machine that can be used from a different meta-layer.
However, it is still recommended to create a custom machine configuration based on that machine in order to keep better order of the machine used in the custom Yocto build.

To create a custom machine, it is necessary to add a machine.conf file in the '''meta-layer/conf/machine''' directory.
For example, this is how the directory structure should look when adding a new machine to the custom meta-layer:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ └── machine
│ └── proventusnova-jetson-orin-nx-16-devkit.conf
└── README.md
</syntaxhighlight>

And, as a reference, here is a custom machine based on [https://github.com/OE4T/meta-tegra/blob/scarthgap/conf/machine/p3509-a02-p3767-0000.conf NVIDIA meta-tegra p3509-a02-p3767-0000] machine.

<syntaxhighlight lang="bash">
#@TYPE: Machine
#@NAME: Nvidia Jetson Orin NX 16GB (P3767-0000)
#@DESCRIPTION: Nvidia Jetson Orin NX 16GB module in P3509 carrier

TEGRA_FLASHVAR_PINMUX_CONFIG ?= "tegra234-mb1-bct-pinmux-p3767-hdmi-a03.dtsi"
TEGRA_FLASHVAR_PMC_CONFIG ?= "tegra234-mb1-bct-padvoltage-p3767-hdmi-a03.dtsi"
TEGRA_PLUGIN_MANAGER_OVERLAYS ?= "tegra234-carveouts.dtbo tegra-optee.dtbo tegra234-p3768-0000+p3767-0000-dynamic.dtbo tegra234-dcb-p3767-0000-hdmi.dtbo"
TEGRA_DCE_OVERLAY ?= "tegra234-dcb-p3767-0000-hdmi.dtbo"

require conf/machine/include/orin-nx.inc

</syntaxhighlight>

===Step 4. Add initial config template files===

Bitbake will require 2 configuration files for building an image:

'''bblayers.conf''': This file contains information about the location of the required meta-layers for the project.

'''local.conf''': This file contains general build configuration for bitbake. For instance, in this file it is possible to determine where to store downloads, cache and even which package management configuration to use.

Now, in order to simplify the configuration of a custom Yocto build, it is possible to include template configuration files on the custom meta-layer. This practice is encouraged in order to increase build repeatability.

These 2 files are generally created inside '''meta-layer/conf/templates'''.
For reference, this is how the directory structure would look like after the files are created:

<syntaxhighlight lang="bash">
meta-proventusnova/
├── conf
│ ├── distro
│ │ └── proventusnova.conf
│ ├── layer.conf
│ ├── machine
│ │ └── proventusnova-jetson-orin-nx-16-devkit.conf
│ └── templates
│ ├── bblayers.conf.sample
│ └── local.conf.sample
└── README.md
</syntaxhighlight>

Here is an example of a custom bblayers.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/bblayers.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
# Version of layers configuration, specific to
# each defined distro in the repository.
# Format: ${DISTRO}-<version>
TD_BBLAYERS_CONF_VERSION = "proventusnova-1"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
##OEROOT##/meta \
##OEROOT##/../meta-tegra \
##OEROOT##/../meta-tegra-community \
##OEROOT##/../meta-virtualization \
##OEROOT##/../meta-openembedded/meta-oe \
##OEROOT##/../meta-openembedded/meta-python \
##OEROOT##/../meta-openembedded/meta-networking \
##OEROOT##/../meta-openembedded/meta-filesystems \
"

</syntaxhighlight>

And, this is an example of a custom local.conf.sample file based on [https://github.com/OE4T/tegra-demo-distro/blob/scarthgap-l4t-r35.x/layers/meta-tegrademo/conf/templates/tegrademo/local.conf.sample NVIDIA tegra-demo-distro]:

<syntaxhighlight lang="bash">
#
# Machine Selection
#
MACHINE ??= "proventusnova-jetson-orin-nx-16-devkit.conf"

#
# Where to place downloads
#
DL_DIR ?= "${TOPDIR}/../downloads"

#
# Where to place shared-state files
#
SSTATE_DIR ?= "${TOPDIR}/../sstate-cache"

#
# Where to place the build output
#
TMPDIR = "${TOPDIR}/tmp"

#
# Default policy (distro) config
#
DISTRO ?= "proventusnova"

#
# Package Management configuration
#
PACKAGE_CLASSES ?= "package_deb"

#
# SDK target architecture
#
SDKMACHINE ?= "x86_64"

#
# Extra image configuration defaults
#
EXTRA_IMAGE_FEATURES ?= "debug-tweaks"

#
# Additional image features
#
USER_CLASSES ?= "buildstats"

#
# Interactive shell configuration
#
PATCHRESOLVE = "noop"

#
# Disk Space Monitoring during the build
#
BB_DISKMON_DIRS ??= "\
STOPTASKS,${TMPDIR},1G,100K \
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
HALT,${TMPDIR},100M,1K \
HALT,${DL_DIR},100M,1K \
HALT,${SSTATE_DIR},100M,1K \
HALT,/tmp,10M,1K"

#
# Qemu configuration
#
PACKAGECONFIG:append:pn-qemu-system-native = " sdl"

# CONF_VERSION is increased each time build/conf/ changes incompatibly and is used to
# track the version of this file when it was generated.
CONF_VERSION = "1"

</syntaxhighlight>

===Step 5. Add base image recipe===

How to create a custom yocto meta layer

2025-03-11T18:36:07Z

Andres: /* Step 3. Add base machine */

How to create a custom yocto meta layer

2025-03-11T18:04:25Z

Andres: /* Step 2. Add base distro config */

How to create a custom yocto meta layer

2025-03-11T18:00:20Z

Andres: /* Step 2. Add base distro config */

How to create a custom yocto meta layer

2025-03-11T17:35:18Z

Andres: /* Step 1. Add base layer.conf file */

How to create a custom yocto meta layer

2025-03-11T17:30:21Z

Andres: /* Step 1. Add base layer.conf file */

How to create a custom yocto meta layer

2025-03-11T16:23:28Z

Andres: /* Step 1. Add base layer.conf file */

How to create a custom yocto meta layer

2025-03-11T15:53:57Z

Andres: /* Create Base Meta-Layer */

How to create a custom yocto meta layer

2025-03-11T15:51:46Z

Andres: Created page with "=Introduction= This wiki will provide a detailed guide on how to create a custom Yocto meta-layer. ==Create Base Meta-Layer== This section contains steps to create the base custom meta-layer. After completion, the custom base meta-layer will contain the following parts: * Custom layer configuration * Custom distro configuration * Custom machine * Custom config template files * Custom image recipe '''Step 1. Add base layer.conf file''' '''Step 2. Add base distro con..."

Main Page

2025-02-15T19:06:48Z

Andres:

= Welcome to the ProventusNova Developer Wiki =
'''Expert knowledge for Embedded Systems, AI, and Software Development.'''

Looking to build high-performance embedded systems, optimize AI models, or streamline multimedia processing? This wiki is a '''public knowledge hub''' designed to help engineers, developers, and businesses solve real-world technical challenges.

Here, you’ll find '''step-by-step tutorials, best practices, and deep technical insights''' to help you bring your projects to life.

== 🚀 What You’ll Find Here ==
* '''Hands-on Tutorials''' – Practical guides to get you started quickly.
* '''Industry Best Practices''' – Proven workflows and methodologies.
* '''Optimized Solutions''' – Performance tuning for embedded, AI, and multimedia applications.
* '''Open-Source Resources''' – Code samples, frameworks, and tools to accelerate development.

Whether you're an individual developer, a startup, or an enterprise, you’ll find resources here to '''enhance your expertise and improve your products'''.





== ⚙️ Technical Resources ==
* [[Embedded Systems Development]] – BSPs, firmware, and real-time processing.
* [[AI & Computer Vision]] – Edge AI, model training, and deployment.
* [[GStreamer Development]] – High-performance video and audio streaming.
* [[Web & Cloud Solutions]] – Scalable, production-ready applications.

== 🏗 Need a Solution for Your Project? ==
Are you looking for ways to:
✅ Optimize your '''embedded system''' for better performance?
✅ Integrate '''AI and computer vision''' into your products?
✅ Improve '''multimedia processing''' for real-time applications?
✅ Develop a '''robust and scalable''' web platform?

Our team has helped businesses across multiple industries solve these challenges.

📩 '''Let’s collaborate!''' Contact us at '''[support@proventusnova.com](mailto:support@proventusnova.com)''' or visit '''[ProventusNova.com](https://proventusnova.com)''' to discuss your project.