Signed-off-by  chyba popraw, bo wygląda jak pozostałość z Ctrl-C/Ctrl-V

Małe OT: sprawdziłem w logach i niestety, poza standardowymi osobami robiącymi mirrory tylko 8 różnych IP pobrało sobie obrazy dla LBR20. Nie wiem czy ciekawości, czy faktycznie mają ten router, ale może ktoś właśnie sprawdza się odezwie z feedbackiem.

Sysupgrade działa, ale jak masz kabel w lan2 to będzie migał na czerwono po restarcie. Także wyjąć kabel z lan2, sysupgrade, niech się zrestartuje i możesz podłączyć. Przynajmniej przy domyślnych zmiennych bootloadera.

Tak, władowali to jakiś czas temu.

Czy w MIFI , w pasmach LTE , Restart połączenia coś ma robić ? Bo wygląda jakby się nic nie działo...

Ale jak robię ifup wan z terminala , to mi się Liczba wznowień połączenia zwiększa , ping przestaje na chwilę działać , no i najważniejsze , widzę to w logu , a naciśnięcie tego przycisku nic takiego nie robi....

Kolega Chorwat zaczął się wyżywać na PR
M.n, chce usunięcia labeli z LEDów.... To jak to będzie wyglądać i jak później odróżnić , jak wszystkie się później będą wyświetlać w /sys/class/leds/ jako LED_FUNCTION_STATUS ?

No i pyta się dlaczego taki mały rozmiar kernela i czy nie dało się go w ubi zrobić....

No i co po nich wyjdzie w /sys/class/leds/  ?

Poźniej est takie coś:

    soc {
        rng@22000 {

I do tego mam już dodać jakieś labels ..... Jakie ?

No tak , i u nas tylko tu label wynika z linii function i lini status , a tu po usunięciu label tworzy się takie coś:

root@OpenWrt:~# ls /sys/class/leds/
ath10k-phy0     blue:status     green:status    green:status_1  red:status      red:status_1    white:boot
root@OpenWrt:~# 

Trzeba tm u górze jakąś funkcję wymyśleć .... Może faktycznie LED_FUNCTION_BOOT ,jak dla białej ?

No i skąd ten led ath10k-phy0 się utworzył ?

EDIT: , i jeszcze w sumie LED_FUNCTION_BACKLIGHT dla tych obi się mi rzuciła w oczy

Ok , a w tych następnych punktach ?

&tlmm {
    mdio_pins: mdio_pinmux {
        mux_1 {

i tu komentarz " mdio "

i dalej

        bias-pull-up;
        };

        mux_2 {

I tu komentarz : " mdc "

Coś zamienić ?

Ok , zerknijcie czy te poprawki są ok ...

Jeszcze się pytał dlaczego taki mały kernel , no i czy kernel w ubi bootloader nie odczytuje...

Obraz sysupgrade jest chyba przygotowany w zły sposób. Obecnie jest zdefiniowany tak:
- w Device/DniImage

    IMAGE/sysupgrade.bin := append-kernel | pad-offset 64k 64 | append-uImage-fakehdr filesystem | \
        append-rootfs | pad-rootfs | check-size | append-metadata

- w Device/netgear_orbi

    IMAGE/sysupgrade.bin/squashfs := append-rootfs | pad-to 64k | \
        sysupgrade-tar rootfs=$$$$@ | append-metadata

Może sprawdzicie coś takiego:

define Device/netgear_lbr20
    $(call Device/netgear_orbi)
    DEVICE_MODEL := LBR20
    NETGEAR_BOARD_ID := LBR20
    NETGEAR_HW_ID := 29766182+0+256+512+2x2+2x2+2x2+1
    KERNEL_SIZE := 3932160
    BLOCKSIZE := 128k
    PAGESIZE := 2048
    UBINIZE_OPTS := -E 5
    IMAGE/factory.img := append-kernel | pad-offset $$$$(BLOCKSIZE) 64 | \
        append-uImage-fakehdr filesystem | pad-to $$$$(KERNEL_SIZE) | \
        append-ubi | netgear-dni
    IMAGE/sysupgrade.bin := append-kernel | pad-offset $$$$(BLOCKSIZE) 64 | \
        append-uImage-fakehdr filesystem | sysupgrade-tar kernel=$$$$@ | \
        append-metadata
    DEVICE_PACKAGES := ipq-wifi-netgear_lbr20 ath10k-firmware-qca9888-ct kmod-usb-net-qmi-wwan kmod-usb-serial-option uqmi
endef
TARGET_DEVICES += netgear_lbr20

Dobra wiadomość , że BDFy zostały dodane do firmware_qca-wireless.

Czyli teraz trzeba te wpisy  w package/firmware/ipq-wifi/Makefile:

PKG_SOURCE_DATE:= 
PKG_SOURCE_VERSION:=
PKG_MIRROR_HASH:=

I będą się ściągać już z tego gita  ? Tylko skąd te dane wziąść ?

A dwa ,kolega dalej drąży temat małego kernela....  Może po prostu zwiększyć rozmiar partycji kernel  ? Powiedzmy do 0x00500000 ( 5 242 880b) ?

Jak sprawdzić ,czy uboot obsługuje kompresję LZMA kernela ?( bo takie pytanie padło).