brcmfmac firmware #46
Comments
|
7Ji/linux-firmware-orangepi-git But it should come pre-installed? |
|
7Ji/linux-firmware-orangepi-git is installed. I tried reinstalling it, but there was no change. This problem does not seem to occur when using orangepi-xunlong's bcmdhd.ko. The preinstalled bcmdhd.ko does not work. |
What do you mean by "using orangepi-xunlong's bcmdhd.ko"? How did you use a kernel module built for a different kernel? The kernel shouldn't even accept drivers not built against it. But that reminds me.. The current firmware package "linux-firmware-orangepi-git" is using orangepi's firmware tree as upstream and only packs those not existing in "linux-firmware". It's totally legitimate that Joshua uses a different version of the bcmdhd driver in their kernel their that relies on a newer firmware. |
|
Try |
I think it was consistent because it was when I was using the I replaced the firmware with linux-firmware-joshua-git, but now it seems that the wifi device is not recognized anymore (it does not show up in If Perhaps https://github.com/Joshua-Riek/ubuntu-rockchip is using this kernel and firmware, so I'll compare it to this. |
|
This is a driver issue, ive been trying to work on a dkms package as a workaround, but this driver is terrible. I'm close to fully disabling the WiFi and Bluetooth device tree nodes as this is ridiculous. |
|
But it's mentioned that brcmfmac works on other devices like Rock Pi 4b and Radxa Zero 2, which also utilize the ap6256 chip. What differentiates these devices from the Orange Pi 5 Pro in terms of brcmfmac compatibility? |
|
I suspect Orange Pi is using a different hardware variant that is not compatible. Someone could also try backporting brcmfmac. |
|
The However, in the case of ubuntu-rockchip, the drivers are loaded correctly on the first boot, while this kernel seems to encounter errors even on the first boot. Is this due to differences in the kernel build configuration, or are there other changes specific to the ubuntu-rockchip kernel that are not included in this one? |
As far as how I wrote the image packer, there's no such concept of "first boot" for my ALARM images, as there's no such concept in either upstream ALARM or Arch, and I don't want to introduce non-mainline logic. So your first boot on the images here are conceptually the same as all later boots on them. My doubt is that the initcpio in ubuntu-rockchip is using a similar config to generic Ubuntu and it would load as many drivers as possible, mitigating some key drivers not built-in for the core peripherals. For Arch mkinitcpio with "fallback" config pretty much does that similarly, but I'm using booster and it tries not to pre-load too many drivers. Here it's very likely that bcmdhd-sdio being a badly modified -pcie driver does not have a correct sdio dependency and sdio bus is not even initialized. |
|
After some investigation, it seems that The issue of the Therefore, I believe that the reboot logs mentioned the use of the default MAC address because of this. By executing Additionally, Bluetooth was made functional by using brcm_patchram_plus, which is used in ubuntu-rockchip. I have one final query. How can I integrate wiringOP into Arch Linux? I have attempted to install it directly from Thank you for your assistance. |
|
@jamstec0 I have WiringOP packaged for my Ubuntu Rockchip project and can help with compiling / installing if needed. Are you able to provide the exact steps you took to produce the error? |
In order to build wiringPi for the rootfs, I ran these commands: However, upon executing these commands, I encountered the following errors: These errors did not occur in previous builds. There may be a missing package. |
|
A quick hack would be adding I can't look at the source code right now, but the error is triggered due to a return with no value, a safe bet would be to return 0 on wiringPi.c:7212. Again, this may be incorrect as I can't look at the code right now, but it should get you passed the compile error. |
|
That would need to be fixed to a |
|
I see there was such a change. The build went well, and I think the GPIOs are working just by setting BOARD=orangepi5pro in /etc/orangepi-release. Anyway, I think everything is working now. Since the Arch Linux kernel for Orange Pi originally had a defect where the NPU didn't work, this is all thanks to both of you. Thank you very much. |
|
|
|
It seems that the previous issue might have been resolved, but after several shutdowns, I am unable to connect to Wi-Fi. Moreover, I cannot determine the cause of this error at all. Previously, I had experienced sudden connectivity issues like this, but reinstalling the OS resolved them. The brcmfmac driver seems to be loading correctly, and the hardware itself appears to be functional as it worked with the Ubuntu-rockchip image. wpa_cli: nmcli: Additionally, when installing NetworkManager, the following error occurred: |
|
I tested NetworkManager on a newly installed Arch Linux, but the same |
|
Please open another issue and attach a log with kernel cmdline argument Moreover, open at https://github.com/7Ji-PKGBUILDs instead of here, if this problem only affects |
I am using
linux-aarch64-rockchip-bsp6.1-joshua-gitkernel on orange pi 5 pro. ap6256 does not seem to work withbrcmfmac.The
brcmfmacdriver is loaded.However, I am getting errors due to lack of firmware.
Do you know where this firmware file is located?
Or do I need to create it?
The text was updated successfully, but these errors were encountered: