cedryk

Zarejestrowany
Noobie
28 Sierpień 2026
3
0
5
Odznaki
5
QNAP
TS-x31
Ethernet
1 GbE
Poz.
0
 
Cześć,

mam QNAP TS-431XeU (płyta QZ11 rev 1.1) z uszkodzonym bootloaderem w pamięci SPI. Log z konsoli szeregowej (UART0_DEBUG, 115200 8N1):

Kod:
Stage 3 version: 1.73.0
Device ID = a314
Device Info: AL31400-1700
Loading DT to 00100000 (22335 bytes)...
Board config ID: alpine_db_qnap
Loading application to 00100000 (484248 bytes)...
al_flash_obj_data_load: data checksum validation failed!
al_flash_obj_data_load failed!

Loader dochodzi do stage 3, inicjalizuje RAM, ładuje Device Tree i wywala się na sumie kontrolnej obrazu aplikacji czytanego z SPI. Sprzęt jest sprawny – wykluczyłem dyski, trzy różne kości RAM, wentylatory i zasilacz (12,11 V stabilne).

Oficjalna procedura recovery (zworka J1 + TFTP) nie działa – log jest identyczny co do linijki, serwer TFTP nie dostaje żadnego żądania. Obsługa zworki siedzi najwyraźniej w tym właśnie uszkodzonym obrazie. Firmware TS-X31XU_434.zip zawiera tylko rootfs2.ubi, uImage i nasconfig.ubi – bez bootloadera.

Czego potrzebuję

Zrzutu kości U24 – Macronix MX25L016 (25L016CSIG), 2 MB, 3,3 V z działającego TS-431XeU lub TS-431XU na płycie QZ11. Kość jest podpięta pod złącze AL SPI1 (sprawdzone miernikiem). Planuję wgrać obraz programatorem CH341A.

Pytania:

1. Czy obraz z innego egzemplarza wystarcza, czy trzeba podmienić dane specyficzne dla urządzenia (MAC, S/N)?
2. Pinout złącza AL SPI1 – które pady to CS, CLK, MISO, MOSI, VCC, GND?
3. Czy programowanie in-circuit na tej płycie działa, czy trzeba kość wylutować?

Z góry dzięki za pomoc.

Pozdrawiam
Grzegorz
 
Rozwiązanie
Dobra udało mi się to naprawić. Pobrałem za pomocą programatora CH341A dane z tego chipa, wrzuciłem ten plik do Clauda i on wykrył, że suma kontrolna się rzeczwyiście nie zgadza i zrobił fix'a - Claude:
Twój zrzut zawiera kompletny, sprawny bootloader. Nie potrzebujesz obrazu od nikogo.

Rozpracowałem format pamięci. Na początku siedzi tablica siedmiu obiektów, każdy z własnym 72-bajtowym nagłówkiem i 4-bajtową sumą kontrolną na końcu, będącą zwykłą sumą bajtów. Rozmiary z tablicy zgadzają się co do bajta z logiem konsoli: uboot ma 484 248 bajtów, dt ma 22 335. Dokładnie te liczby widziałeś przy starcie.

Policzyłem sumy wszystkich czterech obiektów:

obiektzapisanaobliczona
...
Krótko: 1) Obraz SPI z innego, sprawnego TS-431XeU (płyta QZ11, ta sama rewizja) najczęściej wystarczy, ale trzeba uważać na dane unikatowe (MAC, S/N, kalibracje) — lepiej najpierw odczytać i porównać zawartość obu kości. 2) Nie podam „pewnego” pinoutu AL SPI1 dla QZ11, którego nie mam w oficjalnych fragmentach — zamiast zgadywać opisuję jak bezpiecznie go zidentyfikować i zweryfikować. 3) Programowanie in‑circuit możliwe, ale ryzykowne; najbezpieczniej wylutować kość i programować zewnętrznym programatorem. Poniżej pełna, samodzielna procedura i praktyczne wskazówki.

Wyjaśnienie i zagrożenia (ważne)
  • ZAWSZE wykonaj kopię działania/backup dysków przed jakąkolwiek ingerencją sprzętową — operacje na SPI/bootloaderze ryzykują trwałą utratę możliwości uruchomienia urządzenia.
  • Przy operacjach na pamięciach SPI stosuj izolację ESD, stabilne źródło zasilania i poprawne napięcie 3.3 V. Nie stosuj 5 V do Macronix MX25L016.
  • Jeśli bootloader jest uszkodzony i oficjalna procedura (zworka J1 + TFTP) nie działa, odzyskanie przez programator SPI to standardowy kolejny krok. Jednak QNAP może przechowywać niektóre identyfikatory sprzętowe (np. MAC, S/N, kalibracje) w pamięci SPI lub w oddzielnym EEPROM — trzeba to zweryfikować.

Odpowiedzi na Twoje pytania + konkretne kroki

1) Czy obraz z innego egzemplarza wystarcza, czy trzeba podmienić dane specyficzne dla urządzenia?
- Z doświadczenia: obraz z innego, tego samego modelu i tej samej rewizji płyty (QZ11 rev 1.1) często pozwala przywrócić bootloader i uruchomić urządzenie. Jednak:
- Niektóre QNAPy przechowują MAC adresy, SN, klucze w obszarze NVRAM/EEPROM lub w części pamięci SPI. Jeśli tak jest w TS‑431XeU, wgrywając „czysty” dump możesz stracić MAC/SN i (w skrajnych przypadkach) mieć problemy z licencjami/identyfikacją.
- Procedura bezpieczna: odczytaj dump z uszkodzonej kości (jeśli możliwe) przed flashowaniem jakiegokolwiek obrazu, porównaj z dumpem z dawcy. Jeśli dump z uszkodzonej kości jest częściowo czytelny, spróbuj wyodrębnić sekcje zawierające MAC/SN i wgrać tylko bootloader/firmware, zachowując regiony z danymi unikatowymi. Jeżeli nie potrafisz rozpoznać regionów, najbezpieczniej wgrać cały obraz od sprawnego egzemplarza i potem zmienić MAC/SN zgodnie z procedurami (ale to może wymagać dodatkowych kroków i nie zawsze jest proste).
- Podsumowanie: obraz z innego egzemplarza prawdopodobnie wystarczy do odzyskania bootu, ale koniecznie sprawdź/podmień dane unikatowe jeśli to konieczne.

2) Pinout złącza AL SPI1 – które pady to CS, CLK, MISO, MOSI, VCC, GND?
- Nie mogę podać pewnego pinoutu „z pamięci” poza oficjalnymi fragmentami: pinout zależy od konkretnego rozmieszczenia padów AL na QZ11 i nie znajduje się w dostarczonych fragmentach. Podaję procedurę bezpiecznej identyfikacji:
a) Zlokalizuj fizycznie pamięć U24 (MX25L016) na płycie i identyfikuj wyprowadzenia układu (zwykle SOIC8). Na obudowie kości są standardowe numery nóżek; sprawdź orientację (denotacja kropką).
b) Typowy układ SPI SOIC8 (ogólnie dla MX25Lxxxx): nóżki to (dla obudowy SOIC8) zwykle: 1 = /CS, 2 = DI (MOSI), 3 = WP, 4 = VCC, 5 = GND, 6 = DO (MISO), 7 = CLK, 8 = HOLD. To jest ogólny standard dla wielu układów SPI (ale ZAWSZE zweryfikuj po oznaczeniach na kości i datasheetie), natomiast układy mogą być obrócone lub inne footprinty. (To jest ogólna informacja techniczna, nie oficjalny pinout płyty QZ11.)
c) Użyj multimetrów/ciągłości ścieżek aby zidentyfikować GND do masy płyty i VCC do raila 3.3 V. Sprawdź, czy wokół są rezystory, kondensatory lub konwertery poziomów (mogą być elementy odseparowujące linię).
d) Jeśli chcesz tylko podpiąć klips SOIC8: sprawdź orientację i numery nóżek kości, zrób pomiar zgodności (GND do GND, VCC do 3.3 V). Następnie narzędziem logicznym (oscyloskop / analizator stanów logicznych) zobacz czy po włączeniu urządzenia pojawiają się sygnały CLK/MOSI etc. przy starcie (jeżeli boot proces próbuje czytać flash).
e) Jeśli nie masz sposobu na weryfikację elektroniczną: wylutuj układ i odczytaj go na stole programatora — to eliminuje ryzyko błędów pinoutu.

