All Activity

@helix afaik, no tool for that. phandles are the way how kernel navigates the device tree. BTW, you may wish to try to enable box-wlan-ap6330 or box-wlan-ap6334 device tree overlay in /boot/armbianEnv.txt and see if you advance in getting bluetooth: broadcom chips have the need for some bits in the device tree to load the driver and attach the communication "bus" (which is usually a simple UART port). Also they are very similar chips. the driver is usually capable of handling the detection of features despite you declare a different chip in device tree. You can see the source of the ap6330 overlay here And yes, you definitely need to enable the led-conf3 because the dtb declares that your board definitely has a rk805 PMIC: that's why the photo of the board is heavily suggested in the first page to get help.

Description After testing, it was found that Firefly-RK3399 cannot boot using the mainline device tree due to issues with the PMU (Power Management Unit). Even after fixing the PMU problem, Bluetooth still cannot be used. Therefore, the original patch has been optimized by removing unnecessary parts. How Has This Been Tested? [x] Almost all hardware functions(HDMI, WiFi, BT, GbE, USB...). [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

Cannot tell for sure since I do not have this board. However I would use a multimeter and measure the voltage between the outer pins to determ which is GND and which is 5V. Then I'd hook ground to ground and randomly connect rxd and txd. The chances are 50:50 to get it right the first try. If there is no output, swap rxd and txd and try again.

@going thank you for your time - I tried your suggestion and got this ../fix-6.6.30-version.patch diff: unrecognized option '--git' diff: Try 'diff --help' for more information. ../fix-6.6.30-version.patch: line 2: index: command not found ../fix-6.6.30-version.patch: line 3: ---: command not found ../fix-6.6.30-version.patch: line 4: +++: command not found ../fix-6.6.30-version.patch: line 5: @@: command not found ../fix-6.6.30-version.patch: line 7: syntax error near unexpected token `)' ../fix-6.6.30-version.patch: line 7: ` current)

Hi Werner, thanks a lot for your recommendations. I finally found some time to go back to the issue. I bought a CP2102 USB UART Adapter as you recommended in your video. The Odroid h1 has a Molex 5268-04a coonncetor mounted on its PCB. In the "ODROID Port description of UART Connector" (https://wiki.odroid.com/accessory/development/usb_uart_kit) the pins are described like follows. However, on the board itself the pins are not marked. I would not want to destroy anything here. Do you know which is which? _____UART____ |Pin 4 - VCC| |Pin 3 - RXD| |Pin 2 - TXD| |Pin 1 - GND| \___________| BTW: In the manual (https://magazine.odroid.com/wp-content/uploads/odroid-xu4-user-manual.pdf#page=7) the baud rate is specified with 115200.

lib & config: give shellcheck directions (to /dev/null for dynamic, to repo-relative path for static) for all sourced references lib & config: give shellcheck directions (to /dev/null for dynamic, to repo-relative path for static) for all sourced references in preparation for tightening the shellcheck severity level it needs to be able to follow all sources; dynamic ones are ignored, static ones need root-relative prefix View the full article

t95z: add board file (and u-boot 2024.04) for T95Z Plus Amlogic tvbox t95z: add board file (and u-boot 2024.04) for T95Z Plus Amlogic tvbox we've had kernel patches/DT (from chewitt) for this in meson64 for a long time, but I never sent the board uses blobs for the tartiflette-s912 which is also an DDR3 S912 (VIM2's blobs are DDR4 and won't boot) this adds u-boot 2024.04 support, using chewitt's DT & 000.patching_config.yaml & a specific BOOTPATCHDIR this is a full board as-if it was an SBC, and expects to boot from mainline u-boot; for that to work you've to wipe the eMMC and get rid of the vendor-supplied u-boot if this is not what you want/need, you can use the aml tvbox "board" instead, together with Android u-boot View the full article

khadas-vim3: fix stray closing brace in board file khadas-vim3: fix stray closing brace in board file a stray closing brace, meant for the function, that ends up doing the wrong config change View the full article

"OLED stats working also in debian, you need to activate I2C5 M3 overlay in orangepi-config" By doing above, do you still need to execute point #1 (add overlay) from original instructions?

try https://github.com/armbian/build/pull/6610

@JohnTheCoolingFan neither am I familiar with much of that. I'd just like to say that H618 support evolves out of H616 and the DTS for Orange Pi Zero 3 and Zero 2W is contributed by Andre Przywara from 6.6 mainline kernel. But that various contributors here worked the DTS further, check in the thread for details. Note that there are also change in *u-boot* for Orange Pi Zero 3, mainly to add the PMIC and DDR4 support for Orange Pi Zero 3 I think some key difference between Orange Pi Zero 2 (H616) vs Orange Pi Zero 3 (H618) are : - PMIC the power management IC is different - Orange Pi Zero 3 uses lpddr4 vs Orange Pi Zero 2 lpddr3 various other 'small' differences and that H618 is after all based on H616 codebase. Hence, my guess is to attempt to use the 6.6 and up mainline kernel and do a rebuild for CB1. One thing I'm not sure is where to configure that so that the build would use the 6.6.x mainline kernel during the build. It would likely 'not build cleanly' (e.g. without errors) and the build errors especially if the 'old' patches for the same board is applied and those would need to be resolved. You would take into account the actual hardware differences vs Orange Pi Zero 2 or Orange Pi Zero 3 if after all they are different on the CB1.

Description Issue reported from radxa's forum: https://forum.radxa.com/t/the-changable-wifi-interface-name-of-rock-5c-lite/20921 Rock5c has an onboard aic8800 usb wifi/bt module, which has random wifi interface name by default, which will cause non-static connection name created by networkmanager. How Has This Been Tested? Please describe the tests that you ran to verify your changes. Please also note any relevant details for your test configuration. [x] PREFER_DOCKER=no ./compile.sh kernel BOARD=rock-5c BRANCH=vendor BUILD_DESKTOP=yes BUILD_MINIMAL=no DEB_COMPRESS=xz KERNEL_CONFIGURE=no RELEASE=jammy KERNEL_GIT=shallow DESKTOP_APPGROUPS_SELECTED= DESKTOP_ENVIRONMENT=gnome DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base Checklist: Please delete options that are not relevant. [x] My code follows the style guidelines of this project [x] I have performed a self-review of my own code [ ] I have commented my code, particularly in hard-to-understand areas [x] My changes generate no new warnings [ ] Any dependent changes have been merged and published in downstream modules View the full article

You will only get the resolution that you TV is capable of supporting. I always use high quality cables.

@ Hqnicolas The network card is still unable to receive data, and the reason is unclear. In the past, connecting the network port was a simple task, but now it seems very difficult😂 [ 25.313329] rk_gmac-dwmac fe010000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 25.318206] rk_gmac-dwmac fe010000.ethernet eth0: PHY [stmmac-1:00] driver [Generic PHY] (irq=POLL) [ 25.321898] dwmac4: Master AXI performs any burst length [ 25.324480] rk_gmac-dwmac fe010000.ethernet eth0: No Safety Features support found [ 25.327033] rk_gmac-dwmac fe010000.ethernet eth0: IEEE 1588-2008 Advanced Timestamp supported [ 25.329956] rk_gmac-dwmac fe010000.ethernet eth0: registered PTP clock [ 25.333601] rk_gmac-dwmac fe010000.ethernet eth0: configuring for phy/rmii link mode

Sorry - I am probably the only one who is interested in network performance using the 2.5G interface (theoretical max 2.35Gbit/s). (iperf3.17.1 measurements attached, download and upload) # ./iperf3 -c 192.168.240.30 -p 5201 Connecting to host 192.168.240.30, port 5201 [ 5] local 192.168.240.54 port 54011 connected to 192.168.240.30 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.01 sec 284 MBytes 2.37 Gbits/sec [ 5] 1.01-2.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 2.01-3.01 sec 281 MBytes 2.36 Gbits/sec [ 5] 3.01-4.00 sec 278 MBytes 2.34 Gbits/sec [ 5] 4.00-5.01 sec 280 MBytes 2.34 Gbits/sec [ 5] 5.01-6.01 sec 281 MBytes 2.36 Gbits/sec [ 5] 6.01-7.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 7.01-8.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 8.01-9.01 sec 281 MBytes 2.36 Gbits/sec [ 5] 9.01-10.01 sec 281 MBytes 2.35 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.01 sec 2.74 GBytes 2.35 Gbits/sec sender [ 5] 0.00-10.01 sec 2.74 GBytes 2.35 Gbits/sec receiver iperf Done. # ./iperf3 -c 192.168.240.30 -p 5201 -R Connecting to host 192.168.240.30, port 5201 Reverse mode, remote host 192.168.240.30 is sending [ 5] local 192.168.240.54 port 54013 connected to 192.168.240.30 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.01 sec 276 MBytes 2.30 Gbits/sec [ 5] 1.01-2.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 2.01-3.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 3.00-4.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 4.01-5.01 sec 280 MBytes 2.35 Gbits/sec [ 5] 5.01-6.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 6.00-7.01 sec 281 MBytes 2.35 Gbits/sec [ 5] 7.01-8.00 sec 280 MBytes 2.35 Gbits/sec [ 5] 8.00-9.01 sec 281 MBytes 2.35 Gbits/sec [ 5] 9.01-10.01 sec 280 MBytes 2.35 Gbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.01 sec 2.74 GBytes 2.35 Gbits/sec 16 sender [ 5] 0.00-10.01 sec 2.73 GBytes 2.35 Gbits/sec receiver iperf Done.

