schwar3kat

Orangepi zero plus Images boot, network connection functions (iperf3). USB ports function. Orangepi R1 Images boot, both ethernet ports and wifi function as expected (iperf3).

PR submitted. https://github.com/armbian/build/pull/5231

Orangepi R1 Plus LTS (RK3328) - networking issue AR-1747. Caused by one of the network interface logical names changing from eth0 to end0. I can can submit a PR to fix this with a rename in /etc/udev/rules.d/70-rename-lan.rules which is already created from a hook in the board config file (to rename the other network interface). Already tested and works as expected on current and edge, Ubuntu and Debian. Before I take this route, I'm just wondering if anyone knows a reason for this happening that could possibly lead to a better fix? I didn't find anything obvious in the PR's.

- Orange Pi PC - Pine64 Images boot (xfce_desktop), network connection functions (iperf3). USB ports function, HDMI video and audio work.

I couldn't reproduce the problem, after deleting `cache/tools/oras`, even with CLEAN_LEVEL=debs ARTIFACT_IGNORE_CACHE=yes. I deleted the whole cache and was able to reproduce it. EDIT: deleting cache/tools/oras. does reproduce the error. Not sure why I didn't get the same result earlier. https://github.com/armbian/build/issues/4889

Thanks @schwar3kat ! This has been elusive, but its clear that when the tooling is 1st downloaded, the parsing fails. 2nd run the tooling is already there so doesn't fail. Will try to address! Do you want me to log a GitHub issue for this?

https://github.com/armbian/build/issues/4879

Hold off investigating for now. This might be my fault. I usually set global git username and user email. I think that I may only have set them locally on the master branch folder. I will retest when I get a chance. Edit: Tested. Damn, I messed up. Of course it can't do mbox without email address. Apologies for wasting your time.

@rpardini Next/main. Creating patches. When I create a patch with armbian/build master (deprecated) using CREATE_PATCHES=yes, I get a patch in the output/patch folder in mbox format. When I create a patch with armbian/build main using CREATE_PATCHES=yes ARTIFACT_IGNORE_CACHE=yes, I only get a diff file in the output/patch folder. Is this intentional, a bug, or have I perhaps not set something up? Can I get a mbox patch?

@rpardini My apologies for not testing much on next/main the last two weeks. (13+ hour workdays with two hour commute is a bit rough). New main branch. Error on first run. The build works on second run. Running on Linux Mint Vera (Jammy) without docker: $ git clone --depth 1 https://github.com/armbian/build Cloning into 'build'... remote: Enumerating objects: 8900, done. remote: Counting objects: 100% (8900/8900), done. remote: Compressing objects: 100% (5308/5308), done. remote: Total 8900 (delta 3651), reused 7386 (delta 3146), pack-reused 0 Receiving objects: 100% (8900/8900), 83.75 MiB | 5.65 MiB/s, done. Resolving deltas: 100% (3651/3651), done. Updating files: 100% (12015/12015), done. $ cd build $ ./compile.sh BOARD=orangepi-r1plus-lts BRANCH=current RELEASE=bullseye BUILD_MINIMAL=no BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no CREATE_PATCHES=no COMPRESS_OUTPUTIMAGE=img ...... [\U0001f331] Getting ORAS manifest [ ORAS manifest from ghcr.io/armbian/cache-uboot/uboot-orangepi-r1plus-lts-current:2022.07-Se092-Pbb0c-B680b ] [\U0001f331] Downloading required [ ORAS tooling ] parse error: Invalid numeric literal at line 1, column 11 [\U0001f4a5] Error 4 occurred in SUBSHELL [ SUBSHELL at /mnt/data/build-armbian/armbian-main/build/lib/functions/general/oci-oras.sh:141 ] [\U0001f4a5] Error 4 occurred in main shell [ at /mnt/data/build-armbian/armbian-main/build/lib/functions/general/oci-oras.sh:141 oras_get_artifact_manifest() --> lib/functions/general/oci-oras.sh:141 is_artifact_available_in_remote_cache() --> lib/functions/artifacts/artifacts-obtain.sh:279 artifact_uboot_is_available_in_remote_cache() --> lib/functions/artifacts/artifact-uboot.sh:107 artifact_is_available_in_remote_cache() --> lib/functions/artifacts/artifacts-obtain.sh:24 do_with_logging() --> lib/functions/logging/section-logging.sh:72 obtain_complete_artifact() --> lib/functions/artifacts/artifacts-obtain.sh:169 build_artifact_for_image() --> lib/functions/artifacts/artifacts-obtain.sh:209 main_default_build_packages() --> lib/functions/main/build-packages.sh:49 full_build_packages_rootfs_and_image() --> lib/functions/main/default-build.sh:4 do_with_default_build() --> lib/functions/main/default-build.sh:17 cli_standard_build_run() --> lib/functions/cli/cli-build.sh:17 armbian_cli_run_command() --> lib/functions/cli/utils-cli.sh:126 cli_entrypoint() --> lib/functions/cli/entrypoint.sh:164 main() --> compile.sh:52 ] [\U0001f4a5] Cleaning up [ please wait for cleanups to finish ] Sorry vnc copy messed up the icons. Logs attached. log-build-fad6555a-d76c-4966-b374-91b1812b012a.log log-build-fad6555a-d76c-4966-b374-91b1812b012a.log.ans summary-build-fad6555a-d76c-4966-b374-91b1812b012a.md

