schwar3kat's post in Recommanded ways to change the default overlays at build time was marked as the answer
In my opinion, for what it's worth , that's exactly the sort of thing customize-image.sh is intended to be used for.
It's arguably less "hackish" than many other hacks, because it is intended for the purpose.
schwar3kat's post in Building Armbian for a New Board (Radxa CM3) was marked as the answer
Using Armbian build:
If creating a patch for u-boot, the dts will go in build/cache/sources/u-boot/v2022.07/arch/arm/dts/
Or similar depending on uboot version.
If creating a patch for kernel, the dts will go in build/cache/sources/linux-mainline/6.0/arch/arm64/boot/dts/rockchip/
Or similar depending on kernel version and architecture.
Don't forget to modify the Makefile's
schwar3kat's post in Add support for NanoPi R2C was marked as the answer
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.
schwar3kat's post in AR-1172 - Load induced RX bug in the r8152 usb network driver on rockchip64 5.15, 5.16 and 5.17 was marked as the answer
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.
schwar3kat's post in GPIO depreciation sysfs on O-PI; No /sys/class/gpio/... anymore? was marked as the answer
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).
schwar3kat's post in Does anyone have any experience with armbian on Orange Pi R1 Plus LTS? I have one on order. was marked as the answer
I've since become a maintainer for this board.
I've added the new phy into the build, and it's working well for Linux-5.10y, Linux-5.15y and Linux-5.16y.
schwar3kat's post in Where / how can I edit boot environment on the SPI NOR flash on Zero Plus? was marked as the answer
Thanks martinayotte - it is working now.
I'm describing this for other newbs who might struggle to find these things.
Your referenced patch has pointed me to "arch/arm/mach-sunxi/usb_phy.c" which I found in my Vagrant build environment at "/home/vagrant/armbian/cache/sources/u-boot/<version>/"
The line "static int initial_usb_scan_delay = CONFIG_INITIAL_USB_SCAN_DELAY;" exists so it looks like the referenced patch is now a part of the build.
I found the u-boot configs under "/home/vagrant/armbian/cache/sources/u-boot/<version>/configs" and the one for my board is named "orangepizero_plus_defconfig"
sudo nano config-default.conf
modify line CREATE_PATCHES="no" to CREATE_PATCHES="yes"
^X y enter to save
Select your board then enter at the prompts until you reach:
[ warn ] Make your changes in this directory: [ /home/vagrant/armbian/cache/sources/u-boot/]
[ warn ] Press <Enter> after you are done [ waiting ]
In a new session - (I used putty, I couldn't do it from the windows command prompt vagrant ssh )
sudo nano orangepizero_plus_defconfig
add a line CONFIG_INITIAL_USB_SCAN_DELAY=3000
^X y enter to save
Back to the original session press enter and answer all prompts until compile is complete.
diff --git a/configs/orangepizero_plus_defconfig b/configs/orangepizero_plus_defconfig index 4298f1e..ef14bcb 100644 --- a/configs/orangepizero_plus_defconfig +++ b/configs/orangepizero_plus_defconfig @@ -20,3 +20,4 @@ CONFIG_SUN8I_EMAC=y CONFIG_USB_EHCI_HCD=y CONFIG_MMC_SUNXI_SLOT_EXTRA=2 CONFIG_SD_BOOT=y +CONFIG_INITIAL_USB_SCAN_DELAY=3000 The patch will be in \vagrant\output\patch\u-boot-sunxi64-next.patch
Don't be tempted to edit this file in windows. It will be corrupted by the line feeds.