All Activity

@royk thanks again for your help I've followed the step to build ffmpeg, mpp and rga, but after that i cannot build kodi anymore, and I'm unable to understand where the error is, i suppose that can be related with the configure option of ffmpeg. i've added these ones: ./configure --prefix=/usr --enable-gpl --enable-gnutls --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libdav1d --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-nonfree --enable-gpl --enable-libopus --enable-version3 --enable-libdrm --enable-rkmpp --enable-rkrga and this are the results when i grep from ffmpeg V..... av1_rkmpp Rockchip MPP (Media Process Platform) AV1 decoder (codec av1) V..... h263_rkmpp Rockchip MPP (Media Process Platform) H263 decoder (codec h263) V..... h264_rkmpp Rockchip MPP (Media Process Platform) H264 decoder (codec h264) V..... hevc_rkmpp Rockchip MPP (Media Process Platform) HEVC decoder (codec hevc) V..... mpeg1_rkmpp Rockchip MPP (Media Process Platform) MPEG1VIDEO decoder (codec mpeg1video) V..... mpeg2_rkmpp Rockchip MPP (Media Process Platform) MPEG2VIDEO decoder (codec mpeg2video) V..... mpeg4_rkmpp Rockchip MPP (Media Process Platform) MPEG4 decoder (codec mpeg4) V..... vp8_rkmpp Rockchip MPP (Media Process Platform) VP8 decoder (codec vp8) V..... vp9_rkmpp Rockchip MPP (Media Process Platform) VP9 decoder (codec vp9) V..... h264_rkmpp Rockchip MPP (Media Process Platform) H264 encoder (codec h264) V..... hevc_rkmpp Rockchip MPP (Media Process Platform) HEVC encoder (codec hevc) V..... mjpeg_rkmpp Rockchip MPP (Media Process Platform) MJPEG encoder (codec mjpeg) ... overlay_rkrga VV->V Rockchip RGA (2D Raster Graphic Acceleration) video compositor ... scale_rkrga V->V Rockchip RGA (2D Raster Graphic Acceleration) video resizer and format converter ... vpp_rkrga V->V Rockchip RGA (2D Raster Graphic Acceleration) video post-process (scale/crop/transpose) and i've also started from scratch with a different build "Armbian_24.5.0-trunk.434_Orangepi5_noble_vendor_6.1.43_xfce_desktop" installed panfork, ubuntu, updated the kernel with patches, compiled ffmpeg, mpp and rga, and as last kodi could be related with a ffmpeg bad configuration? thanks

Try adding a delay and see if that corrects the DRAM detection. https://github.com/armbian/build/blob/main/patch/u-boot/v2024.01/board_bananapim4zero/006-sunxi-restore-modified-memory.patch#L149

Moved

Visionfive2 booting spi version starfive 5.11.3 firmware. U-boot sees the 8GB RAM. I am using Armbian_community_24.5.0-trunk.433_Visionfive2_jammy_edge_5.15.0_xfce_desktop.img. I suspect there is something broken with the dtb file. I am loading this dtb: load nvme 0:1 ${fdt_addr_r} /boot/dtb/starfive/jh7110-visionfive-v2.dtb When I use OpenBSD 7.5 the 8GB is seen, but that is a different dtb file and EFI boot process. Is there a different dtb file to use?

Hello, I would like to add support for Milk-V Mars in the Armbian build system. Right now I am building for visionfive2(build boots fine with u-boot in spi) and intend to see if I can reuse the DTBs produced by the Milk-V Mars official SDK build(https://github.com/milkv-mars/mars-buildroot-sdk/releases/). I am looking for guidance on how to proceed. The board has the same SoC as the Visionfive2 but different peripherals (USB, m.2).

@voapilro oops, did you backup your original u-boot from the image? to restore this, you would need that u-boot backup. some u-boot bin files are customized with particular ways to start the kernel and that stored into u-boot in that 1st 1 meg or so. For the standard u-boot, it uses files in /boot/boot.cmd or /boot/boot.scr in the Linux root partition to boot linux, that is normally the case for Armbian distributions btw that scary prompt is the u-boot command prompt / shell https://docs.u-boot.org/en/latest/usage/index.html https://linux-sunxi.org/U-Boot https://krinkinmu.github.io/2023/08/12/getting-started-with-u-boot.html try ls mmc 0 [directory e.g. /, /boot etc] and 'help' in the u-boot command prompt, confusing at least if you can post the contents of /boot/boot.cmd in the root partition, normally those are the commands to boot linux from u-boot. If that is goofy (incorrect), linux will not boot. Those bunch of u-boot commands are critical to start linux. normally that can be compiled into another file called /boot/boot.scr (that is for an older version of u-boot) u-boot reads that /boot/boot.cmd (or /boot/boot.scr) which contains the commands to start linux with the kernel image, ram disk and the device tree binary (also called the flattened device tree FDT) this is so that changing the kernel probably means only editing /boot/boot.cmd (and generate /boot/boot.scr if needed)

This is due to wrong cable being used: moin moin moin ( p1mon ) : duh therefore this topic can be removed as I will find proper AP9827 cable first...

Hi @prahal, Yes, for few weeks I took the habit to use the serial console to better understand whether the boot crashes or is stuck at some steps (I've got a long long network config step with systemd-networkd). The message appears after u-boot gives the hand to linux, and is part of the very first lines where linux checks the hard drive filesystem.

I don’t suppose you ever found a workaround for this? Do we know if this is a driver or hardware issue?

Thanks @ag123 for your help! I tried your u-boot image and I got a different error, probably because Debian image I have is different than yours, so I have to restore u-boot from backup. This is console output I got: I see some differences from u-boot of my Debian image, but I am not able to see what is wrong or missing. Here is normal console log to compare:

hmm once cable is attached it does report FTDI USB Serial Device converter is attached, however apcupsd does not want to comm. with my APC Back-UPS 650, so either Modular or compiled in does not resolve my issue. [160575.289133] usb 7-1: new full-speed USB device number 3 using xhci-hcd [160575.444894] usb 7-1: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00 [160575.444943] usb 7-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [160575.444966] usb 7-1: Product: FT232R USB UART [160575.444985] usb 7-1: Manufacturer: FTDI [160575.445003] usb 7-1: SerialNumber: AL[hidden] [160575.453241] ftdi_sio 7-1:1.0: FTDI USB Serial Device converter detected [160575.453585] usb 7-1: Detected FT232R [160575.455687] usb 7-1: FTDI USB Serial Device converter now attached to ttyUSB0

Thanks!, saved me significant messing around. Generic-ish "T95MAX"(lol) here, 4GB... bridged UART rx FET Source Drain but no luck with that... mounted SD to setup some credentials. Don't really use HDMI, BTOOTH, WIFI(rarely) but I owe you(s) one so if you need something let me know... edit: board is one where BTOOTH seems like it works and WIFI does not due to new brcm chipset etc. etc.

I do not use quotas, so the fix for this issue is: https://github.com/openSUSE/snapper/issues/894#issuecomment-2054220427

Yes it needs to be low and then the broadcom dongle host driver needs to search for any hw on the sdio, which fires the init seaquence and enables the wifi module. This dhd is for some reason not started during boot.

Thanks @FRANK333 , I actually have an orange pi too so bookmarked that guide. For future readers: As for changing u-boot on Le Potato, I just followed https://docs.u-boot.org/en/latest/build/gcc.html https://docs.u-boot.org/en/latest/board/amlogic/libretech-cc.html they've guides for lots of boards. Everything seems to work so far as I was able to boot into armbian. Also, I recommend getting a USB U-art cable and using the terminal program minicom so you can see what happens during u-boot and with timestamps

Alright, thanks again to the replies ! I followed the u-boot guides and it worked out ! "make menuconfig" let me change the environment variable I wanted to. Compiling took just a few minutes. I did the dd commands from the guide and was able to boot the board. Armbian is intact, no issues.

Not sure 'AI' is the answer, this requires actual embedded dev skills. I have (lame) news tho. I gave the box away. A family member needed a TV box and the Tanix is doing that now. Giving up is kinda lame I know but there were good reasons for it. Mostly that the box is pretty much undocumented except that it has an rk3566 on it. This and that the manufacturer seems to have no interest in open source support and never replied to repeated attempts of getting some documnetation, SDK etc. The idea was to teach myself SBC embedded linux/android and reverse engineering seemed interesting at first but ialso maybe not the best way to learn. In the end it didnt seem worth the effort. I bought a firefly rk3566 instead, stationpc m2 instead. Well documented board with NVME interface, good wiki/docs, Android and Linux SDKs on gitlab, plenty of tools and firmware to play with. It's a much more rewarding environment for a developer to learn. Sorry if I disappointed people replying, trying to support here. Thanks in any case!

If the issue is that the cpu frequency is switched too fast and I can reproduce the crash with a regulator-ramp-delay of 1000, then there is no point in testing anything above 1000 that will make the issue worse. regulator-ramp-delay is badly named. It is not a dealy it is a divider for the delay. The greater regulator-ramp-delay the fastest the transition (I believe the Kobol team made this mistake, but as I also believe the issue could be otherwise than the delay between transitions this is not a big deal). I still have not tried with a lower than 1000 value for regulator-ramp-delay (ie without tweaking the opp voltages as I am currently doing).

@ebin-devI believe initramfs messages are not written to syslog. @Trillien you see that message on the serial console? /usr/share/initramfs-tools/scripts/local-bottom/mdadm is part of the mdadm package which pcakaged by Debian. "dpkg -S /usr/share/initramfs-tools/scripts/local-bottom/mdadm", "apt policy mdadm" Though it could be the fact that the generated initramfs lack/bin/rm is armbian specific. You might want to open a bug against armbian or at least open a topic in the forum. But nothing helios64 specific as far as I know. Could even be a Debian bug. I don't even know if we ought to fix this missing /bin/rm for mdadm at the board level, even as a workaround.

could you try my older test case code: Turns out I did not compile my test case anew before pasting it to github gist and could be the new one I pasted there is not testing what I expected (in that it could be I changed it to try testing CPU frequency changes from max to min instead of each step). Mind I use a binary of the test case I made long ago for my tests which is the one in the link above. I did not feel like sharing a binary test case was a good idea. I prefer you to be able to audit the code (or have someone audit it for you). , I did not have much time to devote to sharing my findings so I checked the source was fine but not if the test was the same as the one I used on my side to stress test the big cpu. Sorry. It looks normal for you the test case I shared to you working fine as as far as I know 1.8GHz 1.2V and 408MHz at 825mV are pretty stable. They could crash I am not sure of that, but it would take more than 50 runs of the test for it to happen (at least it took 80 of them for the 600MHz to fail at 825mV). Mind you should do at least 5 runs of the above test case to be somewhat confident you cannot get the cpu b to crash. The fact that it does not crash is not the point of the test. Its usefulness is that it nearly always crashes the big cpu on the first run. EDIT: the previous gists I gave you as a test case was my v1. The current test case is https://gist.github.com/prahal/8fab73325eb0d7091ad7c4627bf8e25a which is in the other thread I linked in this comment.

Hi, I've been using the /dev/ttyAML1 UART port on my Odroid N2+ at the GPIO pins 8 and 10 with buster. With the update to bullseye, the /dev/ttyAML1 device disappeared. Also now in bookworm it is no longer present. Now I happen to need the UART at GPIO 8 and 10 again and did some more persistent research and came across this post over in the DietPI forum. It provided an alternative meson-g12b-odroid-n2-plus.dtb which I installed in my system. Since then my /dev/ttyAML1 device is back and I can use the UART at GPIO 8 and 10 as I wished. However, I am a bit nervous, since I just installed some binary dtb file to my system at a path which is owned by the linux-dtb-current-meson64 package. So it is endangered by a system update. Is there an "official" way to get back my /dev/AML1 UART device which is sustainable? Thank you very much

Hi, to my side same: root@helios64:~# cat /var/log/syslog | grep mdadm root@helios64:~# and, for moment not crash/freeze to my helios64...

Hi @Igor. All the above are 5 commands?

Sorry for the confusion. For the moment I'm using it with original android firmware. I tried the build suggested by user blustOne (above in this thread), booting from SD card, GPU has signal output but seems not to have HW acceleration for playback (it loads the file, but stutter/choppy playback). Also no sound through HDMI port. I'm tring to first dump the entire firmware of the device. I don't want to get it bricked because of playing with it. Once I can dump it, I will try to play with the armbian variants, try to build my own, etc. I have never done this and I know I have a long way ahead reading and learning (and no much time), just I want to start with the backup. I will also try to debloat the android version. I'm using it connecting a flash drive with videos, I connect it to internet as little as possible, it has many bloatware that I'm not sure of what thing it can cause in my private network. Probbaly i'm worring too much about it? ..

Dear All, I get frequent and random disconnection from orangepizero3 onboard wifi with armibian community (self-built) both trunk and 24.02 current kernel, 6.6.26 and 6.6.28 message is always [21738.338021] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21848.116072] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21915.426734] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection sm_state (5), status: (2)! [21915.426817] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection Vodafone-CSC failed status code:1! [21919.477424] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [[21738.338021] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21848.116072] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it [21915.426734] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection sm_state (5), status: (2)! [21915.426817] unisoc_wifi unisoc_wifi sta0: sprdwl_report_connection Vodafone-CSC failed status code:1! [21919.477424] sprdwl:sprdwl_fc_add_share_credit, 536, mode:1 closed, index:0, share it Full logs available at armbianmonitor -u Any help/hint/solution deeply appreciated