3) Czy programowanie in-circuit na tej płycie działa, czy trzeba kość wylutować?
- Programowanie in‑circuit (z klipsem SOIC8 lub podpinaniem do padów) TEORETYCZNIE działa, ale:
- Często na płycie są elementy (rezystory, level shiftery, multipleksery) które mogą wpływać na odczyt/zapis i uniemożliwić poprawne flashowanie przez programator. Mogą też występować pull‑up/pull‑down, które zaburzają sygnały.
- Programowanie z klipsem przy wyłączonym zasilaniu programatora, a zasileniu płyty zewnętrznym — bywa ryzykowne (możesz uszkodzić programator lub płytę). Przy programowaniu in‑circuit najbezpieczniej:
1) Zasilanie kości zapewnić z programatora, a płytę odłączyć (czyli wylutować kość) — to najpewniejsze.
2) Alternatywnie: jeśli programator obsługuje tryb „power from target”, podłącz programator tak, aby target zasilał kość, ale rozważ wpływ pozostałych układów. Wiele problemów wynika z tego właśnie.
- Jeżeli nie masz doświadczenia lub klipu wysokiej jakości, najlepsza praktyka to wylutować chip i programować z niego zewnętrznie (bezpieczniej i szybciej diagnozuje problem).
- Reasumując: In‑circuit możliwe, ale niewystarczająco pewne — jeśli chcesz 100% pewności, wylutuj.

Praktyczny plan działania (krok po kroku)
1) Przygotowanie
- Zdobądź: sprawny donor TS‑431XeU (ta sama rewizja QZ11), lub programator CH341A, klips SOIC8 dobrej jakości, stację lutowniczą, desolder flux, ESD.
- Datasheet MX25L016 do ręki (dla mapy pamięci i pinoutu układu).

2) Odczyt z donor i z uszkodzonego egzemplarza (jeśli to możliwe)
- Jeżeli możesz odczytać uszkodzoną kość: spróbuj to zrobić najpierw. Jeśli bootloader błęduje sumą kontrolną, być może część pamięci jest OK i da się odzyskać dane unikatowe.
- Odczytaj dump z donor i z uszkodzonego (jeśli odczytowalny). Zachowaj obie kopie.

3) Weryfikacja regionów z danymi unikatowymi
- Porównaj dumpy heksadecymalnie (bin2hex/diff). Szukaj ciągów ASCII zawierających MAC/SN, ewentualnych ciągów konfiguracyjnych.
- Jeśli znajdziesz region z MAC/SN, wyodrębnij go i zapisz osobno.

4) Flashowanie
- Preferowane: wylutuj U24 i programuj na stole programatora (CH341A) przy 3.3 V.
- Alternatywa: jeśli chcesz programować in‑circuit, podłącz klips i wykonaj odczyt. Jeżeli odczyt jest stabilny (bez błędów CRC), możesz spróbować zapisu. Jeśli pojawiają się błędy — wylutuj.
- Po zapisie sprawdź verify (programator powinien porównać zapis z obrazem).

5) Po flashu
- Włóż z powrotem (jeśli była lutowana) lub odczep klips i podłącz. Uruchom i obserwuj konsolę UART (jak robiłeś) czy loader przechodzi dalej.
- Jeżeli urządzenie uruchamia się, sprawdź czy MAC/SN jest poprawne. Jeśli nie, przywróć region z danymi unikatowymi (opisane w pkt 3).

Dodatkowe wskazówki praktyczne
  • Używaj klipu o dobrej jakości i upewnij się, że styki nie ślizgają się (niestabilne połączenie daje błędy odczytu).
  • CH341A ma ograniczenia prędkości i kompatybilności; na większych rozmiarach flash może być wolny, ale zwykle wystarczający do MX25L016.
  • Jeśli nie czujesz się komfortowo z wylutowaniem układu – zleć to serwisowi sprzętowemu. Uszkodzenie ścieżki lub padów uniemożliwi dalsze naprawy.
  • Dokumentuj każdy krok i trzymaj oryginalne dumpy w bezpiecznym miejscu.

Podsumowanie (konkretne kroki do wykonania teraz)
1) Odczytaj dump z donor (ten sam model i rewizja QZ11). 2) Spróbuj odczytać Twoją uszkodzoną kość; jeśli się da, porównaj z donorem i zidentyfikuj regiony z MAC/SN. 3) Najpewniej: wylutuj U24 i zaprogramuj dump z donora przez CH341A (3.3 V), następnie wgraj/odtwórz oryginalne dane unikatowe jeśli trzeba. 4) Po zapisie sprawdź konsolę UART i poprawność MAC/SN. 5) Jeśli wszystko zawiedzie lub płyta ma uszkodzenia poza SPI, rozważ serwis sprzętowy.

Ostrzeżenie końcowe
Operacje na pamięci SPI i bootloaderze mogą trwale unieruchomić NAS jeśli wykonane nieprawidłowo. Najbezpieczniejsze i najmniej ryzykowne podejście to wylutowanie kości i zaprogramowanie jej na stole programatora. Jeśli nie masz praktyki z lutowaniem BGA/SOIC, zleć wylutowanie serwisowi.

Źródła na forum:

Ta wiadomość pochodzi od asystenta AI — może zawierać błędy, zweryfikuj przed zastosowaniem. Oceń ją, głosując pod postem: ▲ pomocna lub ▼ nieprzydatna.
Na tym forum nie ma złych ocen — wszyscy wciąż się uczymy i wszyscy jesteśmy adminami, a +1 czy −1 to zawsze tylko 1 punkt. Każde Twoje kolejne pytanie to wspólna pomoc, która zostaje nie tylko na forum, ale i w internecie. Społeczność forum QNAP działa od 2008 roku i po niemal dwóch dekadach nieprzerwanie dostarcza rzetelne treści, z których korzystają kolejni admini — a ostatnio uczy się na nich także AI.
 
1. Czy obraz z innego egzemplarza wystarcza, czy trzeba podmienić dane specyficzne dla urządzenia (MAC, S/N)?
do przeprogramowania za pomocą hwtest lub samym hal set mac itd itd

3. Czy programowanie in-circuit na tej płycie działa, czy trzeba kość wylutować?
dziala

co jest powodem ze bootloader sie uszkodzil? skad pomysl ze jest sprawna kosc?
 
do przeprogramowania za pomocą hwtest lub samym hal set mac itd itd


dziala

co jest powodem ze bootloader sie uszkodzil? skad pomysl ze jest sprawna kosc?
Dzieki za odpowiedz. Zaczeło się od tego, ale to pare miesięcy temu, że nie mam NASa w sieci, patrze ikonki się swiecą (dyski, i, siec lan, ale znikl siec SPF+), zrestartowalem i dziala, potem mialem tak jeszcez ile razy... ale juz nie chcial wstawc od razu (wlaczal sie ale nie bylo beep), ostatnio w ogole juz nie chcial wstac (w sensie wszystko sie odpala ale nie ma tego beep co jest po chwili) dlatego go zdebugowalem i widze ze jest ten problem z "
Loading application to 00100000 (484248 bytes)...
al_flash_obj_data_load: data checksum validation failed!
al_flash_obj_data_load failed!" - probowalem procedure recovery z tą zworką J1, ale de facto nic to nie zmienia, nie inicjalizuje się te pobieranie z TFTP - wiec chyba zostaje pobawic sie z ta koscią - zamawiam ten programator i zobacze czy uda mi sie cos z tej kosci wyciagnąć - wtedy bede wiedzial czy kosc dziala czy nie... ale chyba bede potrzebowal ten firmware do wgrania... tylko nie wiem czy uda mi się go dostać.
 
Dobra udało mi się to naprawić. Pobrałem za pomocą programatora CH341A dane z tego chipa, wrzuciłem ten plik do Clauda i on wykrył, że suma kontrolna się rzeczwyiście nie zgadza i zrobił fix'a - Claude:
Twój zrzut zawiera kompletny, sprawny bootloader. Nie potrzebujesz obrazu od nikogo.

Rozpracowałem format pamięci. Na początku siedzi tablica siedmiu obiektów, każdy z własnym 72-bajtowym nagłówkiem i 4-bajtową sumą kontrolną na końcu, będącą zwykłą sumą bajtów. Rozmiary z tablicy zgadzają się co do bajta z logiem konsoli: uboot ma 484 248 bajtów, dt ma 22 335. Dokładnie te liczby widziałeś przy starcie.

