0.1.20

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlay dkms package

Due to the much more frequent development happening on the overlay compared to
the kernel in general, we are once again splitting the overlay into a dedicated package.

However, to guarantee the overlay is compatible with the installed kernel, this
package will be delivered as a source code package using dkms, instead of a prebuilt
binary package.

You can build the dkms package using the below commands:

sudo apt-get update
sudo apt-get build-dep --no-install-recommends -y .
make all deb

Build overlays in-tree

You will need this patch so this repo can be built with the kernel.

This is how overlays were distributed previously as part of the kernel package.
We are still supporting this for older kernels. Newer kernels like Rockchip 6.1
kernel will use the above dkms package instead.

Build overlays locally

First, make sure you have the running kernel header, gcc, and device-tree-compiler installed.

You can then run the following command to build overlays:

make build-dtbo -j$(nproc)

Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail,
as this command will use the current system's kernel header.

Please take a look at the CI workflow to see how to select installed vendor kernel header.

To delete built overlays, run the following command:

make clean

Download prebuilt artifacts

As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs here, and the artifact is located inside each run.

Please be aware that artifacts expire over time, and they are not officially tested versions.

Code style

We mandate reference style for our overlays. Please visit the DTO Syntax page to learn more.

If your existing overlay uses target-path, then the Android documentation does not show a clear migration path. Below is an example of how to convert them:

/{
	fragment@0 {
		target-path = "/";
		__overlay__ {
			some_node: some-node {
				some_prop = "okay";
				...
			};
		};
	};
}

&{/} {
	some_node: some-node {
		some_prop = "okay";
		...
	};
}

Metadata specs

Currently, we mandate a custom metadata node in overlays. This data is parsed by rsetup to provide a human-readable description and conflict detection. Below is a sample metadata node with detailed guidelines:

/ {
	metadata {
		title = "Enable ENC28J60 on SPI2";
		category = "misc";
		compatible = "unknown";
		description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40";
		exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7";
		package = "dkms-enc28j60";
	};
};

A. Title (string)

1. title should not contain the product name.
   rsetup will only show compatible overlays with compatible field defined. As such, do not confuse users to second guess if an overlay is truly compatible when the product name is not explicitly mentioned.
2. title should not end with a period.

B. Category (string)

1. category currently can be one of the following:
   camera, display, misc

C. Compatible (array)

1. compatible should not be an SoC unless it is truly compatible with every product using that SoC.
   rsetup will match the base device tree's compatible with the overlay's compatible. As long as one value from each match, the overlay is considered compatible. Since most products' device tree contains their SoC in compatible, setting SoC in overlay's compatible will make it compatible with every such product.
   Explicit products list should be preferred to generic SoC matching.
2. If an overlay is broken, compatible should be unknown.

D. Description (string)

1. description is a multi-line text to describe the function of the overlay. It can be the same as title with an ending period.
2. Newline in description should use \n.
3. Hardware parameters should be listed at the end to help the user connecting their devices.

E. Exclusive (array)

1. exclusive should refer to the device tree node and property.
2. For features that are muxed to a GPIO line, exclusive should be the GPIO ID.
3. For features that use multiple GPIO lines, they should all be listed under exclusive.
4. For complex overlay, list all GPIO lines used.
   For exaple, some devices may use GPIO for interrupt, which is also used by another overlay.

F. Package (array)

1. package specify the additional packages to be used with this overlay.
2. When the overlay is disabled, the specified package will NOT be removed.

Changelog for 0.1.20

radxa-overlays (0.1.20) jammy; urgency=medium
.
  [ ZHANG Yuntian ]
  * fix: update linux-rk2410 header package URL
  * feat: add rk3308-uart1-full
.
  [ Ken Wang ]
  * feat: add vp1 for 8K HDMI output
.
  [ Chen Jiali ]
  * feat: add rock-3ab-max98357a

0.1.19

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlay dkms package

Due to the much more frequent development happening on the overlay compared to
the kernel in general, we are once again splitting the overlay into a dedicated package.

However, to guarantee the overlay is compatible with the installed kernel, this
package will be delivered as a source code package using dkms, instead of a prebuilt
binary package.

You can build the dkms package using the below commands:

sudo apt-get update
sudo apt-get build-dep --no-install-recommends -y .
make all deb

Build overlays in-tree

You will need this patch so this repo can be built with the kernel.

This is how overlays were distributed previously as part of the kernel package.
We are still supporting this for older kernels. Newer kernels like Rockchip 6.1
kernel will use the above dkms package instead.

Build overlays locally

First, make sure you have the running kernel header, gcc, and device-tree-compiler installed.

You can then run the following command to build overlays:

make build-dtbo -j$(nproc)

Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail,
as this command will use the current system's kernel header.

Please take a look at the CI workflow to see how to select installed vendor kernel header.

To delete built overlays, run the following command:

make clean

Download prebuilt artifacts

As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs here, and the artifact is located inside each run.

Please be aware that artifacts expire over time, and they are not officially tested versions.

Code style

We mandate reference style for our overlays. Please visit the DTO Syntax page to learn more.

If your existing overlay uses target-path, then the Android documentation does not show a clear migration path. Below is an example of how to convert them:

/{
	fragment@0 {
		target-path = "/";
		__overlay__ {
			some_node: some-node {
				some_prop = "okay";
				...
			};
		};
	};
}

&{/} {
	some_node: some-node {
		some_prop = "okay";
		...
	};
}

Metadata specs

Currently, we mandate a custom metadata node in overlays. This data is parsed by rsetup to provide a human-readable description and conflict detection. Below is a sample metadata node with detailed guidelines:

/ {
	metadata {
		title = "Enable ENC28J60 on SPI2";
		category = "misc";
		compatible = "unknown";
		description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40";
		exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7";
		package = "dkms-enc28j60";
	};
};

A. Title (string)

1. title should not contain the product name.
   rsetup will only show compatible overlays with compatible field defined. As such, do not confuse users to second guess if an overlay is truly compatible when the product name is not explicitly mentioned.
2. title should not end with a period.

B. Category (string)

1. category currently can be one of the following:
   camera, display, misc

C. Compatible (array)

1. compatible should not be an SoC unless it is truly compatible with every product using that SoC.
   rsetup will match the base device tree's compatible with the overlay's compatible. As long as one value from each match, the overlay is considered compatible. Since most products' device tree contains their SoC in compatible, setting SoC in overlay's compatible will make it compatible with every such product.
   Explicit products list should be preferred to generic SoC matching.
2. If an overlay is broken, compatible should be unknown.

D. Description (string)

1. description is a multi-line text to describe the function of the overlay. It can be the same as title with an ending period.
2. Newline in description should use \n.
3. Hardware parameters should be listed at the end to help the user connecting their devices.

E. Exclusive (array)

1. exclusive should refer to the device tree node and property.
2. For features that are muxed to a GPIO line, exclusive should be the GPIO ID.
3. For features that use multiple GPIO lines, they should all be listed under exclusive.
4. For complex overlay, list all GPIO lines used.
   For exaple, some devices may use GPIO for interrupt, which is also used by another overlay.

F. Package (array)

1. package specify the additional packages to be used with this overlay.
2. When the overlay is disabled, the specified package will NOT be removed.

Changelog for 0.1.19

radxa-overlays (0.1.19) jammy; urgency=medium
.
  [ ZHANG Yuntian ]
  * feat: add RK3576 SoC and rk2410 kernel support
.
  [ Ken Wang ]
  * feat: add overlays description for rock 5t
.
  [ Chen Jiali ]
  * feat: rockchip: completion of renamed macro definitions
.
  [ Logan147 ]
  * feat: add radxa-zero-spi-b-waveshare13

0.1.18

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlay dkms package

Due to the much more frequent development happening on the overlay compared to
the kernel in general, we are once again splitting the overlay into a dedicated package.

However, to guarantee the overlay is compatible with the installed kernel, this
package will be delivered as a source code package using dkms, instead of a prebuilt
binary package.

You can build the dkms package using the below commands:

sudo apt-get update
sudo apt-get build-dep --no-install-recommends -y .
make all deb

Build overlays in-tree

You will need this patch so this repo can be built with the kernel.

This is how overlays were distributed previously as part of the kernel package.
We are still supporting this for older kernels. Newer kernels like Rockchip 6.1
kernel will use the above dkms package instead.

Build overlays locally

First, make sure you have the running kernel header, gcc, and device-tree-compiler installed.

You can then run the following command to build overlays:

make build-dtbo -j$(nproc)

Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail,
as this command will use the current system's kernel header.

Please take a look at the CI workflow to see how to select installed vendor kernel header.

To delete built overlays, run the following command:

make clean

Download prebuilt artifacts

As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs here, and the artifact is located inside each run.

Please be aware that artifacts expire over time, and they are not officially tested versions.

Code style

We mandate reference style for our overlays. Please visit the DTO Syntax page to learn more.

If your existing overlay uses target-path, then the Android documentation does not show a clear migration path. Below is an example of how to convert them:

/{
	fragment@0 {
		target-path = "/";
		__overlay__ {
			some_node: some-node {
				some_prop = "okay";
				...
			};
		};
	};
}

&{/} {
	some_node: some-node {
		some_prop = "okay";
		...
	};
}

Metadata specs

Currently, we mandate a custom metadata node in overlays. This data is parsed by rsetup to provide a human-readable description and conflict detection. Below is a sample metadata node with detailed guidelines:

/ {
	metadata {
		title = "Enable ENC28J60 on SPI2";
		category = "misc";
		compatible = "unknown";
		description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40";
		exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7";
		package = "dkms-enc28j60";
	};
};

A. Title (string)

1. title should not contain the product name.
   rsetup will only show compatible overlays with compatible field defined. As such, do not confuse users to second guess if an overlay is truly compatible when the product name is not explicitly mentioned.
2. title should not end with a period.

B. Category (string)

1. category currently can be one of the following:
   camera, display, misc

C. Compatible (array)

1. compatible should not be an SoC unless it is truly compatible with every product using that SoC.
   rsetup will match the base device tree's compatible with the overlay's compatible. As long as one value from each match, the overlay is considered compatible. Since most products' device tree contains their SoC in compatible, setting SoC in overlay's compatible will make it compatible with every such product.
   Explicit products list should be preferred to generic SoC matching.
2. If an overlay is broken, compatible should be unknown.

D. Description (string)

1. description is a multi-line text to describe the function of the overlay. It can be the same as title with an ending period.
2. Newline in description should use \n.
3. Hardware parameters should be listed at the end to help the user connecting their devices.

E. Exclusive (array)

1. exclusive should refer to the device tree node and property.
2. For features that are muxed to a GPIO line, exclusive should be the GPIO ID.
3. For features that use multiple GPIO lines, they should all be listed under exclusive.
4. For complex overlay, list all GPIO lines used.
   For exaple, some devices may use GPIO for interrupt, which is also used by another overlay.

F. Package (array)

1. package specify the additional packages to be used with this overlay.
2. When the overlay is disabled, the specified package will NOT be removed.

Changelog for 0.1.18

radxa-overlays (0.1.18) jammy; urgency=medium
.
  [ ZHANG Yuntian ]
  * feat: add rk3588-uart1-m1
  * fix: fiq_debugger must be disabled when using uart2-m0 pins
  * feat: clean additional files created by DKMS build
  * feat: add (non-working) GPIO IR overlay
  * docs: explicitly require all GPIOs to be listed in exclusive
.
  [ Chen Jiali ]
  * feat: add overlay rk3308-pdm-m2
  * feat: add rk3568-hdmi-disable and rockchip-gpu-disable
.
  [ Ken Wang ]
  * feat: add dsi1_backlight enable-gpios and change vcc_lcd_mipi1 enable gpio
  * feat: cm3: enable dual imx219 camera
.
  [ 叶离 ]
  * feat:add radxa-zero-spi-b-waveshare35b

0.1.17

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlay dkms package

Due to the much more frequent development happening on the overlay compared to
the kernel in general, we are once again splitting the overlay into a dedicated package.

However, to guarantee the overlay is compatible with the installed kernel, this
package will be delivered as a source code package using dkms, instead of a prebuilt
binary package.

You can build the dkms package using the below commands:

sudo apt-get update
sudo apt-get build-dep --no-install-recommends -y .
make all deb

Build overlays in-tree

You will need this patch so this repo can be built with the kernel.

This is how overlays were distributed previously as part of the kernel package.
We are still supporting this for older kernels. Newer kernels like Rockchip 6.1
kernel will use the above dkms package instead.

Build overlays locally

First, make sure you have the running kernel header, gcc, and device-tree-compiler installed.

You can then run the following command to build overlays:

make build-dtbo -j$(nproc)

Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail,
as this command will use the current system's kernel header.

Please take a look at the CI workflow to see how to select installed vendor kernel header.

To delete built overlays, run the following command:

make clean

Download prebuilt artifacts

As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs here, and the artifact is located inside each run.

Please be aware that artifacts expire over time, and they are not officially tested versions.

Code style

We mandate reference style for our overlays. Please visit the DTO Syntax page to learn more.

If your existing overlay uses target-path, then the Android documentation does not show a clear migration path. Below is an example of how to convert them:

/{
	fragment@0 {
		target-path = "/";
		__overlay__ {
			some_node: some-node {
				some_prop = "okay";
				...
			};
		};
	};
}

&{/} {
	some_node: some-node {
		some_prop = "okay";
		...
	};
}

Metadata specs

Currently, we mandate a custom metadata node in overlays. This data is parsed by rsetup to provide a human-readable description and conflict detection. Below is a sample metadata node with detailed guidelines:

/ {
	metadata {
		title = "Enable ENC28J60 on SPI2";
		category = "misc";
		compatible = "unknown";
		description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40";
		exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7";
		package = "dkms-enc28j60";
	};
};

A. Title (string)

1. title should not contain the product name.
   rsetup will only show compatible overlays with compatible field defined. As such, do not confuse users to second guess if an overlay is truly compatible when the product name is not explicitly mentioned.
2. title should not end with a period.

B. Category (string)

1. category currently can be one of the following:
   camera, display, misc

C. Compatible (array)

1. compatible should not be an SoC unless it is truly compatible with every product using that SoC.
   rsetup will match the base device tree's compatible with the overlay's compatible. As long as one value from each match, the overlay is considered compatible. Since most products' device tree contains their SoC in compatible, setting SoC in overlay's compatible will make it compatible with every such product.
   Explicit products list should be preferred to generic SoC matching.
2. If an overlay is broken, compatible should be unknown.

D. Description (string)

1. description is a multi-line text to describe the function of the overlay. It can be the same as title with an ending period.
2. Newline in description should use \n.
3. Hardware parameters should be listed at the end to help the user connecting their devices.

E. Exclusive (array)

1. exclusive should refer to the device tree node and property.
2. For features that are muxed to a GPIO line, exclusive should be the GPIO ID.
3. For features that use multiple GPIO lines, they should all be listed under exclusive.

F. Package (array)

1. package specify the additional packages to be used with this overlay.
2. When the overlay is disabled, the specified package will NOT be removed.

Changelog for 0.1.17

radxa-overlays (0.1.17) jammy; urgency=medium
.
  [ Ken Wang ]
  * add some overlays support for rock 5t
.
  [ Chen Jiali ]
  * feat: add rockchip-uart-dma
.
  [ ZHANG Yuntian ]
  * fix: correctly disable FIQ debugger
  * refactor: reuse existing FIQ debugger overlay
  * feat: add pcf8563 overlay
.
  [ Nascs Fang ]
  * feat: add PCIe2x1 on rock 3a
.
  [ vickash ]
  * Add zero3 to rk3568-i2c5-m0.dts
  * Add rock-3c to rk3568-i2c5-m0.dts

0.1.16

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlay dkms package

Due to the much more frequent development happening on the overlay compared to
the kernel in general, we are once again splitting the overlay into a dedicated package.

However, to guarantee the overlay is compatible with the installed kernel, this
package will be delivered as a source code package using dkms, instead of a prebuilt
binary package.

You can build the dkms package using the below commands:

sudo apt-get update
sudo apt-get build-dep --no-install-recommends -y .
make all deb

Build overlays in-tree

You will need this patch so this repo can be built with the kernel.

This is how overlays were distributed previously as part of the kernel package.
We are still supporting this for older kernels. Newer kernels like Rockchip 6.1
kernel will use the above dkms package instead.

Build overlays locally

First, make sure you have the running kernel header, gcc, and device-tree-compiler installed.

You can then run the following command to build overlays:

make build-dtbo -j$(nproc)

Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail,
as this command will use the current system's kernel header.

Please take a look at the CI workflow to see how to select installed vendor kernel header.

To delete built overlays, run the following command:

make clean

Download prebuilt artifacts

As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs here, and the artifact is located inside each run.

Please be aware that artifacts expire over time, and they are not officially tested versions.

Code style

We mandate reference style for our overlays. Please visit the DTO Syntax page to learn more.

If your existing overlay uses target-path, then the Android documentation does not show a clear migration path. Below is an example of how to convert them:

/{
	fragment@0 {
		target-path = "/";
		__overlay__ {
			some_node: some-node {
				some_prop = "okay";
				...
			};
		};
	};
}

&{/} {
	some_node: some-node {
		some_prop = "okay";
		...
	};
}

Metadata specs

Currently, we mandate a custom metadata node in overlays. This data is parsed by rsetup to provide a human-readable description and conflict detection. Below is a sample metadata node with detailed guidelines:

/ {
	metadata {
		title = "Enable ENC28J60 on SPI2";
		category = "misc";
		compatible = "unknown";
		description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40";
		exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7";
		package = "dkms-enc28j60";
	};
};

A. Title (string)

1. title should not contain the product name.
   rsetup will only show compatible overlays with compatible field defined. As such, do not confuse users to second guess if an overlay is truly compatible when the product name is not explicitly mentioned.
2. title should not end with a period.

B. Category (string)

1. category currently can be one of the following:
   camera, display, misc

C. Compatible (array)

1. compatible should not be an SoC unless it is truly compatible with every product using that SoC.
   rsetup will match the base device tree's compatible with the overlay's compatible. As long as one value from each match, the overlay is considered compatible. Since most products' device tree contains their SoC in compatible, setting SoC in overlay's compatible will make it compatible with every such product.
   Explicit products list should be preferred to generic SoC matching.
2. If an overlay is broken, compatible should be unknown.

D. Description (string)

1. description is a multi-line text to describe the function of the overlay. It can be the same as title with an ending period.
2. Newline in description should use \n.
3. Hardware parameters should be listed at the end to help the user connecting their devices.

E. Exclusive (array)

1. exclusive should refer to the device tree node and property.
2. For features that are muxed to a GPIO line, exclusive should be the GPIO ID.
3. For features that use multiple GPIO lines, they should all be listed under exclusive.

F. Package (array)

1. package specify the additional packages to be used with this overlay.
2. When the overlay is disabled, the specified package will NOT be removed.

Changelog for 0.1.16

radxa-overlays (0.1.16) jammy; urgency=medium
.
  [ Chen Jiali ]
  * feat: rk3588: add two i2s2 sound card
.
  [ Ken Wang ]
  * update some overlays for radxa cm5 io

0.1.15

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlay dkms package

Due to the much more frequent development happening on the overlay compared to
the kernel in general, we are once again splitting the overlay into a dedicated package.

However, to guarantee the overlay is compatible with the installed kernel, this
package will be delivered as a source code package using dkms, instead of a prebuilt
binary package.

You can build the dkms package using the below commands:

sudo apt-get update
sudo apt-get build-dep --no-install-recommends -y .
make all deb

Build overlays in-tree

You will need this patch so this repo can be built with the kernel.

This is how overlays were distributed previously as part of the kernel package.
We are still supporting this for older kernels. Newer kernels like Rockchip 6.1
kernel will use the above dkms package instead.

Build overlays locally

First, make sure you have the running kernel header, gcc, and device-tree-compiler installed.

You can then run the following command to build overlays:

make build-dtbo -j$(nproc)

Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail,
as this command will use the current system's kernel header.

Please take a look at the CI workflow to see how to select installed vendor kernel header.

To delete built overlays, run the following command:

make clean

Download prebuilt artifacts

As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs here, and the artifact is located inside each run.

Please be aware that artifacts expire over time, and they are not officially tested versions.

Code style

We mandate reference style for our overlays. Please visit the DTO Syntax page to learn more.

If your existing overlay uses target-path, then the Android documentation does not show a clear migration path. Below is an example of how to convert them:

/{
	fragment@0 {
		target-path = "/";
		__overlay__ {
			some_node: some-node {
				some_prop = "okay";
				...
			};
		};
	};
}

&{/} {
	some_node: some-node {
		some_prop = "okay";
		...
	};
}

Metadata specs

Currently, we mandate a custom metadata node in overlays. This data is parsed by rsetup to provide a human-readable description and conflict detection. Below is a sample metadata node with detailed guidelines:

/ {
	metadata {
		title = "Enable ENC28J60 on SPI2";
		category = "misc";
		compatible = "unknown";
		description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40";
		exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7";
		package = "dkms-enc28j60";
	};
};

A. Title (string)

1. title should not contain the product name.
   rsetup will only show compatible overlays with compatible field defined. As such, do not confuse users to second guess if an overlay is truly compatible when the product name is not explicitly mentioned.
2. title should not end with a period.

B. Category (string)

1. category currently can be one of the following:
   camera, display, misc

C. Compatible (array)

1. compatible should not be an SoC unless it is truly compatible with every product using that SoC.
   rsetup will match the base device tree's compatible with the overlay's compatible. As long as one value from each match, the overlay is considered compatible. Since most products' device tree contains their SoC in compatible, setting SoC in overlay's compatible will make it compatible with every such product.
   Explicit products list should be preferred to generic SoC matching.
2. If an overlay is broken, compatible should be unknown.

D. Description (string)

1. description is a multi-line text to describe the function of the overlay. It can be the same as title with an ending period.
2. Newline in description should use \n.
3. Hardware parameters should be listed at the end to help the user connecting their devices.

E. Exclusive (array)

1. exclusive should refer to the device tree node and property.
2. For features that are muxed to a GPIO line, exclusive should be the GPIO ID.
3. For features that use multiple GPIO lines, they should all be listed under exclusive.

F. Package (array)

1. package specify the additional packages to be used with this overlay.
2. When the overlay is disabled, the specified package will NOT be removed.

Changelog for 0.1.15

radxa-overlays (0.1.15) jammy; urgency=medium
.
  [ Ken Wang ]
  * add i2c/pwm for radxa cm5 rpi cm4 io
.
  [ ZHANG Yuntian ]
  * fix: resolve some build warnings
  * fix: consolidate CI workflows
  * docs: update build guide

0.1.14

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlay dkms package

Due to the much more frequent development happening on the overlay compared to
the kernel in general, we are once again splitting the overlay into a dedicated package.

However, to guarantee the overlay is compatible with the installed kernel, this
package will be delivered as a source code package using dkms, instead of a prebuilt
binary package.

You can build the dkms package using the below commands:

sudo apt-get update
sudo apt-get build-dep --no-install-recommends -y .
make all deb

Build overlays in-tree

You will need this patch so this repo can be built with the kernel.

This is how overlays were distributed previously as part of the kernel package.
We are still supporting this for older kernels. Newer kernels like Rockchip 6.1
kernel will use the above dkms package instead.

Build overlays locally

First, make sure you have the running kernel header, gcc, and device-tree-compiler installed.

You can then run the following command to build overlays:

make -j$(nproc)

Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail. This is because the Makefile is intended to find overlays that are incompatible with the upstream kernel.

To delete built overlays, run the following command:

make clean

Download prebuilt artifacts

As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs here, and the artifact is located inside each run.

Please be aware that artifacts expire over time, and they are not officially tested versions.

Code style

We mandate reference style for our overlays. Please visit the DTO Syntax page to learn more.

If your existing overlay uses target-path, then the Android documentation does not show a clear migration path. Below is an example of how to convert them:

/{
	fragment@0 {
		target-path = "/";
		__overlay__ {
			some_node: some-node {
				some_prop = "okay";
				...
			};
		};
	};
}

&{/} {
	some_node: some-node {
		some_prop = "okay";
		...
	};
}

Metadata specs

Currently, we mandate a custom metadata node in overlays. This data is parsed by rsetup to provide a human-readable description and conflict detection. Below is a sample metadata node with detailed guidelines:

/ {
	metadata {
		title = "Enable ENC28J60 on SPI2";
		category = "misc";
		compatible = "unknown";
		description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40";
		exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7";
		package = "dkms-enc28j60";
	};
};

A. Title (string)

1. title should not contain the product name.
   rsetup will only show compatible overlays with compatible field defined. As such, do not confuse users to second guess if an overlay is truly compatible when the product name is not explicitly mentioned.
2. title should not end with a period.

B. Category (string)

1. category currently can be one of the following:
   camera, display, misc

C. Compatible (array)

1. compatible should not be an SoC unless it is truly compatible with every product using that SoC.
   rsetup will match the base device tree's compatible with the overlay's compatible. As long as one value from each match, the overlay is considered compatible. Since most products' device tree contains their SoC in compatible, setting SoC in overlay's compatible will make it compatible with every such product.
   Explicit products list should be preferred to generic SoC matching.
2. If an overlay is broken, compatible should be unknown.

D. Description (string)

1. description is a multi-line text to describe the function of the overlay. It can be the same as title with an ending period.
2. Newline in description should use \n.
3. Hardware parameters should be listed at the end to help the user connecting their devices.

E. Exclusive (array)

1. exclusive should refer to the device tree node and property.
2. For features that are muxed to a GPIO line, exclusive should be the GPIO ID.
3. For features that use multiple GPIO lines, they should all be listed under exclusive.

F. Package (array)

1. package specify the additional packages to be used with this overlay.
2. When the overlay is disabled, the specified package will NOT be removed.

Changelog for 0.1.14

radxa-overlays (0.1.14) jammy; urgency=medium
.
  [ Nascs Fang ]
  * fix: delete cm3-io waveshare35 support
  * fix: replace the interrupt pin from gpio3_c6 to gpio4_c5
  * feat: add waveshare lcd for 5a/5c/5d
.
  [ ZHANG Yuntian ]
  * fix: update GPIOZ_6's interrupt number
.
  [ Ken Wang ]
  * cm5io: add dwc3 host and devices support

0.1.13

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlay dkms package

Due to the much more frequent development happening on the overlay compared to
the kernel in general, we are once again splitting the overlay into a dedicated package.

However, to guarantee the overlay is compatible with the installed kernel, this
package will be delivered as a source code package using dkms, instead of a prebuilt
binary package.

You can build the dkms package using the below commands:

sudo apt-get update
sudo apt-get build-dep --no-install-recommends -y .
make all deb

Build overlays in-tree

You will need this patch so this repo can be built with the kernel.

This is how overlays were distributed previously as part of the kernel package.
We are still supporting this for older kernels. Newer kernels like Rockchip 6.1
kernel will use the above dkms package instead.

Build overlays locally

First, make sure you have the running kernel header, gcc, and device-tree-compiler installed.

You can then run the following command to build overlays:

make -j$(nproc)

Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail. This is because the Makefile is intended to find overlays that are incompatible with the upstream kernel.

To delete built overlays, run the following command:

make clean

Download prebuilt artifacts

As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs here, and the artifact is located inside each run.

Please be aware that artifacts expire over time, and they are not officially tested versions.

Code style

We mandate reference style for our overlays. Please visit the DTO Syntax page to learn more.

If your existing overlay uses target-path, then the Android documentation does not show a clear migration path. Below is an example of how to convert them:

/{
	fragment@0 {
		target-path = "/";
		__overlay__ {
			some_node: some-node {
				some_prop = "okay";
				...
			};
		};
	};
}

&{/} {
	some_node: some-node {
		some_prop = "okay";
		...
	};
}

Metadata specs

Currently, we mandate a custom metadata node in overlays. This data is parsed by rsetup to provide a human-readable description and conflict detection. Below is a sample metadata node with detailed guidelines:

/ {
	metadata {
		title = "Enable ENC28J60 on SPI2";
		category = "misc";
		compatible = "unknown";
		description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40";
		exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7";
		package = "dkms-enc28j60";
	};
};

A. Title (string)

1. title should not contain the product name.
   rsetup will only show compatible overlays with compatible field defined. As such, do not confuse users to second guess if an overlay is truly compatible when the product name is not explicitly mentioned.
2. title should not end with a period.

B. Category (string)

1. category currently can be one of the following:
   camera, display, misc

C. Compatible (array)

1. compatible should not be an SoC unless it is truly compatible with every product using that SoC.
   rsetup will match the base device tree's compatible with the overlay's compatible. As long as one value from each match, the overlay is considered compatible. Since most products' device tree contains their SoC in compatible, setting SoC in overlay's compatible will make it compatible with every such product.
   Explicit products list should be preferred to generic SoC matching.
2. If an overlay is broken, compatible should be unknown.

D. Description (string)

1. description is a multi-line text to describe the function of the overlay. It can be the same as title with an ending period.
2. Newline in description should use \n.
3. Hardware parameters should be listed at the end to help the user connecting their devices.

E. Exclusive (array)

1. exclusive should refer to the device tree node and property.
2. For features that are muxed to a GPIO line, exclusive should be the GPIO ID.
3. For features that use multiple GPIO lines, they should all be listed under exclusive.

F. Package (array)

1. package specify the additional packages to be used with this overlay.
2. When the overlay is disabled, the specified package will NOT be removed.

Changelog for 0.1.13

radxa-overlays (0.1.13) jammy; urgency=medium
.
  [ ZHANG Yuntian ]
  * fix: clean up RK3568 SPI3 exclusive
.
  [ Mitchell Ma ]
  * overlays: rk3588: add pull-up on i2c3-m1 and i2c8-m4
  * overlays: disable i2c1-m0 for ROCK5B/ROCK5B+
  * overlays: enable radxa 25w poe for ROCK5B+
.
  [ Feng Zhang ]
  * rock 5d: add radxa 8mp camera support on camera interface

0.1.12

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlay dkms package

Due to the much more frequent development happening on the overlay compared to
the kernel in general, we are once again splitting the overlay into a dedicated package.

However, to guarantee the overlay is compatible with the installed kernel, this
package will be delivered as a source code package using dkms, instead of a prebuilt
binary package.

You can build the dkms package using the below commands:

sudo apt-get update
sudo apt-get build-dep --no-install-recommends -y .
make all deb

Build overlays in-tree

You will need this patch so this repo can be built with the kernel.

This is how overlays were distributed previously as part of the kernel package.
We are still supporting this for older kernels. Newer kernels like Rockchip 6.1
kernel will use the above dkms package instead.

Build overlays locally

First, make sure you have the running kernel header, gcc, and device-tree-compiler installed.

You can then run the following command to build overlays:

make -j$(nproc)

Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail. This is because the Makefile is intended to find overlays that are incompatible with the upstream kernel.

To delete built overlays, run the following command:

make clean

Download prebuilt artifacts

As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs here, and the artifact is located inside each run.

Please be aware that artifacts expire over time, and they are not officially tested versions.

Code style

We mandate reference style for our overlays. Please visit the DTO Syntax page to learn more.

If your existing overlay uses target-path, then the Android documentation does not show a clear migration path. Below is an example of how to convert them:

/{
	fragment@0 {
		target-path = "/";
		__overlay__ {
			some_node: some-node {
				some_prop = "okay";
				...
			};
		};
	};
}

&{/} {
	some_node: some-node {
		some_prop = "okay";
		...
	};
}

Metadata specs

Currently, we mandate a custom metadata node in overlays. This data is parsed by rsetup to provide a human-readable description and conflict detection. Below is a sample metadata node with detailed guidelines:

/ {
	metadata {
		title = "Enable ENC28J60 on SPI2";
		category = "misc";
		compatible = "unknown";
		description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40";
		exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7";
		package = "dkms-enc28j60";
	};
};

A. Title (string)

1. title should not contain the product name.
   rsetup will only show compatible overlays with compatible field defined. As such, do not confuse users to second guess if an overlay is truly compatible when the product name is not explicitly mentioned.
2. title should not end with a period.

B. Category (string)

1. category currently can be one of the following:
   camera, display, misc

C. Compatible (array)

1. compatible should not be an SoC unless it is truly compatible with every product using that SoC.
   rsetup will match the base device tree's compatible with the overlay's compatible. As long as one value from each match, the overlay is considered compatible. Since most products' device tree contains their SoC in compatible, setting SoC in overlay's compatible will make it compatible with every such product.
   Explicit products list should be preferred to generic SoC matching.
2. If an overlay is broken, compatible should be unknown.

D. Description (string)

1. description is a multi-line text to describe the function of the overlay. It can be the same as title with an ending period.
2. Newline in description should use \n.
3. Hardware parameters should be listed at the end to help the user connecting their devices.

E. Exclusive (array)

1. exclusive should refer to the device tree node and property.
2. For features that are muxed to a GPIO line, exclusive should be the GPIO ID.
3. For features that use multiple GPIO lines, they should all be listed under exclusive.

F. Package (array)

1. package specify the additional packages to be used with this overlay.
2. When the overlay is disabled, the specified package will NOT be removed.

Changelog for 0.1.12

radxa-overlays (0.1.12) jammy; urgency=medium
.
  [ Feng Zhang ]
  * rock 5d: add antenna toggle switch
