c0rnelius

@iav nice. Yeap. One fixes topology and the other pcie performance. Tested on the BananaPi BPI-CM4

https://lore.kernel.org/linux-amlogic/20251127170908.14850-1-18255117159@163.com/T/#t https://lore.kernel.org/linux-amlogic/176397825606.3590190.10935817124468233062.b4-ty@linaro.org/T/#t

Short of KIckPi opening a contract with Armbian and providing the units they want worked on. I don't see how?

I haven't personally had issue with 6.17.y, but 6.18.y is a mess on meson-g12. It is basically unusable in my opinion. PCIe is hosed, even the patch that kind of fixes the issue just makes the error go away and doesn't fix the underlining problem "performance". I also get topology errors, but as I haven't really seen anyone yet complain about that, I'm assuming its me. For my personal use, I will be sticking with 6.12.y until things get sorted.

The v2 uses a diff wifi chip: SKW wifi module VS6621S I have a patch for it, which came from KICKPI in the deb builder, but... I don't have a V2 to work any magic on it. chuanzz at one point contacted KICKPI and they sent him an archive that had a bunch of Armbian adds in it, including the patches and board.confs. But the HDD I had the archive on got erased by mistake, so yeah... I don't have the info anymore. I don't see the K2B REV2 getting official support here or by me, as its using a wifi chip that is just to obscure. Here is a u-boot-v2025.07 binary for the K2B REV2 u-boot-sunxi-with-spl.bin

If you are using the radxa-pkg github "which is the most up-to-date" know that its hardcoded to point to specific firmware. To get around this you need to create a file: This example is for an SDIO variant using the radxa dkms package cat > /etc/modprobe.d/aic8800-wireless.conf <<- EOT options aic8800_fdrv_sdio aicwf_dbg_level=0 custregd=0 ps_on=0 options aic8800_bsp_sdio aic_fw_path=/lib/firmware/aic8800_fw/SDIO/aic8800 EOT Also note that the AIC8800 firmware located in armbian-firmware is kind of old and probs not compat with the radxa builds.

Ur welcome.

Ok. Also I think these are wrong for the PI5: dtoverlay=disable-wifi dtoverlay=disable-bt I believe it's: dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 My notes on this: # Pi3 / ZERO2W dtoverlay=pi3-disable-wifi dtoverlay=pi3-disable-bt # PI5 dtoverlay=disable-wifi-pi5 dtoverlay=disable-bt-pi5 # Everything else dtoverlay=disable-wifi dtoverlay=disable-bt Back in the day, I read somewhere that Bluetooth can inhibit serial from functioning correctly on the Pi's. I've never seen it happen, but maybe using the wrong overlay is hindering it in some way? Worth looking into.

Does it work when you remove that HAT?

Same deal using Noble; https://paste.armbian.com/orexafoxen.less

I installed a fresh Trixie img to SD, made the adjustments I suggested, booted, upgraded and rebooted. root@rpi5b:~# ls /dev/ttyAMA* /dev/ttyAMA0 /dev/ttyAMA10 Still there.

Without it being enabled in the config.txt file `ttyAMA0` isn't visible under /dev, last I checked. pibox: ~ $ cat /boot/firmware/config.txt | grep "enable_uart*" enable_uart=1 pibox: ~ $ ls /dev/ttyAMA* /dev/ttyAMA0 /dev/ttyAMA10 I wouldn't use `raspi-config` on an img that isn't RASPIOS. I feel that is bound to produce failure.

Give serial priority console=tty1 console=serial0,115200

The /boot/firmware/cmdline.txt requires: console=serial0,115200 The /boot/firmware/config.txt requires: enable_uart=1 That's it.

Here is everything I have been able to piece together from the web. Maybe something in there would be helpful? https://github.com/pyavitz/binary/releases/download/060420/KICKPI.zip

Post a dmesg and sudo gpioinfo https://paste.armbian.com/

Looks like the same thing REV 1.1 uses. My guess would be the GPIO or PINCTRL may be different on the REV2. The problem is the schematic only shows 1.0 / 1.1 You could try shooting them an email in an attempt to obtain the v2 schematic? Without it, you would just be guessing.

Nice.

I was just about to post a binary with something similar. So does the above work for you? I was gonna try this: CONFIG_DRAM_SUNXI_DX_ODT=0x03030303 CONFIG_DRAM_SUNXI_DX_DRI=0x0e0e0e0e CONFIG_DRAM_SUNXI_CA_DRI=0x1f12 CONFIG_DRAM_SUNXI_TPR0=0xc0001002 CONFIG_DRAM_SUNXI_TPR10=0x2f1107 CONFIG_DRAM_SUNXI_TPR11=0xddddcccc CONFIG_DRAM_SUNXI_TPR12=0xeddc7665 CONFIG_MACH_SUN50I_H616=y CONFIG_SUNXI_DRAM_H616_DDR3_1333=y CONFIG_DRAM_CLK=648

Change the loglevel to 7 in the armbianEnv file and if anything comes up after Starting kernel ... post it.

Another problem here is that they don't have a schematic available for the rev2. They may have changed more than the DRAM? So the first u-boot I posted could have been fine, but the kernel DTS may need adjusting. Oh NVM. You did post the schematic EDIT: Not helpful. Its the same schematic I already have, which was incorrect as the variant I purchased is using DDR4. Not sure whats up with this company but they aren't very good at providing proper sources or essential unit information.

Try this one. I unfortunately I haven't been able to find any other timings. Hopefully this simple change makes a diff. u-boot-sunxi-with-spl.bin

There is another DDR3 option. GIve me a bit and I'll post it.

I've got a REV 1.1. Try flashing the binary. I got the timing from the opi zero2 Make sure you flash it to the correct node, be it mmcblk1, sdb, etc. sudo dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblkX conv=fsync bs=1024 seek=8 u-boot-sunxi-with-spl.bin

If it isn't the PSU or SD than I'm not sure. The only REV available in the STATES "which is where I am" is the 2GB. The u-boot patch set is identical to the BPI-M4-Zero "minus the dts and defconfig of course". All my testing has been done with the unit I have available to me. It works with the Armbian, KIckpi and my own personal builds. As an aside the Kickpi web site is down for me STATE side. Not sure what that means? Doesn't look good though. Anyway, I'm out of ideas. Sorry.