Policzyłem sumy wszystkich czterech obiektów:

obiektzapisanaobliczona
boot-mod0x000000050x00000005OK
u-boot-spl0x0002B4D50x0002B4D5OK
uboot0x026415A80x026415E8błąd
dt0x000AF51E0x000AF51EOK
Trzy obiekty zgadzają się idealnie, co potwierdza, że algorytm odgadłem prawidłowo. Różnica przy uboot wynosi dokładnie 64, czyli jeden przekręcony bit. I najciekawsze: zapisana suma to A8, obliczona E8 — różnią się wyłącznie bitem 6 w najmłodszym bajcie samej sumy kontrolnej.

Po wgraniu tego QNAP startuje, wszystko wygląda jak przed awarią. Oczywiście nie wiem, czemu tak się stało i nie wiem czy to już permamenta poprawką, czy znowu się tam coś może popsuć. Jeżeli problem powróci, postaram się wymienić chipa i wgrać jeszcze raz ten działający zrzut. Dzięki.
 
tam sie nic nei zmienia od lat....
  • kondzioły straciły sprawność po latach i przy niestabilnym zasilaniu SPI pływa
  • masz sąsiada w pobliżu z chińskimi panelami solarnymi, jakieś inne na wioskach zaniki prądu, niekontrolowane powroty i mikro przepięcia, problemy własne w instalacji energetycznej
  • (najbardziej obstawiam) temperatury i zwyczajne usterki
Nie dawalo mi to spokoju...
wiec wiedzialem ze gdzies te pliki są, chodzilem od rana, szukalem itd, rozpakowalem wszystkie firmware dla wszystkich modeli nas...
1788020164702.webp


Kod:
qfwpack.exe batch unpacked . --no-big
...
==> [2] TS-X32U_20260819-6.1.0.3591.img
unpacked ./TS-X32U_20260819-6.1.0.3591.img
  model=TS-X32U version=6.1.0 date=20260819 build=3591
  PARTIAL extract: kept 42 of 46 members (not repack-capable)
  fw/       : 42 files
...

no a fw recovery?
Kod:
┌Address─┐┌Hex──────────────────────────────────────────────────────────────────────┐┌ASCII───────────────────┐
│00000000││55 42 49 23 01 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 10 00  ││UBI#⍾0000000000000⍾000⍾0│
│00000018││6F 99 6A 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ││o�j⍾00000000000000000000│
│00000030││00 00 00 00 00 00 00 00 00 00 00 00 5F 56 6E 79 FF FF FF FF FF FF FF FF  ││000000000000_Vny��������│
│00000048││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│00000060││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│00000078││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│00000090││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│000000A8││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│000000C0││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│000000D8││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│000000F0││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│00000108││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│00000120││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│00000138││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│00000150││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
│00000168││FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF  ││������������������������│
└────────┘└─────────────────────────────────────────────────────────────────────────┘└────────────────────────┘
┌Signed 8 bit──────────────┐┌Signed 32 bit─────────────┐┌Hexadecimal──────────────┐┌Float 32 bit──────────────┐
│85                        ││592003669                 ││55                       ││1.0910278e-17             │
└──────────────────────────┘└──────────────────────────┘└─────────────────────────┘└──────────────────────────┘
┌Unsigned 8 bit────────────┐┌Unsigned 32 bit───────────┐┌Octal────────────────────┐┌Float 64 bit──────────────┐
│85                        ││592003669                 ││125                      ││2.414484466e-314          │
└──────────────────────────┘└──────────────────────────┘└─────────────────────────┘└──────────────────────────┘
┌Signed 16 bit─────────────┐┌Signed 64 bit─────────────┐┌Binary───────────────────┐┌Offset────────────────────┐
│16981                     ││4886970965                ││01010101                 ││0x0                       │
└──────────────────────────┘└──────────────────────────┘└─────────────────────────┘└──────────────────────────┘
┌Unsigned 16 bit───────────┐┌Unsigned 64 bit───────────┐┌Stream Length────────────┐┌Notifications─────────────┐
│16981                     ││4886970965                ││8                        ││                          │
...
takze pewnie o to Ci chodzim aktywujesz hwinfo i wpisujesz z palca parametry SN i MAC