Ponieważ najnowsze przecieki na temat linii Samsung Galaxy S2 uderzają nas na lewo i prawo, ludzie przeskakują między ROMami, głównie pomiędzy błędnymi, przedpremierowymi wersjami ICS i bardzo stabilnymi GB. W końcu to jest to, co robimy na XDA jako nawyk: widzimy wyciek, flashujemy go, używamy go i poprawiamy. Jeśli nie poleci, po prostu się wycofamy. Oczywiście zawsze istnieje ryzyko związane z flashowaniem rzeczy, które w ogóle nie powinny znajdować się na twoim urządzeniu, ale ryzyko całkowitego zamurowania urządzenia w dzisiejszych czasach jest raczej niewielkie. Zwłaszcza, że dostępne są narzędzia do przywracania urządzeń z martwych, takie jak Mod niemożliwy do zbudowania autorstwa uznanego programisty XDA Elite AdamOutler.
Powiedziawszy to, nie wszystko wydaje się być w porządku w świecie przecieków. Dzięki uznanemu programiście XDA Elite Entropia512dowiedzieliśmy się, że w przypadku większości urządzeń, które uległy wyciekom, istnieje bardzo duże ryzyko, że nigdy nie wybudzą się po błysku. Okazuje się, że w jądrze ICS, które wyciekło, występuje poważny błąd, który wpływa na
- Wszystko Epicki dotyk 4G (SPH-D710) Wycieki ICS
- Wszystko Galaxy Note (GT-N7000) Wycieki ICS
- The AT&T Galaxy S II (SGH-I777) Wyciek UCLD3 - i prawdopodobnie wszystkie inne
- Oficjalne wydania koreańskie SHW-M250S/K/L i dowolne jądro zbudowane z ich źródeł
Entropy i inni twórcy opublikowali kilka ostrzeżeń rozsianych po całej witrynie, w których szczegółowo wyjaśniają, co się dzieje. Nasza sugestia jest taka, że użytkownicy powinni trzymać się z daleka od flashowania ICS ze względu na wycieki, dopóki błąd w jądrze nie zostanie całkowicie naprawiony, chyba że oczywiście chcesz mocno uszkodzić swoje urządzenie. Pamiętaj, że nie jest to coś, co można wskrzesić za pomocą Unbrickable Mod lub nawet za pomocą JTAG, ponieważ jest to błąd oprogramowania układowego w eMMC. To jest bezpośrednio od samego Entropy dla tych z Was, którzy interesują się nieco większymi szczegółami:
NIEBEZPIECZEŃSTWO: Wiele wyciekających jąder Samsung ICS może uszkodzić Twoje urządzenie!
Ci, którzy zwracają uwagę na to, co dzieje się z różnymi urządzeniami Samsunga, mogli zauważyć, że w niektórych urządzeniach występuje duża ilość twardych usterek, gdy używane są jądra ICS, które wyciekły. Te twarde cegły są szczególnie paskudne, ponieważ dostawcy usług JTAG nie byli w stanie wskrzesić tych urządzeń, w przeciwieństwie do zwykłych twardych cegieł powodujących uszkodzenie bootloadera. Dzieje się tak dlatego, że jądra te w rzeczywistości powodują coś, co wydaje się trwałym uszkodzeniem urządzenia pamięci masowej eMMC.
Jądra, których dotyczy problem, to:
[*]Wszystkie wycieki ICS Epic 4G Touch (SPH-D710)[*]Wszystkie przecieki ICS Galaxy Note (GT-N7000)[*]AT&T Galaxy S II (SGH-I777) Wyciek UCLD3 - i prawdopodobnie wszystkich innych[*]Koreańskie oficjalne wydania SHW-M250S/K/L i dowolne jądro zbudowane z ich źródło
Jądra, które POWINNY być bezpieczne to:
[*]Wycieki GT-I9100 ICS[*]Oficjalne wydania GT-I9100[*]Jądra zbudowane na podstawie bazy źródłowej GT-I9100 Update4
Operacje, które mogą spowodować uszkodzenie podczas uruchamiania dotkniętego jądra:
Wymazywanie w CWM (i prawdopodobnie inne niestandardowe odzyskiwanie) (potwierdzone)
Przywracanie kopii zapasowej Nandroid w CWM (najpierw czyszczenie)
Flashowanie innego oprogramowania w CWM (większość flashowań najpierw wymazuje)
Wycieranie w stocku 3e recovery (podejrzewam, czyści też partycję)
Usuwanie dużych plików podczas uruchamiania jądra, którego dotyczy problem (podejrzewane, ale niepotwierdzone)
Jeśli masz jądro, którego dotyczy problem:
Natychmiast zflashuj znane, dobre jądro przy użyciu Odina/Heimdalla. NIE używaj Mobile Odin, CWM ani żadnej innej metody na urządzeniu do flashowania. Znane dobre jądra obejmują:
[*]Prawie dowolne jądro Gingerbread[*]Jądra ICS zbudowane z kodu źródłowego GT-I9100 Update4
Pierwotna przyczyna tego problemu nie została jeszcze ustalona, jednak wielu uznanych programistów XDA podejrzewa, że jest to spowodowane włączeniem przez firmę Samsung tej funkcji w dotknięte jądra, MMC_CAP_ERASE — jest to funkcja zwiększająca wydajność, która może znacznie zwiększyć wydajność zapisu w pamięci flash, ale wydaje się, że uwydatnia wadę pamięci flash chipset. Jądra GT-I9100 ICS nie mają włączonej tej funkcji i wydają się bezpieczne. Jednakże nie ma wystarczającej wiedzy, aby zadeklarować, że wszystkie jądra bez tej funkcji są bezpieczne – jest to jedyna jednostka, która może potwierdzić pierwotną przyczynę ten problem i ogłosić, że został rozwiązany bez podejmowania dużego ryzyka (zniszczenie wielu urządzeń bez możliwości ich naprawy) to firma Samsung sobie.
Ogólnie rzecz biorąc, do odwołania, jeśli masz wyciek Samsung ICS dla dowolnego urządzenia opartego na Exynos innego niż GT-I9100, zdecydowanie zaleca się flashowanie czegoś innego.
To samo pojawiło się dziś rano na naszych forach, dzięki uprzejmości członka XDA garwynn. Najwyraźniej skontaktowano się z firmą Google i firma jest świadoma problemu, a jeden z inżynierów ma nadzieję opracować rozwiązanie.
Cóż, minęło trochę czasu, ale na szczęście pan Sumrall z Androida odpowiedział na nasze pytania. Myślę, że społeczność przekona się, że warto było na to czekać.Problem: fwrev nie jest poprawnie ustawiony.Ponieważ podejrzewaliśmy, że poprawka nie znajduje się w naszej kompilacji. (Poprawka stosuje to bezwarunkowo.)Pytanie: Wersja nie była zgodna z poprawką(Podkreśl moje na czerwono, ponieważ omawia kwestię superbricka.)Cytat:
Oryginalnie przesłane przez Kena Suralla
Łatka zawiera linię w mmc.c ustawiającą fwrev na bity praw z rejestru cid. Przed tą łatką plik /sys/class/block/mmcblk0/device/fwrev nie był inicjalizowany z CID dla urządzeń emmc w wersji 4 i nowszych i dlatego pokazywał zero.(Przy drugim zapytaniu)fwrev wynosi zero do momentu zastosowania łatki.
Pytanie: Dlaczego partycja /data?Cytat:
Oryginalnie przesłane przez Kena Suralla
Prawdopodobnie masz błąd, ale wersja 0x19 była poprzednią wersją oprogramowania sprzętowego, którą mieliśmy w naszych prototypowych urządzeniach, ale odkryliśmy, że zawierała ona inny błąd, który w przypadku wydał polecenie kasowania mmc, mogło to zepsuć struktury danych w chipie i doprowadzić do zablokowania urządzenia do czasu włączenia zasilania rowerem. Odkryliśmy to, gdy wielu naszych programistów usuwało dane użytkownika za pomocą szybkiego rozruchu, podczas gdy my opracowywaliśmy ICS. Dlatego Samsung naprawił problem i przeszedł do wersji oprogramowania 0x25.Tak, to bardzo denerwujące, że 0x19 to liczba dziesiętna 25, co prowadziło do wielu nieporozumień podczas prób diagnozowania problemów z oprogramowaniem układowym emmc. W końcu nauczyłem się _ZAWSZE_ odwoływać się do wersji emmc w formacie szesnastkowym i poprzedzać liczbę 0x, żeby była jednoznaczna.Jednakże, chociaż 0x19 prawdopodobnie ma błąd, który może wstawić 32 kilobajty zer do pamięci flash, nie można używać tej poprawki na urządzeniach z wersją oprogramowania 0x19. Ta łatka dokonuje bardzo specyficznego hackowania dwóch bajtów kodu w wersji oprogramowania sprzętowego 0x25 i większości łatek prawdopodobnie nie będzie działać na 0x19 i prawdopodobnie spowoduje w najlepszym wypadku awarię chipa i utratę danych najgorszy. Jest powód, dla którego kryteria wyboru dotyczące zastosowania tej poprawki do oprogramowania sprzętowego emmc są tak rygorystyczne.Kilka dni później przekazałem nasze wyniki, wspominając, że system plików nie uległ uszkodzeniu aż do momentu wyczyszczenia. To jest odpowiedź na te działania następcze.Jak wspomniałem w poprzednim poście, wersja oprogramowania 0x19 zawiera błąd, przez który układ emmc może się zawiesić po wydaniu polecenia kasowania. Nie za każdym razem, ale wystarczająco często. Zwykle po tym urządzenie może zostać ponownie uruchomione, ale następnie zawiesza się podczas procesu uruchamiania. Bardzo rzadko może się zawiesić nawet przed załadowaniem fastboota. Twój tester miał pecha. Ponieważ nie możesz nawet uruchomić fastboota, urządzenie prawdopodobnie jest zamurowane. :-( Gdyby mógł uruchomić fastboot, wtedy prawdopodobnie można będzie odzyskać urządzenie za pomocą posiadanego kodu aktualizacji oprogramowania sprzętowego, zakładając, że mogę go udostępnić. Zapytam.
Pytanie: Dlaczego JTAG nie będzie działać?Cytat:
Oryginalnie przesłane przez Ken Sumrall (Android SE)
Ponieważ /data to miejsce, w którym chip doświadcza największej aktywności zapisu. /system nigdy nie jest zapisywany (z wyjątkiem aktualizacji systemu), a /cache jest rzadko używany (głównie do odbierania OTA).
Pytanie: Czy można naprawić uszkodzony system plików (na eMMC)?Cytat:
Oryginalnie przesłane przez Kena Suralla
Jak wspomniałem powyżej, oprogramowanie sprzętowe w wersji 0x19 zawierało błąd polegający na tym, że po wydaniu polecenia kasowania emmc mogło opuścić wewnętrzne struktury danych chipa emmc są w złym stanie, co powoduje blokowanie się chipa, gdy znajduje się w określonym sektorze dostępny. Jedynym rozwiązaniem było wyczyszczenie chipa i aktualizacja oprogramowania sprzętowego. Mam do tego kod, ale nie wiem, czy mogę go udostępnić. Zapytam.
Tak więc, chociaż poprawka nas w tej chwili nie dotyczy, otrzymaliśmy świetny wgląd w problem Superricka, a także informację, że poprawka Jest już opracowany (miejmy nadzieję, że zostanie wydany!). Błąd prawdopodobnie dotyczy nas i zakładając, że zostanie wydana poprawka dla oprogramowania sprzętowego 0x19, będzie dotyczyć naszych urządzeń.Mówiąc jaśniej, chciałem uwzględnić jego zamknięcie:Cytat:
Oryginalnie przesłane przez Kena Suralla
e2fsck może naprawić system plików, ale często 32 KB było wstawiane na początku grupy bloków, co usuwało wiele i-węzłów, a zatem uruchomienie e2fsck często powodowało utratę wielu plików.
Cytat:
Oryginalnie przesłane przez Kena Suralla
Dajesz wgląd w ekscytujące życie programisty jądra Androida. :-) Okazuje się, że praca polega głównie na walce z błędnym sprzętem. Przynajmniej czasami tak się wydaje.
Prosimy nie instalować żadnych plików ICS na swoich urządzeniach, dopóki problem nie zostanie rozwiązany.
Chcesz coś opublikowanego w Portalu? Skontaktuj się z dowolnym autorem wiadomości.
[Dzięki Entropia512 za całą twoją ciężką pracę!!!]