Jump to content

ag123

Members
  • Posts

    233
  • Joined

  • Last visited

Everything posted by ag123

  1. @thuvasooriya wrote hi if you review this thread, the earlier comments, you would notice that there are quite varous discussions about DTS overlays for the gpio headers. noticably discussions from / between @Gunjan Gupta @pixdrift @Stephen Graf. Unfortunately, it seemed for now not all the changes have made it into the trunk. there are also various discussions about libgpiod and gpiod, hope those may help with access to the pins.
  2. @thuvasooriya wrote rather than to use HDMI and a monitor, I used a usb-uart (usb-serial) dongle that lets me connect over the serial console with the debug pins and I'm literally able to boot up in a serial console and (even) configure networking, i.e. I didn't even need network and can change the network interface configurations. That would also be a way to troubleshoot boot up problems if there is. I used the serial debug pins/console to configure networking as more than often, the default setup of network isn't what I want, and playing with the network interfaces will lock me out of ssh. After I've network configured over usb-uart, I can then ssh remotely into the device over the network. And that if you use dynamic IP, it may help to install and use avahi-daemon and avahi-tools (i.e. multicast DNS), I installed avahi-daemon on the OPi Z3 Armbian board so that I can find it from my main linux box using avahi-browse -a , and that ssh into there could be simply ssh orangepizero3.local that's a way to practically use it headless , in fact, after I've setup things, it is now my WiFi AP on the desk.
  3. Among the things to try, get and set up a usb-serial (usb-uart) dongle to the debug UART pins, and you should be able to see the boot up in a serial console. The boot messages may provide a clue to what went wrong.
  4. @electricworry I can't remember where I saw comments about the HDMI sound issues, but that it is more than likely that HDMI and even graphics could be *undocumented* and *reverse engineered* (possibly by the talented people on the linux sunxi https://linux-sunxi.org/Main_Page and such efforts), it could be an up hill task to reverse engineer HDMI sound in particular considering the complexity of such interfaces. there is apparently some related work, thread and thanks to @Nick A for researching and sharing various info, there may be some hints as to what needs to be done. it seemed quite possible to patch dts files to get hdmi sound support, but it is just wild guesses, you would need to review the info.
  5. @thuvasooriya while I do not have an OrangePi Zero 2W (I only have Zero 3), it would seem to me that Zero 2W is basically Zero 3 less the onboard Ethernet. I'm not sure what else is different where 'compatibility' goes. Ethernet for Zero 2W is on the expansion board that Orange Pi sells, hence if you want ethernet, you may want to purchase the expansion board to experiment. No promises if it'd works though. It'd seem to me that OrangePi is basically selling on the 'form factor' difference, and 2W being smaller won't fit the bulky ethernet RJ45 connector and the phy chip. But that if you actually try that, it'd be good to report in a comment if it (expansion board and ethernet) works or otherwise. As well if you used the Zero 3 images, e.g. from 'original' image https://www.armbian.com/orange-pi-zero-3/ , if you scroll down to the bottom you woul see the links to the images and torrents. It would be good to feedback in a comment about what works or not etc. I went straight with Zero 3 initially as I wanted both ethernet and wifi, those are built on board for Zero 3 and hence that.
  6. @boorch wrote Hi thanks for trying it out, I feel somewhat embarrassed that I've not tried it out myself. In terms of the release the vendor Orange Pi (Xun Long) actually first released the Zero 3 then subsequently Zero 2W they are both based on H618 do post a comment to say what works or not. If your are trying my image, that is based on a minimal Debian Bookworm build, I did that mainly to save up on the image size/footprint. And also that I'm using that mainly as a wifi hotspot, and a desktop environment bring along too much baggage add gigabytes of storage use, consume a lot of memory and possibly slow down my intended use. To go from minimal to a desktop environment, I googled and found this page: https://wiki.debian.org/DesktopEnvironment as documented you can try > apt show task-desktop Package: task-desktop Version: 3.73 Priority: optional Section: tasks Source: tasksel Maintainer: Debian Install System Team <debian-boot@lists.debian.org> Installed-Size: 6,144 B Depends: tasksel (= 3.73), xorg, xserver-xorg-video-all, xserver-xorg-input-all, desktop-base Recommends: task-gnome-desktop | task-xfce-desktop | task-kde-desktop | task-lxde-desktop | task-gnome-flashback-desktop | task-cinnamon-desktop | task-mate-desktop | task-lxqt-desktop, xdg-utils, fonts-symbola, avahi-daemon, libnss-mdns, anacron, eject, iw, alsa-utils, sudo, firefox | firefox-esr, cups Download-Size: 1,036 B APT-Sources: http://mirror.sg.gs/debian bookworm/main arm64 Packages Description: Debian desktop environment > apt show task-gnome-desktop Package: task-gnome-desktop Version: 3.73 Priority: optional Section: tasks Source: tasksel Maintainer: Debian Install System Team <debian-boot@lists.debian.org> Installed-Size: 9,216 B Depends: tasksel (= 3.73), task-desktop, gnome-core Recommends: gnome, synaptic, libreoffice-gnome, libreoffice-writer, libreoffice-calc, libreoffice-impress, libreoffice-help-en-us, mythes-en-us, hunspell-en-us, hyphen-en-us, network-manager-gnome Download-Size: 1,184 B APT-Sources: http://mirror.sg.gs/debian bookworm/main arm64 Packages Description: GNOME ^ I think that is the package to install the desktop environment for instance to install gnome desktop it could be > sudo apt install task-gnome-desktop Reading package lists... Done Building dependency tree... Done Reading state information... Done The following additional packages will be installed: accountsservice acl adwaita-icon-theme apache2-bin apg appstream apt-config-icons at-spi2-common at-spi2-core baobab bluez-obexd bubblewrap colord colord-data dconf-cli dconf-gsettings-backend dconf-service desktop-base desktop-file-utils dictionaries-common emacsen-common eog evince evince-common evolution-data-server evolution-data-server-common folks-common fonts-quicksand fonts-urw-base35 gcr gdisk gdm3 geocode-glib-common gir1.2-accountsservice-1.0 gir1.2-adw-1 gir1.2-atk-1.0 gir1.2-atspi-2.0 gir1.2-evince-3.0 gir1.2-freedesktop gir1.2-gck-1 gir1.2-gcr-3 gir1.2-gdesktopenums-3.0 gir1.2-gdkpixbuf-2.0 gir1.2-gdm-1.0 gir1.2-geoclue-2.0 gir1.2-gmenu-3.0 gir1.2-gnomebluetooth-3.0 gir1.2-gnomedesktop-3.0 gir1.2-gnomedesktop-4.0 gir1.2-goa-1.0 gir1.2-graphene-1.0 gir1.2-gst-plugins-base-1.0 gir1.2-gstreamer-1.0 gir1.2-gtk-3.0 gir1.2-gtk-4.0 gir1.2-gtksource-4 gir1.2-gweather-4.0 gir1.2-handy-1 gir1.2-harfbuzz-0.0 gir1.2-ibus-1.0 gir1.2-javascriptcoregtk-4.1 gir1.2-json-1.0 gir1.2-mutter-11 gir1.2-nm-1.0 gir1.2-nma-1.0 gir1.2-notify-0.7 gir1.2-pango-1.0 gir1.2-peas-1.0 gir1.2-polkit-1.0 gir1.2-rsvg-2.0 gir1.2-soup-3.0 gir1.2-upowerglib-1.0 gir1.2-webkit2-4.1 gjs gkbd-capplet glib-networking glib-networking-common glib-networking-services gnome-backgrounds gnome-bluetooth-3-common gnome-bluetooth-sendto gnome-calculator gnome-characters gnome-contacts gnome-control-center gnome-control-center-data gnome-core gnome-desktop3-data gnome-disk-utility gnome-font-viewer gnome-keyring gnome-logs gnome-menus gnome-online-accounts gnome-session gnome-session-bin gnome-session-common gnome-settings-daemon gnome-settings-daemon-common gnome-shell gnome-shell-common gnome-shell-extensions gnome-software gnome-software-common gnome-sushi gnome-system-monitor gnome-terminal gnome-terminal-data gnome-text-editor gnome-themes-extra gnome-themes-extra-data gnome-user-docs gnome-user-share grilo-plugins-0.3 gsettings-desktop-schemas gstreamer1.0-gl gstreamer1.0-gtk3 gstreamer1.0-packagekit gstreamer1.0-pipewire gstreamer1.0-plugins-base gstreamer1.0-plugins-good gstreamer1.0-x gtk-update-icon-cache gtk2-engines-pixbuf gvfs gvfs-backends ... Suggested packages: apache2-doc apache2-suexec-pristine | apache2-suexec-custom www-browser colord-sensor-argyll gnome | kde-standard | xfce4 | wmaker ispell | aspell | hunspell wordlist eog-plugins nautilus-sendto unrar evolution fonts-freefont-otf | fonts-freefont-ttf fonts-texgyre orca libpam-fprintd libpam-sss libpam-pkcs11 gstreamer1.0-pulseaudio pkexec gnome usbguard gir1.2-malcontent-0 gir1.2-telepathyglib-0.12 gir1.2-telepathylogger-0.2 ... Recommended packages: xserver-xephyr fonts-noto-color-emoji cups-pk-helper gnome-remote-desktop power-profiles-daemon rygel | rygel-tracker malcontent-gui network-manager-gnome realmd firefox-esr | firefox | chromium | chromium-browser | epiphany-browser | gnome-www-browser libproxy1-plugin-networkmanager low-memory-monitor gnome-keyring-pkcs11 iio-sensor-proxy pkexec bolt chrome-gnome-shell ibus switcheroo-control gnome-shell-extension-prefs fwupd nautilus-extension-gnome-terminal gnome-accessibility-themes aspell-en | aspell-dictionary | aspell6a-dictionary libaacs0 libcanberra-gtk3-module enchant-2 libgdk-pixbuf2.0-bin libgphoto2-l10n fonts-droid-fallback libgtk-3-bin libgtk-4-bin usbmuxd libmtp-runtime ... 0 upgraded, 584 newly installed, 0 to remove and 32 not upgraded. Need to get 301 MB of archives. After this operation, 1,218 MB of additional disk space will be used. Do you want to continue? [Y/n] I stopped and answered 'n' at the prompt, if you have the space, you could try that out to see if that works to install and setup a full desktop environment note that I've not tried the above, and there are also other selections / desktop environment that you can choose Recommends: task-gnome-desktop | task-xfce-desktop | task-kde-desktop | task-lxde-desktop | task-gnome-flashback-desktop | task-cinnamon-desktop | task-mate-desktop | task-lxqt-desktop, xdg-utils, fonts-symbola, avahi-daemon, libnss-mdns, anacron, eject, iw, alsa-utils, sudo, firefox | firefox-esr, cups e.g. there are the above of task-xxx-desktop which I'd think installs the respective desktop environment. After installing sudo systemctl set-default graphical.target to make sure that the desktop environment starts up on reboot if you do try that out, do leave a comment on your experiences with it and how it works. That may help others wanting to do the same. post a screenshot another page found from a google search for a reference https://www.layerstack.com/resources/tutorials/How-to-install-Graphical-User-Interface-GUI-for-Debian-11-Cloud-Servers ^ there are other stuff there e.g. enable root login etc
  7. SBC and embedded world is an absolute jungle, take for instance Orange Pi Zero 3 (just as an example) , it has an on board flash chip which can store a boot rom. the kernel bootloader u boot https://en.wikipedia.org/wiki/Das_U-Boot can either: boot from a normal sd card (and this depends on the vendor's boot rom, which loads the first few sectors on the sd card (which is u-boot itself) and jumps to u-boot which in turns boots linux (no uefi) u-boot can be installed in that boot rom become the BIOS ! itself, and u-boot can boot linux *directly* u-boot can practically emulate any kind of booting scheme (including the vendor's original, uefi etc) but that requires u boot to replace the vendor's boot rom (deemed a risky activity, it may brick the board) and that every different board can have different hardware configuration (a LED on a different pin or configuration (e.g. pull up or pull down) make a different board (with everything else being the same) !) the above already constitute M different boot configurations and N different boards, with just 8 pins for LEDs you can make a combination of 8! 8x7x6x5x4x3x2x1 permutations x 2 configurations (pull up or pull down) ~ 80640 different boards for the same board. so for sanity and practicality, a device tree overlay is made for a *fixed* board. e.g. Orange Pi Zero 3 and that this project is practically supporting M socs x N boards x X configurations x Y distributions (debian / ubuntu to name just 2, wrong not just 2 within that 2 there are different *releases* ) x Z kernels (legacy / stable / bleeding edge) and that is not just 3 versions, oh and just UEFI alone has another N different versions https://uefi.org/specifications 😛 btw u-boot practically achieved the *holy grail* (look ma no BIOS) http://www.haifux.org/hebrew/lectures/111/img0.html it is as hard core and bare metal as one can be. it isn't about OS being 'portable' per se, than it is about what you see in each figment (i.e. a particular board with a particular config) is just one single very narrow endpoint in the sea of infinite permutations.
  8. @Igor, @Gunjan Gupta thanks for all that effort, I'm sure many would patiently, and eagerly wait for that and an ad for Armbian, for/to new users who have stumbled into this thread https://www.armbian.com/donate/ those who are using Armbian e.g. on Orange Pi Zero 3, do consider 'sponsoring' Armbian (e.g. with a subscription etc). 'donate' is actually an incorrect term for that, but there is no equivalent. open sourced projects like such takes a lot of effort, but that unlike commercial SASS (software as a service) etc, there is practically no feasibility to put a *paywall* as do most other commercial providers / software. Some providers resorted to *close source*. And most will *detest* this as imagine that you need to fix a bug that *blink a led* on your pin header, that'd means *no access*, *cannot be done*. embedded *intrusive* ads would be a next wors(e,t) thing --- on another topic, about technicals: i look at some 'solutions' for patches, i've not found practically anything that 'works' the problem of patch sets against multiple targets (different patch set applies) and version, and between multiple different *contexts*, between 'release' upgrades and that the patch sets in themselves has their own dependencies on the core source codes (sometimes even modules in the source codes become recursive patch-on-patch dependencies) and between patches. something like gerrit code review, *does not address the issue* https://www.gerritcodereview.com/about.html https://gerrit-documentation.storage.googleapis.com/Documentation/3.9.2/intro-rockstar.html that would instead cause stalls in development workflow as we have n different boards with different distribution targets with different *boot loaders* and hardware and configuration (e.g. a led on a different pin makes a *different board* even if every thing else being the same) this conundrum has never been fully addressed even today with the device tree. We need 'dynamic device tree' that can literally *change on the fly* after things booted up, because you can hot plug anything on the pin headers. the whole development would practically *stop* as the different *boards* would have *no (or very few) reviewers* then I looked at stackedgit https://stacked-git.github.io/guides/usage-example/ https://stacked-git.github.io/guides/tutorial/ https://github.com/stacked-git/stgit/ looks promising but again that would take time and effort to explore and it is likely not adequate to address this same issue.
  9. the 'community' one is here, scroll right to the bottom https://www.armbian.com/orange-pi-zero-3/ and the kernel version is at least 6.6 and above apparently someone has seen the same , so it isn't 'new' https://www.linux.org/threads/protocol-0000-is-buggy-dev-wlan0.42774/ if one google around the web one may stumble into this https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml it could mean a device you have is sending out goofy packets that are not regular IP packets. the normal protocols used are usually TCP, UDP and ICMP.
  10. just like to mention that I managed to run a build for Orangepizero3 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bookworm_edge_6.7.10_minimal the kernel is 6.7.10 the build managed to run to completion the image is completely untested -rw-rw-r-- 1 armbian root 1413480448 Mar 20 02:38 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bo okworm_edge_6.7.10_minimal.img -rw-rw-r-- 1 armbian root 213 Mar 20 02:38 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bo okworm_edge_6.7.10_minimal.img.sha -rw-rw-r-- 1 armbian root 19756 Mar 20 02:38 Armbian-unofficial_24.5.0-trunk_Orangepizero3_bo okworm_edge_6.7.10_minimal.img.txt And I'm not sure if it'd even work. It is not uploaded anywhere, For this build as OrangePi Zero 3 is deemed csc, you need to select the experimental unsupported builds to see the boards being listed. I ran the build just to see that the build completes after all, having no time (yet) to run tests with that. -- update it was TLDR (too late didn't read) then ok it is here, and remember *untested* (it is not known if it'd work if at all), *unofficial* *unsupported* use at your own risk https://www.mediafire.com/file/bym559l94sn8xyd/Armbian-unofficial_24.5.0-trunk_Orangepizero3_bookworm_edge_6.7.10_minimal20240320.7z/file this (file) won't be there on the permanent basis it'd seem @Igor is moving Armbian to 6.8 (hey that's just 9 days 'old' https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tag/?h=v6.8, as of this comment) that's a good thing, and thanks this linked image would be a pre-6.8, if it works. other fun stuff https://www.omgubuntu.co.uk/2024/03/linux-kernel-6-8-new-features https://www.zdnet.com/article/linux-kernel-6-8-offers-some-exciting-new-features-and-fixes-all-over/ https://www.theregister.com/2024/03/04/linux_6_8_rc_7/ https://www.phoronix.com/review/linux-68-features https://lore.kernel.org/linux-kernel/CAHk-=wiehc0DfPtL6fC2=bFuyzkTnuiuYSQrr6JTQxQao6pq1Q@mail.gmail.com/T/
  11. i'd be kind of 'off topic' here, armbian is somewhat in the 'fast lane', 'bleeding edge' https://www.debian.org/releases/ recently when we worked on Orange Pi Zero 3 we actually jumped right into bookworm, had there been something more 'bleeding edge' that may be it and that we jumped into 6.6 kernel (as it is about the 1st kernel that has support for Orange Pi Zero 3 on allwinner H618 cpu, and that actually as development progress, it actually advanced to 6.7, 6.8 etc. Today, I just installed Ubuntu jammy from Ubuntu, only to find that that is 6.5 ! and that even orange pi's 'official' image for Orange Pi Zero 3 gets 'left behind' at 6.1 I'd suggest to try upgrading to the 'latest' debian (bookworm?) image, it may take quite a bit of 'reinstall' though. And that everything is 'brand new', 'bleeding edge' there. the python 3 version is 3.11, that in ubuntu jammy is 3.10 ! that said, there are bound to be some broken bones left around somewhere, it is 'under construction' (all the time) oh some fun stuff, 6.8 is 9 days old, who knows that might be the new Armbian kernel https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/
  12. it is there in 'community releases' https://www.armbian.com/orange-pi-zero-3/ scroll to the bottom of that page get a 'whole number' (1GB, 2GB, 4GB) dram size board, for 1.5GB there it is still under 'research', you + (community) need to find a way to tell u-boot (the bios and boot loader) that the board is 1.5GB once that is figured out, it is possible to practically use any board with any amount of memory.
  13. @jvro wrote: Try the 'server' / minimal image? it used to be called 'run levels' in sysv init. Now it is systemd https://opensource.com/article/20/5/systemd-startup#targets https://www.cyberciti.biz/faq/switch-boot-target-to-text-gui-in-systemd-linux/ There may be some features if you review the user guide https://docs.armbian.com/User-Guide_Getting-Started/ and maybe check in the tutorials forum section https://forum.armbian.com/forum/40-reviews-tutorials-hardware-hacks/ but that for anything more complicated, what I did instead is to get a usb-uart dongle connect to the 3 pins for 'debug' console, check the documentation for Orange Pi Zero 3 from the vendor. Then that you can literally boot up in a console / terminal app, login on the console / terminal app etc even for the first time. For now I keep the steps as a set of manual command line commands I run, including changing the passwords etc. And basically 'copy and paste' the commands say from a pre maintained file with the steps and commands. edit: I think for that matter, it is quite possible to *script* that say using python https://pyserial.readthedocs.io/en/latest/ and have the 'auto setup and config' all done over serial usb-uart over that debug port. and for those who are 'ancient' enough, there is tcl/tk https://www.tcl.tk/ and expect https://wiki.tcl-lang.org/page/Expect https://wiki.tcl-lang.org/page/BOOK+Exploring+Expect https://gist.github.com/fstab/6d39fae3a436d9bd6cecb1d9fde9a667 ---- I think it is possible to directly customize the image though. That would take mounting the image as a loop device in Linux (prefably make a copy of it). And perhaps for the config files (e.g. in /etc) on your running SD card, copy them out and replace the same in the image.
  14. @Long-Johnny Rather than to say 'never solved', we (as a community) need to learn about *uboot* https://docs.u-boot.org/en/latest/ https://linux-sunxi.org/U-Boot this is practically the *BIOS* for these little boards that we use and that u-boot boots Linux - it is the boot loader. Once you / we find a way to pass that memory size to *uboot*, then it is a matter of learning to configure a file e.g. edit a DTS overlay to encode the memory size. And there you have it, a fully supported board. But that that step/procedure may have to be manually done by hand. In that sense, once one figures this out, one can manually configure these boards for any arbitrary memory size.
  15. @Long-Johnny 1.5gb issue is a *known issue* The problem is in u-boot, rather to explain it in a simple manner, the DRAM controller in H616/H18 is *undocumented*, so developers has to probe in the dark to try to reverse engineer how it works, it is a 'miracle' that it works today where there is practically *no documentation* about the DRAM controller. The dram chips has registers which encode the size of the dram, but that there is *no way* to access the dram registers because the DRAM controller is *undocumented*. Hence, developers working on open source u-boot, Linux resort to *hacks*, the memory size is probed by writing some data at specific locations and reading it back. The trouble is that for DDR4 1.5gb dram chips, the address wraps around, so that trying to write something to 2GB for a 1.5GB chip produce *no errors*, so 1.5 GB boards are detected as 2GB boards. it gets written into an unknown location that will corrupt some other memory and uboot or kernel or any apps that use memory above 1.5GB and uboot, kernel or the app will simply *crash*. For that matter, there is no practical code fixes that can fix this, because no algorithms can generally handle arbitrary address wrap around for *different* memory sizes. e.g. there can be at some point 2.5gb, 3.5gb, 1.2gb, 1.4gb. 1.8gb, 0.9gb or any odd combination of memory, and there is no way to detect by writing and reading back memory how that wraps around if say writing memory to every 512MB locations simply wrap around to some unknown address. The only way is if Allwinner release documentations for the H618 memory controller and that the memory size be read from the dram chip registers as a formal fix to it. To find a solution to this, one would need to research a way to pass the memory size to *uboot* (and therefore the kernel), so that u-boot can read that memory size say from a config file, DTS overlay or on the uboot command prompt. In the mean time, if one don't want to try researching the 'deep end' as suggested above, use boards with 'whole numbers' memory sizes. e.g. 1GB, 2GB, 4GB.
  16. @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.
  17. @robertoj, all I stumbled into this: https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/about/ This seemed to be there in a 'minimal' build, check if you are able to run those commands the pins didn't seemed named sudo gpioinfo [sudo] password for armbian: gpiochip0 - 288 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high line 4: unnamed unused input active-high ... gpiochip1 - 32 lines: line 0: unnamed unused input active-high line 1: unnamed unused input active-high line 2: unnamed unused input active-high line 3: unnamed unused input active-high ... however, that they seemed to be mapped to 2 (set of) pin-control drivers https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/pinctrl/sunxi/pinctrl-sun50i-h616.c?h=v6.7.4 #include "pinctrl-sunxi.h" static const struct sunxi_desc_pin h616_pins[] = { /* Internally connected to the AC200 part in the H616 SoC */ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 0), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "emac1"), /* ERXD1 */ SUNXI_FUNCTION(0x4, "i2c0"), /* SCK */ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 0)), /* PA_EINT0 */ SUNXI_PIN(SUNXI_PINCTRL_PIN(A, 1), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "emac1"), /* ERXD0 */ SUNXI_FUNCTION(0x4, "i2c0"), /* SDA */ SUNXI_FUNCTION_IRQ_BANK(0x6, 0, 1)), /* PA_EINT1 */ ... a lot more ... static const unsigned int h616_irq_bank_map[] = { 0, 2, 3, 4, 5, 6, 7, 8 }; static const struct sunxi_pinctrl_desc h616_pinctrl_data = { .pins = h616_pins, .npins = ARRAY_SIZE(h616_pins), .irq_banks = ARRAY_SIZE(h616_irq_bank_map), .irq_bank_map = h616_irq_bank_map, .irq_read_needs_mux = true, .io_bias_cfg_variant = BIAS_VOLTAGE_PIO_POW_MODE_CTL, }; static int h616_pinctrl_probe(struct platform_device *pdev) { return sunxi_pinctrl_init(pdev, &h616_pinctrl_data); } static const struct of_device_id h616_pinctrl_match[] = { { .compatible = "allwinner,sun50i-h616-pinctrl", }, {} }; static struct platform_driver h616_pinctrl_driver = { .probe = h616_pinctrl_probe, .driver = { .name = "sun50i-h616-pinctrl", .of_match_table = h616_pinctrl_match, }, }; builtin_platform_driver(h616_pinctrl_driver); https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/pinctrl/sunxi/pinctrl-sun50i-h616-r.c?h=v6.7.4 #include "pinctrl-sunxi.h" static const struct sunxi_desc_pin sun50i_h616_r_pins[] = { SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 0), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "s_rsb"), /* SCK */ SUNXI_FUNCTION(0x3, "s_i2c")), /* SCK */ SUNXI_PIN(SUNXI_PINCTRL_PIN(L, 1), SUNXI_FUNCTION(0x0, "gpio_in"), SUNXI_FUNCTION(0x1, "gpio_out"), SUNXI_FUNCTION(0x2, "s_rsb"), /* SDA */ SUNXI_FUNCTION(0x3, "s_i2c")), /* SDA */ }; static const struct sunxi_pinctrl_desc sun50i_h616_r_pinctrl_data = { .pins = sun50i_h616_r_pins, .npins = ARRAY_SIZE(sun50i_h616_r_pins), .pin_base = PL_BASE, }; static int sun50i_h616_r_pinctrl_probe(struct platform_device *pdev) { return sunxi_pinctrl_init(pdev, &sun50i_h616_r_pinctrl_data); } static const struct of_device_id sun50i_h616_r_pinctrl_match[] = { { .compatible = "allwinner,sun50i-h616-r-pinctrl", }, {} }; static struct platform_driver sun50i_h616_r_pinctrl_driver = { .probe = sun50i_h616_r_pinctrl_probe, .driver = { .name = "sun50i-h616-r-pinctrl", .of_match_table = sun50i_h616_r_pinctrl_match, }, }; builtin_platform_driver(sun50i_h616_r_pinctrl_driver); gpiochip0 apparently corresponds to sun50i-h616-pinctrl, the main large bank of IO lines / those are muxed and a lot of them have alternate functions e.g. emac, etc. it'd seemed a little strange that gpiochip1 (sun50i-h616-r-pinctrl) gets a readout of 32 lines. (^edit: https://www.kosagi.com/w/index.php?title=Definitive_GPIO_guide linux gpio number = (gpio_bank - 1) * 32 + gpio_bit solves the puzzle, it could mean that the gpio register is 32 bits and that actually 2 lines are defined. that gives a feeling that the other bits/lines are *undocumented* (often marked 'reserved') 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 and apparently gpiod bindings are after all standard https://git.kernel.org/pub/scm/libs/libgpiod/libgpiod.git/tree/bindings
  18. @robertoj I started reading up a few things but that I'm more confused as ever: There is this thing about pincontrol https://www.kernel.org/doc/html/v4.13/driver-api/pinctl.html https://elinux.org/images/b/b6/Pin_Control_Subsystem_Overview.pdf https://wiki.st.com/stm32mpu/wiki/Pinctrl_overview ^ I liked this one from ST, but that I've not read well enough to understand how pin-control relates to gpio. on a superficial level, I understand it like such, as there are various configurations related to gpio pins e.g. that gpio pins can be configured in varous setups, e.g. input, output, pull up, pull down and other gpio properties etc (possibly soc related), then that for the pins in addition to gpio, there is pin mux, which 'behind' it can be configured for various 'alternate functions' e.g. spi, i2c, uart, pwm etc, then add interrupts etc. and accordingly earlier 'gpio' implementations eventually digressed and requires 'hacks' to get around 'missing' capabilities that is mapped in the more complex pin-control. But that I don't understand deeper than this that if pin control after all configures the pins as above, then where do gpio in the 'simple' sense e.g. reading the pins high or low, or writing to the pins work? Accordingly, there are API interfaces for that if you read the documentation, but I got stuck understanding further about this, i.e. I still don't know how gpio works in this context. on further 'google searches', I stumbled into more recent documentation https://www.kernel.org/doc/html/v6.7/driver-api/pin-control.html https://www.kernel.org/doc/html/v6.7/driver-api/gpio/index.html so it'd seem pin-control and gpio are after all 2 sets of API
  19. @Tusc wrote: they are not quite yet ready for 'prime time', check out the rolling releases: https://github.com/armbian/os/releases/latest https://github.com/armbian/os/releases/tag/24.2.0-trunk.519 expand the 'Assets' flap, use your web browser's in page search and look for 'zero3'. still in 'bleeding edge' (technology) stage, try it/them out feedback on what works, issues etc. @Gunjan Gupta curiously in the most recent trunk.526 https://github.com/armbian/os/releases/latest a text search for 'zero3' draws a blank, but it is there in 519
  20. i used one of those ch340 dongles https://www.aliexpress.com/w/wholesale-ch340.html , but with Orange Pi Zero 3, they worked quite well not so much for 'quality', but that they are rather low costs, and that some of the modules has switches between 3.3v and 5v vcc. I get one of those with switches and set it at 3.3v
  21. @VioletGiraffe Orange Pi Zero 3 is still in *test* phase, review the many comments above e.g. from @pixdrift, @Gunjan Gupta, @Stephen Graf et.al. , if images links are embedded in comments, those are *test* images if they are listed for now. the rolling release images can be found here: https://github.com/armbian/os/releases/latest do try them out and add your comment as feedback in this thread if you tried it, providing info such as your board , memory size, the image used etc. what works and any issues if you discovered it. but practically speaking, support for Orange Pi Zero 3 is really / practically *reverse engineered*, even the dram controller is *undocumented* and it is an 'best effort' that it works (many things are wild guesses e.g. trials based on other chips e.g. H616 and 'they happened to work'). Hence, the images would likely always be *use at your own risk* even if it becomes 'community' support.
  22. actually that box is good in a sense that it has quite a few peripherals on board and is probably cheaper than development boards in a sense that it comes with a case. i've not 'touched' them as that normally public documentation tend to be even thinner than do development boards. but yup, I'd think it would be good if Armbian runs on them as well, more options for whoever is using Armbian hopefully that the H618s are after all similar that the difference between them is simply a DTS
  23. @pixdrift rather than to say that 'enable all' isn't well received, i think we (at least myself) may be misguided, as I've not explored a lot of things, especially access to the io header pins. there are also a lot of things that we'd need @pixdrift, @Gunjan Gupta, @Stephen Graf and others who happened to use those functionality (e.g. the header pins / spi / gpio etc) to share if after all enabling them actually lead to conflicts? and if after all pinmux 'works the way as expected', e.g. my notion that pin mux selects the function is *pure speculation*, e.g. that after all we can simply 'enable everything' and just use pin mux to choose between them. e.g. pin mux determines if gpio or alternate function ( spi / uart/ i2c / pwm etc is seen at the pin. There are also *unproven* things that I simply speculate if simply 'okay' the device in DTS actually cause a higher power consumption / higher temperature, there is no actual report / comment to indicate that it really works that way ! i'm simply being *lazy* to comment that maybe leaving it 'disabled' is just 'safe', that may not even be true.
  24. @Igor it is a little unfortunate that in this open sourced world, not all users would see using and supporting Armbian as a cooperative https://dictionary.cambridge.org/dictionary/english/cooperative I'm not sure what can be done, but this state of the situation would likely persist. in a certain sense, getting Linux and Armbian to run on Orange Pi Zero 3 is already a 'heroic' effort. Given, the dram controller is *undocumented*, all that u-boot codes that made the memory detection work is a 'miracle' pieced together from reverse engineering and wild guesses. So are all that 'heroic' efforts by linux-sunxi and Armbian to make it run on H616 / H18 and supporting the ethernet PHY as well as uwe-5622 wifi. for that matter the H618 and uwe5622 technical reference manual cannot be found in the wild and all these efforts thus far from notably @Gunjan Gupta , @pixdrift , @Stephen Graf et.al. the wild tests and trials to tweak the configurations *so happens to work*! it can reasonably be said that running any open-sourced linux and/or Armbian on Orange Pi Zero 3 will practically be always *use at your own risk*, as no one can give any assurance that any of these are after all formal. In short, it wouldn't have happened without all these community effort and Armbian itself and efforts from linux-sunxi contributors. it is an incredible effort on its own. for that matter Orange Pi Zero 3 with all these community effort from Armbian and linux sun-xi nearly makes it lives up to an Raspberry Pi 3B+, at least in terms of functionality and performance. it is no small feat / achievement. There is also the notion that the board developers / manufacturers should after all fund and support Armbian including the technicals, it is a different consideration however. I'd like to say that Armbian *runs well* on Orange Pi Zero 3, for 'basic' use with ethernet and wifi. There are many other things that I've not yet explored but the @pixdrift, @Stephen Graf have explored to some extent. e.g. the gpios, spi and such alternate functions on the pins etc. as for the "1.5GB problem", my thoughts are currently this. We'd need to publish *release notes* or more correctly *read this first*, with this board if this board is hosted as a 'community supported' board. Because, the memory detection logic *in uboot* will probe into *wrap around* addresses and falsely detect memory as available. There is *no solution* as the dram controller is *undocumented* , so one way out of this is to publish a note to say that for 1.5GB and some such board owners, a *solution*, is they have to edit /boot/armbianEnv.txt, and use a different DTS overlay that encode the memory size in the overlay. This is thinking ahead, I've not tried this solution if it after all works if at all. we'd probably can put other *pitfalls* and known-limitations and *disclaimers* (e.g. use at your own risk) in the *read this first*
  25. @Uko take a look at this comment it is 'stashed in the middle' a few pages earlier in this thread https://forum.armbian.com/topic/29202-orange-pi-zero-3/?do=findComment&comment=179400
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines