Jump to content

ag123

Members
  • Posts

    233
  • Joined

  • Last visited

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines