All Activity

Hi @jock! Recently I do really look into the rockchip docs and try to work on that little dongle toy a bit. And then I look back at my original post, and I realize that at that time I totally didn't know what I was doing At that time, after trying and failing the other rkdeveloptool commands (rfi, ppt etc), I did have execute rkdeveloptool db rk322x_loader_v1.10.256.bin at that time, but I was not aware that these commands would now work after the loader bin file had been loaded, and then I stopped trying. OK, these are what I have tried this time: root@debianvm:~# ./rkdeveloptool/rkdeveloptool ld DevNo=1 Vid=0x2207,Pid=0x320b,LocationID=101 Maskrom root@debianvm:~# ./rkdeveloptool/rkdeveloptool db /home/h__c___g/rk322x_loader_v1.10.256.bin Downloading bootloader succeeded. root@debianvm:~# ./rkdeveloptool/rkdeveloptool ul /home/h__c___g/rk322x_loader_v1.10.256.bin Upgrading loader succeeded. root@debianvm:~# ./rkdeveloptool/rkdeveloptool rfi Flash Info: Manufacturer: SAMSUNG, value=00 Flash Size: 0 MB Flash Size: 0 Sectors Block Size: 512 KB Page Size: 2 KB ECC Bits: 0 Access Time: 40 Flash CS: root@debianvm:~# ./rkdeveloptool/rkdeveloptool rci Chip Info: 41 32 32 33 FF FF FF FF FF FF FF FF FF FF FF FF root@debianvm:~# ./rkdeveloptool/rkdeveloptool rcb Capability:07 00 00 00 00 00 00 00 Direct LBA: enabled Vendor Storage: enabled First 4m Access: enabled Read Com Log: enabled I realize that the Flash Size read 0 mb. I obtain rk322x_loader_v1.10.256.bin by commenting out the rm -f line in the (github) rkbin/scripts/checkpatch.sh file. Maybe the loader firmware did not support SPI? But before I do the ul line, I do try dumping the storage using rkdeveloptool rl 0 xxxxx dump.bin and then strings dump.bin, and nothing comes out; but after I do the ul line, the strings really do spit out many random lines, and I think it is evidence that I can use the rkdeveloptool binary to write bytes to the SPI... Is there any chance for me to make this dongle sort of working by using the rockchip proprietary binaries to pack up the uboot.img, trust.img and boot.img files, and then flash them in?

Since what I need is only /proc/schedstats and not a debug package probably my task will be a little simple. I will let you know about the result. Thank you very much! Stefanita Vilcu

Hi, To my side, it's too complex and risky for me to change hardware components on Helios64. I prefer for my case of uses change CPU Freq and Governor for less performance but stable inside take risk of damage my board by change components. Have a good day

@Igor This line may sound rude, but you are probably waiting for the developers of the source code to take some action to improve patches or kernel settings. As long as this heresy is present in the build system (bad package build scripts), the project will receive crumbs from what developers can and do locally.

I don't have a TTL at the moment, but I can confirm too that: Armbian 24.2.1 Jammy CLI - does not boot Armbian 24.2.1 Bookworm CLI - boots tagging the maintainer for visibility @schwar3kat

The developers of Armbian have signed their own impotence with this. They cannot or do not want to add support for creating an additional package with debugging symbols. If we look at simple scripts for creating debian packages directly in the kernel source codes, we will see that the debugging package is created automatically when the configuration option is selected: CONFIG_DEBUG_INFO The only way is to change the script of the build system itself by removing these lines and adding 10 lines to the script to create a debugging package. With respect to all free software developers. Leonid.

Well you can try to disable the mentioned switch and see what goes wrong when packaging happens. Then you need to figure out how to fix it.

Currently as a desktop. Wanted to try it out, but the kernel update over apt upgrade bricked my device. So I need to reflash everything. I am still doing everything on the current 6.6 kernel. IR works I just need to create a keymap and I will test KODI out - just need to recompile it in a VM. I am still waiting for my sound bar that has SPDIF to test it out. I think currently it is not working as I saw that spdif@fe460000 is currently disabled. I am also looking for the current Linux-headers file 6.6.28 so that I can try with openvfd. I was unable to find them with the previous kernel version 6.6.27. Once I install everything back I will retry this. What is funny about this box - every reinstallation brings a new MAC address. I am also trying to set up a CasaOS - currently in YouTube mode on how to set up Cloudflare tunnels.

