alexc

@qq20739111 1. The logs show the Ethernet link repeatedly going up and down, but without any explicit errors. Could you double-check whether the cable and related hardware are in good condition? Does the same cable work properly with your other laptops/devices? Since I don’t have an A7A/S board myself, and there are no clear errors in the logs, I’m not entirely sure what’s causing it. Hopefully others can help test as well. 2. The logs also contain many messages like: [ 216.539249][ T97] sunxi:sunxidrm:[INFO]: [EDP_INFO]: drm_edp->desc->connector_type: 10 [ 216.547367][ T97] sunxi:sunxidrm:[INFO]: [EDP_INFO]: drm_edp->hpd_state_now: 0 This usually means the display could not be detected, or that it isn’t providing an HPD signal. I’d suggest trying a native USB-C to DisplayPort adapter or cable instead. As for the RAM issue, unfortunately since this is a DIY-modified board, it’s difficult to determine exactly what’s going wrong. @humanus I'll test the PCIE later. But in the meantime, could you also take a look at these? Probably helpful. https://github.com/geerlingguy/raspberry-pi-pcie-devices/issues/430 https://github.com/geerlingguy/raspberry-pi-pcie-devices/discussions/756

Hi @qq20739111, In the log, DP looks fine to me, maybe you can try plug in / out a few times? The display is not that stable to be honest. As for the ethernet, I think @Nick A didn't update the config so the driver is still not built into the kernel (https://github.com/NickAlilovic/build/blob/Radxa-mainline-WIP-a7s/config/kernel/linux-sun60iw2-edge.config). You can build by yourself (just enable CONFIG_AW_STMMAC_ETH)

@humanus That's something we might need to work on next. I only have a M.2 board but my Raspberry Pi is using it right now. Let me see if I can use it to test later. So PCIE definitely works on 5.15/6.6, right? Your log doesn't really say where it crashes. For the GPU, what's the GPU? I don't think we built the kernel with any PCIE GPU drivers enabled, so that might be a potential problem. @Wintermute The same thing goes to the SATA. It's possible your PCIE to SATA controller is not supported/enabled in the kernel config (This applies to any kernel version).

@humanus I took a second look at the log, I think it's probably due to the enabled eMMC. EDIT: I added the emmc part to my A7Z dts, it also crashes... So that's definitely the root cause. I disable it for A7S in my repo for now, you can compile it yourself with a Linux 6.18 kernel or wait for Nick. By the way A733 eMMC seems to use the same eMMC driver as A523, so probably mainline already supports it.

@humanus Thanks, just noticed the log. Interestingly looks like it's the mmc part. A few things I can think of: 1. emmc is only presented on A7A/S, so if you are using emmc or your board has an emmc, it might be a problem. You can try to disable sdc2 on device tree and see if it works. 1. sd card part is the same on A7A/S/Z, but I don't think my card is a UHS-II card. Looking at the log, it might be doing something with UHS-II, so it might be worth trying a different SD card to see if it behaves differently. If it does turn out to be related to UHS-II handling, I can look into a proper fix later. on.

Hi @qq20739111, Thanks for testing! It looks like your system may be getting stuck during boot. The SHA256 hash will change every time you rebuild the image. The best way to debug this is by connecting to the UART console, since it should show exactly where the boot process is failing. That said, I’ve also made some updates to the 6.18 kernel, including changes for the A7A and A7S device trees, along with enabling the Ethernet port. Unfortunately I don’t have either an A7A or A7S on hand, so I haven’t been able to test those changes myself. Nick hasn’t updated the Armbian build yet, but you can also try building the kernel yourself and manually replacing the kernel image and DTBs in the /boot directory for testing.

@Dalibor Pospíšil I haven't tested if the pcie works, maybe others did? But it's a bsp driver so it should. If that works, and if the SATA device has a driver in Linux 6.18, simply enable it in menuconfig and you should be good to go. EDIT: Right, I don't have A7A so I didn't really touch the dts for A7A, there might be a little works needed for it to boot.

@eli I think I’ve got KVM enabled, but as they discussed previously, it's not a Linux kernel issue, there's some specific u-boot firmware needed. Since I don't think the open source firmware is ready yet, I guess KVM likely is not feasible on A733 for now.

Hi @xuyitao, My repository is focused on moving toward a usable mainline kernel. As of this week, there are no longer any dependencies on BSP NPU drivers. I plan to remove those, along with the BSP GPU drivers, to avoid any potential confusion. Could you take a look at the mainline etnaviv driver? Hopefully it meets your needs.

Hi all, Over the past few months working on the A7Z, I’ve successfully ported a number of BSP drivers to Linux 6.18. The code is available here: https://github.com/alexcaoys/allwinner-bsp/tree/linux-6.18.y It’s currently tested on 6.18.19 and should, in theory, work with newer 6.18.y releases. I’ve tried to reuse as much upstream (mainline) drivers as possible, and have also upstreamed support for PCK600 and ET7304 used on the A7Z. Hopefully this helps accelerate ongoing mainline efforts. Feedback, issues, and PRs are very welcome. I may also look into creating branches for Linux 7.x in the future.

@Nick A No problem. Thanks for your Armbian build as well! I am also looking forward to mainline. Currently I still didn't find open source Mesa driver for Allwinner BSP, GLES is only available as pre-compiled binary for Debian (haven't tested it but it's in the Radxa images). There already are mainline Mesa/Linux IMG GPU supports so I hope things can be ported to mainline soon. Please let me know if anyone finds the source code for Mesa BSP.

@Nick A Oh yeah, I did change a few things as well for type c. Maybe the drm heap changes are not needed after all. Looking at my changes. husb311 is now under drivers/power/typec, so just enable it. et7304 is not included in the original bsp, radxa team added them later so simply apply this same patch. https://github.com/radxa/allwinner-bsp/commit/156b6578cc173855b41ea311a229403ccbadb17c

@Nick A @Bones558 Hi there, I am not sure if that's definitely due to DRM heap. But I fixed that driver and it could be built now. I didn't know if USB C DP works or not before but it is working now (on a USB C monitor, maybe needs a few re-plug). I opened a PR on Radxa allwinner-bsp github (https://github.com/radxa/allwinner-bsp/pull/11), you can also test it out.

I have a Radxa Zero 3E and was facing the same issue. Since RK3566 is a stripped down version of RK3588. I figured the quirks on RK3588 might be able to apply to RK3566 as well. The issue seems to be fixed now after I implemented these quirks taken from rk3588-base.dtsi on top of rk356x-base.dtsi. tested on Linux 6.17.9 and 6.18.0-rc7(Armbian linux-edge-rockchip64) usb_host1_xhci: usb@fd000000 { compatible = "rockchip,rk3568-dwc3", "snps,dwc3"; reg = <0x0 0xfd000000 0x0 0x400000>; interrupts = <GIC_SPI 170 IRQ_TYPE_LEVEL_HIGH>; clocks = <&cru CLK_USB3OTG1_REF>, <&cru CLK_USB3OTG1_SUSPEND>, <&cru ACLK_USB3OTG1>; clock-names = "ref_clk", "suspend_clk", "bus_clk"; dr_mode = "host"; phys = <&usb2phy0_host>, <&combphy1 PHY_TYPE_USB3>; phy-names = "usb2-phy", "usb3-phy"; phy_type = "utmi_wide"; power-domains = <&power RK3568_PD_PIPE>; resets = <&cru SRST_USB3OTG1>; snps,dis_u2_susphy_quirk; + snps,dis_enblslpm_quirk; + snps,dis-u2-freeclk-exists-quirk; + snps,dis-del-phy-power-chg-quirk; + snps,dis-tx-ipgap-linecheck-quirk; status = "disabled"; }; If anyone else has other RK356x devices please try it out and I think it would be nice if someone could submit a patch to mainline kernel dts.

I am trying to use radxa-zero with HDMI CEC support on Armbian debian. I tried all different Armbian debian versions, lsmod never give me module cec So I took a look at images provided by radxa (https://github.com/radxa-build/radxa-zero/releases/tag/20220801-0213, not armbian ones), cec is loaded by default I think this is the key: /lib/modules/SOME_KERNEL/kernel/drivers/media/cec/core/cec.ko This is in their image but not /lib/modules/6.1.11-meson64 folder (I guess also not in other kernel versions) If that's the case, CEC should not work on any meson64 devices. I saw CONFIG_CEC_CORE=y is in config. btw, another possible related missing module is meson_dw_hdmi.ko Could someone take a look and figure out why they are not there? Really appreciate your help!