alexc

@Sand_Death Really interesting read! Would it be possible to submit these changes through GitHub or as a kernel patch? We'd love to see the full context of the changes—the code actually provides such a clear picture of what's happening (even more so than the docs!), so a proper review of the diff would be great. EDIT: Looking at the description, it seems Claude addressed the issue on the Hailo driver side rather than fixing it in the PCIe driver. Personally, I don't think that's the ideal approach, since the BSP PCIe driver appears to be the root cause. If you get a chance to try my patch instead, I'd be interested to hear how it works for you.

Hi @Sand_Death, Thanks again for identifying the MSI issue. I've just updated my branch with some MSI-related changes. I tried to align the implementation as closely as possible with the Raspberry Pi 5 PCIe driver. Could you give it a try and let me know whether it resolves the issue on your end? I'm now seeing additional MSI interrupts being generated by my NVMe drives. https://github.com/alexcaoys/allwinner-bsp/commit/a9eaa51dace582a15b1a3a7380f588cd31e06a54#diff-63112d28b443d435556e546cdc59423df248d8f963a80b15680a52ae67f1cf1c That said, I still believe there are some significant issues in the PCIe driver. For example, I think it causes my NVMe SSD to overheat when used with a board also based on the ASM1182e. Please keep an eye on whether you observe similar behavior with your Hailo-8 as well. If the HAILO_DRIVER_TIMEOUT issue still persists after testing this change, could you also attach your dmesg output? Thanks!

Hi @Sand_Death, Thanks a lot for identifying this! Could you please check if this also happens on the kernel provided by Radxa? If it works on their side, it's likely something we need to address in our configuration. Since PCIe is still handled by the vendor's BSP, if it's a bug on their end, it would be best to open an issue with Radxa first. I'm happy to take a closer look once I have some time later.

@Jacob GeorgeThat's excellent progress, thanks for sharing! EDK2 support on the A733 would be a very welcome addition, and it's great to hear the port is moving along so quickly. One thing that would be especially valuable for the community is if some of the platform work could eventually be drafted as mainline kernel patches/drivers. That would save a lot of development effort and benefit everyone using these boards.There are already a few A733 patches in 7.x or in the queue. Looking forward to seeing the project reach the finish line.

@Marvin-03 You're probably right—it may be worth checking the FPC connection. A timeout usually only occurs when the PCIe/NVMe board is not being detected. I'm currently using an early MCUZone NVMe 2230 HAT. I recently ordered a new Waveshare AIO HAT as well, so once it arrives I'll be able to do some additional testing.

@Marvin-03 Just to confirm: for both boards, with and without eMMC, are you using the same microSD card as the boot device? From the current boot log, it looks like there may be an issue with the microSD card. Both the previous boot log (using the BSP MMC driver) and the current boot log (using the mainline MMC driver) show problems detecting mmc0 (the microSD card). Could you try a different microSD card, preferably from another brand, and see if the issue persists?

Hi @Marvin-03, could you try the latest build? It looks like your board is still using the BSP MMC driver, but we migrated to the mainline MMC driver last week. That should at least resolve the issue you're currently seeing. Also looking forward to your testing on the eMMC side, since the A7Z does not have eMMC support.

OK, it looks like the BSP PCIe driver might have some issues related to power management. I’m not entirely sure of the root cause yet, but when I connected an NVMe drive, it got extremely hot and failed to initialize properly. The NVMe dmesg output suggested adding the following kernel parameters: nvme_core.default_ps_max_latency_us=0 pcie_aspm=off This resolved the NVMe issues on my side. I’ll try to dig deeper into the root cause, but @humanus please give it a try as well.

My board is A7Z so unfortunately I couldn't fully test the Ethernet drivers. Hi @qq20739111 / @humanus, any luck with the on board Ethernet? FYI, my new version utilizes mainline MMC drivers as well. And I'm looking into PCIE at the moment.

@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.