-Clean, remove params for old kernel -Add option to disable usb autosuspend -Add display console replace rootdev with "LABEL=armbi_root" to boot from sd card an emmc with same boot.ini View the full article

to use RK3568 DTS on RK3566 chip you will need to add these lines on the botom of dts &gpu_opp_table { /delete-node/ opp-800000000; }; &dmc_opp_table { opp-324000000 { opp-hz = /bits/ 64 <324000000>; opp-microvolt = <875000>; }; opp-528000000 { opp-hz = /bits/ 64 <528000000>; opp-microvolt = <875000>; }; }; &cpu0_opp_table { /delete-node/ opp-1992000000; opp-216000000 { opp-hz = /bits/ 64 <216000000>; opp-microvolt = <825000 825000 1150000>; clock-latency-ns = <40000>; }; opp-312000000 { opp-hz = /bits/ 64 <312000000>; opp-microvolt = <825000 825000 1150000>; clock-latency-ns = <40000>; }; }; /delete-node/ &combphy0_us; /delete-node/ &gmac0_clkin; /delete-node/ &gmac0_xpcsclk; /delete-node/ &gmac0; /delete-node/ &gmac_uio0; /delete-node/ &pcie30_phy_grf; /delete-node/ &pcie30phy; /delete-node/ &pcie3x1; /delete-node/ &pcie3x2; /delete-node/ &qos_pcie3x1; /delete-node/ &qos_pcie3x2; /delete-node/ &qos_sata0; /delete-node/ &sata0;

I don't have neither of these boards, but I can help answering any question regarding state of the art drivers in mainline kernel.

After releasing the button, then remove the power and plug the power back in. What happens then? Also what dtbs have you tried?

The moment it gives an image that says android, I stop pressing the button. No, I have never installed another OS before.

I have tried every one of the latest 24.x images on my newly purchased LaFrite s805x-ac board. NONE worked. They all gave an error about overwriting reserved memory. I randomly chose a 20.x image and it worked immedaitely. I do not currently have time to do further analysis.

🤯 Is there a tool to convert hex pointers (phandle) to human readable names when doing dtc -I dtb -O dts? For example, in original dtb file I have: io-domains { compatible = "rockchip,rk3328-io-voltage-domain"; status = "okay"; vccio1-supply = <0x29>; vccio2-supply = <0x2a>; vccio3-supply = <0x29>; vccio4-supply = <0x2b>; vccio5-supply = <0x29>; vccio6-supply = <0x29>; pmuio-supply = <0x29>; phandle = <0xa3>; }; where <0x29> is: RK805_DCDC4 {}

If you are getting the android recovery you are holding the reset button too long. Have you ever installed and/or run any other OS on this box other than the preinstalled android?

I've only worked with the BPI-M4-ZERO. My personally opinion on the h616/8 line up is that the focus should be on stable and not LTS. Little to none of the official mainline patches are being back ported and the patches being used currently in LTS are kind of hack-a-noodle patches. For example: https://lore.kernel.org/linux-arm-kernel/CA+E=qVeMnQNrT8tNnHBnCL2Efy3VjbRAYQGMXstziCThRsiBDw@mail.gmail.com/T/ https://lore.kernel.org/linux-arm-kernel/20240419071450.7aiheeoyq35yjoo7@vireshk-i7/T/ The ones being currently used in Armbian I believe are either RFC's or taken from OPI. The thermal patch above is already in 6.9.y. But with that said, if you have any questions feel free to hit me up and if I can, I'll help.

[ LINUXFAMILY='rockchip64' ] Try to freeze the kernel version for the target family. Apply this patch to the build system itself. fix-6.6.30-version.patch cd /mnt/music/Armbian/build ls ../fix-6.6.30-version.patch ../fix-6.6.30-version.patch git status git restore file1 file2 .... git pull patch -p1 -i ../fix-6.6.30-version.patch Put the patch in a /mnt/music/Armbian/ folder. Check the status and if there are modified files, do the following: git restore "list files" All this is for the main branch P.S. Try to make an assembly. And please post the log.