Remove unused ESP8089 firmware [V42]

[DavisNT]

The firmware is not used, because Batocera's RK3326 kernel:
https://github.com/shantigilbert/hardkernel-linux/blob/d167de7358c9c53d5e6592978f7cdde7674c420b/drivers/net/wireless/esp8089/esp_main.c#L178
uses different file names than in the repo referenced in this package: https://github.com/jwrdegoede/esp8089/tree/38cb0c10d70754392932a52d9335a29eed9c3b94/firmware

As this is a minor cleanup, it should probably go into v42.

[dmanlfc]

i'm not sure about this as i added the firmware for a specific device that required that firmware for working wifi.

[DavisNT]

@dmanlfc Which device was it? And are you sure adding this firmware actually fixed the wifi?

Looks like this firmware was added in dfc611b (commit text is "add missing esp8089 firmware for rk3326") and this is around 4 months after wifi on RK3326 boards was broken by batocera-linux/buildroot@2ae792d .

I.e. Looks like at the time of adding this firmware wifi on RK3326 boards was actually broken due to a completely different reason - missing wpa_supplicant_k44 package.

P.S. AFAIK ESP8089 firmware is embedded in kernel files eagle_fw1.h, eagle_fw2.h and eagle_fw3.h

[dmanlfc]

the report from the user suggested their wifi was fixed, hence i added it.
the dmesg also outlined it was looking for the specific firmware filename in the package which is different from the kernel as highlighted.

does it cause a conflict? if not, let's keep it for now.

[DavisNT]

@dmanlfc Awesome! These might be much better news than initially seems!

Looks like:

1. Whel searching batocera.linux folder after RK3326 build (make rk3326-cleanbuild of commit d58b6d5 plus all my PRs) for eagle_fw_ (grep -r "eagle_fw_" .) the only found file is ./dl/armbian-firmware/git/.git/index.
2. When booting the official batocera-rk3326-41-20241109 build (that contains ESP8089 firmware and does not contain wpa_supplicant_k44 - just like at the time when ESP8089 firmware was added) and invoking ifconfig wlan0 up and iw wlan0 scan, the string eagle_fw_ cannot be found in the output of dmesg.

Seems like the user who contacted you is using a different kernel! Do you have any other explanations?
If this kernel connected to a wifi without wpa_supplicant_k44 package (if it worked with wpa_supplicant 2.10) then most likely it is newer than 4.4.
I think this can be very relevant for moving Batocera to 6.x kernel for RK3326 boards. 👍 🐧

Can you please ask the user:

1. Whether a different kernel is intentionally used?
2. What other distros had been installed on the microSD card currently used for Batocera?
3. What is the contents of boot.ini in the root of FAT32 partition?

P.S. No - these files don't cause any conflicts as they are not used by the current Batocera "stock" kernel.
P.P.S. The same files (with the same names and the same content) are already in the armbian-firmware package.

davis@bb:~/batocera.linux$ find . -name "*eagle_fw_*" -exec sha256sum {} \;
3ac55633c7c9aa2a0025072a597a19550450bf954d63befe789aeef2b25cfd24  ./dl/armbian-firmware/git/eagle_fw_second_init_v19.bin
8f2f3f1fe623e1fe0d4aa1376b4bb6a129479cea9bce6374855b4cec19ac1687  ./dl/armbian-firmware/git/eagle_fw_ate_config_v19.bin
1b8b7f93f40d3c2dd7ab7f3e2d29cd118604249a5926a320163bf358254e4162  ./dl/armbian-firmware/git/eagle_fw_first_init_v19.bin
3ac55633c7c9aa2a0025072a597a19550450bf954d63befe789aeef2b25cfd24  ./output/rk3326/build/armbian-firmware-5d685ad233b4dfd03a4d025fa0061f6b0f850cb3/eagle_fw_second_init_v19.bin
8f2f3f1fe623e1fe0d4aa1376b4bb6a129479cea9bce6374855b4cec19ac1687  ./output/rk3326/build/armbian-firmware-5d685ad233b4dfd03a4d025fa0061f6b0f850cb3/eagle_fw_ate_config_v19.bin
1b8b7f93f40d3c2dd7ab7f3e2d29cd118604249a5926a320163bf358254e4162  ./output/rk3326/build/armbian-firmware-5d685ad233b4dfd03a4d025fa0061f6b0f850cb3/eagle_fw_first_init_v19.bin
davis@bb:~/batocera.linux$

[dmanlfc]

Actually, now that I think about it, it could have been before we backtracked on mainline back to the 4.4 kernel. So it could be that the firmware files were required at the time. I've had a lot of sleeps since then ;-) We'll need to explore / experiment with a LTS 6.x kernel at some stage for future ease of support.