Hello, I have a bunch of boards (rpi4b, rpi5, orangepi5, orangepi5-plus, nanopct6, rock3a, rock5b, vim4) in a Kubernetes cluster using Cilium. Cilium requires CONF_SCHEDSTATS=y in the kernel, which is dependent on CONFIG_DEBUG_KERNEL=y but... in build/lib/functions/compilation/armbian-kernel.sh we have # DONE: Disable: debug option kernel_config_set_n DEBUG_KERNEL # Armbian doesn't know how to package a debug kernel. Which invalidates the option I enabled during ./compile.sh BOARD=... BRANCH=... kernel-config Except for the VIM4, with DEBUG_KERNEL enabled in build/config/sources/families/meson-s4t7.conf Is there a way to enable DEBUG_KERNEL for the rest of the boards? Thank you! Stefanita Vilcu

You are choosing to use the edge kernel, which is the 'bleeding edge" development work area, it is expected to be unstable. If you want fewer issues you shouldn't be using edge.

Is this message important or will I be able to continue with this trunk version (kernel)? This is what I have so far on my system:

Installed this on an old Heltec Helium miner Any idea how to enable SPI so spidev shows in /dev/?

I'm also keeping this two torrent files from official release 24.5.0-trunk.474 in my H96 MAX torrent server Armbian_community_24.5.0-trunk.474_H96-tvbox-3566_jammy_current_6.6.28_gnome_desktop.img.xz.torrent Armbian_community_24.5.0-trunk.474_H96-tvbox-3566_bookworm_current_6.6.28_minimal.img.xz.torrent

Manged to boot latest armbian on Transpeed T98 6K clone. Don't quite understand actions needed to boot from SD card, but investigating uBoot setup I noticed, that it can also boot from USB stick. I'd like to join the development. Device looks promising.

After blaming: - networkmanager - ifupdown - systemd - my router - my provider - myself I tested with a separate wifi AP (not managed by my provider) and sprdwl_ng crashes to the point of being incapable of "seeing" any network again (until rmmod and insmod) when the same ESSID is broadcast both under 2.4Ghz and 5.5Ghz My wild assumption is that this driver doens't like (buggy perhaps?) to be "band-steered" Whens ticking to a single band, no issue. Hope it helps someone in my same situation

Will compile and test today... (compiled) did you test the 6.8 kernel? how you're using this device? did you test the video player on chromium? Pull Request to Armbian https://github.com/armbian/build/pull/6520 (accepted) rk3566-h96-tvbox.dts rk3566-h96-tvbox.dtb

Hi Kanken, can you link that build please? I (and I imagine lots of others) would be very interested in trying it!

Yea my biggest issue here is getting it to run without having to keep android on it . We have successfully created a duel boot but that takes up mem I also know a project that uses raspberry pi boot loader to install onto the rockchip . Your right it seems its a free for all

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

If the image in question is not at Github its gone. trunk images are not archived over longer period. The amount of storage needed for this task would be just insane.

Thank you for taking the time to respond. Will you have the trunk.286 image to download? I looked for it and couldn't find it... the one I have saved is trunk.287. Thank you so much I tried to download it but it does not exist: https://github.com/armbian/os/releases/download/24.5.0-trunk.286/Armbian_24.5.0-trunk.286_Orangepi5_trixie_edge_6.8.1_minimal.img.xz

The world of open source is all about reverse engineering things where manufacturers don't want to invest in openness. That is why Armbian exists. But it takes a lot of effort. Here are a couple of threads that show how the process works and the time it takes to do what you want without support from the manufacturer: https://forum.armbian.com/topic/24091-efforts-to-develop-firmware-for-h96-max-v56-rk3566-4g32g https://forum.armbian.com/topic/28895-efforts-to-develop-firmware-for-h96-max-v56-rk3566-8g64g

In other words we are beholden to the manufacture...