Which manual are you using. My manual doesn't have anything about GPIOs on pg130. (orangepi_r1_plus_lts_rk3328_user manual_v1.4) Only ports A and D are exposed according to the manual image. Correction: GPIO C0 is exposed on pin 10, I just didn't spot it. Example: Pin 13 -- gpioNumber: 2, port: 'A', portNumber: 2

Hi gangclar, I assume that you mean OrangePi R1 Plus LTS ? (not LTS plus). This board is usually used as a router or firewall, so I don't think that the community has done much with GPIO. I don't use GPIO, and know very little about it. Page 5 of the user manual gives you the GPIO pin mapping on the board image. There are other things to take into account. Device tree mappings will almost certainly not exist, because only devices included by default are included in the default device tree. You will probably need to develop a specific device tree overlay for your application place it in the overlay directory, and select it in armbian-config or in the armbianEnv.txt boot file. https://docs.armbian.com/User-Guide_Allwinner_overlays/ (This is for allwinner. Rockchip is similar). Kat

Orangepizeroplus tested success: Armbian_23.02.1_Orangepizeroplus_bullseye_current_5.15.93.img.xz Armbian_23.02.1_Orangepizeroplus_bullseye_current_5.15.93_minimal.img.xz Armbian_23.02.1_Orangepizeroplus_jammy_current_5.15.93.img.xz All images tested and working as expected. Iperf performance is as expected in both directions on ethernet and wifi ports simultaneously. 2 images listed on RC testing form (minimal build left off).

Orangepi-r1 tested success: Armbian_23.02.1_Orangepi-r1_bullseye_current_5.15.93.img.xz Armbian_23.02.1_Orangepi-r1_bullseye_current_5.15.93_minimal.img.xz Armbian_23.02.1_Orangepi-r1_jammy_current_5.15.93.img.xz All images tested and working as expected. Iperf performance is as expected in both directions on both ethernet ports simultaneously. Wifi works. 2 images listed on RC testing form (minimal build left off).

Orangepi-r1plus-lts tested success: Armbian_23.02.1_Orangepi-r1plus-lts_bullseye_current_5.15.93.img.xz Armbian_23.02.1_Orangepi-r1plus-lts_bullseye_current_5.15.93_minimal.img.xz Armbian_23.02.1_Orangepi-r1plus-lts_jammy_current_5.15.93.img.xz All images tested and working as expected. Iperf performance is as expected in both directions on both ports simultaneously. 2 images listed on RC testing form (minimal build left off).

Suggestion: allow more than two images per board in the RC testing form.

SD cards tend to get corrupted if they lose power in the middle of a write. It's is unlikely to be build related.

I was just looking into trying to set this up manually a couple of days ago, but life got in the way and I didn't take it very far. Just a fun idea to try out and maybe get a little more speed when stuff isn't cached.

Excellent... just making sure that the issue is on your radar. I noticed a distcc.sh in the compilation folder. I'm guessing/hoping that this will mean easy distributed compilation.

It's unlikely that anyone here will be able to help you with knowledge about a third party image. Your best option would be to ask on the forum of the maintainer of that image.

I don't know the answer, but I suspect that there could be issues with built in drivers. The software might just be too complex for box86. Is an Arm version available? Have you set up the udev rules as per Intel instructions? There could also be dependency issues. You don't mention your board or the Armbian image, but have you had this running on the equivalent Debian/Ubuntu version on an x86_64 machine, and what did you have to do to make it work. Debian complexities: http://fpgacpu.ca/fpga/debian.html Ubuntu complexities: https://www.alteraforum.com/forum/showthread.php?t=22481

@rpardini I'm not sure how far you have progressed cached stuff on next. Hook function changes? A change inside a hook function in the board config file is not causing the bsp change to be detected. The hook is post_family_tweaks_bsp. Example: orangepi-r1plus-lts.conf. I just changed some of the values in the two files that are written into the build and the changes don't make it into the build. The bsp cache is used.

I intend to do a PR to include these device tree overlays, fix the lan0 LEDS, and include a status heartbeat in a future release.