Jump to content

Stephen Graf

Members
  • Posts

    96
  • Joined

  • Last visited

Other groups

Contributor/Maintainer

Recent Profile Visitors

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

  1. @klaute I did a quick check with my test orangepione and could not replicate your problem. I tested with 100Mbs and 1Gbps Ethernet switches. Welcome to Armbian 24.2.1 Bookworm with Linux 6.6.16-current-sunxi root@orangepione:~# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 02:81:b1:07:76:5e brd ff:ff:ff:ff:ff:ff inet 192.168.1.24/24 brd 192.168.1.255 scope global noprefixroute end0 valid_lft forever preferred_lft forever inet6 fe80::4834:c56a:be43:e99e/64 scope link noprefixroute valid_lft forever preferred_lft forever root@orangepione:~# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc mq state DOWN group default qlen 1000 link/ether 02:81:b1:07:76:5e brd ff:ff:ff:ff:ff:ff inet 192.168.1.24/24 brd 192.168.1.255 scope global noprefixroute end0 valid_lft forever preferred_lft forever inet6 fe80::4834:c56a:be43:e99e/64 scope link noprefixroute valid_lft forever preferred_lft forever root@orangepione:~# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 link/ether 02:81:b1:07:76:5e brd ff:ff:ff:ff:ff:ff inet 192.168.1.24/24 brd 192.168.1.255 scope global noprefixroute end0 valid_lft forever preferred_lft forever inet6 fe80::4834:c56a:be43:e99e/64 scope link noprefixroute valid_lft forever preferred_lft forever From your logs it would seem that your Ethernet port is not connected. Can you verify. ### ip addr: 1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet XXX.XXX.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host noprefixroute valid_lft forever preferred_lft forever 2: end0: mtu 1500 qdisc noop state DOWN group default qlen 1000 link/ether 02:81:1f:4d:3f:5b brd ff:ff:ff:ff:ff:ff I do not understand your comment "If I disconnect it, from a normal operating switch, the OpiOne’s behavior looks the same." Is your "normal" something different than in the failure mode? What is "looks the same"? When you unplug the network can you still interact with he serial port?
  2. For a quick test I ran sbc-bench every 20 minutes overnight, about 11 hours. The system is still running well. See the attached log. sbc-bench v0.9.65 Xunlong Orange Pi.txt You might want to connect to the serial port logged in as root to see if it is available after a system hang. There may be some messages.
  3. @SteeMan Yes it is. I just found it also. After reading those posts I loaded ubuntu 23.10 with kernel 6.5 and am having success creating images. Can you add my posts to the other thread? What changed a few days ago to cause this? I had been using the official ubuntu build for months without ant changes of snags.
  4. Yesterday I started to have problems using the build environment. Any build I have tried fails with something as shown below. (https://paste.armbian.com/noloqaquqo) Today I updated vbox, reinstalled ubuntu git cloned master and tried again with the similar results (different loopx sometimes). Any help would be greatly appreciated. 🔨] The partition table has been altered. [🔨] Syncing disks. [🌿] Allocated loop device [ LOOP=/dev/loop3 ] [🔨] Error: Partition(s) 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64 on /dev/loop3 have been written, but we have been unable to inform the kernel of the change, probably because it/they are in use. As a result, the old partition(s) will remain in use. You should reboot now before making further changes. [💥] Error 1 occurred in main shell [ at /home/sysadmin/build/lib/functions/logging/runners.sh:211 run_host_command_logged_raw() --> lib/functions/logging/runners.sh:211 run_host_command_logged() --> lib/functions/logging/runners.sh:193 prepare_partitions() --> lib/functions/image/partitioning.sh:230 do_with_logging() --> lib/functions/logging/section-logging.sh:81 build_rootfs_and_image() --> lib/functions/main/rootfs-image.sh:86 full_build_packages_rootfs_and_image() --> lib/functions/main/default-build.sh:36 do_with_default_build() --> lib/functions/main/default-build.sh:42 cli_standard_build_run() --> lib/functions/cli/cli-build.sh:25 armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:136 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:176 main() --> compile.sh:50 ] [💥] Cleaning up [ please wait for cleanups to finish ] [🌿] Unmounting recursively [ SDCARD - be patient ] [🌿] Unmounting recursively [ MOUNT - be patient ] [🚸] Freeing loop [ trap_handler_cleanup_rootfs_and_image /dev/loop3 ] [🌿] Freeing loop device [ /dev/loop3 ]
  5. I have used the old /sys/class gpio interface quite extensively in the past. However it is not available in the newer kernels and my only experience with the new api has been to test the orangepizero3 with the code in the links below. It worked. https://docs.rs/gpio-cdev/latest/gpio_cdev/ https://github.com/rust-embedded/rust-gpio-cdev
  6. @Roberto I think the /sys/class type of gpio is no longer supported in the new linux releases. I have not used python to control gpio but when I tested gpio on the zero3 I discovered that the /sys/class procedures no longer worked. I then looked up some rust code and used their examples to test using the /dev/gpiochip procedures. I am sure that there must be some uptodate python code.
  7. This works on my orangepione. I think dtc comes with the standard image. Armbian-unofficial 23.11.0-trunk Bookworm with bleeding edge Linux 6.6.1-edge-sunxi sysadmin@orangepione:~$ nano screen.dts sysadmin@orangepione:~$ dtc -I dts -O dtb -o screen.dtbo screen.dts sysadmin@orangepione:~$
  8. What are you booting from? I use an SD card with the up to date image which works just fine. There is no boot partition in the image, just a boot directory. Can you try an up to date image with and SD card? The fel firmware would be part of u-boot that is on the Armbian image.
  9. @SteeMan Thanks for the update. Please excuse me for being confused. I am looking at things like an end user would to determine board status.
  10. Why am I seeing this: https://www.armbian.com/orange-pi-zero-2/ Maintainer needed?
  11. I would like to have a clear statement of how the orangepizero2 and orangepizrto3 are going to be treated going forward. Currently the orangepizero2 is a supported board, although how it got that way I can't figure out. So little of it was working until this round of development over the last few months. There is no maintainer listed at present. The only software differences between the zero3 and zero2 were taken care of upstream and are not an issue for Armbian. Other than the work to set up the orangepizero3 as a wip all the recent development work benefited the zero2 (a supported board) as much as the zero3. There was a lot of good work done that benefited a supported board. Any arguments to support or not the zero2 applies equally to the zero3. With the availability of the zero3, the zero2 is probably hardware obsolete. It is important for someone who is trying to choose a board for use to clearly understand what software support there is for the board. I probably made a mistake by assuming that because the zero2 was supported the zero3 would also be. There were volunteers willing and capable to make that happen. We were being supported by a developer. The zero3 is now much more ready to be a supported board than the zero2 ever was. If there is no possibility of this happening then the potential users of the zero3 need to be aware so that they can take that into consideration in going forward. Also there is no point for volunteers to work on the zero3 if developers are just going to ignore, or worse reject, the volunteers work. A clearer, if possible, statement would be much appreciated.
  12. Igor fixed the problem that was probably part of the "glitch" on the last release.
  13. @SteeManI would like to set up discussion on the overly topic. Should we continue here or start a new thread? I don't think we should be starting to write code until there is a reasonable agreement on how to proceed. We should also share our ideas instead of pushing them to a PR first thing. Recently @Gunjan Gupta posted this in the current PR he proposed. It has some good thoughts. We can start with this, see what can be done to make it smooth for the end user and minimize the work required by developers. I use armbian-config. I think anyone who takes part in this discussion should confess to whether they do.😊 "These are generic overlays, other examples are there in the existing patches and can be extracted from kernel source. There is no other documentation. There never was anything on any platform or OS that provides the behavior you are expecting to have. Even on raspberry pi running raspian, you can add all those hundreds of overlay in the config.txt file and other than maybe having trouble booting, no other kind of indication is given to the user. It was always left for the user to decide what overlays they want to enable, and it was always left to the user wits to determine whether overlay will have conflicts or not. I understand you want to make it as simple as possible for user to easily determine what overlays can conflict with other overlays. That part can not be implemented within overlay itself. Thats something that needs to be implemented in armbian-config. armbian-config also lacks one other thing, it doesn't tell users overlay parameters are there and what their values can be. So it is long due for the change. Here is a proposal for how this functionality can be implemented Extend armbian-config's hardware configuration to two different configurations i.e lets say one file is for SoC overlays listing all existing overlays that can be applied on that SoC, their corresponding parameters and the possible values for the same. Also mentions the overlays that can conflict with each other. Second config file will be board specific configuration file providing a list of overlays that can be used on that board. Then extend armbian-config to use that information and provide the behavior you are expecting user to get." Here are some of my current thoughts. It may be possible to provide a full list of overlays without modifying armbian-config. I am glad to see that @Gunjan Gupta has acknowledged that a board specific file could be used. There is an Armbian cli procedure that @Gunjan Gupta showed me that I think takes a dts and creates a dtbo and puts it in ArmbienEnv which will then load at boot time. I think a dts can have comment lines. If we created the dts files for the secondary overlays with suitable comments within the dts file that warned about possible conflicts, pins that the dts will use etc, and then put these files into the allwinner/overlay directory, it would give the more knowledgeable user the option to install the secondary overlay. The less savvy user could just use the primary overlays provided by armbian-config. This design would not require any work on armbian-config. The dts files for the secondary overlays would become the "generic" overlays. I am not sure how to get the secondary dts files into the allwinner/overlay directory, but hopefully this is a patch procedure. Any new dts files would require a patch anyway. I don't think it is necessary to go back and modify overlays for the existing SBC. Anyway, I am sure there are multiple solutions and this is possibly one for discussion.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines