All Activity

as mentioned except code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } .. everything should belong to your current user Take note of the permissions for code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } .. Which admin?

i am using armbian 24.2.1 debian bookworm inn orangepi 5b. At first i used sd card to boot. then i wanted to use emmc to boot. so i went to armbian-config and install os in emmc from there from sd card. now it is booting from emmc if the sd card is not connected but if the sd card is connected it is booting from sd card. The worst part is, if i connect a sd card where there is no OS, it will not even boot. How can i set a order like if there is bootable os in emmc boot from there and use the sd card as storage if not boot from sd card ?

In action: branching to 24.5 (asap) freezing sources merging all board status changes making RC builds

Hi, thanks for the efforts with this. Just tried this on my MXQ Pro V72 (3228A) with latest Armbian w/ XFCE. Unfortunately, any playback on mpv within xfce did not have good performance. In terms of hardware decode, only h264 8-bit could run w/ hw decode. Meanwhile 10-bit H264 and HEVC did not run with HW decode at all. All files were tested at 1080p. Playback performance was only good when run in virtual terminal, but on XFCE, even 8bit H264 stuttered, not to mention the pink/red color issue (which was fixed with the additional mesa flags). I thought it was a throttling issue, since xfce sensors report 80C, so I added a fan blowing from under the tv box and the temps are now within 55-70C. However that did not fix the issue. Is there anything else I could check or try? Thanks.

checked in detail. spi-dev - it works (in the new firmware) gpio - it works key the path by name is different ( /dev/input/by-path/platform-gpio-keys-event ) I haven't been able to launch the display on spi0.1 yet

Definitely, if you look at the kernel source code you can enable the codec Yes, it is. I think it is in the kernel mailing list, so it is something that is already floating around and eventually will be merged.

This device is used to control the Audio HUB сrossbar switch, for example it makes possible to use external i2s interfaces. https://github.com/elkoni/Opi_Zero_3_I2S3_5.4/blob/main/OpiZero3_I2S_3_mixer.JPG

Hi, the Armbian_community_24.5.0-trunk.563_Bananapi_jammy_current_6.6.30_xfce_desktop.img shows black screen after going to the desktop GUI (the LCD panel shows "no signal").. PS: The Armbian_23.11.1_Bananapi_jammy_current_6.1.63_xfce_desktop.img after an update/upgrade shows black screen after going to the desktop GUI (the LCD panel shows "no signal") as well.. The Armbian_22.11.0-trunk_Bananapi_bullseye_edge_5.19.6_xfce_desktop.img Armbian_23.8.2_Bananapi_jammy_current_6.1.51_xfce_desktop.img Armbian_23.11.1_Bananapi_jammy_current_6.1.63_xfce_desktop.img work.

Description phytium_embedded: update phytium u-boot binary to support 50Mhz SDIO WiFi. Phytium has not open-sourced the u-boot they use, so I have to use the non-free u-boot binary file they provide. How Has This Been Tested? [x] Successfully built. [x] System startup. Checklist: [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [x] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [x] Any dependent changes have been merged and published in downstream modules View the full article

Except what? You open up a flood door like that, you have to explain to op and hold his hand in how to find out what different users/groups are supposed to own different files. And since I have no idea what op has installed on his system, and how he did it, and what user he was when he did (sudo and root is NOT the same) I recommend op reinstall and do everything the correct way. Example from a system with docker running, nothing out of the ordinary. 3 cointainers the correct way, user in docker group and never using sudo with docker. $ sudo find . -group root -printf '.'| wc -c 153 153 files/directories just for root inside ~/. And this is only a quick search for root group, there are obviously other users and groups owning a whole bunch of stuff too. Probably a GREAT idea to "sudo chown -R 1000:1000 ~/"... Remember, op stated: And this is just an example of what can happen. Blows my mind an armbian admin thinks blindly taking ownership is a good idea... 😮

Oh, yes. This must also work. or "commit:xxxxxxxxxxxxxxxxx"

I meant this line: KERNELBRANCH="tag:v6.1.69" which uniquely determines which version of the kernel patches are applied cleanly. I.e. to version 6.1.69 and not to the current 6.1.90 for today.

in a normal case, files in your home directory should belong to you except ..

Hasn't changed. https://github.com/armbian/build/tree/main/patch/kernel Just symlinking of subfolder are perhaps adding some confusion.

Thank you soooo much Stephan. I realized my error. I had to add the patches with the expected root path. Which was linux6.6. So I had to add my patches here: ~/src/build/userpatches/kernel/sunxi-6.6/linux-6.6/ @sasa Thank you for showing us how to enable audio through the mixer.

@Charlie Romer Hi. Let's try to figure it out. Core panic - how is this problem solved? It is assumed that you have the kernel source code. You look at the kernel messages, and then using utilities like grep you find the function in the source code. The very function that could not cope and caused panic. This appears in the kernel panic messages. The first probable reason that led to this is that a patch was incorrectly applied to a file with this function. I.e. we are looking for all patches that modified this source code file. In fact, we will need to apply all the patches in the series to the source code in the core git repository. Apply as the "git am" command. We pay special attention to those patches that change our target file. Then we extract a series of our patches from the repository using a script and place it in the target patch folder. I.e., we replace the existing series with a new one, which is applied without offsets and fuzziness. The second reason is the changes in the upstream of the kernel that led to the situation our patch has aged. In this case, we are fixing this patch. We simply make our new changes to the fixation after applying the patch in the process of applying the series step by step. The complexity of the core panic situation in the Armbian project lies in the fact that it is impossible to reproduce this particular problem. Therefore, if you did everything as I wrote and made the necessary corrections from your point of view, then assembled the kernel and the panic repeated, you simply push your changes to your repository on github and only after that you can write here on the forum or ask a question here by specifying a link to your repository and the kernel version to which corrections have been applied. Only after that, the maintainer or the interested user will be able to check it. The third possible option is that the u-boot code does not match the kernel code due to their development. We may have to monitor this loader build process as well. @Igor Did I miss something? Where did the fixed kernel version go in these settings? How is the correct application of patches controlled today?

I'm using a few Libre Computer Renegades as headless servers, and they're working well (thank you!), but I'm wanting to set one up for personal use, and I've discovered that when I plug headphones into the analog audio jack, the left and right channels are reversed. (Also, the default volume, (for example, from speaker-test in a terminal) is too loud for headphones.) sudo armbianmonitor -u Says: System diagnosis information will now be uploaded to https://paste.armbian.com/Error adding document. so I've attached armbian-hardware-monitor.log instead. armbian-hardware-monitor.log

Did not work out sudo dtc -@ -I dts -O dtb -o /boot/overlay-user/st7789.dtbo st7789.dts added user_overlays=st7789 to /boot/armbianEnv.txt after a reboot the log constantly writes May 10 08:18:48 vm00 kernel: fb_st7789v spi0.1: fbtft_update_display: write_vmem failed to update display buffer May 10 08:18:48 vm00 kernel: fb_st7789v spi0.1: write() failed and returned -22 May 10 08:18:48 vm00 kernel: fb_st7789v spi0.1: write() failed and returned -22 Probably dts running on the previous firmware is not suitable for this one. my knowledge is not enough i use one spi for external device and for display spi-dev uses cs=0 display uses cs=1

@Joko Christian For the archive, go to the image download page for the orangepione and look at the line just below the image icons. It would be very useful to know how your system is failing. Could you describe what is running on the machine at the time it fails? Please provide output of: sudo armbianmonitor -u

I can confirm that new armbian-firmware make instabilities. (orange pi one board, Linux 6.6.16-current-sunxi) can someone point out the location of repository (3rd party is ok) of previous armbian-firmware releases ? I need to downgrade it from version 24.2.1 to version 21

This is what I've been trying to say the whole time... I know many distros are small projects with no full time developers. I saw in this thread that it looked like you guys could use some help and given how new this board is I wasn't expecting anyone to just solve something for me. I wanted to jump in and help if and where I could. What did you expect? Truth or fake happiness and prompt resolving of your problem? The opposite literally. I figured that if I have the ability to help and hardware in hand that I should help (or at least offer to be a guinea pig) - I wasn't and haven't been looking for someone to solve this thing for me but literally offering my assistance as I happen to have the hardware and wanted to give back if I could. This whole conversation has felt like I've been gaslit by people who assume everyone posting for the first time on this forum must be demanding fixes for everything right now. That may be many (or even most) folks but it's not a great feeling when all you're doing is trying to offer help.

@sasa I tested with your patch and it gets rid of the error but also creates a new sound device. ahubdam, that has no input or output. I then just took the device creation out of the dtb and then there is no error even without the patch. Analog and HDMI audio still work. This is the piece removed from the dtb. ahub_dam_mach { compatible = "allwinner,sunxi-snd-mach"; soundcard-mach,name = "ahubdam"; status = "okay"; phandle = <0x3f>; soundcard-mach,cpu { sound-dai = <0x0e>; }; soundcard-mach,codec { }; };