Jump to content

Orange Pi Zero 3 GPIO

robertoj

By robertoj
in Allwinner sunxi

 Share

Recommended Posts

robertoj

robertoj

Posted
Posted

Yesterday, I tried to use the digital IO in my opi zero3, with the Python GPIO package from https://opi-gpio.readthedocs.io/en/latest/ by Richard Hull

 

It depends on having sysfs files in /sys/class/gpio/

 

My original opi zero has these files and it works, but my opi zero3 doesn’t have these files

 

I learned that /sys/class/gpio is created if the linux kernel is configured with a specific option ON, as suggested in the documentation:

https://github.com/rm-hull/OPi.GPIO

https://linux-sunxi.org/GPIO 

 

Also, a developer has made a change on the opi.GPIO project to support opi zero3

https://github.com/rm-hull/OPi.GPIO/issues/79 

 

I will have time to try this tomorrow... but I want to ask: is anyone using GPIO in its most basic way?

 

As reference: I saw this older thread about zero3's GPIO... 

https://forum.armbian.com/topic/31493-how-to-enable-i2c3-on-orange-pi-zero-3/

 

It is using leebobby's "armbian" image, with raspi-config, and wiringpi

Using my original opi-zero, I never needed to use armbian-config to enable basic gpio and the python opi.gpio just worked as documented

 

Note: the opi.gpio only claims to support basic gpio, not i2c.

 

Update: these are interesting potential solutions and discussions (but they are all from before there was armbian for opiz3)

https://www.reddit.com/r/OrangePI/comments/16vfa4g/orange_pi_zero_3_gpio_python_library/

https://github.com/eutim/OPI.GPIO

https://www.reddit.com/r/OrangePI/comments/16ioyri/gpio_python_library_for_orange_pi_zero_3/

https://www.reddit.com/r/OrangePI/comments/18iveo3/how_to_control_gpio_pins_in_android_orange_pi/

 

0
robertoj

robertoj

Posted
  • Author
Posted

Thank you Gunjan... I hope i have the skill (or time to develop the skill) to add support for opiz3

 

In the older thread, I was told that /sys/class/gpio won't work anymore... well, it is very true:

https://forum.armbian.com/topic/29202-orange-pi-zero-3/?do=findComment&comment=180975

https://www.thegoodpenguin.co.uk/blog/stop-using-sys-class-gpio-its-deprecated/

 

So, any methods and libraries that depend on sys/class/gpio, like opi.gpio, JUST WONT WORK

0
Gunjan Gupta

Gunjan Gupta

Posted
Posted

MRAA doesn't depend on sysfs. Its intelligent enough to choose either that or /dev/gpiochip* device

 

Simpler method if you wish to try - https://github.com/eclipse/mraa/blob/master/docs/jsonplatform.md

Example file for the same - https://github.com/eclipse/mraa/blob/master/examples/platform/turbotjson.json

create json file, export MRAA_JSON_PLATFORM=<path_to_json_file> and you should have it working

0
robertoj

robertoj

Posted
  • Author
Posted

References for trying tomorrow:

https://wiki.radxa.com/Mraa

https://wiki.radxa.com/RockpiE/dev/libmraa

https://www.okdo.com/project/how-to-install-mraa-library-on-the-rock-4c/

https://www.ics.com/blog/getting-started-mraa-raspberry-pi

Has anyone used mraa in rockpi+armbian?

 

Old discussion about alternatives to mraa

https://forum.armbian.com/topic/12285-providing-mraa-as-common-gpio-library-as-a-replacement-for-wiringpi/

 

0
robertoj

robertoj

Posted
  • Author
Posted (edited)

Ok. I got one output pin to work. 😀

 

This is how to do it in OrangePi Zero 3, pin 8 PH2:

 

image.thumb.png.62138b55398142cce2eca5bf1c894995.png

 

In Bash as root:

# addgroup --system gpio

# chown root:gpio /dev/gpiochip0

# chmod 660 /dev/gpiochip0

# nano /etc/udev/rules.d/61-gpio-tools.rules

{add line SUBSYSTEM=="gpio",KERNEL=="gpiochip*", GROUP="gpio", MODE="0660"}

# usermod -a -G gpio myusername

# apt install python3-dev

# reboot

 

In a new folder for your Python script, as normal user:

$ python3 -m venv .venv

$ source .venv/bin/activate

$ pip install gpiod

 

