Gunjan Gupta Posted January 5 Share Posted January 5 39 minutes ago, pixdrift said: is this because the board defined in the dts/dtb already correctly matches so doesn't need explicit overwrite? Yes, thats correct 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 5 Share Posted January 5 44 minutes ago, pixdrift said: perhaps @Gunjan Gupta you can advise on what level (file) I should add these two lines?, then I will update the patch before the PR. pinctrl-names = "default"; pinctrl-0 = <&i2c3_ph_pins>; Edited 43 minutes ago by pixdrift I will advice to add that as an overlay. Its an optional functionality and its possible someone might just use those pins for gpio ir not use them at all. The currently present overlays for H616 are some overlays that were added for bigtreetech cb1 coming from https://github.com/armbian/build/blob/main/patch/kernel/archive/sunxi-6.7/patches.armbian/arm64-dts-overlay-sun50i-h616-bigtreetech-cb1.patch Let me know if you need any help with cretaing overlay files 0 Quote Link to comment Share on other sites More sharing options...
MrBells Posted January 5 Share Posted January 5 Hi, has anyone been able to properly use GPU Acceleration? 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 5 Share Posted January 5 @pixdrift, @Gunjan Gupta Re overlays: The current set of overlays for h616 don't make sense to me. Zero2 and zero3 have identical external layouts. The ports on the external connections are: - i2c3 - spi1 - uart5 - ir - tv - lineout - usb3 - usb2 I would like to have overlays that enable/disable i2c3, spi1, uart5, ir, usb3 and usb2 and an overlay to switch usbotg between otg/host. The overlays could also include assigning pins so that no extra patches are required. I can try to teach myself about dtbo and slowly pick away at what I think is required. I think I can do this without patches and rebuilds as the changes are just files in the overlay directory. In the end the changes will require a patch. I would however like some comment and confirmation as to what should be in the overlays. 0 Quote Link to comment Share on other sites More sharing options...
pixdrift Posted January 5 Share Posted January 5 1 hour ago, Stephen Graf said: I would however like some comment and confirmation as to what should be in the overlays. I have only really known about overlays for 24 hours, but this sounds like a good plan to me. My only question is (as I don't play in this space much), what's the issue with having these enabled by default? and what benefit are you getting by making this disabled with a toggle? From a user experience perspective, there is then an additional step (armbian-config) to make this 'work', but I assume there is a benefit such a memory or power efficiency perspective for having these off if they aren't in use? I would really like the overlays to be named h61x if they apply to both 616 and 618.. but I haven't thought too deeply about that. As long as we are happy with h618 always matching the h616 due to the fact that they are pin compatible as @Gunjan Gupta says, I guess we stay with h616 to avoid changing thing unnecessarily. @Stephen Graf I am happy to take up your offer of you figuring it out, as you seem well versed in this part of the board. If you would like me to do a rebuild where those components are removed from the base configuration (so you can move them to overlays), I can do that on my i2c3 branch in github if you like, based on the list you have provided, just let me know.. as I am keen to assist where I can. As always, thanks to the assistance and feedback everyone, it's been an excellent help in gaining understanding of the board and Armbian and I am sure others following along will also get value out of this information. 1 Quote Link to comment Share on other sites More sharing options...
ag123 Posted January 5 Author Share Posted January 5 I *think* some pins / IOs etc are disabled in dts, in part as these days pins has multiple (alternate) functions (e.g. gpio / i2c / uart / spi / usb etc). I'm not too sure if say the same pin is enabled for gpio and i2c that if they'd conflict with each other as in that in practice it would only be one of the function i2c or gpio that is valid. the device tree compiler dtc has become pretty common and used these days it shouldn't be too difficult for anyone to edit the dts file (e.g. change that status from 'disabled' to 'okay' and re-compile that into its dtb file, then reboot. some non-armbian examples are like: https://mjoldfield.com/atelier/2017/03/rpi-devicetree.html ^ in fact even without the dts file, it is possible to take the dtb file and convert that to a dts file, make the edits and recompile that back to the edited dtb file. other examples: https://www.udoo.org/forum/threads/manually-editing-device-tree-dts-files.21600/ https://www.emcraft.com/som/vf6/controlling-gpio-from-linux dtsi are includes, so that those common things get included as common templates, and the differences changes are updated in the final dts file for the board. I think boot loaders like uboot may be possible to choose different dts/dtb file etc on the boot prompt command line, but I'm not sure how nor have i tried that. more interesting reading about device tree, https://elinux.org/images/a/a3/Elce2013-petazzoni-devicetree-for-dummies.pdf it is invented originally for the beagle bone black, in fact it exist earlier, subsequent to that these days device tree has become a linux standard practice especially for single board computers. Computers used to have standard features e.g. drives, keyboard, mouse, usb and that practically they are 'all the same'. then came single board computers 'revolution' and there are 'capes' and FPGAs (hardware is software ! change the program and hardware changes !), and that GPIO pins are pin-muxed, so today hardware is *configurable*. e.g. if you place a led on a board, it can be physically wired to any of the gpio pins, and you can further wire it as LOW = ON (sink), or HIGH = ON (source). but that as an 'alternate' function e.g. a led, you may even configure PWM and blink patterns and/or events for the leds. that that is still a gpio pin, but that the function changes by simple virtue of the context. it is a led. https://elinux.org/images/1/19/Dynamic-dt-keynote-v3.pdf https://cdn-learn.adafruit.com/downloads/pdf/introduction-to-the-beaglebone-black-device-tree.pdf https://elinux.org/images/e/e2/Engaging_Device_Trees_0.pdf https://ofitselfso.com/BeagleNotes/AboutTheDeviceTree.pdf https://elinux.org/Device_Tree_Usage 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted January 5 Author Share Posted January 5 - dup - 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted January 5 Author Share Posted January 5 - dup - 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 6 Share Posted January 6 @Gunjan Gupta Thank you for your suggestion on overlay_prefix. I built a system with OVERLAY_PREFIX=sun50i-h616 in the board config and that then ran fixup script on boot. I then tried to create a dtbo for the i2c3 from: sysadmin@orangepizero3:/mnt/dtbo$ more sun50i-h616-i2c3.dts /dts-v1/; / { compatible = "allwinner,sun50i-h616"; fragment@0 { target-path = "/aliases"; __overlay__ { i2c3 = "/soc/i2c@5002c00"; }; }; fragment@1 { target = <0xffffffff>; __overlay__ { status = "okay"; }; }; __fixups__ { i2c3 = "/fragment@1:target:0"; }; }; After dtc and coping the dtbo file to overlay I used armbian-config to enable the i2c3 overlay, and rebooted. The overlay seemed to run: Boot script loaded from mmc 219 bytes read in 1 ms (213.9 KiB/s) 31261 bytes read in 4 ms (7.5 MiB/s) Working FDT set to 4fa00000 378 bytes read in 3 ms (123 KiB/s) Applying kernel provided DT overlay sun50i-h616-i2c3.dtbo 4203 bytes read in 3 ms (1.3 MiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) ## Executing script at 45000000 18404199 bytes read in 769 ms (22.8 MiB/s) 23169032 bytes read in 969 ms (22.8 MiB/s) Unfortunately it did not enable (change disabled to okay) in the master dtb: i2c@5002c00 { compatible = "allwinner,sun50i-h616-i2c\0allwinner,sun8i-v53> reg = <0x5002c00 0x400>; interrupts = <0x00 0x09 0x04>; clocks = <0x02 0x4b>; resets = <0x02 0x1a>; status = "disabled"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x51>; }; Any more suggestions? 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 6 Share Posted January 6 8 hours ago, Stephen Graf said: The current set of overlays for h616 don't make sense to me. May be because they were added for Bigtreetech CB1 51 minutes ago, Stephen Graf said: Unfortunately it did not enable (change disabled to okay) in the master dtb: Why would it change the dtb? That would defeat the whole purpose of having overlays. Overlays are applied at runtime. If you want to check if your changes are applied, you can verify the same by reading i2c related files in /proc/device-tree There is no need to use that fragment syntax. There is much simpler way to do the same almost identical to writing dts files. Check https://bootlin.com/blog/using-device-tree-overlays-example-on-beaglebone-boards/ 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 6 Share Posted January 6 @Gunjan Gupta thank you for the advice. Yes /proc/device-tree shows status okay. I have never done this before. I will now try to add the pins to the dtbo. 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 6 Share Posted January 6 48 minutes ago, Stephen Graf said: I have never done this before Sorry if I sounded rude. Any statement I post is direct translation done in my head from my native language. Thats how I talk to anyone and everyone. Any hint of arrogance is not intended and just there due to my lack of english speaking skills and social skills. I am not really a social person. 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 6 Share Posted January 6 @Gunjan Gupta No offence taken. I am always impressed by people who have to communicate in a language other than their native. Keep giving me advice and I will keep trying to learn. In that respect can you tell me why this dts does not compile: sysadmin@orangepizero3:/mnt/dtbo$ dtc -O dtb -o sun50i-h616-i2c3.dtbo sun50i-h616-i2c3.dts sun50i-h616-i2c3.dts:19.29-23.19: ERROR (phandle_references): /fragment@1/__overlay__: Reference to non-existent node or label "i2c3_ph_pins" ERROR: Input tree has errors, aborting (use -f to force output) sysadmin@orangepizero3:/mnt/dtbo$ more sun50i-h616-i2c3.dts /dts-v1/; / { compatible = "allwinner,sun50i-h616"; fragment@0 { target-path = "/aliases"; __overlay__ { i2c3 = "/soc/i2c@5002c00"; i2c3_ph_pins = "/soc/pinctrl@300b000/i2c3-ph-pins"; }; }; fragment@1 { target = <0xffffffff>; __overlay__ { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&i2c3_ph_pins>; }; }; __fixups__ { i2c3 = "/fragment@1:target:0"; }; }; 2 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 6 Share Posted January 6 34 minutes ago, Stephen Graf said: In that respect can you tell me why this dts does not compile: You are missing -@ in the commandline. It should be dtc -@ -O dtb -I dts -o sun50i-h616-i2c3.dtbo sun50i-h616-i2c3.dts. There is also a shortcut if you like to take it. Just run armbian-add-overlay <dts_file_name>. It will automatically compile the overlay, copy it to necessary directory and add the corresponding entry in /boot/armbianEnv.txt file 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 6 Share Posted January 6 @Gunjan Gupta There is more to it than the -@. I just have no experience with dtc to be able to figure it out. sysadmin@orangepizero3:/mnt/dtbo$ dtc -@ -O dtb -o sun50i-h616-i2c3.dtbo sun50i-h616-i2c3.dts sun50i-h616-i2c3.dts:19.29-23.19: ERROR (phandle_references): /fragment@1/__overlay__: Reference to non-existent node or label "i2c3_ph_pins" ERROR: Input tree has errors, aborting (use -f to force output) sysadmin@orangepizero3:/mnt/dtbo$ sudo armbian-add-overlay sun50i-h616-i2c3.dts Compiling the overlay sun50i-h616-i2c3.dts:19.29-23.19: ERROR (phandle_references): /fragment@1/__overlay__: Reference to non-existent node or label "i2c3_ph_pins" ERROR: Input tree has errors, aborting (use -f to force output) Error compiling the overlay sysadmin@orangepizero3:/mnt/dtbo$ 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 6 Share Posted January 6 I noticed you are adding something to alias. Aliases are autogenerated. If something doesnt have an alias, you can use its full path for refering the same. For example, pinctrl-0 = <&i2c3_ph_pins>; Can be changed to pinctrl-0 = <&{/soc/pinctrl@300b000/i2c3-ph-pins}>; You also seems to be missing /plugin/; This should be placed after /dts-v1/; 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 6 Share Posted January 6 I will suggest you go through https://bootlin.com/blog/using-device-tree-overlays-example-on-beaglebone-boards/ once. It helped me a lot when I was learning about device trees and overlays 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 6 Share Posted January 6 Thank you again. This compiles: /dts-v1/; /plugin/; / { compatible = "allwinner,sun50i-h616"; fragment@0 { target-path = "/aliases"; __overlay__ { i2c3 = "/soc/i2c@5002c00"; }; }; fragment@1 { target = <0xffffffff>; __overlay__ { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&{/soc/pinctrl@300b000/i2c3-ph-pins}>; }; }; __fixups__ { i2c3 = "/fragment@1:target:0"; }; }; Should pinctrl-0 = <&i2c3_ph_pins>; have been pinctrl-0 = <&{i2c3_ph_pins}>; ? I am just going by examples, mostly from the overlay files on may machine. 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 6 Share Posted January 6 Honestly I have never used the fragment syntax. Just use the following for your overlay /dts-v1/; /plugin/; &i2c3 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&i2c3_ph_pins>; }; 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 6 Share Posted January 6 The above will compile and should work fine. If you will then decompile it you will get the overlay in fragment syntax 0 Quote Link to comment Share on other sites More sharing options...
ag123 Posted January 6 Author Share Posted January 6 accordingly device tree overlay may have to be loaded by uboot https://bootlin.com/blog/using-device-tree-overlays-example-on-beaglebone-boards/ https://docs.kernel.org/devicetree/overlay-notes.html I'm not sure how uboot is setup if it loads a single fixed dtb or that it loads the dtb for the board followed by a device tree overlay (e.g. dtbo ?) following a naming convention for boards. Note that there is an Armbian document for device tree overlays https://docs.armbian.com/User-Guide_Allwinner_overlays/ But I'd guess most users wanted it 'dynamically' e.g. to load it at runtime from a linux shell, hence I did further googling: it turns out there is something called configfs which is intended for this purpose https://www.96boards.org/documentation/consumer/dragonboard/dragonboard410c/guides/dt-overlays.md.html Quote Now its the time to insert the device tree blobs into running kernel using configfs. (Your kernel must have been compiled with CONFIG_OF_OVERLAY and CONFIG_CONFIGFS for the following steps to work.) > mount -t configfs none /sys/kernel/config > mkdir -p /sys/kernel/config/device-tree/overlays/tsys01 > cd <bin directory under DT-Overlays> > cat tsys01.dtbo > /sys/kernel/config/device-tree/overlays/tsys01/dtbo I'm not sure about that tsys01 folder how it relates here https://github.com/ikwzm/dtbocfg Quote Create a directory in ConfigFS To place a device tree blob overlay, make a directory under /config/device-tree/overlays. The name of the directory actually does not matter, but in this example, a directory named uio0, which corresponds to the entry in the Device Tree Source, is created. note that apparently there seem to be a few different implementations of configfs dtbocfg is one of them and only that the above quote applies I'm not too sure if configfs is a feature of specific forks, e.g. here is another https://elinux.org/R-Car/DT-Overlays there is a documentation for this and it seemed for this particular fork https://git.kernel.org/pub/scm/linux/kernel/git/geert/renesas-drivers.git/tree/Documentation/devicetree/configfs-overlays.txt?h=topic/overlays if you look at mainline, apparently configfs is not mentioned https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree off-topic: some other unrelated fun stuff here https://github.com/ikwzm/udmabuf ^ I think this is driver for a particular SOC and *not* likely to be universal https://www.xilinx.com/products/silicon-devices/soc/zynq-ultrascale-mpsoc.html don't think DMA controllers are 'standard' across socs. 0 Quote Link to comment Share on other sites More sharing options...
Gunjan Gupta Posted January 6 Share Posted January 6 44 minutes ago, ag123 said: if you look at mainline, apparently configfs is not mentioned https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/devicetree Thats becuase loading overlays from configfs is something that was viewed as not a recommended way and hence was not merged into the kernel. If you still wants to do the same, I believe our Allwinner kernels do have a patch that adds that functionality. Not sure if the same can be said for every soc family supported by Armbian. Also I am not sure if loading overlay via configfs is ever tested and hence cant say how well that works. 1 Quote Link to comment Share on other sites More sharing options...
ag123 Posted January 6 Author Share Posted January 6 @Gunjan Gupta agreed about that opinion, in general it is *risky* to configure device tree in a running kernel as it can lead to (all sorts of) unexpected problems with all the kernel threads running on all multiprocessing cores. I think there may be some serious synchronization issues, e.g. would the kernel running simultaneously on all cores 'know' about the changes? And I'd guess it could lead to *kernel panic* when the device tree is updated at runtime as another kernel thread running on another core could be accessing the in memory kernel device tree when it is changed form another. but that as the idea is still attractive / 'seductive' , I'd guess those interested can try out this repository https://github.com/ikwzm/dtbocfg my guess is that *certain* ops is 'possibly safe' e.g. to tweak the status of a particular device say gpio from 'disabled' to 'okay', but the thought about synchronization still applies, simply changing the device tree at runtime can lead to *kernel panic* and even possible data corruption for that 'simple' change. The safe way is probably to only load the overlay from uboot. https://docs.armbian.com/User-Guide_Allwinner_overlays/ oh configFS is actually mentioned in this slide https://elinux.org/images/1/19/Dynamic-dt-keynote-v3.pdf hence, those keen on that may want to try out that at your own risk. if you review the slides, it seemed there are functions within the kernel to support such 'configFS' changes. but that it is likely 'experimental', i.e. it isn't 'proven beyond doubt' it is risk free, but the slides documents some mechanisms for synchronization etc, which is necessary to update the in memory device tree at run time. these days gpio / i2c / spi etc is just a pin mux away, a single register change muxes it differently. 'big' computers and/or notebooks/laptops etc are deemed to be 'fixed', but for SBC practically all the pins on the headers can be 'hot swapped' with a cape/hat etc. note that the implementation as is relevant to the slides seemed to be this specific fork, different implementations would likely have different behaviour/bugs: https://github.com/Xilinx/linux-xlnx/blob/master/Documentation/devicetree/configfs-overlays.txt https://lore.kernel.org/lkml/1414528565-10907-4-git-send-email-pantelis.antoniou@konsulko.com/ the slides specifically mentioned using a mutex to lock the whole tree when changes are taking place (changesets) that is a minimum necessary. But I think that won't prevent possible deadlock situations, because device tree is heavily accessed when devices are referenced, some of the (old) references may be stored away in apps say in variables, which could mean the change could at least crash the app and the kernel is running concurrently *in parallel* on all cores so kernel panics , or simply *hang* would likely be still a thing, but that at least find a 'safer' implementation, one would need to review the codes and do so accordingly. 0 Quote Link to comment Share on other sites More sharing options...
Serby Posted January 6 Share Posted January 6 (edited) If you’re still taking suggestions there for overlays … don’t forget the g_ether (usb gadget Ethernet support) a good reference for overlays would just be the raspberry pi overlays directory… just got to change the actual settings of the pins and what not… but it’s a good base that’s well documented, including things like the hdmi hot plug etc, the video memory… one thing I noticed if you are doing the dtc with the gpu “okay” thing… it works on the “beta” 6.1 Debian from OrangePi, but I noticed that the CMA memory ? Could be wrong acronym … but I didn’t find it in the DTB /DTC when I was changing the gpu from disabled to okay… but when you run the command `dmesg | grep cma` in terminal it shows in the “beta” 6.1 Debian is only 128mB … but I think The CMA is shared with everything not specific to the GPU, but that would most likely need to be raised maybe by like 64mBs or more for mesa / Mali panfrost driver? But if your up to making that an overlay then depending on users need they can just set whatever value they need… ref: https://developer.toradex.com/software/linux-resources/linux-features/contiguous-memory-allocator-cma-linux/#intended-audience https://lwn.net/Articles/396707/ oh and there is something with the ETH or EMAC that’s kinda strange but if you look at bottom of page 16 it references 2 interfaces emac0 10/100/1000 and emac1 10/100, which really doesn’t make sense to me, ( I have an OrangePi zero2w ) I don’t have the external adapter board but it claims it’s 10/100… but if you read in that datasheet ( I know it says h616 … but that’s what pops up when you click h618), it says that the 10/100 (emac1) interface is internal only… so that means the 10/100/1000 (emac0) is what’s actually exposed to the pins, why they need a second IC for the 10/100/1000 on OrangePi zero 3 🤷♂️or why the zero2w only has 10/100 ( maybe the pcb design or w/e couldn’t be routed for the 1000 speed 🤷♂️) But maybe something there that they might have missed that might address the Ethernet bugs or issues you had encountered / patched ? Like maybe something is mapped incorrectly that the internal 10/100 is being used ? I assume the internal one would be for bridging / vlans like maybe for the g_ether I mentioned above ? So it has its own dedicated phy / bus 🤷♂️ another thing, remember the mail GPU is just the 3d acceleration hardware it really doesn’t address anything about the other hardware on the chip ref: page 12, the 2d graphics (G2D) or the “display engine”, 🤷♂️heh a lot of random things like that I don’t understand or is not clearly documented anywhere but the datasheet, but then if you look at the arm website for Mali-g31 ref: https://developer.arm.com/downloads/-/mali-drivers/bifrost-kernel notice it mentions: “Note that these components are not a complete driver stack. To build a functional OpenGL ES you need access to the full source code of the Mali GPU DDK, which is provided under the standard Arm commercial licence to all Mali GPU customers.” So if Sunix / allwinner doesn’t provide that then I guess we out of luck for that part of it… or maybe it’s just already in the mainline kernel or panfrost mesa driver 🤷♂️… I also tried installing Wayland GNOME as an alternative login / desktop manager option, but that just crashes after awhile and the CPU usage is madness just moving the mouse across the screen heh. But according to the docs I think it specifically says the Mali supports x11 Wayland Vulcan and the non windowed one (can’t find that doc ATM) but also I think you mentioned you looked at this , but this might address the hdmi issues etc in the case you were referring to something else in cedrus video graphics docs https://linux-sunxi.org/Display Edited January 6 by Serby 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 6 Share Posted January 6 @Gunjan Gupta Thank you again for your advice. Your overly works. The i2c3 device works, device 38 is a sensor I have connected: sysadmin@orangepizero3:~$ sudo i2cdetect -l i2c-0 i2c mv64xxx_i2c adapter I2C adapter i2c-1 i2c DesignWare HDMI I2C adapter i2c-2 i2c mv64xxx_i2c adapter I2C adapter sysadmin@orangepizero3:~$ sudo i2cdetect 2 WARNING! This program can confuse your I2C bus, cause data loss and worse! I will probe file /dev/i2c-2. I will probe address range 0x08-0x77. Continue? [Y/n] 0 1 2 3 4 5 6 7 8 9 a b c d e f 00: -- -- -- -- -- -- -- -- 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 30: -- -- -- -- -- -- -- -- 38 -- -- -- -- -- -- -- 40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 70: -- -- -- -- -- -- -- -- sysadmin@orangepizero3:~$ Note that i2c3 becomes /dev/i2c-2. With this success I forged on to set up spi1, which is on the header. Spi0 is used internally to connect to the flash memory. After much consternation (confusion with - and _) I managed to get the following to compile and load. /dts-v1/; /plugin/; &spi1 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi1_pins &spi1_cs0_pin>; }; When I rebooted both i2c3 and spi1 overlays loaded: Working FDT set to 4fa00000 344 bytes read in 2 ms (168 KiB/s) Applying kernel provided DT overlay sun50i-h616-i2c3.dtbo 406 bytes read in 3 ms (131.8 KiB/s) Applying kernel provided DT overlay sun50i-h616-spi1.dtbo 4203 bytes read in 3 ms (1.3 MiB/s) Applying kernel provided DT fixup script (sun50i-h616-fixup.scr) BUT /dev/i2c-2 was not created and then i2c3 would not work. I also noted there has never been any entries for spi devices in /dev nor was there one created for spi1. I looked into /proc and both spi1 and i2c3 have status okay! I have downloaded some utilities for spi but they depend on /dev entries. When I took out the spi1 overlay, i2c3 appeared in /dev and worked again. This gets more confusing by the day. 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 7 Share Posted January 7 @Gunjan Gupta I found the problem with the spi1/i2c3 overlays. There is a conflict within pin provisioning. In the dtb spi1-cs is set to PH5 which is also used by i2c3 SDA. I think this is an error as the hardware doc shows spi1-cs as PH9. PH9 is not referenced in the dtb and so I set spi1-cs to PH9. This resolved the conflict and i2c3 works again. 0 Quote Link to comment Share on other sites More sharing options...
Serby Posted January 7 Share Posted January 7 (edited) In that datasheet, it shows the ALT pins, most of this SoCs has a pin mux, and depending on which alt setting you used for 1 pin sometimes dictates the whole pinout for the rest of the pins in that ALT “group”. also a lot of this SoC have programable Pull Up / Pull downs. And/or the PCB manufacture adds a pull up/down on the pcb itself … or for example if the spi NAND that’s on the board already, if for example it’s on spi0-0 since it’s already present, if you try to switch spi0-0 to some other pin the IC is still physically connected which might cause SoC pin to PULL some kinda way that conflicts with the ALTs pin Pull * and sometimes if there is no pull direction set depending on the chip and pcb can cause some parasitic capacitance and drive the pin high when it’s meant to be low, so as a precaution you might want to force the pin the direction it needs to be and not leave that setting unset ( this usually isn’t an issue but I remember the raspi 1B had this issue ), just mentioning it cus if theirs some weird unexpected behavior happening , this is often overlooked, bang your head for days and might be something along this lines * ah yeah and double check that the data-sheet pins on the SoC match the numbering scheme on the PCB pin outs , and if there is a difference between the two figure out which set they using to describe the GPIOs … remember that was a headache also , cus the pcb manufacture might be calling the GPIO header pins 0-15 for example but on the soc its p30-45 or w/e ** I remember when I was messing with the crypto chips ATTECC608 i2c chips, I had a bad batch of gpio jumper cables , and wouldn’t read on the bus untill I fanageled with the cables… couldn’t figure it out for the longest time lol stick the multimeter everything worked but the little sleeve was wider then the gpio pin , and the pin would rest on the plastic and not make contact 😐 , similar to your Ethernet cable issue, rule that out before you jump to conclusions , but as far as SPI is concerned , if the CS pin is causing issues backtrace SPI1, if it has spi1.0 1.1 1.2 etc all the spi1-CS pins need to be low ( or high?) , cus if one is set in the high ( or low?) it’s going to block the bus cus it’s signaling to the bus that it needs the bus, and could cause the issues mentioned above Maybe later today when I hit the pc I’ll make a spreadsheet / chart… based off that datasheet similar to this https://elinux.org/RPi_BCM2835_GPIOs… or as you go fill in a spears sheet there in excel or w/e cus that helps a lot as a simple look up table , the one in the datasheet is okay but is mixed in with a lot of other things that might be confusing Edited January 7 by Serby 0 Quote Link to comment Share on other sites More sharing options...
Serby Posted January 7 Share Posted January 7 (edited) 20 hours ago, Stephen Graf said: /dts-v1/; /plugin/; &spi1 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi1_pins &spi1_cs0_pin>; }; @Stephen Graf this is the overlay ? But how about in the main devicetree, do you have module called spidev@0… @1.. and make sure it’s not “disabled” that’s what supposedly loads the spi into /dev/ … there is supposed to be an spidev in the kernel, but maybe your overlay needs that too address the “disabled” to “okay” ( I assume the main device tree would be set disabled and depending on the overlay you pick will enable / change the corresponding spidev@X to status=“okay” also *if I’m not mistaken I think there is i2c-dev also so for example if &spi1 {… ; spi@X {… status=”okay”…}; spi@Y{… status=“disabled}; … }; I’d assume spi@X, Y would be different overlays for the different CS options so like dtoverlay=spi1-Xcs , spi1-Ycs would have their own overlay or some function maybe ? That sets the status=“okay” enabled to the corresponding one @Stephen Graf i mentioned to look at the raspberry pi repo here is how they do it ( also go up to the parent directory of that file for all the examples, and the README there also explains what things do.. * https://github.com/raspberrypi/linux/blob/rpi-6.1.y/arch/arm/boot/dts/overlays/spi1-1cs-overlay.dts#L40 obviously the settings going to be different for OrangePi but Atleast you got something to compare / work with ** I mention the spread sheet as you go along, mainly just for Documents purposes later on. So others using it know which overlay corresponds to what gpio pins / function. If you do it as you go will save time having to go back and do it again + it kind of acts like a checklist Edited January 7 by Serby 0 Quote Link to comment Share on other sites More sharing options...
Stephen Graf Posted January 8 Share Posted January 8 @Serby Thank you for the advice. With my limited experience with dtbo I have put together the following with not much success. If you could help it would be appreciated. The overlay compiles with warnings. It loads on boot but no spidev is generated in /dev. I am guessing at the compatible line. Original dtb: spi@5010000 { compatible = "allwinner,sun50i-h616-spi\0allwinner,sun8i-h3-spi"; reg = <0x5010000 0x1000>; interrupts = <0x00 0x0c 0x04>; clocks = <0x02 0x4f 0x02 0x4d>; clock-names = "ahb\0mod"; resets = <0x02 0x1c>; pinctrl-names = "default"; pinctrl-0 = <0x1c 0x1d>; status = "okay"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x53>; flash@0 { #address-cells = <0x01>; #size-cells = <0x01>; compatible = "jedec,spi-nor"; reg = <0x00>; spi-max-frequency = <0x2625a00>; }; }; spi@5011000 { compatible = "allwinner,sun50i-h616-spi\0allwinner,sun8i-h3-spi"; reg = <0x5011000 0x1000>; interrupts = <0x00 0x0d 0x04>; clocks = <0x02 0x50 0x02 0x4e>; clock-names = "ahb\0mod"; resets = <0x02 0x1d>; pinctrl-names = "default"; pinctrl-0 = <0x1e>; status = "disabled"; #address-cells = <0x01>; #size-cells = <0x00>; phandle = <0x54>; }; spi0_pins = "/soc/pinctrl@300b000/spi0-pins"; spi0_cs0_pin = "/soc/pinctrl@300b000/spi0-cs0-pin"; spi1_pins = "/soc/pinctrl@300b000/spi1-pins"; spi1_cs0_pin = "/soc/pinctrl@300b000/spi1-cs0-pin"; spi0 = "/soc/spi@5010000"; spi1 = "/soc/spi@5011000"; Overlay: /dts-v1/; /plugin/; &spi1 { status = "okay"; pinctrl-names = "default"; pinctrl-0 = <&spi1_pins &spi1_cs0_pin>; spidev1_0: spidev@0 { compatible = "allwinner,sun50i-h616-spidev\0allwinner,sun8i-h3-spidev"; reg = <0>; #address-cells = <0x01>; #size-cells = <0x00>; spi-max-frequency = <0x2625a00>; status = "okay"; }; }; Compile: sysadmin@orangepizero3:/memstick/dtbo$ dtc -@ -O dtb -o sun50i-h616-spi1.dtbo sun50i-h616-spi1.dts sun50i-h616-spi1.dts:11.3-13: Warning (reg_format): /fragment@0/__overlay__/spidev@0:reg: property has invalid length (4 bytes) (#address-cells == 2, #size-cells == 1) sun50i-h616-spi1.dtbo: Warning (pci_device_reg): Failed prerequisite 'reg_format' sun50i-h616-spi1.dtbo: Warning (pci_device_bus_num): Failed prerequisite 'reg_format' sun50i-h616-spi1.dtbo: Warning (simple_bus_reg): Failed prerequisite 'reg_format' sun50i-h616-spi1.dtbo: Warning (i2c_bus_reg): Failed prerequisite 'reg_format' sun50i-h616-spi1.dtbo: Warning (spi_bus_reg): Failed prerequisite 'reg_format' sun50i-h616-spi1.dts:9.22-16.4: Warning (avoid_default_addr_size): /fragment@0/__overlay__/spidev@0: Relying on default #address-cells value sun50i-h616-spi1.dts:9.22-16.4: Warning (avoid_default_addr_size): /fragment@0/__overlay__/spidev@0: Relying on default #size-cells value sun50i-h616-spi1.dtbo: Warning (avoid_unnecessary_addr_size): Failed prerequisite 'avoid_default_addr_size' sun50i-h616-spi1.dtbo: Warning (unique_unit_address): Failed prerequisite 'avoid_default_addr_size' sysadmin@orangepizero3:/memstick/dtbo$ 0 Quote Link to comment Share on other sites More sharing options...
TechX Posted January 8 Share Posted January 8 Hi all, been having a look over this topic and seems interesting. I recently bought an orange pi zero 3 and have got it running the armbian image that orange pi suggests. I know a bit of linux as I usually design my python programs in the linux environment. As soon as I run any sort of updates using the armbian image provided by orange pi, the OS becomes unusable. I'm not 100% sure as to what you guys have achieved but it seems like a more stable version. Just wondering if one of the images may be better suited, as I want to use it for PiVPN and PiHole. TIA 0 Quote Link to comment Share on other sites More sharing options...
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.