76

(1,014 odpowiedzi, napisanych Sprzęt / Hardware)

Dodałem to :

/dev/mtd14 0x0 0x40000 0x20000

77

(1,014 odpowiedzi, napisanych Sprzęt / Hardware)

Ok, zrobię to i dam znać.

78

(1,014 odpowiedzi, napisanych Sprzęt / Hardware)

Mam wgrane kmod-mtd-rw i zrobiłem też ten plik w /etc/config co wyświetla informacje o fw_printenv.

79

(1,014 odpowiedzi, napisanych Sprzęt / Hardware)

No właśnie jestem na własnej kompilacji i od początku nie działa mi fw_printenv.

80

(1,014 odpowiedzi, napisanych Sprzęt / Hardware)

Mam pytanko, próbuję ustawić fw_setenv żeby było dostępne bootowanie z pena w razie czego, ale mam takie cuś:

MTD erase error on /dev/mtd14: Invalid argument Error: can't write fw_env to flash

Jak to teraz zrobić ?

81

(642 odpowiedzi, napisanych Sprzęt / Hardware)

Niestety, dokładnie tak jest i będzie, bo na ipq5018 nss nie działa poza oprogramowaniem które robią producenci.

82

(642 odpowiedzi, napisanych Sprzęt / Hardware)

W forku masz sterownik rmnet-nss, on wspiera akceleracje sprzętową i to on przerzuca większość pracy sieciowej na co-procesor nss. W czystym openwrt tego nie ma, więc wszystkie zadania sieciowe spadają na główny CPU. To jest to samo co w ipq80xx na AW1000, jak zrobisz sobię obraz z paczkami nss.

83

(642 odpowiedzi, napisanych Sprzęt / Hardware)

Próbowałem rózne kombinacje quectel-cm i luci-proto-quectel. O ile różne wersje quectel-cm działają, to luci-proto-quectel nie chcę z nimi działać, nie mam pojęcia dlaczego. A w kwestii osiągów, to praktycznie doszliśmy do ściany. Bez NSS nie ma mowy, że przebije się 450-500 download na modemie i zmniejszy zużycie procesora, to jest niemożliwe bez NSS niestety. Dlatego platforma IPQ5018 w porównaniu do Mediateka MT7981 wypada po prostu słabo.

84

(642 odpowiedzi, napisanych Sprzęt / Hardware)

Ogólnie ta wersja quectel-cm jest badziewna. To ona też ustawia użycie procka na jeden rdzeń. Trzeba będzie poszukać innych wersji, które obsługują też mhi.

85

(642 odpowiedzi, napisanych Sprzęt / Hardware)

A co do DNS-ów, to nie luci-proto-quectel takie ustawia, tylko sam quectel-cm, teraz sprawdziłem.

86

(642 odpowiedzi, napisanych Sprzęt / Hardware)

No ale właśnie, to się dzieje tylko podczas speed-testu. Jak ściągam np. torrent to zużycie cpu to maks 25 - 30 procent.

87

(642 odpowiedzi, napisanych Sprzęt / Hardware)

Sprawdziłem przed chwilą htop-em, i rzeczywiście podczas speed-testu przy pobieraniu użycie pierwszego rdzienia dobija do 100 procent. Co ciekawe, podczas wysyłania to się nie dzieje.

88

(642 odpowiedzi, napisanych Sprzęt / Hardware)

Ale ze sterami quectela działa na pci, tak jak w forku. Więc z nss byłoby więcej.

89

(642 odpowiedzi, napisanych Sprzęt / Hardware)

No właśnie ten sprzęcior działa u nas na sterach Quectela, na pci_generic nie działa. Ja download w Play mam 350-450, upload 150-200. Wiadomo że z nss było by więcej.

90

(642 odpowiedzi, napisanych Sprzęt / Hardware)

Ja chyba kupie jeszcze jedną sztukę i będę walczył z tym pci-generic. Ta co mam zostaje jak jest teraz na mhi_q.

91

(642 odpowiedzi, napisanych Sprzęt / Hardware)

Uprzejmie informuję, że paczki do quectela, które ci przesłałem, nie działają na kernelu 6.18 haha. Wiem, bo próbowałem je skompilować do BPI-R4 na snapshot, a tam już jest kernel 6.18.

92

(642 odpowiedzi, napisanych Sprzęt / Hardware)

Bo to chyba musi być odpowiednia kombinacja quectel-cm, luci-proto-quectel i sterownik pcie od quectela. Jutro może spróbuję to jakoś wrzucić na githuba to co ja użyłem.

93

(642 odpowiedzi, napisanych Sprzęt / Hardware)

No nie mów że to co ci podesłałem nie działa ? A jeszcze jedno, podczas robienia obrazu, usuń z configu kmod-rmnet, bo to konfliktuje z sterami quectela.

94

(642 odpowiedzi, napisanych Sprzęt / Hardware)

Pogrzebałem jeszcze trochę w logach i w pliku pci_generic.c. W sterownikach od quectela w logach pojawia się takie cos:

[   30.838683] [i][mhi0][mhi_dtr_probe] Enter for DTR control channel
[   30.838724] [i][mhi0][__mhi_prepare_channel] Entered: preparing channel:18
[   30.841481] [i][mhi0][mhi_dump_tre] carl_ev evt_cmd_comp code=1, type=33
[   30.841591] [i][mhi0][__mhi_prepare_channel] Chan:18 successfully moved to start state
[   30.841617] [i][mhi0][__mhi_prepare_channel] Entered: preparing channel:19
[   30.845220] [i][mhi0][mhi_dump_tre] carl_ev evt_cmd_comp code=1, type=33
[   30.845359] [i][mhi0][__mhi_prepare_channel] Chan:19 successfully moved to start state
[   30.845461] [i][mhi0][mhi_dtr_probe] Exit with ret:0
[   30.846694] [i][mhi_netdev_enable_iface] Prepare the channels for transfer
[   30.846754] [i][mhi0][__mhi_prepare_channel] Entered: preparing channel:100
[   30.873402] [i][mhi0][mhi_dump_tre] carl_ev evt_cmd_comp code=1, type=33
[   30.873802] [i][mhi0][__mhi_prepare_channel] Chan:100 successfully moved to start state
[   30.873831] [i][mhi0][__mhi_prepare_channel] Entered: preparing channel:101
[   30.883688] [i][mhi0][mhi_dump_tre] carl_ev evt_cmd_comp code=1, type=33
[   30.884434] [i][mhi0][__mhi_prepare_channel] Chan:101 successfully moved to start state
[   30.890633] [i][mhi_netdev_enable_iface] Exited.

W pliku pci_generic.c pod konfigiem modemu są kanały 100 i 101, ale nie ma 18 i 19 i nie wiem za co one odpowiadają. Może to jest przyczyna że ten modem nie chcę działać na generycznym sterowniku ?

95

(642 odpowiedzi, napisanych Sprzęt / Hardware)

https://filebin.net/s3g8db6hahzlku6i

Musiałem ci wystawić w pojedynczych plikach, bo całego folderu nie akceptowało.

96

(642 odpowiedzi, napisanych Sprzęt / Hardware)

Jak chcesz to mogę ci wystawić kombinacje jaką używam.

97

(642 odpowiedzi, napisanych Sprzęt / Hardware)

No ja też wszystko w LuCI, luci-proto-quectel pomógł.

98

(642 odpowiedzi, napisanych Sprzęt / Hardware)

No właśnie ja to zrobiłem bez QModem smile

99

(642 odpowiedzi, napisanych Sprzęt / Hardware)

OK, więc dotarło do mnie to urządzonko. Zrobiłem sobie obraz ze sterownikami Quectela i modem działa w trybie PCI. Napisałem już na forum OpenWRT, że problem w obrazie z ModemManagerem i sterownikiem mhi-pci-generic jest taki, że modem jest wykrywany w tym samym czasie jako modem PCIe i USB. W związku z tym wszystkie porty się time-outują. To by działało, jeśli podczas detekcji modem byłby widoczny tylko jako PCIe.

W końcu udało mi się rozwikłać problemy z modemami na pcie na kernelu 6.12 i 6.18 już też w BPI-R4. W kernel_menuconfig, w device drivers > pci należy wyłączyć ASPM i Advanced Error Reporting. To pomogło przy Foxconn T99W175 na pcie i powinno pomóc przy modemach na pcie.