Create script (example in https://pypi.org/project/gpiod/ with one fix):

$ nano blink_pin.py
  

import time
import gpiod #needed in example
from gpiod.line import Direction, Value

#Calculating PH2 "line" number
#H=8
#2=2
#line=(8-1)x32+2=226
#also shown in https://github.com/rm-hull/OPi.GPIO/issues/79

LINE = 226
with gpiod.request_lines(
    "/dev/gpiochip0",
    consumer="blink-example",
    config={
        LINE: gpiod.LineSettings(
            direction=Direction.OUTPUT, output_value=Value.ACTIVE
        )
    },
) as request:
    while True:
        request.set_value(LINE, Value.ACTIVE)
        time.sleep(1)
        request.set_value(LINE, Value.INACTIVE)
        time.sleep(1)

 

Run script:

$ python3 blink_pin.py

 

When done working with your project:

$ deactivate

 

Pin 8 PH2 turns ON and OFF 😄

I haven't tested the other pins yet

Edited by robertoj
updated to add udev rule for gpio
2
usual user

usual user

Posted
Posted

This thread inspired me to tinker with GPIO again. I was curious to see how I would realize the example for myself. Since python is not my strong point, I chose a poor man's solution with "dnf install libgpiod-utils".

I then ran this command: 

gpioset --toggle 100ms,100ms,100ms,100ms,100ms,300ms,300ms,100ms,300ms,100ms,300ms,300ms,100ms,100ms,100ms,100ms,100ms,700ms --consumer panic con1-08=active

I'm wondering now what the flashing code could say, but I think a ham radio operator would know for sure what it means 😉
Recreating the python example wasn't really challenging with: 

gpioset -t1000 -Cblink-example con1-08=1

And besides, I find my flashing pattern much more interesting. I would be interested to know how something like this would be implemented with sysfs. Certainly not with a one-liner.
These commands work the same way on all my different devices, i.e. it is used for all pin 8 of the first expansion connector. I find it more pleasant to address the pins with con1-xx than to deal with some device-specific gpio-lines again and again. Generated code is therefore portable and can be used on any device without modification, provided that the device can provide GPIO functionality on the corresponding pins.
The only requirement is that the same gpio-line-name is used for the corresponding GPIO of the extension port. But this can be ensured by a simple DTB overlay. Creating such an overlay is a one-time effort for any device and the first thing I do for a device that I care off.

1
robertoj

robertoj

Posted
  • Author
Posted

gpio-sysfs is deprecated and gpiod is one of the replacements

 

https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/

 

What would be needed to have my orangepi zero 3 show this? 

VVV This is NOT what I get. This is what I want to get VVV
$ gpioinfo
gpiochip0 - 27 lines:
line 229: "PH5/I2C3_SDA" input
line 228: "PH4/I2C3_SCK" input
line 73 "PC9" input
line 226 "PH2/UART5_TX" output
line 227 "PH3/UART5_RX" input
line 70 "PC6" input
line 75 "PC11" input
line 69 "PC5" input
line 72 "PC8" input
line 79 "PC15" input
line 78 "PC14" input
line 231 "PH7,SPI1_MOSI" input
line 232 "PH8,SPI1_MISO" input
line 71 "PC7" input
line 230 "PH6,SPI1_CLK" input
line 233 "PH9,SPI1_CS" input
line 74 "PC10" input
line 234 "PH10/UART6_TX" input
line 235 "PH11/UART6_RX" input
line 236 "PH12/I2C4_SDA" input
line 237 "PH13/I2C4_SCK" input
line 238 "PH14/SPI2_MOSI" input
line 239 "PH15/SPI2_MISO" input
line 240 "PH16/SPI2_CLK" input
line 241 "PH17/SPI2_CS" input
line 242 "PH18/UART7_TX" input
line 243 "PH19/UART7_RX" input

 

0
robertoj

robertoj

Posted
  • Author
Posted

What should I do in my orangepi zero 3, so that the result of "gpioinfo " is "line 229: "PH5...", and just show the usable lines (as shown in https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/ )

 

What I get now is: "line 0: unnamed... (288 lines)" (as shown in https://forum.armbian.com/topic/29202-orange-pi-zero-3/?do=findComment&comment=181015)

 

Is this the way to do it? https://stackoverflow.com/questions/60100907/gpiod-use-labels-in-devicetree

 

 

0
Gunjan Gupta

Gunjan Gupta

Posted
Posted

If that also shows the same output. The pin numbers starts from 0 for PA0 to 31 for PA31, 32 for PB0 to 63 for PB31 and so on until PI* lines. So basically there are 32 pins in each lines stacked together and lines are PA to PI making them 288 pins total on gpiochip 0. Then you have PL line on gpiochip1. You should see the names. If its not visible, then it is a bug in kernel pinctrl driver.

0
ag123

ag123

Posted
Posted

@robertoj, all,

 

apparently, it may be possible to name the lines in the DTS

https://www.kernel.org/doc/Documentation/devicetree/bindings/gpio/gpio.txt

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpio/gpiolib.c?h=v6.7.4#n456

  

Example:

gpio-controller@00000000 {
	compatible = "foo";
	reg = <0x00000000 0x1000>;
	gpio-controller;
	#gpio-cells = <2>;
	ngpios = <18>;
	gpio-reserved-ranges = <0 4>, <12 2>;
	gpio-line-names = "MMC-CD", "MMC-WP", "VDD eth", "RST eth", "LED R",
		"LED G", "LED B", "Col A", "Col B", "Col C", "Col D",
		"Row A", "Row B", "Row C", "Row D", "NMI button",
		"poweroff", "reset";

 

I'm not sure though if the gpio-line-names assignment can be used in pin-control devices that is currently present in the existing DTS.

 

note also that the line/pin functions are actually defined in the source codes for the pin-control driver, just that this won't automatically appear as gpio-line-names.

 

you may want to start experimenting, post your findings and perhaps make a PR?

 

note that there is another source tree to commit though , which is in linux-sunxi - that would be directly mainlining / upstreaming the changes.

https://linux-sunxi.org/Main_Page

https://git.kernel.org/pub/scm/linux/kernel/git/sunxi/linux.git/

they have a google groups here:

https://groups.google.com/g/linux-sunxi

https://linux-sunxi.org/Mailing_list

 

I'm not too sure about the procedure to commit changes in mainline though.

1
Gunjan Gupta

Gunjan Gupta

Posted
Posted

@ag123Yes, its possible to name in dts. But pins should have their names already defined and visible in the debugfs as they are being defined using a macro

https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c#L19

https://elixir.bootlin.com/linux/latest/source/drivers/pinctrl/sunxi/pinctrl-sunxi.h#L32

https://elixir.bootlin.com/linux/latest/source/include/linux/pinctrl/pinctrl.h#L63

0
usual user

usual user

Posted
Posted
  On 2/9/2024 at 12:23 AM, robertoj said:

What would be needed to have my orangepi zero 3 show this?

Expand  

As allredy stated, a quite simple DTB overlay. See this thread as an entry point for discussions that have already taken place on this topic.
More on gpio-line-names assignment can also be found in other posts of mine in this forum.
But after the last posts in this thread I have doubts whether I should continue to participate here. IMHO the basic knowledge seems to be lacking, but they think to know exactly what the solution should look like and don't accept any other implementation. Something like this has repeatedly led to inconclusive discussions, which I am no longer prepared to engage in.
If you'd like, I can try to walk you through creating a suitable overlay.
For a first step, I need the output of 

cat /sys/kernel/debug/gpio

 from your running system and the DTB that is currently being used for your system. And last but not least, I need an online link to the DTB source of your device or is this already correct.

0
Gunjan Gupta

Gunjan Gupta

Posted
Posted
  On 2/9/2024 at 8:23 AM, usual user said:

But after the last posts in this thread I have doubts whether I should continue to participate here. IMHO the basic knowledge seems to be lacking, but they think to know exactly what the solution should look like and don't accept any other implementation. Something like this has repeatedly led to inconclusive discussions, which I am no longer prepared to engage in.

Expand  

You probably are misunderstanding my comment and intent here. I assumed that robertoj needed the pin number pin name mapping for development and gave an alternative way of finding the same using debugfs. Also my previous comment was simply an attempt of explaining how pin names gets populated in pinctrl directory in debugfs and if its not present in pinctrl directory in debugfs then it probably will be a bug in the pinctrl driver. Looks like both the my intent and what was conveyed is being misunderstood. I was only trying to help.

0
robertoj

robertoj

Posted
  • Author
Posted
  On 2/9/2024 at 1:09 AM, Gunjan Gupta said:

what is the output of  

sudo /bin/bash -c "cat /sys/kernel/debug/pinctrl/*/pinmux-pins"

Does that suffice?

Expand  

 

  Reveal hidden contents

 

 

0
Gunjan Gupta

Gunjan Gupta

Posted
Posted

@robertojI assumed you were looking for that pin name, number mapping for development. If so I hope that file will be helpful. If you still want the output to be in gpioinfo command, I guess you have to add the overlay as suggested by others. I personally don't use gpiod that much as I find it somewhat lacking. I last checked it in late 2022 or early 2023 I believe and it was only supporting simple gpio operations and was not supporting i2c, spi, etc. I am not sure it changed. But if its still the case and if you require to use more functionality, I will suggest going the MRAA route like I suggested before. 

0
robertoj

robertoj

Posted
  • Author
Posted
  On 2/9/2024 at 8:23 AM, usual user said:

For a first step, I need the output of 

cat /sys/kernel/debug/gpio
Expand  

  

roberto@orangepizero3:~$ sudo cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl:
 gpio-76  (                    |red:status          ) out hi 
 gpio-77  (                    |green:power         ) out hi 
 gpio-80  (                    |regulator-usb1-vbus ) out hi 
 gpio-166 (                    |cd                  ) in  lo ACTIVE LOW
 gpio-210 (                    |reset               ) out hi ACTIVE LOW

gpiochip1: GPIOs 352-383, parent: platform/7022000.pinctrl, 7022000.pinctrl:


Attaching DTB from /boot/dtb/allwinner/sun50i-h618-orangepi-zero3.dtb in rolling armbian release.

I dont know whether there are any armbian patches toward the GPIO, but this is the folder with armbian patches for orangepi zero 3

https://github.com/armbian/build/tree/main/patch/kernel/archive/sunxi-6.7/patches.armbian

sun50i-h618-orangepi-zero3.dtbFetching info...

0
robertoj

robertoj

Posted
  • Author
Posted
  On 2/9/2024 at 8:18 PM, Gunjan Gupta said:

@robertojI assumed you were looking for that pin name, number mapping for development. If so I hope that file will be helpful. If you still want the output to be in gpioinfo command, I guess you have to add the overlay as suggested by others. I personally don't use gpiod that much as I find it somewhat lacking. I last checked it in late 2022 or early 2023 I believe and it was only supporting simple gpio operations and was not supporting i2c, spi, etc. I am not sure it changed. But if its still the case and if you require to use more functionality, I will suggest going the MRAA route like I suggested before. 

Expand  

Thank you... I already got the help that I personally needed to get my work project rolling again :)

I want to learn how to make a DTS, compile it into a DTBO and make a Pull Request

 

I agree that GPIOD is less capable than MRAA. I may have the time to learn how to make it work.

0
usual user

usual user

Posted
Posted
  On 2/9/2024 at 8:23 PM, robertoj said:

sun50i-h618-orangepi-zero3.dtb 31.64 kB · 1 download

Expand  

I've written an overlay that I think is correct. Since I don't have a Orange Pi Zero 3 I need your help to verify my work. Therefore I have applied my overlay staticly to your provided DTB. Please replace your existing DTB with the attached one. Reboot and post the "cat /sys/kernel/debug/gpio" output again.
If everything works as expected, I will post the overlay source and explain how to use it.

sun50i-h618-orangepi-zero3.dtbFetching info...

0
robertoj

robertoj

Posted
  • Author
Posted
  On 2/10/2024 at 8:11 AM, usual user said:

Please replace your existing DTB with the attached one. Reboot and post the "cat /sys/kernel/debug/gpio" output again.

Expand  

 

With armbian's DTB. cat /sys/kernel/debug/gpio 

root@orangepizero3:~# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl:
 gpio-76  (                    |red:status          ) out lo 
 gpio-77  (                    |green:power         ) out hi 
 gpio-80  (                    |regulator-usb1-vbus ) out hi 
 gpio-166 (                    |cd                  ) in  lo ACTIVE LOW
 gpio-210 (                    |reset               ) out hi ACTIVE LOW

gpiochip1: GPIOs 352-383, parent: platform/7022000.pinctrl, 7022000.pinctrl:
root@orangepizero3:~#

 

With the DTB you created yesterday 

root@orangepizero3:~# cat /sys/kernel/debug/gpio
gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl:
 gpio-69  (con1-13             )
 gpio-70  (con1-11             )
 gpio-71  (con1-22             )
 gpio-72  (con1-15             )
 gpio-73  (con1-07             )
 gpio-74  (con1-26             )
 gpio-75  (con1-12             )
 gpio-76  (                    |red:status          ) out lo 
 gpio-77  (                    |green:power         ) out hi 
 gpio-78  (con1-18             )
 gpio-79  (con1-16             )
 gpio-80  (                    |regulator-usb1-vbus ) out hi 
 gpio-166 (                    |cd                  ) in  lo ACTIVE LOW
 gpio-210 (                    |reset               ) out hi ACTIVE LOW
 gpio-226 (con1-08             )
 gpio-227 (con1-10             )
 gpio-228 (con1-05             )
 gpio-229 (con1-03             )
 gpio-230 (con1-23             )
 gpio-231 (con1-19             )
 gpio-232 (con1-21             )
 gpio-233 (con1-24             )

gpiochip1: GPIOs 352-383, parent: platform/7022000.pinctrl, 7022000.pinctrl:
root@orangepizero3:~#

 

And, the result of gpioinfo is:

  Reveal hidden contents

 

And the contents of pinmux-pins

  Reveal hidden contents

 

0
usual user

usual user

Posted
Posted

Ok, everything is as expected.
So attached is the overlay source as promised and here is how to use it:
To avoid path information in the commands, I use 

cd /boot/dtb/allwinner/

as the working directory.
To compile the overlay, execute: 

dtc --in-format dts sun50i-h618-orangepi-zero3-con1.dtso --out sun50i-h618-orangepi-zero3-con1.dtbo

This is an one-off action that has only to be repeated when the overlay source changes.
To apply the overlay statically, execute: 

mv sun50i-h618-orangepi-zero3.dtb sun50i-h618-orangepi-zero3-native.dtb
fdtoverlay --input sun50i-h618-orangepi-zero3-native.dtb --output sun50i-h618-orangepi-zero3-con1.dtb sun50i-h618-orangepi-zero3-con1.dtbo
ln -s sun50i-h618-orangepi-zero3-con1.dtb sun50i-h618-orangepi-zero3.dtb

By modifying the symlink, you can now easily switch between both or possibly multiple pre-build variants of DTBs, regardless of which overlay application method your system provides or not.
If you don't want pre-built variant support, an in-place application is also possible with: 

fdtoverlay --input sun50i-h618-orangepi-zero3.dtb --output sun50i-h618-orangepi-zero3.dtb sun50i-h618-orangepi-zero3-con1.dtbo

The application of the overlay must always be repeated if the base DTB changes (update). I've attached this feature to my kernel build process so I don't have to worry about it. The kernel install process is also an option to apply local overlays permanently.

Of course, you can also use your OS's overlay application system.
If you want to modify the label names, use my *.dtso as a template and choose a new overlay filename. In this way, both variants can exist at the same time and you can choose as you wish.
Since this overlay only modifies one property value, it can even be applied repeatedly. I.e. with: 

fdtoverlay --input sun50i-h618-orangepi-zero3.dtb --output sun50i-h618-orangepi-zero3.dtb sun50i-h618-orangepi-zero3-my-labels.dtbo

you can simply rewrite the property without any further necessary actions.
I'm sorry that my method doesn't require patches or even rebuilding the entire OS and works in every system from userspace that has the DTC software package installed and the firmware get the DTB provided from the userspace (filesystem) for loading.
Any system administrator should be able to execute the commands (either symlink adjustment or overlay application) from a running system and activate the changes by rebooting.

sun50i-h618-orangepi-zero3-con1.dtsoFetching info...

0
robertoj

robertoj

Posted
  • Author
Posted

usual user,

 

I compiled the "con1" dtso you provided, but I didn't integrate it in the whole SBC dtb. I left it as a dtbo and copied it to the user overlays... it worked and I have the opiz3 gpio pins named 😄

 

As a reminder, here's how to do it:

  

{start with a fresh armbian OS, or make sure that the orangepizero3 dtb is the original}
# cat /sys/kernel/debug/gpio
{check that the GPIO pins are not named}
{copy the dtso to /boot/user-overlays}
# dtc --in-format dts sun50i-h618-orangepi-zero3-con1.dtso --out sun50i-h618-orangepi-zero3-con1.dtbo
# ls -l
total 8
-rw-r--r-- 1 root    root     591 Feb 18 01:35 sun50i-h618-orangepi-zero3-con1.dtbo
-rw-r--r-- 1 root    root    1374 Feb 17 22:36 sun50i-h618-orangepi-zero3-con1.dtso
# nano /boot/armbianEnv.txt
{add line: user_overlays=sun50i-h618-orangepi-zero3-con1}
# reboot
# cat /sys/kernel/debug/gpio
{the gpio pins are named}

 

I was expecting it that the user overlays appear in the armbian-config utility... but my dtbo didnt show in the system>hardware selection options... is this normal?

 

To any newbie trying this: be careful of conflicts in activating a kernel-provided overlay and a user overlay at the same time:

https://docs.armbian.com/User-Guide_Allwinner_overlays/

 

I just noticed that there's a February 15 linux image... I will try that :)

 

Update... the compiled dtso did not work for the new linux OS image... uboot could not overlay the dtbo

  Reveal hidden contents

and I noticed that it uses a different dtb... what should I do to update the dtso and make it work?

sun50i-h618-orangepi-zero3.dtb

 

HOWEVER: the DTSO works when applying it in the DTB, as you suggested. It is only when trying to apply the DTBO with uboot, it fails.

Unfortuately, the linux os freezes after 10 minutes or so  nevermind... it maybe another cause...

 

0
usual user

usual user

Posted
Posted
  On 2/18/2024 at 1:56 AM, robertoj said:

I didn't integrate it in the whole SBC dtb. I left it as a dtbo and copied it to the user overlays

Expand  

A perfectly legitimate method, but not always available:

 

  On 2/18/2024 at 1:56 AM, robertoj said:

https://docs.armbian.com/User-Guide_Allwinner_overlays/#armbian-specific-notes
Armbian specific notes
DT overlays are a Work-in-Progress (WIP) feature, present only in certain images.
Please note that different SoCs will have different sets of available overlays.

Expand  

 

  On 2/18/2024 at 1:56 AM, robertoj said: 
{check that the GPIO pins are not named}
Expand  

This is not necessary, an overlay is just an overlay that overlays what already exists. Run the command "fdtoverlay..." three times in a row, keep DTB backups each time and compare them at last.

 

  On 2/18/2024 at 1:56 AM, robertoj said:

I was expecting it that the user overlays appear in the armbian-config utility... but my dtbo didnt show in the system>hardware selection options... is this normal?

Expand  

This is a question for the one who came up with the overlay application method.

 

  On 2/18/2024 at 1:56 AM, robertoj said:

be careful of conflicts in activating a kernel-provided overlay and a user overlay at the same time

Expand  

Mainline kernel usually doesn't come with overlays, they are usually added by the Armbian build system. My method should also work in combination.

 

  On 2/18/2024 at 1:56 AM, robertoj said:

Failed to load '/boot/overlay-user/sun50i-h618-orangepi-zero3-con1.dtbo'

Expand  

Judging by the failure message, the overlay can't be found.

 

  On 2/18/2024 at 1:56 AM, robertoj said:

HOWEVER: the DTSO works when applying it in the DTB, as you suggested. It is only when trying to apply the DTBO with uboot, it fails.

Expand  

You have thus proven that there is nothing wrong with the base DTB and the DTBO. It is to blame the tool (method) that is used to apply the overlay.
Dynamic application of overlays at boot time is only necessary if the firmare can automatically detect the need to apply an overlay by reading hardware identifiers. This is a method inherited from the Raspberry Pi and has its justification with its expansion modules with hardware identifier.
Using a configuration file (armbianEnv.txt) is just another way of statically selecting overlays and basically the same procedure as my method. I understand that overpaid Armbian developers implement something like this method out of boredom for devices that don't need it and then dynamically apply the statically selected overlays. But I prefer to rely on tools (fdtoverlay) that are more mature. After all, it's used in every kernel build (it's part of the kernel sources)  and maintained by the mainline Devicetree developers. And if something didn't work with it, it would immediately stand out and also be repaired. Because kernels are very rarely built 😉

0
SteeMan

SteeMan

Posted
Posted
  On 2/18/2024 at 1:56 AM, robertoj said:

I was expecting it that the user overlays appear in the armbian-config utility... but my dtbo didnt show in the system>hardware selection options... is this normal?

Expand  

It depends on what you mean by normal.  Currently the OVERLAY_PREFIX for this board is set to: OVERLAY_PREFIX="sun50i-h616" as the overlays are currently being shared between the h616 and h618.  So if you rename the overlay with that prefix it should be picked up by armbian-config.

0
usual user

usual user

Posted
Posted
  On 2/18/2024 at 9:53 PM, SteeMan said:

the overlays are currently being shared between the h616 and h618.

Expand  

Overlays are always device-specific, and in most cases, even use-case-specific.
Trying to share between different devices takes a huge amount of maintenance as opposed to a simple copy of a similar overlay. All possible interactions have to be taken into account and expecting NOOB users to understand their dependencies is asking for trouble. And if they do have to be different later, it is even more difficult to sort them apart.
And besides, what advantage does it bring to the user, since all Armbian images only address one specific device at a time?

0

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept