All Activity

Hi. I would like to know if someone can help me. I was successfully able to compile armbian 6.6.30 with all of @Stephen Graf patches for my orangepi zero 3 having Full Audio working even on HDMI. see below for reference. Now I have a 2nd project. It runs the h616 with 2GB DDR3 RAM with AXP313. Can someone help me with a patch for the AXP313 on h616. Or alternatively, could my h618 orangepi zero 3 setup work if I patch it to run with DDR3? If so where can I find such a patch. Thanks in advance.

main-config.sh: workaround: set the default ARCH to arm64 (replacing armhf) main-config.sh: workaround: set the default ARCH to arm64 (replacing armhf) armhf was disabled for some releases and now we get spurious failures building certain artifacts (firmware) Signed-off-by: Ricardo Pardini ricardo@pardini.net View the full article

based on the messages, it seemed you managed to load the overlay for w1-gpio perhaps venture further and connect a device appropriately ? based on the data sheet https://www.analog.com/media/en/technical-documentation/data-sheets/DS18B20.pdf (page 15, fig 15) it seeemed detection works by master (host) pulling down the line for 480 uS then pull that up again. then the chip would respond by first pulling it down, and after some 60-240 uS pull that up to inform the host of presence. it may take using specialized equipment like a scope / logic analyzer to probe those signals. for what is worth, and not trying to disappoint you, I think it is probably easier to connect the sensor to a (simple) microcontroller e.g. using uart and for the microcontroller to interface the sensor. the thing is for things related to timing, it may take going pretty much close to 'bare metal' e.g. work the on chip hardware to synchronize those signals, e.g. using pwm, spi etc. a h616 manual is found here https://linux-sunxi.org/images/2/24/H616_User_Manual_V1.0_cleaned.pdf if you want to venture there. uart on orange pi zero 3 is likely available in the standard configs without dts overlays.

I read again info https://docs.armbian.com/User-Guide_Allwinner_overlays/ and compile overlay by command: armbian-add-overlay w1-gpio.dts I see that in /boot/overlay-user/ is file w1-gpio.dtbo in /boot/armbianEnv.txt user_overlays=w1-gpio param_w1_pin=PC10 param_w1_pin_int_pullup=1 after this I reboot OZPI v3 after restart OZPIv3 I check dmesg info where found [ 4.990724] Driver for 1-wire Dallas network protocol. [ 4.997793] sun50i-h616-pinctrl 300b000.pinctrl: pin PC10 already requested by onewire@0; cannot claim for 300b000.pinctrl:74 [ 4.997833] w1-gpio onewire@0: gpio_request (pin) failed [ 4.997841] w1-gpio: probe of onewire@0 failed with error -22 cat /sys/kernel/debug/gpio gpiochip0: GPIOs 0-287, parent: platform/300b000.pinctrl, 300b000.pinctrl: gpio-76 ( |red:status ) out lo gpio-77 ( |green:power ) out hi gpio-80 ( |regulator-usb1-vbus ) out hi gpio-166 ( |cd ) in lo ACTIVE LOW gpio-210 ( |reset ) out hi ACTIVE LOW Can anyone help?

on debian distro : sudo nautilus This folder and dtb folder is the same folder it's just an short link

So I been doing some testing and audio through headphone jack "Line Out" works. I added a patch to enable line out in my dts. +&codec { + allwinner,audio-routing = + "Line Out", "LINEOUT"; + status = "okay"; +}; + You need to to enable it using the mixer. (thanks to sasa in the orange pie thread) /usr/bin/amixer -c 0 set 'Left Output Mixer DACL' 100% unmute /usr/bin/amixer -c 0 set 'Left Output Mixer DACR' 100% unmute /usr/bin/amixer -c 0 set 'Right Output Mixer DACL' 100% unmute /usr/bin/amixer -c 0 set 'Right Output Mixer DACR' 100% unmute Bluetooth has a bug where you need to enable bluetooth in android first before it can work with armbian.

Hi, I've tried to blacklist the driver, seemed stable but crashed after 2 weeks. At this point I don't know what else to try. For now i set kernel.panic=10 in /etc/sysctl.d/96-panic.conf to see if at least reboots when a panic happens.

Yes, that i did already. but this machine is supposed to work remotely and if I or for any reason, it reboots, it will never turn ON again if the SD card is not bootable.

Highlighting some of the key changes Collabora worked on with Valve to improve the system update tooling on SteamOS, including the move to Desync, making applying system updates significantly faster and more reliable. View the full article

You will need to boot the board then insert the SD card.

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 ?

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?