Dodałem to :
/dev/mtd14 0x0 0x40000 0x20000Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
eko.one.pl → Posty przez lukasz3134
Dodałem to :
/dev/mtd14 0x0 0x40000 0x20000Ok, zrobię to i dam znać.
Mam wgrane kmod-mtd-rw i zrobiłem też ten plik w /etc/config co wyświetla informacje o fw_printenv.
No właśnie jestem na własnej kompilacji i od początku nie działa mi fw_printenv.
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 flashJak to teraz zrobić ?
Niestety, dokładnie tak jest i będzie, bo na ipq5018 nss nie działa poza oprogramowaniem które robią producenci.
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.
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.
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.
A co do DNS-ów, to nie luci-proto-quectel takie ustawia, tylko sam quectel-cm, teraz sprawdziłem.
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.
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.
Ale ze sterami quectela działa na pci, tak jak w forku. Więc z nss byłoby więcej.
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.
Ja chyba kupie jeszcze jedną sztukę i będę walczył z tym pci-generic. Ta co mam zostaje jak jest teraz na mhi_q.
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.
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.
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.
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 ?
https://filebin.net/s3g8db6hahzlku6i
Musiałem ci wystawić w pojedynczych plikach, bo całego folderu nie akceptowało.
Jak chcesz to mogę ci wystawić kombinacje jaką używam.
No ja też wszystko w LuCI, luci-proto-quectel pomógł.
No właśnie ja to zrobiłem bez QModem ![]()
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.
eko.one.pl → Posty przez lukasz3134
Forum oparte o PunBB, wspierane przez Informer Technologies, Inc