search

kobolabs / Kobo-Reader

http://www.koboereader.com/
604 stars 126 forks source link

dhd.ko module incompatible with self-compiled kernel #105

Open tux-linux opened 3 years ago

tux-linux commented 3 years ago

I've recompiled a kernel from the imx507 sources for a Kobo Mini and Kobo Touch. All is fine but the wi-fi module doesn't want to cope with that kernel. I compiled the other modules using make modules and they work, no problem. I can get USBNet with g_ether and mass storage with g_mass_storage. I've used this tarball here (https://github.com/kobolabs/Kobo-Reader/blob/master/hw/imx508/ntx/bcm-dhd-falcon-5901132-03112011.tgz) and compiled the module for the kernel. Haven't seen any other one for imx507, so I assume it is compatible both with imx508 and 507. insmod works fine.

kobo:/# insmod /modules/dhd.ko
kobo:/# insmod /modules/sdio_wifi_pwr.ko

But when I try to bring the device up, either with wpa_supplicant, iproute2 or ifconfig, it fails:

kobo:/# ifconfig -a
eth0      Link encap:Ethernet  HWaddr ---
          BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          LOOPBACK  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

usb0      Link encap:Ethernet  HWaddr ---
          inet addr:192.168.2.2  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:381 errors:0 dropped:0 overruns:0 frame:0
          TX packets:189 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:34306 (33.5 KiB)  TX bytes:37527 (36.6 KiB)

kobo:/# ifconfig eth0 up
ifconfig: ioctl 0x8914 failed: Operation not permitted
kobo:/#

Any ideas? Thanks

/proc/version: Linux version 2.6.35.3-inkbox (nicolas@debian) (gcc version 4.8.1 20130401 (prerelease) (crosstool-NG linaro-1.13.1-4.8-2013.04-20130417 - Linaro GCC 2013.04) ) #126 PREEMPT Fri Apr 2 13:47:28 EDT 2021

tux-linux commented 3 years ago

It's been almost 1 month... No one has a clue? Thanks

moghingold commented 3 years ago

I found this link, the info in it seems old and OP never confirmed whether or not it ultimately worked, but the responses seemed pretty detailed: http://www.mobileread.mobi/forums/showthread.php?t=215303

tux-linux commented 3 years ago

I found that one too and it didn't work, sadly.

tux-linux commented 3 years ago

@moghingold Actually, I retried today and it worked. I needed to include the firmware shipped in /lib/firmware from the stock rootfs in the /lib/firmware directory of my InkBox rootfs. The interface went up without issue.

tux-linux commented 3 years ago

Reopening because it still does not work.

[root@kobo ~]# insmod /drivers/ntx508/wifi/sdio_wifi_pwr.ko 
[root@kobo ~]# insmod /drivers/ntx508/wifi/dhd.ko 
[root@kobo ~]# ifconfig eth0 up
[root@kobo ~]# ifconfig -a
eth0      Link encap:Ethernet  HWaddr 00:90:A2:25:8E:89  
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

lo        Link encap:Local Loopback  
          LOOPBACK  MTU:16436  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:0 (0.0 B)  TX bytes:0 (0.0 B)

[root@kobo ~]# iwlist eth0 scanning
eth0      Failed to read scan data : Resource temporarily unavailable

[root@kobo ~]#

This is on the stock firmware, with stock kernel and modules. It does the same thing on InkBox's rootfs. Interestingly enough, when Nickel launches, it has no problems with iwlist, so something is missing there. @gtalusan Does that ring a bell? Is there some further hardware initialization I should do before trying to scan networks? This was tested on a Kobo Touch N905B. Thanks.

gtalusan commented 3 years ago

🤣 When I saw this had closed, I was thinking that some neglect had let the grass on this lawn flourish.

Use wlarm_le. strace is your friend!

tux-linux commented 3 years ago

