Chcesz przed sysupgrade koniecznie ? Bo myślę ,że jak Ci skopiuje ten co mam , to od pory wrzycenia softu przez NMRP nic się z tym nie podziało.

Zresztą robiłem test sumy kontrolnej , przed NMRP , po NMRP i po sysupgrade , no i wogóle się suma nie zmieniła...Wniosek , że albo zapisywane jest notorycznie to samo ,albo po prostu tam się nic nie zmienia...

EDIT:
Tak było wczoraj:
https://eko.one.pl/forum/viewtopic.php? … 84#p296384
I dziś te same ( a dziś wgrywałem obrazy Cezarego zarówno przez NMRP , jak i przez sysupgrade) ,  :

oot@MiFi:~# sha256sum /dev/mtd13
f5fb04aa5b882706b9309e885f19477261336ef76a150c3b4d3489dfac3953ec  /dev/mtd13
root@MiFi:~# sha256sum /dev/mtd14
46c6d65b0530747d96b21b60b13c990b8e27f6b29c8bae186b67f914f69a70ae  /dev/mtd14
root@MiFi:~# sha256sum /dev/mtd15
b2fa9bd626a2f23ae043a553904ffc211c85d4b32f5615bd5d6df6593cca4ea0  /dev/mtd15

Chyba ,że te pierwsze 0x20000 jest zerami w img w miejscu rootfs i zapisuje to samo CRC , a sysupgrade już coś innego tam w rootfs wpisuje i CRC się nie zgadza po wykonaniu CRC,,,

Link do zrzutu: https://www.mediafire.com/folder/c3q4xktiy1wd8/Rootfs
rootfs1 to ten zgrany po flashowaniu NMRP , rootfs2 to po zrobieniu sysupgrade.
Przez NMRP wgrywany był mifi z testów Cezarego , po czym kopia zrobiona komendą :
cat /dev/ubi0_0 > /tmp/rootfsx
( nie było różnicy ,jeśli wziąłbym ubiblock0_0) jako rootfs1 , no i po tym wgrany przez sysupgrade -n znowu mifi ( z pliku sysupgrade) , no i ta sama komenda i plik rootfs2.
No od razu co się rzuca w oczy to wielkość , one nie są identyczne rozmiarowo.

EDIT: Zrobiłem jeszcze jeden test, tym razem z initramfs , ( wcześniej wyczyściłem cały kernel i ubi z uboota przez "
nand erase 0xa600000 0x05a00000" , odpaliłem , zrobiłem sysupgrade z mifi , i rootfs jest identyczny z tym co robił wcześniej sysupgrade ( i rozmiarowo i poprzez sha256sum) więc go już tu nie będę zamieszczał.
W każdym razie wida sysupgrade tworzy trochę inny rozmiar ubi0_0 niż kompilacja factory.img , stąd już różnice po sysupgrade.

EDIT2: Oczywiście nawet jak będzie ten sam , to w przyszłości jak zaktualizuje się na coś nowszego to też będzie ten plik inny i zaczną się te problemy.

Nie pytałem , wgrywałem A12 od Zyxel LTE5398-M904  ( na A08 , na A11 się nie da). Te upgrade są przyrostowe (tak jak np dla MF286D) . W necie coś o A13 piszą... Jak znasz drogę to może zapytaj

Co do img i sysupgrade ,to widać ,że kompilacja tworzy ten ubi0_0 trochę krótszy , niż później robi to sysupgrade.
Albo szukamy dalej jak i gdzie ten netgear zapisuje to CRC ,żeby później porównywał to uboot podczas startu , albo po prostu zmieniamy bootcmd ubootowi.

Te wszystkie env są domyślne , ale jak zmodyfikujemy bootcmd to nowe wartości zapisują się do mtd8 - 0:APPSBLENV ( orginalna mtd8 jest bez żadnych zmienionych env i jest czysta , nawet w env jest komenda do czyszczenia env - nand erase 0x680000 0x80000). Więc można ostatecznie w openwrt odblokować mtd8 do zapisu ( przez kmod-mtd-rw), i albo zapisać całą z nowym bootcmd , albo magicznymi komendami albo programami do env ją zmodyfikować.
Link do zmodyfikowanego mtd8: https://www.mediafire.com/file/okbxmuvr … d.bin/file

A bootcmd zmodyfikowany tak: https://eko.one.pl/forum/viewtopic.php? … 86#p296386

Nie działa , błędne CRC:

root@MiFi:/# fw_printenv
Warning: Bad CRC, using default environment
bootcmd=bootp; setenv bootargs root=/dev/nfs nfsroot=${serverip}:${rootpath} ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}::off; bootm
bootdelay=5
baudrate=115200

