bes2600 driver
#21
I would try applying the patch with patch -p1 <  instead of git apply.
  Reply
#22
(11-19-2023, 11:59 PM)Kevin Kofler Wrote: I would try applying the patch with patch -p1 <  instead of git apply.

Thanks for the info. I tried that and this is what i got:

[explit@PineTab2 linux-pinetab2]$ patch -p1 < ../0001-Add-wake-for-WiFi.patch
patching file arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
Hunk #1 succeeded at 162 with fuzz 2 (offset 5 lines).
Hunk #2 succeeded at 180 (offset -96 lines).
Hunk #3 succeeded at 780 with fuzz 2 (offset -76 lines).
Hunk #4 FAILED at 935.
1 out of 4 hunks FAILED -- saving rejects to file arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi.rej
  Reply
#23
So then the idea would be to look at the .rej file, try to figure out why that hunk failed, and do the modifications manually.

Or you could try increasing the fuzz (passing -F3 to patch in addition to the other parameters), but it is probably a bad idea since context is important for .dtsi files. Better check the .rej file by hand.

Hunk 4 is a 1-line patch. It should not be too hard to make the change by hand.
  Reply
#24
(11-20-2023, 04:36 PM)Kevin Kofler Wrote: So then the idea would be to look at the .rej file, try to figure out why that hunk failed, and do the modifications manually.

Or you could try increasing the fuzz (passing -F3 to patch in addition to the other parameters), but it is probably a bad idea since context is important for .dtsi files. Better check the .rej file by hand.

Hunk 4 is a 1-line patch. It should not be too hard to make the change by hand.

Thanks for the Info. Here is the content of the
.rej file

Code:
--- arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
+++ arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -935,7 +949,7 @@ &sdmmc1 {
        cap-sd-highspeed;
        cap-sdio-irq;
        keep-power-in-suspend;
+       mmc-pwrseq = <&sdio_pwrseq &sdio_pwrkey>;
        non-removable;
        pinctrl-names = "default";
        pinctrl-0 = <&sdmmc1_bus4
--

This is the patch:
https://gitlab.com/arjanvlek/bes2600/-/b...type=heads

And this is the file, that should be patched:
https://github.com/dreemurrs-embedded/li...etab2.dtsi

As i understand, the line, which should be patched, doesn't exist in the rk3566-pinetab2.dtsi file.

I am not very familiar with patch, so if you can point me to the right direction - that would be great!

Thanks
  Reply
#25
Try applying the attached patch:

.txt   rk3566-pinetab2.dtsi-readd-wifi.patch.txt (Size: 1.79 KB / Downloads: 63)
before 0001-Add-wake-for-WiFi.patch. (You should apply both patches, mine first, then the other one.) My patch readds some WiFi-related blocks that were removed between v6.5.5-danctnix1 and v6.5.6-danctnix1.

Be warned that I do not know why those blocks were removed and that I have not tested the patches in any way. All I know is that the absence of those blocks is what makes the patch fail to apply, and I can only guess that the WiFi driver wants those blocks anyway, but as I said, I have not found any documentation on why they were removed. (There is not even a commit removing them. The commit adding the .dtsi was just redone without those blocks. So there is no history in which to check the commit messages.)
  Reply
#26
Thanks for the patch. I tried it. Your patch succeeded, the other one failed again on Hunk4
[explit@PineTab2 linux-pinetab2]$ patch -p1 < ../0000-Readd-Wifi_Patch.patch
patching file arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
Hunk #2 succeeded at 267 (offset 11 lines).
Hunk #3 succeeded at 857 (offset 14 lines).
Hunk #4 succeeded at 932 (offset 14 lines).
[explit@PineTab2 linux-pinetab2]$ patch -p1 < ../0001-Add-wake-for-WiFi.patch
patching file arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
Hunk #1 succeeded at 154 (offset -3 lines).
Hunk #2 succeeded at 284 (offset 8 lines).
Hunk #3 succeeded at 867 (offset 11 lines).
Hunk #4 FAILED at 935.
1 out of 4 hunks FAILED -- saving rejects to file arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi.rej


[explit@PineTab2 linux-pinetab2]$ cat arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi.rej
--- arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
+++ arch/arm64/boot/dts/rockchip/rk3566-pinetab2.dtsi
@@ -935,7 +949,7 @@ &sdmmc1 {
cap-sd-highspeed;
cap-sdio-irq;
keep-power-in-suspend;
+ mmc-pwrseq = <&sdio_pwrseq &sdio_pwrkey>;
non-removable;
pinctrl-names = "default";
pinctrl-0 = <&sdmmc1_bus4
--
  Reply
#27
You must be using a wrong version of the 0001 patch. I tried applying the one you linked to: https://gitlab.com/arjanvlek/bes2600/-/b...type=heads and it applies just fine to the file from v6.5.7-danctnix1 patched with my patch.
  Reply
#28
(11-21-2023, 10:44 PM)Kevin Kofler Wrote: You must be using a wrong version of the 0001 patch. I tried applying the one you linked to: https://gitlab.com/arjanvlek/bes2600/-/b...type=heads and it applies just fine to the file from v6.5.7-danctnix1 patched with my patch.

You are absolutely right, sorry, my mistake. Somehow my patch was broken. Thank you very much, now it worked!
  Reply
#29
(11-05-2023, 08:38 PM)459below Wrote: I just redid the procedure accordingly on mobian and it worked flawlessly.

Code:
root@mobian:~# uname -a
Linux mobian 6.6-rockchip #1 SMP PREEMPT_DYNAMIC Mon Oct 30 09:10:41 UTC 2023 aarch64 GNU/Linux
root@mobian:~# lsmod | grep bes
bes2600               253952  0
mac80211              888832  1 bes2600
cfg80211              835584  2 bes2600,mac80211

Wifi speed is the same as on arch. And on mobian it did not even hang on shutdown, i.e. clean shutdown. I am keeping my fingers crossed this is persistent and if so, I will surely include the module in the proper kernel module locations to be loaded normally during boot.

I wrote down a few notes on the differences to arch. I will prepare a MR on https://gitlab.com/arjanvlek/bes2600/-/b.../README.md with the Debian infrastructure approach to this. Like deb-src packages.

Hi, I'm interested for mobian. At the part clone "1.3 Setup kernel...-" which repository you cloned and what kernel did you use? Outside of these, the steps are same, i guess
  Reply
#30
Very interesting fact is, that every new boot, the bes2600 driver generate a new MAC-Address.
This is bad, because i have MAC-WhiteLists in my Router.

Hm, is this possible to force the driver use only one MAC-Address?
  Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)