0.1.6

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlays in-tree

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

The official overlays are built in-tree, and is delivered as part of the kernel package.

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 build 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 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 indvidual 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 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 after:

/ {
	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. 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 products 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 a 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 user to connect 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.6

radxa-overlays (0.1.6) jammy; urgency=medium
.
  [ ZHANG Yuntian ]
  * feat: add radxa-zero-emmc-full-speed.dts
  * format: use multiline text instead of \n
  * fix: use constant instead of magic numbers
  * format: reorder overlays alphabetically
  * feat: add CM3 LVDS overlay
.
  [ Alvin Xie ]
  * rock 5a/5c: modify rpi 7inch display proch
  * rock 5c: add spi module support
.
  [ RadxaMitchell ]
  * update rk3588-i2c6-m0.dts
  * fix: rk3588-spi0-m1-cs0-mcp2515-8mhz.dts
.
  [ Feng Zhang ]
  * arm64: overlays: Add overlay description for rock 5c

0.1.5

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlays in-tree

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

The official overlays are built in-tree, and is delivered as part of the kernel package.

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 build 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 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 indvidual 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 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 after:

/ {
	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. 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 products 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 a 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 user to connect 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.5

radxa-overlays (0.1.5) jammy; urgency=medium
.
  [ Nascs Fang ]
  * rock 3c: add exclusive for i2c3
  * rockchip: extracted from waveshare35 public section
.
  [ Radxa-Alvin ]
  * rk3568 npu add rock 3c and zero3 support
.
  [ Alvin Xie ]
  * zero3: add radxa camera 8m
  * add cs003 display
.
  [ Ken Wang ]
  * radxa cm5 rpi cm4 io: modify camera config for dual cameras
  * add and update overlays for radxa-cm5-rpi-cm4-io
  * modify rock5b+ display backlight pwm polarity
  * add and update some overlays for rock5itx

0.1.4

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlays in-tree

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

The official overlays are built in-tree, and is delivered as part of the kernel package.

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 build 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 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 indvidual 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 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 after:

/ {
	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. 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 products 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 a 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 user to connect 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.4

radxa-overlays (0.1.4) jammy; urgency=medium
.
  [ Feng Zhang ]
  * rock 5a/5c: raspi-7inch-tc: add display-timing
.
  [ Alvin Xie ]
  * radxa cm3i io: modify okdo 5mp config for dual cameras
.
  [ Stephen Chen ]
  * add rk3588-enable-sdhci
.
  [ Nascs Fang ]
  * radxa zero: add pwm overlays
  * radxa zero: add led-8-off dtsi
  * radxa zero: add uart-ao-b-89 for v1.51 and later
.
  [ Peiyu Wu ]
  * add Waveshare 3.5inch RPi LCD (C) support for rock-3c

0.1.3

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlays in-tree

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

The official overlays are built in-tree, and is delivered as part of the kernel package.

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 build 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 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 indvidual 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 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 after:

/ {
	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. 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 products 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 a 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 user to connect 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.3

radxa-overlays (0.1.3) jammy; urgency=medium
.
  [ SongJun Li ]
  * rock 2a: add eeprom support on i2c1-m0
  * rock 2a: add tve support
  * rock 2a: modify usb otg compatible to unknown
  * rock 2a: add usb host and peripheral support
.
  [ Ken Wang ]
  * update rk3588-pwm1-m2 compatible
  * modify rock5b+ display backlight pwm polarity
.
  [ Stephen Chen ]
  * rock 2a: add PCIe support
.
  [ CodeChenL ]
  * fix: display backlight pwm polarity use macro variables
  * refactor: ROCK series overlays are replaced with reference syntax
  * refactor: all amlogic overlays are replaced with reference syntax
  * refactor: ZERO series overlays are replaced with reference syntax
  * refactor: Radxa S0 overlay are replaced with reference syntax
.
  [ Alvin Xie ]
  * radxa cm3i io: modify camera config for dual cameras
  * radxa cm5 io: modify camera config for dual cameras

0.1.2

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlays in-tree

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

The official overlays are built in-tree, and is delivered as part of the kernel package.

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 build 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 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 indvidual 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 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 after:

/ {
	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. 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 products 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 a 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 user to connect 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.2

radxa-overlays (0.1.2) jammy; urgency=medium
.
  [ ZHANG Yuntian ]
  * fix: trigger rebuild_overlays after installing

0.1.0

overlays

Additional device tree overlays to support different hardware on Radxa products

Build overlays in-tree

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

The official overlays are built in-tree, and is delivered as part of the kernel package.

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 build 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 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 indvidual run.

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

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 after:

/ {
	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. 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 products 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 a 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 user to connect 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.0

radxa-overlays (0.1.0) jammy; urgency=medium
.
  [ "Radxa Computer Co., Ltd" ]
  * Initial release