mtd8 ciągle ten z ww linka.

EDIT ,
ale wpis:

/dev/mtd8 0x0 0x40000 0x20000

Nie wiedzieć czemu daje już poprawny wynik.

root@MiFi:/# fw_printenv
baudrate=115200
bootcmd=mii write 0x3 0x0 0x800; sleep 3; nmrp; nboot 0x84000000 0 0xa600000; setenv fdt_high 0x87000000; bootm 0x84000000
bootdelay=1
delenv=nand erase 0x680000 0x80000
ethact=eth0
flash_type=2
ipaddr=192.168.1.1
loadaddr=0x84000000
machid=8010001
serverip=192.168.1.10
stderr=serial
stdin=serial
stdout=serial
root@MiFi:/#

Nie , z takimi też nie , błąd "Environment does not fit into available sectors"

działa co najwyżej z takim:

/dev/mtd8 0x0 0x40000 0x20000 2

bo z 1 też ten sam błąd co wyżej

Poprawny pierwszy , w drugim tez adres musi być ciągle 0x40000,czyli takie są poprawne:

/dev/mtd8 0x0 0x40000 0x20000

/dev/mtd8 0x0 0x40000 0x20000 2

. Generalnie przy powyższym drugim wpisie ( na razie testowałem to z 2) da się ustawiać zmienne env , oczywiście po odblokowaniu partycji:
czyli:

opkg update
opkg install kmod-mtd-rw
insmod mtd-rw.ko i_want_a_brick=1

I wtedy:

fw_setenv bootcmd "mii write 0x3 0x0 0x800; sleep 3; nmrp; nboot 0x84000000 0 0xa600000; setenv fdt_high 0x87000000; bootm 0x84000000"

Da nam to co chcieliśmy.

Natomiast nie udaje mi się skasować tej partycji ( w razie jakbyśmy chcieli na szybko orginał) , chodzi o nazwę - 0 i dwukopek w niej ?

root@MiFi:/# mtd erase 0:APPSBLENV
Could not open mtd device: 0
Could not open mtd device: 0
root@MiFi:/# mtd erase '0:APPSBLENV'
Could not open mtd device: 0
Could not open mtd device: 0
root@MiFi:/# mtd erase "0:APPSBLENV"
Could not open mtd device: 0
Could not open mtd device: 0

EDIT:
Ok , na pewno takie coś zadziała:

 mtd erase /dev/mtd8

Ten plik trochę inaczej wygląda : https://github.com/MiG-41/openwrt/blob/ … es/ipq40xx
Wydaje się ,że razem z buffalo,wtr-m2133hp trzeba go dopisać.

Ok , ale nie będziemy chyba fabryki openwrt poprawiać...
Po co mamy jeszcze routerowi kazać szukać nazwy mtd 0:APPSBLENV i wpisywać numer... Ma to być 8 i tyle
Wpisanie tak jak mówiłem działa.

EDIT: Tak przy okazji ten Buffalo WTR-M2133HP również ma tą partycję APPSBLENV w tym samym miejscu( nawet ten sam początek) , i również o rozmiarze 0x80000 , a mimo to tak samo jest do ENV te 0x40000....