Menion Posted December 7, 2017 Posted December 7, 2017 Hi all Can you suggest some online resource for learning the dts overlay syntax? I am ok with adding things, I have found something about deleting things, but what if I want to change something? Is it delete and add in the same fragment? One fragment to delete and the next one to add? Thanks! 0 Quote
zador.blood.stained Posted December 9, 2017 Author Posted December 9, 2017 On 07.12.2017 at 11:24 AM, Menion said: Can you suggest some online resource for learning the dts overlay syntax? I'm not sure what (besides the device-tree-compiler source code) should be used as a reference for the advanced functionality (/delete-property/, /delete-node/, etc.). On 07.12.2017 at 11:24 AM, Menion said: I am ok with adding things, I have found something about deleting things, but what if I want to change something? Is it delete and add in the same fragment? One fragment to delete and the next one to add? I guess you can do everything in one fragment, overriding and deleting not needed properties to get the end result 0 Quote
Menion Posted December 11, 2017 Posted December 11, 2017 Thanks. Do you know if it is possible to perform a sort of "dry run" of the dtb+overlay combination in order to check the final results without having to load it on the real target? 0 Quote
Menion Posted December 12, 2017 Posted December 12, 2017 Hi all Maybe someone can help I want to change node: r-gpio-keys but the syntax: fragment@0 { target = <&r-gpio-keys>; prompt a syntax error. The problem are the "-" in the node name. Something like target = <&leds> is accepted. So how can select such node? 0 Quote
zador.blood.stained Posted December 12, 2017 Author Posted December 12, 2017 5 minutes ago, Menion said: So how can select such node? Looks like it is a node name, not a label, so using "target" wouldn't work anyway. You should use "target-path" instead. 0 Quote
Menion Posted December 12, 2017 Posted December 12, 2017 Thanks @zador.blood.stained Apparently the dtbo I have made works, I have tested them merging everything with fdtoverlay tool One question: the overlay under /boot/overlay-user are loaded matching the name with overlay_prefix variable in /boot/armbianEnv.txt, or they are just all loaded? 0 Quote
zador.blood.stained Posted December 12, 2017 Author Posted December 12, 2017 20 minutes ago, Menion said: One question: the overlay under /boot/overlay-user are loaded matching the name with overlay_prefix variable in /boot/armbianEnv.txt, or they are just all loaded? Overlays in /boot/overlay-user are matched by the full name, overlay_prefix applies only to packaged overlays in /boot/dtb/.... 0 Quote
Menion Posted December 12, 2017 Posted December 12, 2017 So, I need to list somewhere which overlay uboot shall pick up in overlay-user or all of them are loaded? Also, sorry, but I need another quick help. I want to set musb to host mode only, so I did this: Quote /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h5"; fragment@0 { target-path = "/usb@01c19000"; __overlay__ { /delete-property/ dr_mode; dr_mode = "host"; }; }; }; In the original dtb, the node is: Quote usb@01c19000 { compatible = "allwinner,sun8i-h3-musb"; reg = <0x1c19000 0x400>; clocks = <0x6 0x20>; resets = <0x6 0x11>; interrupts = <0x0 0x47 0x4>; interrupt-names = "mc"; phys = <0x16 0x0>; phy-names = "usb"; extcon = <0x16 0x0>; status = "okay"; dr_mode = "otg"; linux,phandle = <0x44>; phandle = <0x44>; }; The dts compile fine, but ftdoverlay return error -1 applying the fragment.... Do you know why? Thanks! 0 Quote
zador.blood.stained Posted December 12, 2017 Author Posted December 12, 2017 4 minutes ago, Menion said: The dts compile fine, but ftdoverlay return error -1 applying the fragment.... Do you know why? You don't need the "/delete-property/ dr_mode;" line, you should just overwrite dr_mode without deleting the old one (since there can't be 2 properties with the same name old value will be replaced by the new one). 7 minutes ago, Menion said: So, I need to list somewhere which overlay uboot shall pick up in overlay-user or all of them are loaded? They should be listed in "user_overlays" line in armbianEnv.txt. AFAIK u-boot can't iterate through files in a directory so they need to be listed explicitly. 0 Quote
Menion Posted December 12, 2017 Posted December 12, 2017 I have also tried to remove the "/delete-property/ dr_mode", same problem It can be a problem with fdtoverlay, but what happens to the boot process if I put a failing overlay? 0 Quote
zador.blood.stained Posted December 12, 2017 Author Posted December 12, 2017 Now that I look at it - your target path is wrong, on H3/H5 devices it should be "/soc/usb@01c19000", or, since it has a label, you can use "target = <&usb_otg>;" 0 Quote
Menion Posted December 12, 2017 Posted December 12, 2017 You are right! The soc node is very long! Thanks!!!! Anyhow, if it may be of any little interest, two overlay I think are usefull for orangepipc2: one set the red led to mmc activity, the other one set the power switch to issue an acpi shutdown event, so you can gracefully shutdown the board without having to log in the console Bye 0 Quote
zador.blood.stained Posted December 12, 2017 Author Posted December 12, 2017 3 minutes ago, Menion said: Anyhow, if it may be of any little interest, two overlay I think are usefull for orangepipc2: one set the red led to mmc activity, the other one set the power switch to issue an acpi shutdown event, so you can gracefully shutdown the board without having to log in the console Packaging them by default may be rather complicated due to variations in buttons/LED names and available triggers, but they can be added to examples. 0 Quote
Menion Posted December 12, 2017 Posted December 12, 2017 I see also that in the rootfs there is an utility named "armbian-add-overlay" that takes as parameter an overlay dts Is something that automagically compile, put the dtbo in /boot/overlay-user and add the entry in armbianEnv.txt? 0 Quote
zador.blood.stained Posted December 12, 2017 Author Posted December 12, 2017 6 minutes ago, Menion said: Is something that automagically compile, put the dtbo in /boot/overlay-user and add the entry in armbianEnv.txt? Yes. 0 Quote
Menion Posted December 14, 2017 Posted December 14, 2017 Hi @zador.blood.stained There is something strange with one of the overlay, the red led. The overlay is: Quote /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h5"; fragment@0 { target-path = "/leds"; __overlay__ { status { linux,default-trigger = "mmc0"; }; }; }; }; According to the ftdoverlay output (including all the overlay I use) the parameter seems to be inserted: Quote leds { compatible = "gpio-leds"; pwr { label = "orangepi:green:pwr"; gpios = <0x34 0x0 0xa 0x0>; default-state = "on"; }; status { linux,default-trigger = "mmc0"; label = "orangepi:red:status"; gpios = <0x15 0x0 0x14 0x0>; }; }; parameter added, and nothing is changed compared to the original But then if I go in /proc/device-tree/leds/status/ I see the attribute: Quote menion@orangepipc2:/proc/device-tree/leds/status$ ls gpios label linux,default-trigger name menion@orangepipc2:/proc/device-tree/leds/status$ correct value also: Quote menion@orangepipc2:/proc/device-tree/leds/status$ cat linux,default-trigger mmc0menion@orangepipc2:/proc/device-tree/leds/status$ But the result now is that the green led is blinking! When I added manually the parameter in the dts it worked. The only thing is that the parameter was added as last in sub-node status Maybe you have some idea here Bye 0 Quote
dorchain Posted January 8, 2018 Posted January 8, 2018 Hello, still not pleased with the accuracy of the builtin rtc of my banana pi, I added a ds3231 module similar to the one described at https://thepihut.com/blogs/raspberry-pi-tutorials/17209332-adding-a-real-time-clock-to-your-raspberry-pi to it. With that, I noticed two things: - The example I started with at https://github.com/armbian/sunxi-DT-overlays/blob/master/examples/i2c-ds1307.dts contains a typo (a space too much between * and /) at line 11. - It is not completely easy to have an external rtc chip being the default rtc for the board. Anyway, here is the overlay I ended up with: /dts-v1/; /plugin/; / { compatible = "allwinner,sun4i-a10", "allwinner,sun7i-a20", "allwinner,su n8i-h3", "allwinner,sun50i-a64", "allwinner,sun50i-h5"; /* * Aliases can be used to set the external RTC as rtc0 * Needs supplying the correct path to the I2C controller RTC is connect ed to, * this example is for I2C1 on A20 */ fragment@0 { target-path = "/aliases"; __overlay__ { rtc1 = "/soc@01c00000/rtc@01c20d00"; }; }; fragment@1 { target-path = "/aliases"; __overlay__ { rtc0 = "/soc@01c00000/i2c@01c2b400/ds3231@68"; }; }; fragment@2 { target = <&i2c2>; __overlay__ { #address-cells = <1>; #size-cells = <0>; ds3231@68 { compatible = "maxim,ds3231"; reg = <0x68>; status = "okay"; }; }; }; }; Works fine through armbian-add-overlay and is currently in works-for-me state. Added bonus: the chip has a temperature sensor: # sensors ds3231-i2c-1-68 Adapter: mv64xxx_i2c adapter temp1: +19.8°C Bye, Joerg P.s.: These rtc-board are available also from your Chinese hardware crap dealer of least distrust for less than 1 USD. 0 Quote
daten Posted February 24, 2018 Posted February 24, 2018 Hey, I don't even manage to compile the DTS files. For example: https://github.com/armbian/sunxi-DT-overlays/blob/master/examples/spi-ads7846.dts $ dtc -I dts -O dtb -o foo.dtbo foo.dts foo.dtbo: Warning (unit_address_vs_reg): Node /fragment@0 has a unit name, but no reg property foo.dtbo: Warning (unit_address_vs_reg): Node /fragment@1 has a unit name, but no reg property foo.dtbo: Warning (gpios_property): Property 'pendown-gpio', cell 2 is not a phandle reference in /fragment@1/__overlay__/ads7846@0 foo.dtbo: Warning (gpios_property): Could not get phandle node for /fragment@1/__overlay__/ads7846@0:pendown-gpio(cell 2) dtc: livetree.c:521: get_node_by_phandle: Assertion `(phandle != 0) && (phandle != -1)' failed. Aborted The warnings don't even seem to be the issue - suppressing (-q) them and forcing compilation even with errors (-f) still results in the assert. Any hint? 0 Quote
zador.blood.stained Posted February 24, 2018 Author Posted February 24, 2018 3 minutes ago, daten said: Any hint? - device tree compiler (dtc) should be recent enough - either compile from here or use one from kernel headers - you need to tell dtc that you are compiling an overlay (add -@ command line parameter) 1 Quote
daten Posted February 24, 2018 Posted February 24, 2018 2 minutes ago, zador.blood.stained said: - device tree compiler (dtc) should be recent enough - either compile from here or use one from kernel headers - you need to tell dtc that you are compiling an overlay (add -@ command line parameter) The missing '-@' wasn't the issue, as I tried with and without. With the dtc from my linux-git clone it worked. Didn't expect my Debian (testing) version of dtc being the issue here - thanks for pointing me there! For reference, that's the version which caused me above stated trouble: ii device-tree-compiler 1.4.5-3 amd64 Device Tree Compiler for Flat Device Trees 0 Quote
zador.blood.stained Posted February 24, 2018 Author Posted February 24, 2018 1 minute ago, daten said: The missing '-@' wasn't the issue, as I tried with and without. Yes, now I remember that this argument is mostly relevant for the base DT files, not for overlays. 0 Quote
Dobrica Pavlinušić Posted March 8, 2018 Posted March 8, 2018 I'm experimenting with nand overlays and it seems to me that rootfs partition has wrong offset (in all overlays): Quote partition@1000000 { label = "env"; reg = <0x0 0x1000000 0x0 0x400000>; }; partition@1400000 { label = "rootfs"; reg = <0x0 0xa00000 0x01 0xff000000>; }; I think that 0xa00000 should be 0x1400000 ? Am I correct, and should I prepare pull request to fix it? 0 Quote
selfbg Posted April 24, 2018 Posted April 24, 2018 I've notice today, that fixup scripts are failing, if some parameters are passed. For example: if test -n "${param_spinor_spi_bus}"; then test "${param_spinor_spi_bus}" = "0" && setenv tmp_spi_path "spi@01c05000" test "${param_spinor_spi_bus}" = "1" && setenv tmp_spi_path "spi@01c06000" test "${param_spinor_spi_bus}" = "2" && setenv tmp_spi_path "spi@01c17000" fdt set /soc@01c00000/${tmp_spi_path} status "okay" fdt set /soc@01c00000/${tmp_spi_path}/spiflash status "okay" if test -n "${param_spinor_max_freq}"; then fdt set /soc@01c00000/${tmp_spi_path}/spiflash spi-max-frequency "<${param_spinor_max_freq}>" fi if test "${param_spinor_spi_bus}" = "0" && test "${param_spinor_spi_cs}" = "1"; then fdt set /soc@01c00000/${tmp_spi_path}/spiflash reg "<1>" fi env delete tmp_spi_path fi I get: libfdt fdt_path_offset() returned FDT_ERR_NOTFOUND This is caused because u-boot sets paths without leading zero: => fdt list / / { #address-cells = <0x00000001>; #size-cells = <0x00000001>; interrupt-parent = <0x00000001>; model = "Olimex A20-SOM204-EVB-eMMC"; compatible = "olimex,a20-olimex-som204-evb-emmc", "allwinner,sun7i-a20"; ... soc@1c00000 { }; ... }; => As you can see the path is /soc@1c00000 not /soc@01c00000. Does anyone have noticed this? 0 Quote
zador.blood.stained Posted April 24, 2018 Author Posted April 24, 2018 1 minute ago, selfbg said: Does anyone have noticed this? Our overlays should be working on kernel 4.14.x, as stated in the README. Our sunxi-next branch currently points to the kernel 4.14 which still has leading 0s in node names: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/tree/arch/arm/boot/dts/sun7i-a20.dtsi?h=linux-4.14.y -dev kernel branches (and sunxi-dev in this example) are usually not maintained well, and I definitely did not add overlays to it because they requires exactly this type of maintenance every couple of months. 0 Quote
selfbg Posted April 24, 2018 Posted April 24, 2018 How is this related to kernel version? The fixup script is executed inside u-boot? Both next and dev branches uses the same u-boot. EDIT: Sorry. I've answer my self. 0 Quote
zador.blood.stained Posted April 24, 2018 Author Posted April 24, 2018 1 minute ago, selfbg said: How is this related to kernel version? The fixup script code should match the contents of DT files. 2 minutes ago, selfbg said: The fixup script is executed inside u-boot? It is executed by the u-boot from the filesystem, and it is packaged with Device Trees and overlays in the kernel DT package. 0 Quote
Heisath Posted October 19, 2018 Posted October 19, 2018 Hi, I have the Banana Pi M1 and the Banana Pro and just received a I2S to Analogue Module. I'd love to use these together but unfortunately there is no device tree overlay available. The module is from Adafruit (https://learn.adafruit.com/adafruit-i2s-stereo-decoder-uda1334a) they also mention it is the same chip / driver that is also used by the Hifiberry DAC, there is support for Raspbian also with an overlay etc. (see the Raspberry PI kernel tree | https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/overlays/hifiberry-dac-overlay.dts). I tried adapting the overlay for usage with the Banana but didn't get it running. So any help would be greatly appreciated, I will then of course test and report. Also have a uart to usb cable to access uboot and can build images. This is what I have so far: /dts-v1/; /plugin/; / { compatible = "allwinner,sun7i-a20"; fragment@0 { target-path = "/"; __overlay__ { pcm5102a-codec { #sound-dai-cells = <0>; compatible = "ti,pcm5102a"; status = "okay"; }; }; }; fragment@1 { target = "/soc@01c00000"; __overlay__ { sound: sound { compatible = "hifiberry,hifiberry-dac"; i2s-controller = <&i2s0>; status = "okay"; }; }; }; }; Of course using above overlay and enabled I2S0 Port already with Armbian-Config / armbianEnv.txt and the provided overlay. Naturally there is a driver / codec required to get the Sound Module working, but I think we could use the driver from the Raspbian Kernel Source: https://github.com/raspberrypi/linux/blob/rpi-4.14.y/sound/soc/codecs/pcm5102a.c Doesn't seem to rely on anything raspberry specific. I would integrate, test and the do a PR on github, with this stuff, but need some help getting the overlay working first. Greetings, Count-Doku 0 Quote
martinayotte Posted October 19, 2018 Posted October 19, 2018 3 hours ago, count-doku said: Of course using above overlay and enabled I2S0 Port already Are you sure ? Did you verified in /proc/device-tree/ using "cat /proc/device-tree/soc@1c00000/i2s@1c22000/status" ? (because I2C != I2S ...) From the RPi link you provided you didn't kept those lines here : https://github.com/raspberrypi/linux/blob/rpi-4.14.y/arch/arm/boot/dts/overlays/hifiberry-dac-overlay.dts#L8-L13 Also, in Armbian Mainline config, at least for my Olimex-A20-Micro, I don't find the SND_SOC_PCM5102A enabled to build the driver, you will probably have to end-up building your own image. 0 Quote
Heisath Posted October 20, 2018 Posted October 20, 2018 Yes I am sure that the I2S0 port is enabled, Armbian provides a overlay for that (https://github.com/armbian/build/blob/18215550b367919c1b270185e110b901e2843edd/patch/kernel/sunxi-next/add-sunxi-overlays.patch#L2246-L2276) Which I enabled via Armbian-Config / armbianEnv.txt... Also checked that the device is there using /proc/device-tree/ That is also the reason why I didn't keep the I2S -> Okay Lines from the Raspberry PI overlay. That the driver is normally not included is correct, I will add it and then build my own image. But first I would love to get the device tree overlay working. I will conduct some more testing this afternoon or tomorrow and update this reply with my results. EDIT: So I've got the nodes integrated in the device tree, but not using overlays but decompiling and recompiling it online with dtc. I added the following nodes, maybe someone can create a overlay from that? // under soc sound:sound { compatible="hifiberry,hifiberry-dac"; i2s-controller=<0x99>; // this is taken from above i2s controller, in the overlay there should be a label I guess status="okay"; }; // in the root pcm5102a-codec { #sound-dai-cells = <0>; compatible = "ti,pcm5102a"; status="okay"; }; Testing in /proc revealed the changes had been loaded correctly. Then I tried compiling my own kernel with the PCM5102A driver but the option is not displayed in the kernel configuration. Any ideas? Greetings, count-doku 0 Quote
technik007_cz Posted January 15, 2019 Posted January 15, 2019 Kernel version 4.19.13-sunxi does not accept param_w1_pin= while 4.14.70-sunxi is working. After every change I rebooted system and checked value for change with command below: "cat /sys/kernel/debug/gpio" Testing setup: BananaPi M1 Plus, sensors DS18B20, debian stretch. 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.