afiftyp

DRAM settings extracted from the Android image Thx, I'll try the dts change.

I'm currently working on a Tanix TX6 board (no s printed on the housing). On the backside it sates TX6-P. It seems to have a H618 chip but DDR4 Ram and brcmfmac43342 wifi module. Originally I thought that the box is plain H6 based as I wanted exactly the TX6 as it is supported by LibreELEC. Bad luck with that kind of chameleons ☹️ So far I managed to configure a u-boot that has the DDR4 support by taking some orangepi as an example. As a starting point for armbian I used the transpeed-8k618-t.dtb and that allows me to boot (in most cases). Occasionally the kernel crashes very early after start. I also had to add a patch to the kernel to support the wifi chip; the firmware is already in the armbian firmware package. So far hdmi, wifi, Bluetooth, 100m Eth, and the USB3 port is working. The 2 USB2 ports aren't. Other things I didn't test to far. Need to further dig into the Android fdt to see how it is configured there.

Interesting, my Magcubic H618 board shows a similar issue since i got wifi working completely independent of this patch. On every reboot the brcmfmac4330 wifi module fails to initialize but the Bluetooth part is OK. On every power cycle both modules initialize correctly. Instead of So I have some doubt that the root cause of the problem is from the patch.

Hi @Nick A, there is a typo in v20241125/patch/u-boot/u-boot-sunxi/dts-Transpeed-8K618-T-Add-Transpeed-8K618-T-board-support.patch It adds sun50i-h618-transpeed-8k618-t.dts to the Makefile instead of .dtb

Here is a change to support 32k osc on H616/H618 by using the new driver clk/sunxi-ng/ccu-sun6i-rtc.c instead of retrofitting the code into drivers/rtc/rtc-sun6i.c ccu-sun6i-rtc.c needs to be compiled into the kernel instead of being a module. Additionally it need to announce "osc32k-out" instead of "osc32k". There is a diff file that changes the kernel config and the patches to perform and the patch file that changes the driver to place in patch/kernel/archive/sunxi-6.7/patches.armbian/ Move_32k_osc_diff.patch drv-clk-sunxi-ng-use-osc32k-out.patch

Nick, i can do a patch, but I really would like to understand why this change makes it work. In the end it would be less patching. Our sun50i-h618-transpeed-8k618-t.dtb does not have "osc32k" nor "osc32k-out" so i don't think it is dtb related. To try it, it is two additional changes: - change kernel config to CONFIG_SUN6I_RTC_CCU=y - remove the tree patches: patches.armbian/drv-rtc-sun6i-support-RTCs-without-external-LOSCs.patch patches.armbian/drv-rtc-sun6i-Add-Allwinner-H616-support.patch patches.armbian/Code-to-enable-Internal-OSC-Clock-Auto-Calibration.patch rtc-sun6i.c is still in place but it simply calls the new code in drivers/clk/sunxi-ng/ccu-sun6i-rtc.c as it no longer finds a usable RTC. Unfortunately I do not have a H616 to test how it behaves here.

The kernel people are not really happy with the patch to introduce the RTC auto calibration. The right way to go is using the existing code from the newer sunxi-ng source instead of adding the H616/H618 into the drivers/rtc/rtc-sun6i.c. I have to admit that I only partially understood the code in both places. Unfortunately the current code in drivers/clk/sunxi-ng/ccu-sun6i-rtc.c ends up with a completely unreliable box. Crashes and hangs during startup and only occasionally a successful boot. To get around that I have to patch ccu-sun6i-rtc.c the following way: My problem is that I have no idea why this change works Any idea is welcome.

one important point on the BT module is that the frequency setting in the xxxxx-sdio.txt needs to match the speed of the oscillator sitting beside the BT module. There seem to be to common frequency's, 26 and 37.4 MHz. My transpeed uses "xtalfreq=26000". The corresponding link is: brcmfmac4330-sdio.transpeed,8k618-t.txt -> brcmfmac-ap6330-sdio.txt

A bss138 FET or something similar can be used.

I found that my board directly connects AXP313A pin15 (ALDO1) to pin 22 of the BT/wifi module. No idea why changing makes a difference on your board. Which BT firmware is used on your device? For BT BCM4330B1.hcd is loaded. It is part of the standard armbian-firmware package. For wifi the links are in https://forum.armbian.com/topic/29794-how-to-install-armbian-in-h618/?do=findComment&comment=186733

On my board it does not matter if I change "vddio-supply" to be 3.3V in the bluetooth section of the dtb. On pin 22 of the BT/wifi module I still have 1.8V. From that finding there is no need to make a separate armbian build. I think the voltage setting for the module is done by the broadcom brcmfxxxx driver and not by the bluetooth code. As a test I removed both xxx-supply lines from the bluetooth section of the dtb and it still works. Can you also try that?

yep, my Bluetooth also works with 3.3V but I want to measure the voltage on the board tomorrow.

The data sheet for my AP6330 is available on the net. It specifies: VBAT min: 3.0V typ: 3.6V max: 4.8V VDDIO min: 1.2V typ: 1.8V max: 2.9V+/-3% From that 3.3 or 3.6 should both work. Maybe you can try and add the following to bluetooth in your DTS: brcm,requires-autobaud-mode;

Don't be surprised to see the GPIO names in the second column, I have temporarily extended the DTB to include them temporarily for better readability. I used gpioset to toggle IO and check with a DMM on the wifi/bt module. Why does your BT come up on hci1? Is there another one on USB?

Hi Nick, thanks for adding the patches. I updated from git, recompiled the image and wrote it to SD. All is as expected. Here is my bluetooth output from dmesg: I thick communication with the BT module is not coming up on your board because otherwise there should be a message line BCM: chip id xx. My suspicion would be that some of the BT control signals are connected to different GPIO or UART on your hardware. I have used the gpio utilities to identify the ports (without bluetooth being in the device tree).