schwar3kat
-
Posts
241 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by schwar3kat
-
-
1 minute ago, balbes150 said:
at the beginning I manually switch the branch (git checkout branch)
Yes that is what I did.
-
7 hours ago, Igor said:
I tried a build from a clone of that branch using LIB_TAG="v22.05"
I think that it did switch, but I can't guarantee it.
Previously when I tried unsuccessfully to build this branch, balbes150 showed me to use LIB_TAG="v22.05" to prevent it from switching.
targets.conf has your rock-3a changes, so I think it worked. -
3 hours ago, Igor said:
Check if you see anything suspicious here:
I don't see anything suspicious. They all look safe.
I've opened Jira AR-1204
I tried a build from a clone of that branch using LIB_TAG="v22.05" and focal image worked.
No obvious differences between the working and not working images.
I wonder if this issue is similar to the first CI run that affected all three images with the same symptoms. -
4 minutes ago, Igor said:
And RC images were alright, right?
Initial RC images were all bad with the same issue USB3 Ethernet not working. As if the quirk patch was missing.
Final RC images were all good. -
orangepi-r1plus-lts - problems with the published downloads.
Tested:
Armbian_22.05.1_Orangepi-r1plus-lts_focal_current_5.15.35.img.xz - bad image. USB3 Ethernet not working, torrent and direct.
Armbian_22.05.1_Orangepi-r1plus-lts_jammy_edge_5.17.5.img.xz - no image available, torrent or direct.
Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35.img.xz - working, no observed issues (torrent tested).
-
3 hours ago, Igor said:
Today's RC build
Issues now resolved
orangepi-r1plus-lts - no issues observed.
Tested:
Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35.img.xz
Armbian_22.05.1_Orangepi-r1plus-lts_focal_current_5.15.35.img.xz
Armbian_22.05.1_Orangepi-r1plus-lts_jammy_edge_5.17.5.img.xz
iperf on both Ethernet interfaces produced expected results. -
24 minutes ago, Igor said:
CI ads some troubles
All three of the orangepi-r1plus-lts images in the RC folder are bad, they have the USB3 Ethernet receive bug.
When I build the v22.05 branch locally, the images work correctly
Affected images are:
Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35.img.xz
Armbian_22.05.1_Orangepi-r1plus-lts_focal_current_5.15.35.img.xz
Armbian_22.05.1_Orangepi-r1plus-lts_jammy_edge_5.17.5.img.xz
If I understand you correctly, then this is probably a CI issue.
Is there anything that I can I do to help resolve this. -
19 hours ago, schwar3kat said:
RK3328 Orangepi r1plus lts seems to have reverted to broken LAN0 Ethernet behavior
Can someone please advise me.
I tried to clone the RC branch to try and diagnose the issue. I'm not sure if this is correct:
git clone -b v22.05 --single-branch https://github.com/armbian/build
It cloned, but the image that I built worked, unlike the one I downloaded, so I suspect that this clone might not be correct. -
orangepizeroplus - no issues observed.
Tested:Armbian_22.05.1_Orangepizeroplus_bullseye_current_5.15.35
Armbian_22.05.1_Orangepizeroplus_focal_current_5.15.35
Armbian_22.05.1_Orangepizeroplus_jammy_edge_5.17.5
iperf on wifi and Ethernet interfaces produced expected results.
-
orangepi-r1 - no issues observed.
Tested:
Armbian_22.05.1_Orangepi-r1plus-lts_bullseye_current_5.15.35
Armbian_22.05.1_Orangepi-r1_focal_current_5.15.35
Armbian_22.05.1_Orangepi-r1_jammy_edge_5.17.5
iperf on wifi and both Ethernet interfaces produced expected results. -
RK3328 Orangepi r1plus lts seems to have reverted to broken LAN0 Ethernet behavior similar to before the commit
Enable rockchip64: XHCI HCD USB TRB ENT quirk for RK3328 #3763
I can't immediately see what the cause is. The patch works and quirk is included in the dtb.
Same as before, it can be mitigated by disabling tx offload.
I've reset AR1172 to in progress,
-
@thelinuxguy I've sent you a personal message, in your forum profile mailbox.
-
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. -
5 hours ago, thelinuxguy said:
Tried a few things
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 inprogressmerged 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 -
On 5/4/2022 at 1:24 AM, jethome said:
Is it fixed in 5.17?
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
Thereiswas 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. -
14 hours ago, rpardini said:
Yes. `PRESERVE_WORKDIR=yes` won't cleanup the workdir in .tmp
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 CommunicationCreate a new thread in the Armbian Build Framework Subforum
The forum is apparently deprecated and read only. -
On 4/20/2022 at 5:44 AM, Igor said:
Release Planning Meeting Date: 2022-04-23 14:00 UTC+1
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
Armbian 22.05 (Jade) Release Thread
in Armbian Project Administration
Posted
Orangepi Zero Plus - published images work.
Armbian_22.05.1_Orangepizeroplus_bullseye_current_5.15.43.img.xz
Armbian_22.05.1_Orangepizeroplus_focal_current_5.15.43.img.xz
Armbian_22.05.1_Orangepizeroplus_jammy_edge_5.17.11.img.xz