schwar3kat

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.

Debos is a third party build system, and your best source of support would be Debos maintainers and forums. Armbian v5.75 on which your instructions are based is very obsolete, Armbian current is now on v22.11 and a huge amount has changed. If a downloaded Armbian image doesn't suit your purpose, you might be better off building an Armbian minimal image with a modern kernel using the Armbian build system. Documentation is linked in the previous reply. Brief steps below (follow the guide for the longer more complete version). If you are building on a supported Linux Ubuntu (>=focal) on a PC or virtual machine, it's quite simple. Docker and Vagrant methods are also available see the documentation. apt-get -y -qq install git Make a build directory (anywhere suitable) cd into that directory git clone --depth 1 https://github.com/armbian/build cd build ./compile.sh And follow the menu's Or for a minimal version for your board without having to select via menu's: ./compile.sh BOARD=orangepipc BRANCH=current RELEASE=bullseye BUILD_MINIMAL=yes BUILD_DESKTOP=no KERNEL_ONLY=no KERNEL_CONFIGURE=no COMPRESS_OUTPUTIMAGE=img

It looks like you did not add the two files that I attached to the post? You can do this from windows with a sftp program like winscp.

After the above step, your /boot/armbianEnv.txt file should contain: verbosity=1 bootlogo=false overlay_prefix=rockchip fdtfile=rockchip/rk3328-orangepi-r1-plus-lts.dtb rootdev=UUID=0145e6bc-50e4-4004-9ea0-b36906ca051c rootfstype=ext4 console=serial extraargs="ipv6.disable=1" overlays=i2c0 uart1 usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u You can edit this file manually if you find it quicker than armbian-config. Note: If you are on an IPv4 network it's good to use: extraargs="ipv6.disable=1" This will prevent very erratic networking behavior caused buy some routers.

These are disabled by default. These are multi-function PIO pins and need to be configured for your use case using armbian-config. But I also see that there should probably be .dtbo overlays for UART1 and I2C0 which are missing from the build. Would you be able to test them for me? I don't really have anything set up to connect to test these with. Place the attached two .dtbo files in /boot/dtb-5.15.80-rockchip64/rockchip/overlay In a terminal: armbian-config Select "System and security settings" click "OK" Select "Toggle hardware configuration: UART, I2C, etc." click "OK" Activate I2C0 and UART1 (arrow keys to scroll up/down, click or space bar to select/unselect) and save. Reboot and test. Type command: ls /dev/i2c* This should return: /dev/i2c-0 /dev/i2c-1 rockchip-i2c0.dtbo rockchip-uart1.dtbo

I'm happy that you got it going SSH for the first configuration works as shown in the output from my test with Armbian_22.11.1_Orangepi-r1plus-lts_bullseye_current_5.15.80.img.xz Please let me know which image are you using? If there is an issue that I don't know about, I would like to find it and correct it. Perhaps you didn't wait long enough. It feels like forever 🙂 You need to wait for about a minute until after some network adapter lights begin to flash before checking router/dhcp for the IP address?

There may be community members working in this area on Armbian, but Linux userspace is not supported by Armbian in any way (we simply don't have any funding or resources to do this for all different boards). Armbian does provide a simple framework for community development and the Armbian build framework is very suitable for this kind of project. If you get stuck ask for pointers on the forums or IRC/Discord https://docs.armbian.com/Community_IRC/. Search the forums. Ask a specific question on the forums about what you are attempting to do and see if you get a response. You will likely find other users who are doing similar on RK3328 SoC and other SoCs. I don't know anything about Node-RED. I do know that the PIO is likely different and that you will need to research this and possibly change the code or scripts to suit. You will probably need to enable serial1 and I2C as they are likely not enabled. armbian-config and/or dts overlays might be required. Some details are in the Armbian documentation. https://docs.armbian.com PS. My board is v1.2. I don't see any obvious differences.

I have PL2303 variants that connect at 1500000 baud to my board from a Linux laptop. I have both PL2303TA and PL2303HX (from Aliexpress) and at least one of them (probably both) works with the board, because I have debugged at 1500000 baud many times before and using which ever one was at hand at the time. My PL2303HX is a Chinese clone that I'm led to believe doesn't play well with Windows drivers (needs an old driver version, I believe). I suspect that perhaps PL2303 combined with Windows or Windows drivers might have issues with very high speed but I may be wrong. This article from Raxda for a similar board with the same soc says that some PL2303 have limitations and that they use FT232RL. I don't know if this is true, or based on hearsay. https://wiki.radxa.com/RockpiS/dev/serial-console Debugging summary: You are able to boot other OS images therefore your board works. You have flashed other OS images on the same SD card and booted successfully therefore the SD card is okay. Your power supplies have worked with other OS's therfore it is unlikely to be a power supply issue. Armbian image Armbian_22.11.1_Orangepi-r1plus-lts_bullseye_current_5.15.80.img.xz boots correctly on my board therefore Armbian image is okay. This leaves only two likely posibilities that I can think of: 1. Your hardware is a different version that doesn't work with the Armbian image that works on my board version. 2. The image on your SD card is borked for some reason. It's not clear that you have used the same Armbian image? Are you absolutely sure that you are using the correct image? Your SD card flashing method sounds okay but... It's not clear whether you have successfully flashed the image onto the SD card? If you have a Linux system then you can mount the SD and view the file system. I don't know how easy this would be with Windows. Maybe with WSL or third party drivers.

1 500 000 baud is correct for this board. You should not need a level shifter. TTL serial is open drain, and can usually handle both 5v and 3.3v You only connect the tx to rx, rx to tx and gnd to gnd (if the USB to TTL has a power connector do not connect it.) The symptoms seem like a corrupt or missing boot loader (or a bad board). How did you flash the SD card and which image did you use? Did your software decompress the xz file before or while flashing? I have seen similar symptoms when I accidentally flashed a orangepi-r1 image for orangepi-r1plus-lts. It's past midnight here so I'm signing off for now. Kat

I'm at home now and I've successfully tested one of the Armbian Orangepi-r1plus-lts images. I downloaded Armbian_22.11.1_Orangepi-r1plus-lts_bullseye_current_5.15.80.img.xz I'm on Linux so I flashed to SD card using "Disk Image Writer" which decompresses xz while flashing. (If you are on Windows then use balenaEtcher which I believe supports xz decompression or similar). I inserted the SD card into the card slot. I plugged 2 ethernet cables from my switch into the board (it also works with just one ). I plugged in the power (5V 3A) Waited about a minute for the nic leds to start flashing. I looked up the two IP's on my Router DHCP. It had allocated 192.168.0.136 and 192.168.0.138 to orangepi-r1plus-lts I used one to connect as follows: ssh root@192.168.0.138 The authenticity of host '192.168.0.138 (192.168.0.138)' can't be established. ECDSA key fingerprint is SHA256:NEPlUgOF+2eXyioYWW36wZJVpKbF93HBUL6GvvOPnh0. Are you sure you want to continue connecting (yes/no/[fingerprint])? I typed: yes [enter]. root@192.168.0.138's password: I typed: 1234 [enter] Welcome to ARMBIAN! Documentation: https://docs.armbian.com | Community: https://forum.armbian.com IP address: 192.168.0.136 192.168.0.138 Create root password: ********** Repeat root password: ********** Choose default system command shell: 1) bash 2) zsh Shell: BASH Creating a new user account. Press <Ctrl-C> to abort Please provide a username (eg. your first name): kschwar3 Create user (kschwar3) password: ********* Repeat user (kschwar3) password: ********* Please provide your real name: Kat Schwarz Dear Kat Schwarz, your account kschwar3 has been created and is sudo enabled. Please use this account for your daily work from now on. Detected timezone: Pacific/Auckland Set user language based on your location? [Y/n] y At your location, more locales are possible: 1) en_NZ.UTF-8 3) Skip generating locales 2) mi_NZ.UTF-8 Please enter your choice:1 Generating locales: en_NZ.UTF-8 root@orangepi-r1plus-lts:~# I typed: reboot [enter] and waited then logged in with new credentials. ___ ____ _ ____ _ ____ _ _ _____ ____ / _ \| _ \(_) | _ \/ | | _ \| |_ _ ___ | | |_ _/ ___| | | | | |_) | | | |_) | | | |_) | | | | / __| | | | | \___ \ | |_| | __/| | | _ <| | | __/| | |_| \__ \ | |___| | ___) | \___/|_| |_| |_| \_\_| |_| |_|\__,_|___/ |_____|_| |____/ Welcome to Armbian 22.11.1 Bullseye with Linux 5.15.80-rockchip64 System load: 2% Up time: 12 min Memory usage: 12% of 976M IP: 192.168.0.136 192.168.0.138 CPU temp: 75°C Usage of /: 12% of 15G RX today: 53.0 KiB [ Kernel and firmware upgrades disabled: armbian-config ] Last check: 2023-01-19 07:43 Last login: Thu Jan 19 20:46:13 2023 from 192.168.0.105 root@orangepi-r1plus-lts:~# ifconfig eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.136 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::3eee:eadf:24b2:16dc prefixlen 64 scopeid 0x20<link> ether 8a:af:66:80:41:ea txqueuelen 1000 (Ethernet) RX packets 866 bytes 62242 (60.7 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 36 bytes 4069 (3.9 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 40 lan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.0.138 netmask 255.255.255.0 broadcast 192.168.0.255 inet6 fe80::ff58:cd59:4384:ff19 prefixlen 64 scopeid 0x20<link> ether 8a:af:66:80:41:0a txqueuelen 1000 (Ethernet) RX packets 1452 bytes 106409 (103.9 KiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 502 bytes 52497 (51.2 KiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10<host> loop txqueuelen 1000 (Local Loopback) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 root@orangepi-r1plus-lts:~#

Hi Namexx If you have anything plugged into the USB port, try it without. There are some home routers that only do IPv4 some are known to cause issues if IPv6 is enabled. If you are on network using IPv4 then you can try adding a line into /boot/armbianEnv.txt extraargs="ipv6.disable=1" I'm traveling at present, but when I get home, I will download an image and test on my board. Which image are you using, and how are you flashing it to SD card? I tested the current build successfully when it was released, but it's always possible that something has gone wrong since then. Edit: I was very lucky and got an earlier flight. I should be back home about one or two hours. https://docs.armbian.com/User-Guide_Basic-Troubleshooting/

I'm guessing that ">" on the end of the line in the logs means that the patch had no issues and applied correctly?

@rpardini Regarding patches encoded big5 with Chinese in the code comments and in tables and etc. Are you considering a way to accept these. These don't work with current armbian-next, and direct conversion to UTF-8 breaks the one that I tried for master and next. Example: the huge wifi-4002-add-realtek-8723cs.patch (kernel rockchip64 has six identical and there are others with variations) I have created a version of the rockchip64 patch with translated comments and deleted Chinese where this was just a Chinese translation in the same quoted string as the English. In table like structures where it wasn't clear if the string could be left out, I replaced with question marks. This patch builds on both master and next, but I have no way of testing it on hardware. The problem here might be that the Chinese in the table like structures might have a purpose (print or error strings come to mind). Maybe detect big5/foreign-chars and use the old method or something similar?

I don't have an Orange Pi 5. But for all of my Orange Pi's booting from USB is not possible without first programming the onboard SPI flash, and for that you need to boot from SD card. I don't know if Orange Pi 5 is different, it has different storage options like NVMe. The user manual will usually give you details. I Googled it, and it still seems that SD card is needed before other options like USB and SSD. https://jamesachambers.com/orange-pi-5-ssd-boot-guide/ https://forum.armbian.com/topic/25597-orange-pi-5-boot-from-usb-using-uefigrub/

@rpardini one of the actions on the slides: "testing on other architectures (armhf, riscv64)" 😀 For a lark, I thought I would give it a try on armhf, seeing as I have access to an orangepi-pc running Armbian Jammy I mounted an external drive on it. Armbian-next build was not successful, and because I don't think that armhf is a significant option, I didn't try too hard but here are the results. I suspect that the gcc-riscv64-linux-gnu package could be excluded if not cross compiling to riskv64, but I didn't investigate further. First, I tried the same method that I used on Intel, and it failed: [🌱] Preparing [ host ] [🌿] Please read documentation to set up proper compilation environment [🌿] https://www.armbian.com/using-armbian-tools/ [💥] error: Running this tool on non x86_64 or arm64 build host is not supported [ in prepare_host() at /mnt/storage/armbian-build/armbian-next/build/lib/functions/host/prepare-host.sh:63 ] [💥] Build terminating... wait for cleanups... I added this into lib/functions/host/prepare-host.sh at line 60 to include armhf in the permitted architectures: elif [[ $(dpkg --print-architecture) == armhf ]]; then : Native build failed again: [👉] Package gcc-riscv64-linux-gnu is not available, but is referred to by another package. [👉] This may mean that the package is missing, has been obsoleted, or [👉] is only available from another source [👉] E: Package 'gcc-riscv64-linux-gnu' has no installation candidate [👉] --> 🧽 28: 13096 - 13096 - 13096: hBE: trap: main_trap_handler [ ERR and 100 trap_manager_error_handled: short_stack:/mnt/storage/armbian-build/armbian-next/build/lib/functions/logging/runners.sh:186 ] I installed docker: Docker build failed for the same reason: [👉] Get:18 http://ports.ubuntu.com/ubuntu-ports jammy-security/universe armhf Packages [491 kB] ... [👉] Package gcc-riscv64-linux-gnu is not available, but is referred to by another package. [👉] This may mean that the package is missing, has been obsoleted, or [👉] is only available from another source [👉] E: Package 'gcc-riscv64-linux-gnu' has no installation candidate

@rpardini armbian-next - repeat build string at the end of the build process leaves out build options, BOARD=... and NO_APT_CACHER=... (although armbian build master also leaves out NO_APT_CACHER ) and possibly others. I would probably expect that all defined options would be included? Original test build string (with desktop and base configuration selected through dialog): ./compile.sh BOARD=pine64 BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_CONFIGURE=no CREATE_PATCHES=no NO_APT_CACHER=yes Repeat build string returned at the end of the build process ("BOARD=pine64" and "NO_APT_CACHER=yes" are missing): [✨] Repeat Build Options [ ./compile.sh BRANCH=current RELEASE=jammy BUILD_MINIMAL=no BUILD_DESKTOP=yes KERNEL_ONLY=no KERNEL_CONFIGURE=no DESKTOP_ENVIRONMENT=xfce DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base DESKTOP_APPGROUPS_SELECTED="3dsupport browsers chat desktop_tools editors email internet multimedia office programming remote_desktop" COMPRESS_OUTPUTIMAGE=sha,gpg,img ] I would also not expect COMPRESS_OUTPUTIMAGE=sha,gpg,img to be included (although no harm in including it).

I suspect that lot of end users will not have Jira accounts, but most do have forum accounts. Is Jira really the best option for end users?

I enjoyed watching that discussion. Good progress on next. I think that a Github discussion option available to developers before submitting a PR could be very useful. Maybe it could depend on or reference the users Github branch with a pending PR (is this possible)? To me this particular type of development discussion seems to be very clunky on the forum. Git Hub seems a better fit in this very specific case. It sucks that you almost need to submit a PR that you are dubious about, in order to get advice to do it another way, or that your assumptions were misguided. A preview on my own branch seems a much more appealing option, rather than risk cluttering armbian build master and looking like a numpty. I suspect that this could possibly encourage collaboration and mentoring particularly if the developer wants advice or opinions from other teams of developers. In this context, I don't think that moderation would be much of an issue and it would keep the discussion where it already exists on Github, just before, not after the PR. I managed to get a few desktops to build on next. After Ricardo fixed the dialog issue, all remaining desktop issues that I'm encountering seem caching related. Apt catcher ng which I didn't know about until yesterday (and therefore couldn't fix) was the biggest culprit, great to know it's not going to default to on.