.
  [ ZHANG Yuntian ]
  * feat: add overlays to turn off power supply to ROCK 4 USB ports
  * feat: add missing RK3399 PWM overlays
  * fix: do not disable regulator to override power
  * fix: update USB regulator overlay description
.
  [ Nascs Fang ]
  * fix: remove i2c4-m3 from rock-5b-plus
  * feat: open i2c8-m4 for rock-5b-plus
  * feat: open uart4-m2 for rock-5b-plus
.
  [ SongJun Li ]
  * feat: add rock 2f to the overlays of the rk3528 series
  * feat: add medge-rk3528a io board to the overlays of the rk3528 series
.
  [ Stephen Chen ]
  * feat: radxa-e52c: add support for setting usb host and peripheral mode

0.1.11

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlay dkms package

Due to the much more frequent development happening on the overlay compared to
the kernel in general, we are once again splitting the overlay into a dedicated package.

However, to guarantee the overlay is compatible with the installed kernel, this
package will be delivered as a source code package using dkms, instead of a prebuilt
binary package.

You can build the dkms package using the below commands:

sudo apt-get update
sudo apt-get build-dep --no-install-recommends -y .
make all deb

Build overlays in-tree

You will need this patch so this repo can be built with the kernel.

This is how overlays were distributed previously as part of the kernel package.
We are still supporting this for older kernels. Newer kernels like Rockchip 6.1
kernel will use the above dkms package instead.

Build overlays locally

First, make sure you have the running kernel header, gcc, and device-tree-compiler installed.

You can then run the following command to build overlays:

make -j$(nproc)

Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail. This is because the Makefile is intended to find overlays that are incompatible with the upstream kernel.

To delete built overlays, run the following command:

make clean

Download prebuilt artifacts

As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs here, and the artifact is located inside each run.

Please be aware that artifacts expire over time, and they are not officially tested versions.

Code style

We mandate reference style for our overlays. Please visit the DTO Syntax page to learn more.

If your existing overlay uses target-path, then the Android documentation does not show a clear migration path. Below is an example of how to convert them:

/{
	fragment@0 {
		target-path = "/";
		__overlay__ {
			some_node: some-node {
				some_prop = "okay";
				...
			};
		};
	};
}

&{/} {
	some_node: some-node {
		some_prop = "okay";
		...
	};
}

Metadata specs

Currently, we mandate a custom metadata node in overlays. This data is parsed by rsetup to provide a human-readable description and conflict detection. Below is a sample metadata node with detailed guidelines:

/ {
	metadata {
		title = "Enable ENC28J60 on SPI2";
		category = "misc";
		compatible = "unknown";
		description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40";
		exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7";
		package = "dkms-enc28j60";
	};
};

A. Title (string)

1. title should not contain the product name.
   rsetup will only show compatible overlays with compatible field defined. As such, do not confuse users to second guess if an overlay is truly compatible when the product name is not explicitly mentioned.
2. title should not end with a period.

B. Category (string)

1. category currently can be one of the following:
   camera, display, misc

C. Compatible (array)

1. compatible should not be an SoC unless it is truly compatible with every product using that SoC.
   rsetup will match the base device tree's compatible with the overlay's compatible. As long as one value from each match, the overlay is considered compatible. Since most products' device tree contains their SoC in compatible, setting SoC in overlay's compatible will make it compatible with every such product.
   Explicit products list should be preferred to generic SoC matching.
2. If an overlay is broken, compatible should be unknown.

D. Description (string)

1. description is a multi-line text to describe the function of the overlay. It can be the same as title with an ending period.
2. Newline in description should use \n.
3. Hardware parameters should be listed at the end to help the user connecting their devices.

E. Exclusive (array)

1. exclusive should refer to the device tree node and property.
2. For features that are muxed to a GPIO line, exclusive should be the GPIO ID.
3. For features that use multiple GPIO lines, they should all be listed under exclusive.

F. Package (array)

1. package specify the additional packages to be used with this overlay.
2. When the overlay is disabled, the specified package will NOT be removed.

Changelog for 0.1.11

radxa-overlays (0.1.11) jammy; urgency=medium
.
  [ CodeChenL ]
  * fix: add missing #address-cells and #size-cells properties
  * fix: remove the null ranges property
  * fix: correct wrong device tree node name
  * fix: add missing node numbers
  * fix: add missing interrupt-parent property
  * fix: remove redundant pinctrl and cs-gpios definitions
  * fix: modify correct node index
.
  [ ZHANG Yuntian ]
  * fix: print warning message
  * fix: update broken link
  * fix: correct grammar issues
  * fix: document the new distribution method
  * fix: add comment to note why we need to adjust system settings
.
  [ bsp ]
  * rk3588: add i2s1_8ch dummy sound card overlay
.
  [ Nascs Fang ]
  * feat: add w5500 support for rk3568-spi3
.
  [ Ken Wang ]
  * overlays: enable uart7-m2 for rock5b+
  * overlays: add some camera support for rock5b+