schwar3kat

The patch is enabled. It was put there by the developer who configured the build. It is enabled by being in the directory. build/patch/kernel/rockchip64-current (If you are building current) Your board is in the rockchip64 family. There are three active kernels legacy (currently 5.10y), current (5.15y) and edge (5.17y) The drivers are slightly different between 5.10 and 5.15/5.17 so it may be worth trying the legacy build. I suspect that the build worked on an earlier kernel version and that it has has not been maintained on newer kernels.

That's a patch, not an actual dts. That patch modifies a Make file and creates a dts file. The patch is part of a much larger build. You can see an extra line being added into the Make file, (used to compile the new dts along with other dts's). This is similar to the way Armbian build would do it, with one of the build scripts actually doing the compiling of all of the dtb's. A possible way to do this would be to set up Armbian build and add the patch into build/patch/kernel/rockchip64-current. You would need to manually modify the make part to match the Make file in /build/cache/sources/linux-mainline/linux-5.15.y/arch/arm64/boot/dts/rockchip. Or a better way would be to use the CREATE_PATCHES=yes build option which would stop the build and allow you to modify the Make file then create a patch for you (second stop for kernel). You could then use that patch to modify your original patch and build orangepi-R1plus-lts and the dtb will be compiled and end up with the others. But you may not need to do any of that. While looking up the patch path for this reply, I noticed a patch in Armbian Build called add-board-nanopi-r2c.patch. So I used the build menu (which I seldom do) and there is actually a build option for nanopi-r2c (it's not on the download list, implying that it's unsupported, and it's probably in the wrong menu (someone probably missed it when the menu's were split) and who knows if it has survived uBoot and kernel upgrades. I see no archived builds, also implying that it's unsupported. I've requested clarification of it's status, so it's likely to move to community support in the other (CSC/WIP/EOS/TVB) menu. Unsupported boards are " build your own" only. I suggest that you set up Armbian build and try to build it. You can use my instructions a few replies above either on an Ubuntu based PC or virtual machine. Edit: I built it. One time only, it ties up my pc for an hour. Let me know if it works. https://drive.google.com/file/d/1nSug6EYF6O6CALLCaZA1PqRZE5VUBI2n/view?usp=sharing

Three quarters of the way there At least you now have something to start with. If I was you, I would try the rk3328-nanopi-r2-rev06.dtb device tree that is included in the current build (and/or any other promising looking dtb's). Easiest way is to open /boot/dtb/rockchip and rename rk3328-orangepi-r1-plus-lts.dtb to rk3328-orangepi-r1-plus-lts.dtb.bak and rename rk3328-nanopi-r2-rev06.dtb to rk3328-orangepi-r1-plus-lts.dtb. Or you can modify armbianEnv.txt but I can't remember off hand if there is another step to make this work which is why I mentioned the renaming method. If this works, you can look into using Armbian build to customize a build for your board (and maybe contributing as a community build or supporting it). This is quite simple because it's all config with no kernal patching. If this doesn't work, most likely, either the device tree is wrong or there are changes required to the kernel networking code to enumerate/identify/initialize the NIC. (The NIC drivers are already in Armbian and should in theory work). If you can find a build with source for your device on some other Linux (preferably on the same kernel version) with dts (source code for a dtb) or even a dtb and a set of kernel patches, then you can ignore the NIC patch(es) and see if you can modify the other bits to work with code in the current kernels in Armbian build. It can take an enormous amount of effort to research this sort of thing, so it's unlikely that anyone here would be willing to attempt it for you.

Or if you run a recent version of Ubuntu or a derivative like Mint then you can use the Armbian build system. It's pretty easy. (Officially supported version is currently Ubuntu Jammy, but others are unofficially allowed (without support), and for others not on the allowed list, the OS check can be bypassed). Log in as root (sudo su) and run: $ mkdir /build-armbian (wherever you want and named whatever you want) $ cd /build-armbian $ apt-get -y -qq install git $ git clone --depth 1 https://github.com/armbian/build $ cd build Run the script $ ./compile.sh Follow the menu's (build time is slower the first time because it downloads, compiles, and builds caches, (and cpu power makes a big difference) https://docs.armbian.com/Developer-Guide_Build-Preparation/ You can develop your own patches etc.

@thelinuxguy Yes, that's the one. It looks pretty close hardware wise. Nightly builds can be activated once you have a build in place and are internet linked. Use the YT8521S NIC, it's the one not impacted by the bug (if it works). armbian-config, then from the menu, System then Nightly. The new version of Armbian due out later this month will have the fix.

@thelinuxguy Your issue with R2S is probably an incompatible device tree in uboot and kernal. The drivers for both NIC's are in the build, but r8153B has a bug that is being fixed. You could try with the Orangepi R1plus LTS image which appears to be similar. If the rest of the device tree is similar, there is a chance that it will work. The drivers for the NIC's are the same although the chips are different YT8521S vs YT8523B There is a bug in the latest image that affects the r8153B driver. There is a PR in progress merged to fix this that should become available in the nightly builds in the next few days. If you try it, please let us know the results. Regards Kat

Probably not. Edit: See original post. The bug in 5.15, 5.16 and 5.17 can be fixed by activating a xhci trb quirk in rockchip64-current. In 5.17 it is almost identical with the version in 5.16 except for some ethtool_ringparam structures and some other trivial changes. I tried back porting it to 5.16, but would have to remove the incompatible ethtool_ringparam structures to get it to work, which would leave essentially the same driver as is now in 5.16, so I dropped the idea. Armbian rockchip64 edge is still on 5.16 (and I haven't tried to build with 5.17), but when it changes, we will probably have to deal with the same issue, unless the incompatible changes fix it which looks highly unlikely. And 5.18RC is identical to 5.17.

@Contributor/Maintainer AR-1172 - fix complete 08 May 2022 There is was a bug in the 5.15, 5.16 and 5.17 kernel r8152 driver that affected RTL8153b Gigabit USB Ethernet (LAN0) on the Orange Pi R1plus LTS and other boards. The bug only presents on high load and I can trigger it reliably with bidirectional high load on Orange Pi R1plus LTS. The bug kills the RX interface and it requires power down to reset. I assume that it also affects the Orange Pi R1plus, and there are reports of it affecting NanoPi R2S. I would assume that other boards could be impacted. My proposed fix is to revert the driver back to the version used in 5.10 kernel (and to disable TX offload by default). This driver works reasonably well if TX offload is disabled (but with TX offload enabled, another bug is triggered on load). The reason for this post is to alert other board maintainers and to inquire if you are okay with this proposal. The driver from kernel-5.10 (v2.15.0 (2021/04/15)) can be used with 5.15 and 5.16 with minor tweaks. Edit: While researching options for disabling TX ofload, I found a thread on the forums for Helios that talked about xhci trb quirk in rockchip64-current. I followed it to this commit, https://github.com/armbian/build/commit/8eece74eb581367625e6ebcc12ee5c6f4f44617c The quirk is currently funcional for dwc3 xhci usb on rockchip64 and activated for rk3399. It appears that the quirk may not have been applied to rk3328 in the past, so I tried including it in rk3328.dtsi, and it worked very well with the mainline driver on 5.15, 5.16 and 5.17. This means that it is not necessary to revert the driver to the one in 5.10. I have modified AR-1172 and submitted a PR. PR has been merged and fix will be in the new release.

Thanks for the response @rpardini I tried this, it seems to preserve the build artifacts, but not the logs, which seem to be created in .tmp/logs-......./ The text logs, split up into manageable chunks, are what I'm after. I tried 'PRESERVE_LOGDIR=yes' just in case there was such a thing but no such luck. On a new git clone: Orangepi-r1 built to completion after your change, but I noticed another minor issue: Repeat Build Options left out 'BOARD=orangepi-r1' [✨] Repeat Build Options [ ./compile.sh BRANCH=current RELEASE=jammy BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=img ]

I'm building from the armbian-next branch for testing and I'm finding the experience quite unfamiliar and a little annoying. It does seem faster though. Orangepizeroplus (H5) built successfully for current, jammy and the image produced worked. I suspect that other flavors will build okay for testing. but it errored after building the image [] Error occurred [ code 23 at /root/build-armbian/rc/build/lib/functions/logging/runners.sh:134 Orangepi-r1plus-lts (rockchip64 RK3328) built successfully for current, jammy. No build errors. Orangepi-r1 (H2) build system failed near the end. 019.000.create_board_package.log --> 🛠1272: 1319406 - 1319406 - 1319406: ehBE: debug: Running family_tweaks_bsp [ sunxi ] --> 🧽 1272: 1319406 - 1319406 - 1319406: ehBE: trap: main_trap_handler [ ERR and 1 trap_manager_error_handled: ] The annoying 6.8 MiB html log file is a pain to parse. I guess that the build system enhancement issues will be picked up and dealt with separately and should probably not have bugs logged by SBC testers, or should I be logging bugs? Can I switch off the time wasting and annoying markdown / html logging behaviour? I don't want caterpillars, butterflies ants, bunches of leaves and comic explosions that don't make anything clearer and are unnecessary annoyances that don't play nicely with my tools. LOG_ENABLE_EXTENSION=no, didn't do it. Is it possible to keep the split .tmp files on error / build fail?

https://docs.armbian.com/Process_Release-Model/ Probably needs updating... 1. Forum Communication Create a new thread in the Armbian Build Framework Subforum The forum is apparently deprecated and read only.

Please accept my apologies. I'm not available at the meeting time. I will review the IRC logs. I'm maintaining 3 boards: Orange Pi Zero H5 Orange Pi R1 H2 Orange Pi R1 Plus LTS RK3328 There are currently no open bugs or incomplete tasks that I am aware of in Jira for these boards. I'm happy to help out in any way that I can, although it's not yet clear to me how or at what stage I should get involved in testing. K

I just reread your post. Orange pi zero plus only has 512MB ram. On some of the later builds I've found that running a desktop with xrdp is a bit of a tall order, and I have found that I have needed to create a swap file on the SD card to run desktop components successfully. Without the extra swap, I would think that a desktop and Firefox might be too much. Kat

Hi Darsie, On the Orange pi zero plus the terminal is connected to the three pins next to the ethernet port. You will need a USB to serial TTL adapter if you don't already have one. There are dozens of different kinds. If you are on Windows, you will need to download Putty or another terminal program. The OrangePi zero plus_H5 User Manual_v0.9.1 has info on pg 51. Clear as mud.. haha. We have a tutorial for building a NTP server with the OPiZero. http://schwartzel.eu3.org/ntp-stratum1.html Not the same board, but the instructions for the USB to serial TTL adapter and using Putty to debug are included. The pins for the terminal are the same. Note point 7 and 11 under components, and under headings: "Connect the USB to serial TTL adapter to the Orange Pi Zero" "Fire up Putty and connect to the serial port of the USB to serial TTL adapter" If you are not geared up for this kind of stuff, then you will struggle to debug your install and may need to start from scratch and burn a new image. A likely cause for your issue is corruption caused by not powering down correctly. You could try and fsck your SD card on a linux PC. Hope that helps Kat

I'm not able to replicate this. If your SD-card is corrupted, this is a possible symptom. What do you get on the debug terminal? Usually this will tell you where the u-boot/boot process is failing.

@going do you have any ideas? Just a thought. How do you define what type of interrupt is used. (rising edge, falling edge, high or low)? Is this a device tree thing? Regards Kat

Re: /etc/udev/rules.d/99-gpio-group.rules and gpio group. That idea seems sound, but it wouldn't be confined to a file and the security group for one SBC type or family and it would need someone to support it and document it. I think that it would need to be supported by someone closer to gpio user space who is able to understand most of the possible supportable permutations and is closer to supporting and testing across all Armbian devices and families , possibly in the armbian-config space. These are not areas that I am familiar with, and those developers that do work in this area are quite possibly overloaded with higher priorities. My suggestion would be to craft a post in the feature requests forum, briefly describing the issue and how this was resolved for your user case, and suggest adding it as a feature or configurable feature, for Armbian build. You could offer to get involved in the design/test process (or even get involved in development). Then see if it generates any interest.

I've not looked at permissions for gpoid. The file would probably need to be tweaked to cover the device structure.

It should be in the next release cycle, which if I'm not mistaken could be scheduled sometime in May (I don't see a confirmed date in the documentation yet).

Hi Hans, The pull request has been merged. The changes should be available in the nightly builds now. You can switch to nightly builds using armbian-config system settings. If you get a chance please test and report back.

Happy that it works. 😀

Hans, you are missing a / in front of bin.

Update: For others with non-root gpio sysfs ACL issues with this SBC, Hans has now confirmed that the method below works. For ACL's You probably already know this, but if not then you could try this: If you try it then let us know if it works for your purposes. PS I don't know if gpio10 is a pin, I just used it to check ACL's As root (sudo su) create a gpio group: $ groupadd gpio add your user (replace "youruser" with your username): $ usermod -a -G gpio youruser create a file /etc/udev/rules.d/99-gpio-group.rules containing: SUBSYSTEM=="gpio*", PROGRAM="/bin/sh -c 'chown -R root:gpio /sys/class/gpio && chmod -R 770 /sys/class/gpio; chown -R root:gpio /sys/devices/virtual/gpio && chmod -R 770 /sys/devices/virtual/gpio; chown -R root:gpio /sys/devices/platform/soc && chmod -R 770 /sys/devices/platform/soc'" $ reboot Log in as youruser $ cd /sys/class/gpio $ echo 10 > export $ ls -l total 0 -rwxrwx--- 1 root gpio 4096 Apr 5 09:24 export lrwxrwxrwx 1 root gpio 0 Apr 5 09:24 gpio10 -> ../../devices/platform/soc/1c20800.pinctrl/gpiochip1/gpio/gpio10 lrwxrwxrwx 1 root gpio 0 Apr 5 09:23 gpiochip0 -> ../../devices/platform/soc/1c20800.pinctrl/gpio/gpiochip0 lrwxrwxrwx 1 root gpio 0 Apr 5 09:23 gpiochip352 -> ../../devices/platform/soc/1f02c00.pinctrl/gpio/gpiochip352 -rwxrwx--- 1 root gpio 4096 Apr 5 09:23 unexport $ echo out >/sys/class/gpio/gpio10/direction $ ls -Ll /sys/class/gpio/gpio10/ total 0 -rwxrwx--- 1 root gpio 4096 Apr 5 09:24 active_low drwxrwx--- 4 root gpio 0 Apr 5 09:24 device -rwxrwx--- 1 root gpio 4096 Apr 5 09:25 direction -rwxrwx--- 1 root gpio 4096 Apr 5 09:24 edge drwxrwx--- 2 root gpio 0 Apr 5 09:24 power drwxrwx--- 2 root gpio 0 Apr 5 09:24 subsystem -rwxrwx--- 1 root gpio 4096 Apr 5 09:24 uevent -rwxrwx--- 1 root gpio 4096 Apr 5 09:24 value

. Hi Hans, That quote is what the upstream linux mainline kernel developers put in the comments where they disabled gpio sysfs for sunxi. Armbian has no input into the upstream kernel build. I have found how they disabled the gpio sysfs stuff and am in the process of crafting a pull request to restore it to Armbian build When it is restored, I will ask you to please test. Regards Kat

Thanks MichaIng, that's what I thought too. Seems the linux kernel people are trying purposely to make it difficult. I eventually found it I compared the compile artifacts from legacy and current /drivers/gpio (before the build cleaned them) and found that .gpiolib-legacy.o.cmd and .gpiolib-sysfs.o.cmd were missing. They were not compiling. This was in spite of kernel config containing CONFIG_GPIO_SYSFS=y and Makefile containing obj-$(CONFIG_GPIOLIB) += gpiolib-legacy.o and obj-$(CONFIG_GPIO_SYSFS) += gpiolib-sysfs.o I then compared Kconfig, hoping to find a hint in the comments. There was a hint in the comments "select GPIO_CDEV # We need to encourage the new ABI" but also... bool "/sys/class/gpio/... (sysfs interface)" if EXPERT (this I did not expect). I patched Kconfig to remove the if EXPERT, built it and it worked. I tested the GPIO and was able to toggle a pin. I will prep a PR for current and edge. Kat