Przejdź do treści forum
eko.one.pl
OpenWrt, Linux, USB, notebooki i inne ciekawe rzeczy
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Aktywne tematy Tematy bez odpowiedzi
Opcje wyszukiwania
Cezary napisał/a:Nie mam pojęcia. W samym dts nie są zdefiniowane w innym miejscu.
Cezary,
dziękuję za Twoje zaangażowanie i błyskawiczne odpowiedzi. Przez kilka dni męczyłem ten temat na jednym z urządzeń i wszystko wskazuje na to, że pomimo, iż ap3915 ma stosowny moduł radiowy, to jednak producent zabezpieczył to na poziomie sprzętowym przez użyciem radia dla protokołu Zigbee. Odpuszczam sobie próby uruchomienia Zigbee, a Tobie jeszcze raz bardzo dziękuję.
Pozdrawiam
Cezary napisał/a:Są takie same jak były. Wygraj obraz na czysto jeszcze raz, tam jest tylko uart2 włączony na gpio 8, ,9, 10, 11 i nic więcej
Cezary,
próbowałem uruchomić obraz przez TFTP korzystając z pliku .itb (initramfs). Niestety, on również wpada w pętlę restartów dokładnie w tym samym momencie (zaraz po zainicjowaniu UART-ów). Oznacza to, że problem nie leży w partycjach rootfs na flashu, ale w samym kernelu/DTS. Wygląda na to, że aktywacja uart1 na tych pinach powoduje natychmiastowy reset procesora (Watchdog). Czy to możliwe, że te piny są już używane przez jakiś inny krytyczny kontroler w tej rewizji AP3915i?
Pozdrawiam
Wielkie dzięki, Cezary.
Mamy sukces i porażkę jednocześnie! Port ttyMSM1 w Twoim obrazie wstaje poprawnie ([ 1.039532] 78b0000.serial: ttyMSM1...), więc DTS jest już chyba OK. Niestety system wpada w pętlę restartów zaraz potem. Ostatnie linie logu:[ 1.131325] mtd: partition "rootfs" doesn't start on an erase/write block boundary -- force read-only.
Wygląda na to, że kernel 6.12 przesunął granice partycji rootfs i system nie może jej zamontować. Czy mógłbyś zerknąć na offsety partycji dla AP3915i w tym nowym wydaniu?
Pozdrawiam
Cezary, dzięki za błyskawiczną odpowiedź.
Sprawdziłem to i faktycznie w tym DTS, który podlinkowałeś, jest konflikt. &blsp1_uart1 (linia 111) odwołuje się do serial_pins, które (linia 169) siedzą na GPIO 16 i 17. Konsola (&blsp1_uart0) też ich używa. Przez to w systemie mam tylko /dev/ttyMSM0. Czy wiesz może o jakimś obrazie sysupgrade, w którym UART1 dostanie własne piny (z tego co widzę w sieci dla tego modelu, powinny to być GPIO 8 i 9) lub mógłbyś przygotować dla mnie testowy? Bardzo by mi to pomogło ruszyć z tym Zigbee.
Kilka Extreme AP3915i kupiłem za groszę i używam od jakiegoś czasu w domu. Mam też całą sieć urządzeń Zigbee i kiedy dowiedziałem się, że te AP mogą również obsługiwać Zigbee to bardzo mnie to zainteresowało. Niestety z wiedzą fachową zatrzymałem się jakieś 30 lat temu więc pomoc Twoja lub Kolegów z forum będzie dla mnie chyba jedynym ratunkiem.
Pozdrawiam
Cześć,
Mam problem z uruchomieniem modułu IoT na Extreme Networks WS-AP3915i pod kontrolą OpenWrt.
Chciałbym wykorzystać wbudowany układ nRF52832 jako koordynator Zigbee (np. pod Zigbee2MQTT), ale w standardowych obrazach (23.05) port szeregowy połączony z tym modułem jest niewidoczny.
Moja obecna sytuacja: System widzi tylko /dev/ttyMSM0 (konsola). W /sys/bus/platform/drivers/msm_serial/ jest tylko adres 78af000.serial.cat
/sys/kernel/debug/gpio pokazuje, że piny 8-11 (UART1) mają status func0 (zwykłe GPIO), co oznacza, że port UART1 jest wyłączony w Device Tree. Próby ręcznego exportu GPIO z uwzględnieniem offsetu (412) nic nie dają bez aktywacji kontrolera w kernelu. Czy ktoś z Was posiada lub mógłby przygotować obraz (najlepiej sysupgrade) z odpowiednim patchem na DTS, który ustawia status = "okay" dla &blsp1_uart1?
Będę wdzięczny za każdą pomoc lub nakierowanie na właściwy plik .bin.
Z góry dzięki!
Znalezione posty: 5