maxsub
Members-
Posts
37 -
Joined
-
Last visited
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
@sven-ola The nightly is on 6.19 without headers, so I can't build any additional drivers. The nightly is working on the R2S with ethernet ports and no heating issues, no load average problems. How do I get a 6.18 build (Current)? Thanks.
-
@sven-ola Nightly build fixed the load problem and heat problem on R2S: linux-image-current-spacemit/now 26.2.0-trunk.574 riscv64 [installed,local] Armbian Linux current kernel image 6.18.18-current-spacemit This is my current uname -r: 6.18.18-current-spacemit
-
> apt search linux-headers linux-headers-6.19.6+deb14+1-common/testing 6.19.6-2 all Common header files for Linux 6.19.6+deb14+1 linux-headers-6.19.6+deb14+1-riscv64/testing 6.19.6-2 riscv64 Header files for Linux 6.19.6+deb14+1-riscv64 linux-headers-riscv64/testing 6.19.6-2 riscv64 Header files for Linux riscv64 configuration (meta-package) > uname -r 6.18.18-current-spacemit
-
I installed 6.18.18-current-spacemit from the nightly but can't find the headers package to build the GPU support. The repo has 6.19.x headers but no 6.18.x headers.
-
Managed to edit the MMC by booting from USB, mounting the MMC. The R2S is now up and running, with the mainline armbian. However, the CPU still spins in the kernel and generates a lot of heat. Idle load average is 2.02.
-
I ran into some trouble. I managed to boot the USB and then used armbian-config to flash the image to internal eMMC. However the script copied the USB UUID instead of the MMC UUID so now the MMC won't boot. I need to edit the MMC and change the UUID.
-
Thanks for the script @sven-ola. I got the R2S booted from USB. I had to tweak a few minor things. Where did you get the Ubuntu boot.cmd? usb start setenv devtype usb setenv devnum 0:1 setenv prefix boot/ setenv fdtfile dtb-6.6.99-legacy-spacemit/spacemit/x1_orangepi-r2s.dtb #setenv fdtfile spacemit/k1-orangepi-rv2.dtb setenv bootargs "console=ttyS0,115200 root=/dev/sda1" ls ${devtype} ${devnum} ${prefix} load ${devtype} ${devnum} ${ramdisk_addr_r} ${prefix}uInitrd load ${devtype} ${devnum} ${kernel_addr_r} ${prefix}Image load ${devtype} ${devnum} ${fdt_addr_r} ${prefix}/${fdtfile} booti ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}
-
Thank you. R2S has a built in eMMC and USB. The only way to get a new image is to boot from USB but it seems like I have to manually load the image in u-boot. Is the u-boot script (boot.txt) for the build somewhere in GitHub?
-
I ran into a problem. Flashed the nightly build to the eMMC on the R2S and now it won’t boot from USB. I can see the usb drive in u-boot and kernel.img and dtb. What’s the default address to load the kernel and dtb on these boards? thank you.
-
In the meantime I brought up an access point server using the nightly armbian build. So far it is running solidly. The WiFi is underpowered, while the rest of the system seems stable.
-
Excellent. Thank you so much. I will try the newer brcm driver today. So the GPU change is now in main?
-
I setup a fresh install on the RV2 using the pre-built Forky binary. Everything works stably but the idle load average is very high all the time: armbian@orangepirv2:~$ uptime 09:22:27 up 13:30, 1 user, load average: 2.00, 2.00, 2.00 Looks like the bug that cause the kernel to spin is still there.
-
Thanks @sven-ola. I will give that a try. The standard Armbian is unable to connect to an WPA3 access point in basic client mode (no AP). It connects fine to WPA2-Personal.
-
Thanks @sven-ola! You have been of amazing support here. My worry about using the closed source binary firmware is that it opens up a security hole (no patches for vulnerabilities, etc). Same for OpenWrt - the xunlong code is a fork from OpenWrt and not being updated as far as I can tell. That's why I went the Armbian route, with your code in mainstream, it will get continuously updated. The WiFi is definitely underpowered, and CPU overpowered. I am using an R2S with a USB Wireless adapter (realtek): Panda wireless PAU0B. However, the 6.6 kernel seems to not allow AP mode.
-
Is it possible to build against a current kernel (6.18 for example)? I am trying to build an access point on Armbian but 6.6 does not support AP mode on most adapters.
