All Activity
- Past hour
-
@Nick A Great! and Good job! I've tested both the server and desktop versions of v0.6.4 on the A7S, and the DP output works perfectly on both. I've attached a screenshot for your reference. I’m using a USB‑C to HDMI docking station to test it. When I repeatedly plug and unplug it, the display works fine. The dock also has a keyboard receiver plugged in, which works normally. However, if I then plug a USB flash drive into the dock, the display output stops working (probably due to power supply issues). If I unplug the USB drive and plug it back in, the display works normally again. Additionally, I tested the Mainline v0.1. It seems to have issues on the A7S: the blue LED flashes after boot, but neither the Ethernet nor WiFi connects, and there is no output on the DP port. It appears the system cannot be login (I haven't tested via UART). However, the A7Z handles dual screens fine over HDMI and DP.
- Today
-
$ grep -i error /var/log/armbian-hardware-monitor.log [ 2.990779] rockchip-pcie f8000000.pcie: probe with driver rockchip-pcie failed with error -110 Looking at this I see the following: https://patchwork.ozlabs.org/project/linux-pci/patch/20210421083115.30213-1-jinsiyu940203@163.com/ "In function rockchip_pcie_host_init_port(), it defines a timeout value of 500ms to wait for pcie training. However, it is not enough for samsung PM953 SSD drive and realtek RTL8111F network adapter, which leads to the following errors: [ 0.879663] rockchip-pcie f8000000.pcie: PCIe link training gen1 timeout! [ 0.880284] rockchip-pcie f8000000.pcie: deferred probe failed [ 0.880932] rockchip-pcie: probe of f8000000.pcie failed with error -110 The pcie spec only defines the min time of training, not the max one. So set a proper timeout value is important. Change the value to 1000ms will fix this bug." Is it possible for team to add patch such as ../patch/kernel/rockchip64-current/0002-rockchip-pcie-increase-timeout.patch which contains the fix specified in the patchwork.ozlabs.org link above? A humble thank you for any more help and consideration on this!
-
Magcubic HY300 Android 11 Projector Allwinner H713, 1GB/8GB
curse replied to curse's topic in Allwinner CPU Boxes
@well0nez I didn't even think about that. When I made the original post almost two years ago, AI was much less capable than today. You just gave me a few ideas for different projects. As I said, unfortunately I don't have the HY300 anymore, but I do have a Magcubic L018(same chip I think), though it's in use every day as a bedroom TV. I don't think my girlfriend would appreciate if I started to hack it 😉 Especially if core functions like projecting the things coming through the HDMI port to the wall. The L018 has worse software than the HY300, in my opinion, so I've connected it to a certified Android TV 14 Box. -
Hello, I updated to Armbian 26.2.1 trixie installaed on emmc. If I poweroff the nas and power on again it does't work, but if I attach an usb cable to the console it works. I think the problem must be related to the u-boot part.
-
It worked seamlessly! Thanks!
-
I made some patches so that the unified driver / TIM-VX for the NPU works on the A7Z. I am also building a MLIR pipeline that emit TIM-VX code, so hopefully we can get more flexibility running ML models on the SBC soon. https://github.com/MaverickLong/Radxa-A733-NPU-Unified-Driver-Support-Package
-
Magcubic HY300 Android 11 Projector Allwinner H713, 1GB/8GB
well0nez replied to curse's topic in Allwinner CPU Boxes
@curse well yes i started this port because shift did a static analysis of the firmware with ai. but well its not usable (mostly) and there are obviously differences between the 2 projectors. i would somehow call it hacky, its nowhere near to be stable but for now its acceptable. i dont know if i will ever be able to complete it. -
Magcubic HY300 Android 11 Projector Allwinner H713, 1GB/8GB
curse replied to curse's topic in Allwinner CPU Boxes
@well0nez Thank you. Interesting project. It seems to originally be based on a HY300 project. Unfortunately I don't have the Magcubic HY300 anymore, but both of the projects looks really promising, especially the HY310 project you linked that seems to be fully functional. -
Armbian for H313 X96-Q LPDDR3 TV-Box
Давид Васильев replied to sicxnull's topic in Allwinner CPU Boxes
Hi everyone! I tried installing hardware decoding from this link - https://forum.armbian.com/topic/32449-repository-for-v4l2request-hardware-video-decoding-rockchip-allwinner/ , but it didn't work for me. My board version is 5.1. Has anyone been able to fix this? -
I tried to enable the I2S / PCM5102 service with AI, but unfortunately, despite numerous attempts, I couldn't. But anyone can use a USB audio card. Maybe someone else will figure out how to enable it 🙂 Best regards
-
Support for DP Alt Mode is now functional for the A7S running kernel 6.6. https://github.com/NickAlilovic/build/releases/tag/Radxa-cubie-A7S-v0.6.4
-
Magcubic HY300 Android 11 Projector Allwinner H713, 1GB/8GB
well0nez replied to curse's topic in Allwinner CPU Boxes
have alook here: https://github.com/well0nez/allwinner-h713-linux its for an hy310 but its still a h731 ;) - Yesterday
-
-
NanoPC-T6 LTS Reset button doesn't work on 6.18.x kernel
ando replied to ando's topic in NanoPC T6 LTS
yes, i've studied the schematic well to see if that gave any clues and I have learned that it ties into the Power Management Unit. It remains that the button doesn't work on mainline kernels but does on the vendor kernel. There must be some init step or configuration that's missing. -
https://docs.armbian.com/User-Guide_Armbian-Config/System/#desktop Should be straighforward to enable desktop on top of CLI.
-
Hi Gentleman, all desktop images disappeared for Opi 3B. Is there a chance that will be available later?
-
NanoPC-T6 LTS Reset button doesn't work on 6.18.x kernel
usual user replied to ando's topic in NanoPC T6 LTS
According to the circuit diagram, the reset button is connected to the hardware reset lines, so nothing can prevent forcing the reset state. -
Looks like the current-rockchip64 kernel that one receives with apt on PINE64 rockpro64 is 3.18.10 (6.18.10-current-rockchip64), vulnerable to copy-fail. This seems weird because if you go to https://armbian.com/boards/rockpro64 that page says that the "current" kernel for these systems is 6.18.26 and that is what you get when you download the image file. Is there an issue with updating the apt repos?
-
Things are still very sad with Ethernet. Is this could be related to some low-level timings in device configuration?
-
First of all, thanks for your reply. Even though you said there are no "vendor-lockin" i felt like so that's why i created a post on this forum as this issue came only after armbian os flash. As i said, after flashing armbian os, i was not able to use MASK button to bypass emmc boot and about a dozen of different os other than armbian failed to boot from SD card. Then i experimented on different methods including the PC connectivity but changing bootloader or os image didn't work as the mask communication is getting lost during flash command run. I deleted boot files from armbian boot partition to check if that fall back to SD card, but there was no luck. However armbian SD card boot still worked. So i confirmed that it is the change in bootloader that armbian made. Then i re installed armbian os inside emmc and used dd command to write the original bootloader images which is taken from the nanopi r6s official eflasher download link. It worked! Now i am able to install other os than armbian. Kindly fix this issue and acknowledge the same, otherwise people like me will think twice before testing latest armbian os next time. Best regards
-
Armbian does not have things like "vendor-lockin" or something and descriptions like "does not work" aren't much helpful as well. Either way, we cannot help with 3rd party OS since we neither know them nor deal with them, so I suggest to ask at the place where you got the image you are attempting to use get from, like http://friendlyarm.com/
-
Ah, this board has n out of tree dt as well which most likely overwrites the patch. Try adjusting this file: ~/build/patch/kernel/archive/rockchip64-6.18/dt/rk3576-nanopi-r76s.dts
- Last week
-
I'll give it a go when ready for download 🙂 ljones
-
I am trying to get the ARM performance assessment setup working (I'm trying to get Mali profiling for OpenCL code) on the Rock 5B+, and I've hit a blocker. The main component to this is some kernel configuration (CONFIG_ARM_SPE_PMU) and a loadable module. Oddly, those work fine in a custom kernel build. What I am hitting appears to be some missing interrupt setup that renders all those components inert. (It has to be a custom build to get CONFIG_ARM_SPE_PMU set. The issue is that even with the kernel configured and the module loaded, the SPE component remains inactive. ARM has its own system report tool which analyzes a setup, and that tool is reporting an issue: And indeed, nothing seems to show in cat /proc/interrupts. The man page for the module suggests this is the issue: It says: KPTI is definitely disabled and the SPE PMU loads (it's in lsmod) but it still doesn’t show in /sys/bus/event_source/devices/. Nothing relevant seemed to show in dmesg either. Frankly, I have no idea where to look for the SPE interrupt, or how to set it up. If anybody has any pointers or suggestions, I'd be extremely grateful.
-
deleted my patch file in userpatches cp output/patch/kernel-rockchip64-current.patch patch/kernel/archive/rockchip64-6.18/rk3588-1300-arm64-dts-rock5t-eth-reset.patch definitely saw the patch get applied during the build ./compile.sh BOARD=rock-5t BRANCH=current RELEASE=trixie kernel-dtb # cat output/logs/log-kernel-dtb-cd035955-4094-4e6f-b86d-89fe0287a2ce.log.ans |grep eth-reset patch/kernel/archive/rockchip64-6.18/rk3588-1300-arm64-dts-rock5t-eth-reset.patch -> 223/230: rk3588-1300-arm64-dts-rock5t-eth-reset(:1) (+20/-0)[1M] {rk3588-rock-5t.dts} │ rk3588-1300-arm64-dts-rock5t-eth-reset copied the rk3588-rock-5t.dtb over to my Rock5t's /boot/dtb/rockchip/ folder, rebooted it and ..... it didn't work # dmesg |grep -e 'r8169\|RTL8125B' [ 2.286822] r8169 0003:31:00.0: enabling device (0000 -> 0003) [ 2.314767] r8169 0003:31:00.0 eth0: RTL8125B, 00:48:54:20:XX:XX, XID 641, IRQ 123 [ 2.314803] r8169 0003:31:00.0 eth0: jumbo features [frames: 16362 bytes, tx checksumming: ko] [ 2.347904] r8169 0003:31:00.0 enP3p49s0: renamed from eth0 [ 5.367059] Realtek Internal NBASE-T PHY r8169-3-3100:00: attached PHY driver (mii_bus:phy_addr=r8169-3-3100:00, irq=MAC) [ 5.560727] r8169 0003:31:00.0 enP3p49s0: Link is Down [ 7.870963] r8169 0003:31:00.0 enP3p49s0: Link is Up - 1Gbps/Full - flow control rx/tx So either I'm doing something wrong, 1st time building something on this build framework, or this patch just doesn't work on my Rock5t. Ethernet should be the same on the consumer and industrial boards right?