It was not easy indeed. This is probably the worst Wi-Fi driver I've ever dealt with. So, yeah, wlarm_le up works. Thanks. I'll see on InkBox if it gives any other error and close this issue if not.

tux-linux commented 3 years ago

And ... no.

kobo:/home/user# dhcpcd eth0
no such user dhcpcd
dhcpcd-9.4.0 starting
DUID 00:01:00:01:28:83:4a:8a:00:90:a2:25:8e:89
eth0: IAID a2:25:8e:89
eth0: soliciting a DHCP lease
dhcp_openbpf: eth0: Protocol not available
dhcp_openbpf: eth0: Protocol not available
eth0: probing for an IPv4LL address
arp_new: Protocol not available
dhcp_openbpf: eth0: Protocol not available
dhcp_openbpf: eth0: Protocol not available
timed out
dhcpcd exited
dhcpcd_fork_cb: truncated read 0 (expected 4)
kobo:/home/user#

Strangely enough, using udhcpc or dhclient works, but it isn't a fit for my use-case since the rootfs is read-only and those two like to write random temp files for resolv.conf in /etc.

gtalusan commented 3 years ago

It looks good from my house.

tux-linux commented 3 years ago

Yes, dhcpcd worked on the stock OS. Not on my rootfs though. I'll see if I can stick with udhcpc and set the default nameserver to CloudFlare's...

tux-linux commented 3 years ago

It decidedly doesn't want to let me go... Rebuilt the module for imx507 (i.e. Touch, Mini, Glo et. al) and tested on a Glo. I took the relevant /lib/firmware files (rtecdc.bin, nvram.txt) from the stock OS and I put them on my rootfs. I get the same ifconfig: ioctl 0x8914 failed: Operation not permitted error as before. Is there something I'm missing? Is there an imx507-specific quirk that isn't in the sources?

Here's the kernel's ring buffer when I load the module:

[  303.262758] Wifi / BT power control 1
[  303.378897] cd_status=0 inserted
[  303.628838] cd_status=0 inserted
[  303.628851] cd_status=0 inserted
[  303.832475] mmc2: queuing unknown CIS tuple 0x80 (2 bytes)
[  303.833999] mmc2: queuing unknown CIS tuple 0x80 (3 bytes)
[  303.835515] mmc2: queuing unknown CIS tuple 0x80 (3 bytes)
[  303.838236] mmc2: queuing unknown CIS tuple 0x80 (7 bytes)
[  303.841259] mmc2: queuing unknown CIS tuple 0x80 (8 bytes)
[  303.842475] mmc2: queuing unknown CIS tuple 0x80 (2 bytes)
[  303.844593] mmc2: queuing unknown CIS tuple 0x80 (5 bytes)
[  303.846712] mmc2: queuing unknown CIS tuple 0x80 (5 bytes)
[  303.875386] mmc2: new high speed SDIO card at address 0001
[  306.651095] F1 signature read @0x18000000=0x1591a962
[  306.653908] DHD: dongle ram size is set to 245760(orig 245760)
[  306.686875] dhdsdio_write_vars: Download, Upload and compare of NVRAM succeeded.
[  307.178857] dhdsdio_htclk: HT Avail timeout (500000): clkctl 0x50
[  307.178877] dhd_bus_init: clock state is wrong. state = 1
[  307.178903] dhd_bus_start failed bus is not ready
[  307.181757] eth0: Broadcom Dongle Host Driver
[  307.182631] 
[  307.182637] Dongle Host Driver, version 5.90.113.2
[  307.182641] Compiled in drivers/net/wireless/kobo_bcmdhd on Jul 15 2021 at 19:57:45
gtalusan commented 3 years ago

Make sure you choose the right nvram.txt. If my repressed traumas are correct then the recoveryfs scripts will point nvram.txt to the correct one for the various devices.

tux-linux commented 3 years ago

Fine, I'll check, though I took nvram.txt that was in the stock Glo factory image. Thanks again

tux-linux commented 3 years ago

Where would you find this in the scripts? I don't see it anywhere. Even did grep -r on the whole recoveryfs for nvram.txt and found nothing. Here are the contents of (stock rootfs) /lib/firmware/wc121. I see no symlinking of nvram.txt at all.

nicolas@gentoo-linux /m/upgrade> ls /tmp/koboroot/lib/firmware/wc121/ -l
total 720
lrwxrwxrwx 1 nicolas nicolas     16 Oct 15  2012 fw_bcm43362a0.bin -> rtecdc.bin.WC121
lrwxrwxrwx 1 nicolas nicolas     20 Oct 15  2012 fw_bcm43362a0_mfg.bin -> rtecdc_mfg.bin.WC121
lrwxrwxrwx 1 nicolas nicolas     18 Oct 15  2012 fw_bcm43362a2.bin -> rtecdc.bin.WC121A2
lrwxrwxrwx 1 nicolas nicolas     22 Oct 15  2012 fw_bcm43362a2_mfg.bin -> rtecdc_mfg.bin.WC121A2
-rwxr-xr-x 1 root    root       682 Jul 11  2012 nvram.txt
lrwxrwxrwx 1 nicolas nicolas     16 Oct 15  2012 rtecdc.bin -> rtecdc.bin.WC121
-rwxrwxr-x 1 nicolas nicolas 177373 May 10  2012 rtecdc.bin.WC121
-rwxrwxr-x 1 nicolas nicolas 180076 May 28  2012 rtecdc.bin.WC121A2
lrwxrwxrwx 1 nicolas nicolas     20 Oct 15  2012 rtecdc_mfg.bin -> rtecdc_mfg.bin.WC121
-rwxrwxr-x 1 nicolas nicolas 181845 May 10  2012 rtecdc_mfg.bin.WC121
-rw-rw-r-- 1 nicolas nicolas 187126 May 10  2012 rtecdc_mfg.bin.WC121A2

And here are the contents of /lib/firmware/wc121/nvram.txt:

# Copied from bcm94336sdg.txt, same WLBGA pkg, same control logic.
manfid=0x2d0
prodid=0x492
vendid=0x14e4
devid=0x4343
boardtype=0x0598

# Board Revision is P207
boardrev=0x1207

boardnum=777
xtalfreq=26000
boardflags=0xa00
sromrev=3
wl0id=0x431b
macaddr=00:90:4c:07:7${maclo12}
aa2g=1
ag0=2
maxp2ga0=74
ofdm2gpo=0x44111111
mcs2gpo0=0x4444
mcs2gpo1=0x6444
pa0maxpwr=80
pa0b0=5447
pa0b1=-658
pa0b2=-175
pa0itssit=62
pa1itssit=62
cckPwrOffset=4
ccode=0
rssismf2g=0xa
rssismc2g=0x3
rssisav2g=0x7
triso2g=0
noise_cal_enable_2g=0
swctrlmap_2g=0x04040404,0x02020202,0x04040404,0x010101,0x1ff
temp_add=29767
temp_mult=425
temp_q=10
initxidx2g=45

EDIT: there was also a specific nvram file for a board PCB, I think it was E60Q90 or something like that, which didn't work either.

gtalusan commented 3 years ago

Looks like you have an earlier revision that didn't split them out further. You should be fine with the default nvram.txt and firmware from the rootfs partition in that case.

tux-linux commented 3 years ago

Then, something is wrong. Nothing's going fine ;p I'll try again to see if it was just bad luck. EDIT: nope, same error.

akemnade commented 2 years ago

about dhcpcd: is there some CONFIG_BPF in the kernel missing? Or is your dhcpcd just too new for that old kernel?

tux-linux commented 2 years ago

There isn't any CONFIG_BPF option set. I ended up getting DHCP working anyway by switching to BusyBox's udhcpc client, which does the job correctly too.