All Activity

Happy to report that "./compile.sh build BOARD=rock-3c BRANCH=current BUILD_DESKTOP=no BUILD_MINIMAL=yes KERNEL_CONFIGURE=no RELEASE=bookworm SHARE_LOG=yes" builds fine for me now.

Hello and thank you for sharing your experience. https://github.com/redrathnure is the maintainer of your board. Not sure if he is active here in the forum.

Yes, I am fairly confident you were experiencing one of these two https://github.com/armbian/build/pull/8554 https://github.com/armbian/build/pull/8555

a fix was just merged for Rockchip, update your repo and try again, maybe you are lucky

let me have a closer look after I successfully unsuccessfully compile this

Thank you for the reply and suggestion. I tried trixie and got the same error with the same patch. I guess I can't tell it to skip VP9?

First suggestion: try trixie or noble instead of bookworm

Hi, I'm trying to build for the Rock 3C so that I can minimize what goes into the kernel and system. I'm new at this and tried mostly default values (current, bookworm), except that I did minimal image instead of standard. The build failed at applying a patch. I don't know what to do with that. Can anyone help me diagnose? Also, how would I get into more details about building the image and choosing what to add/remove? Thanks!

@Igor well I'm not getting very far, unless I'm prepared to count failures... I have more of those. The SD Card reader / writer works well; I can use it to carry out various operations on my brand-new SanDisk Extreme Pro A2, including formatting from the Ubuntu Disks application, running SDCardFormatter, using usbimager to create the Armbian 25.5.1 Noble Minimal system disk, mounting, unmounting and ejecting... When I've finally got the SD card set up, here's what the Ubuntu Disk application shows. Note the first partition is 4.2MB of free space. When I put this SD card in the Cubox and boot from it, the same thing appears to happen as previously - on the HDMI-connected monitor, the Cubox bootloader runs and hands off to the boot program, after which the monitor reports no HDMI signal and the monitor goes into sleep mode. After approximately two minutes, the Cubox bootloader appears again on the monitor, hands off to the boot program, and... the same thing. Nothing seems to be active at the IP address - I can neither ping nor ssh to it. This time I have my laptop connected vi USB to the Cubox console port. Various positive messages show up in dmesg finally ending in: usb 1-6: Detected FT-X usb 1-6: FTDI USB Serial Device converter now attached to ttyUSB0 But running either screen or minicom, they return immediately, showing no sign of having established any kind of connection, no waiting for a connection, no error message, nothing. Just a reminder that this Cubox boots and runs fine on the current system SD card which is up-to-date bookworm minimal.

Hello. I have not been able to make the ethernet port working on a MKS Pi board with the latest armbian image found here : https://www.armbian.com/mks-pi/ I don't even get a link led ON on the ethernet connector when connected. Can anyone offer guidance? Thanks! P.S. I could not find a MKS-PI tag in the tag menu to identify this thread correctly. Can anyone fix this?

hello @Nick A, thank you for the information, could you give me a virtual machine recomendation? my laptop specs are : cpu intel core i5 8250U (recomend the amount of cores (8 core is max) 12 gb ram (ddr3 4gb+8gb bus 2400mhzx2) (will use 6gb ram), 2 ssd 250gb (1 for os 1 for vm(s)) I need to have a sleep now bye...

@Ducdanh Nguyen

Plus the kernel source is getting pulled from their repo. If they did make a change, you should see it on Armbian.

@Nick A Do i need to use linux this time? or i can do it with windows, it's 9:12 PM in my country...

I don't see anything in the history that would suggest they made any changes? I could submit a RTW88 patch I put together from the lwfinger/rtw88 repo. But seeing as the pi guys haven't appeared to have changed anything on their end, it is probs more trouble than it is worth.

@c0rnelius: I already did a diff, but there are a whole lot of differences. In fact one of the things I also tried, was directly copying the .config file I use to build the RaspberryPi kernel to the config/kernel/linux-bcm2711-current.config and build that kernel, but I got exactly the same result. What I have not tried and might do at some point, is doing a diff on the rtw88 driver sources. But seeing how forcing the 11b mode as described above workarounds the issue, I suspect it might be some kind of config issue causing the 11b modes to be disabled somehow...

OK, I made a really ugly script that sets managed mode, forces 1M legacy mode, switches back to monitor mode, and then performance is exactly as it should. But the thing is, can this be avoided? What could be causing this behaviour on Armbian, and how to avoid it? This is the horrible workaround BTW: #!/usr/bin/env bash set -euo pipefail ip link set mon1 down iwconfig mon1 mode managed ip link set mon1 up iwconfig mon1 rate 1M fixed ip link set mon1 down iwconfig mon1 mode monitor ip link set mon1 up iwconfig mon1 channel 1

Run a diff on the pi and armbian defconfig. https://github.com/raspberrypi/linux/tree/rpi-6.12.y/arch/arm64/configs

kudos for your perseverance. and thank you for sharing your findings. I hope you will be able to work it out eventually.

@Ducdanh Nguyen your box might have secured boot enabled. You’ll need to compile an image with this secure boot patch

Hello @Nick A, i found out my box has verified boot on it, meaning it couldn't boot in other os as you may know, is there any possible way to disable it as soon as i found out my box is not even trying to boot on armbian and with "toothpick method" it showed a fake update screen. I'm so frustrated, couldn't have any way to boot to the sd card and haven't got the dtb too, my box is not rooted. The only last resort is i can see if it automatically boots to it without the "toothpick method"

Thank you @Werner, for letting us know and for your efforts

What U-Boot version is used for eMMC resp. SD-card?

it appears to be a useful application is there a way to use it without a network

After a lot more experimentation, I have noticed the frames I am missing are the 802.11b ones! So something must be disabling these on Armbian. Unfortunately I cannot find what.