|
| 1 | +# Development |
| 2 | + |
| 3 | +## Build overlays locally |
| 4 | + |
| 5 | +First, make sure you have the running kernel header, `gcc`, and `device-tree-compiler` installed. |
| 6 | + |
| 7 | +You can then run the following command to build overlays: |
| 8 | + |
| 9 | +```bash |
| 10 | +make build-dtbo -j$(nproc) |
| 11 | +``` |
| 12 | + |
| 13 | +Please be aware this only builds a subset of overlays, and any overlays that depend on vendor headers will fail, |
| 14 | +as this command will use the current system's kernel header. |
| 15 | + |
| 16 | +Please take a look at the [CI workflow](.github/workflows/test.yaml) to see how to select installed vendor kernel header. |
| 17 | + |
| 18 | +To delete built overlays, run the following command: |
| 19 | + |
| 20 | +```bash |
| 21 | +make clean |
| 22 | +``` |
| 23 | + |
| 24 | +## Download prebuilt artifacts |
| 25 | + |
| 26 | +As part of our CI pipeline, the built overlays are uploaded at the end. You can find all CI runs [here](https://github.com/radxa/overlays/actions), and the artifact is located inside each run. |
| 27 | + |
| 28 | +Please be aware that artifacts expire over time, and they are not officially tested versions. |
| 29 | + |
| 30 | +## Code style |
| 31 | + |
| 32 | +We mandate reference style for our overlays. Please visit the [DTO Syntax](https://source.android.com/docs/core/architecture/dto/syntax#reference) page to learn more. |
| 33 | + |
| 34 | +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: |
| 35 | + |
| 36 | +```dtos |
| 37 | +/{ |
| 38 | + fragment@0 { |
| 39 | + target-path = "/"; |
| 40 | + __overlay__ { |
| 41 | + some_node: some-node { |
| 42 | + some_prop = "okay"; |
| 43 | + ... |
| 44 | + }; |
| 45 | + }; |
| 46 | + }; |
| 47 | +} |
| 48 | +``` |
| 49 | + |
| 50 | +```dtos |
| 51 | +&{/} { |
| 52 | + some_node: some-node { |
| 53 | + some_prop = "okay"; |
| 54 | + ... |
| 55 | + }; |
| 56 | +} |
| 57 | +``` |
| 58 | + |
| 59 | +## Metadata specs |
| 60 | + |
| 61 | +Currently, we mandate a custom `metadata` node in overlays. This data is parsed by [`rsetup`](https://github.com/radxa-pkg/rsetup) to provide a human-readable description and conflict detection. Below is a sample `metadata` node with detailed guidelines: |
| 62 | + |
| 63 | +``` |
| 64 | +/ { |
| 65 | + metadata { |
| 66 | + title = "Enable ENC28J60 on SPI2"; |
| 67 | + category = "misc"; |
| 68 | + compatible = "unknown"; |
| 69 | + description = "Enable Microchip ENC28J60 SPI Ethernet controller on SPI2.\nINT=40"; |
| 70 | + exclusive = "GPIO2_B3", "GPIO2_B2", "GPIO2_B1", "GPIO2_B4", "GPIO4_A7"; |
| 71 | + package = "dkms-enc28j60"; |
| 72 | + }; |
| 73 | +}; |
| 74 | +``` |
| 75 | + |
| 76 | +### A. Title (string) |
| 77 | + |
| 78 | +1. `title` should not contain the product name. |
| 79 | + `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. |
| 80 | +2. `title` should not end with a period. |
| 81 | + |
| 82 | +### B. Category (string) |
| 83 | + |
| 84 | +1. `category` currently can be one of the following: |
| 85 | + camera, display, misc |
| 86 | + |
| 87 | +### C. Compatible (array) |
| 88 | + |
| 89 | +1. `compatible` should not be an SoC unless it is truly compatible with every product using that SoC. |
| 90 | + `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. |
| 91 | + Explicit products list should be preferred to generic SoC matching. |
| 92 | +2. If an overlay is broken, `compatible` should be `unknown`. |
| 93 | + |
| 94 | +### D. Description (string) |
| 95 | + |
| 96 | +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. |
| 97 | +2. Newline in `description` should use `\n`. |
| 98 | +3. Hardware parameters should be listed at the end to help the user connecting their devices. |
| 99 | + |
| 100 | +### E. Exclusive (array) |
| 101 | + |
| 102 | +1. `exclusive` should refer to the device tree node and property. |
| 103 | +2. For features that are muxed to a GPIO line, `exclusive` should be the GPIO ID. |
| 104 | +3. For features that use multiple GPIO lines, they should all be listed under `exclusive`. |
| 105 | +4. For complex overlay, list all GPIO lines used. |
| 106 | + For exaple, some devices may use GPIO for interrupt, which is also used by another overlay. |
| 107 | + |
| 108 | +### F. Package (array) |
| 109 | + |
| 110 | +1. `package` specify the additional packages to be used with this overlay. |
| 111 | +2. When the overlay is disabled, the specified package will NOT be removed. |
0 commit comments