@rpardini When a file has been changed in the local branch being built then master armbian-build provides a useful warning about not being able to update with a dialog to abort, continue or view changes before building. Personally I find this function to be a very useful reminder and would like to see it in armbian-next.

I agree that someone/we should strive to clean. No argument with that. Maybe during the armbian-next development period that is okay, but even then, it potentially drains resources from working on or testing armbian-next functionality. My concern is that unless someone goes through every build possibility and cleans up associated patches even for the community, unsupported and legacy stuff for all archived versions, amateur builders could hit issues that they may not be able to deal with, and that could discourage them. How about a compromise... a build option to override and allow the old way in case of patch issues (maybe with warning messages in case of bad patches)? Another thought, how about a dialog when there is a bad patch, with the option to continue at your own risk or abort?

I have been thinking about this, and i acknowledge that I'm late to the conversation and very ignorant... It seems that this "gold standard" is aimed at creating and maintaining patches in a workflow that relies on distribution lists for code contributions and review. And... yes, good well formatted and well described mbox patches would be fantastic in this context. But it seems to me that this is not what we are dealing with. The build process is consuming already created patches from many developers, and what is required for a build is clean diff's. I haven't been a part of the conversation, so maybe I'm missing something... From my admittedly very limited perspective. The build process should strip out the diff's and process them. There should be no checking of mbox formats at this point because the builder is not responsible for all other developers patches. If we want to clean up mbox patches or verify patches before PR then this should possibly be a separate process that would not stop a build using existing patches. In the build, perhaps something simple... like discard or ignore all content in the patch prior to the first diff, and then process. Is this wishful thinking?