Sedan de senaste läckorna för Samsung Galaxy S2-serien har drabbat oss till vänster och höger, har människor hoppat mellan ROM, främst mellan buggy, pre-release ICS-byggen och mycket stabil GB. Det här är trots allt vad vi gör på XDA som en vana: vi ser en läcka, vi flashar den, vi använder den och vi justerar den. Om den inte flyger rullar vi helt enkelt tillbaka. Naturligtvis finns det alltid en inneboende risk med att blinka saker som inte borde finnas på din enhet i första hand, men risken att helt mura en enhet i denna tid är ganska liten. Speciellt eftersom det finns verktyg tillgängliga för att få dina enheter tillbaka från de döda, som t.ex UnBrickable Mod av XDA Elite Recognized Developer AdamOutler.
Med detta sagt verkar inte allt vara bra i läckornas värld. Tack vare XDA Elite Recognized Developer Entropy512, har vi lärt oss att de flesta enheter som tar emot läckor löper en mycket hög risk att aldrig vakna efter en blixt. Det visar sig att det finns en stor bugg i den läckta ICS-kärnan som påverkar
/data partition i eMMC-chippet, som uppenbarligen blir skadad under vissa operationer som att torka och blinka. Detta ansågs ursprungligen endast påverka operationer som utförs i anpassade återställningar som CWM. Det har dock förekommit rapporter om att hårda tegelstenar har tillverkats från blinkningen från lageråtervinningar också. De berörda enheterna är:- Allt Epic 4G Touch (SPH-D710) ICS-läckor
- Allt Galaxy Note (GT-N7000) ICS-läckor
- De AT&T Galaxy S II (SGH-I777) UCLD3-läcka - och förmodligen alla andra
- Koreanska SHW-M250S/K/L officiella utgåvor och eventuell kärna byggd från deras källa
Entropy och andra utvecklare har postat flera varningar utspridda på webbplatsen, där de förklarar i detalj vad som händer. Vårt förslag är att användare ska hålla sig borta från att blinka ICS från läckor tills buggen i kärnan har åtgärdats helt, såvida du naturligtvis inte är ute efter att stena fast din enhet. Kom ihåg att detta inte är något som kan återupplivas via Unbrickable Mod eller ens via JTAG, eftersom detta är ett firmware-fel i eMMC. Detta är direkt från Entropy själv för er som är intresserade av lite mer detaljer:
FARA: Många Samsung ICS-läckkärnor kan skada din enhet!
De som är uppmärksamma på vad som händer med olika Samsung-enheter kanske har märkt att vissa enheter upplever en stor mängd hårda tegelstenar när ICS-läckta kärnor används. Dessa hårda tegelstenar är särskilt otäcka, eftersom leverantörer av JTAG-tjänster inte har kunnat återuppliva dessa enheter, till skillnad från enkla hårda tegelstenar med bootloader-korruption. Detta beror på det faktum att dessa kärnor faktiskt lyckas orsaka vad som verkar vara permanent skada på eMMC-lagringsenheten.
Kärnor som bekräftas påverkade är:
[*]Alla Epic 4G Touch (SPH-D710) ICS-läckor[*]Alla Galaxy Note (GT-N7000) ICS-läckor[*]AT&T Galaxy S II (SGH-I777) UCLD3-läcka - och förmodligen alla andra[*]koreanska officiella versioner av SHW-M250S/K/L och alla kärnor som byggts från deras källa
Kärnor som BÖR vara säkra är:
[*]GT-I9100 ICS läcker[*]GT-I9100 officiella utgåvor[*]Kärnor byggda av källbasen GT-I9100 Update4
Åtgärder som sannolikt kommer att orsaka skada när en påverkad kärna körs:
Torka i CWM (och troligen annan anpassad återställning) (bekräftad)
Återställa en Nandroid-säkerhetskopia i CWM (torkar först)
Flashar en annan firmware i CWM (de flesta blixtar torka först)
Torka i lager 3e-återställning (misstänkt, torkar även av en partition)
Ta bort stora filer när en påverkad kärna körs (misstänkt men inte bekräftad)
Om du har en påverkad kärna:
Flasha en känd bra kärna med Odin/Heimdall omedelbart. Använd INTE Mobile Odin, CWM eller någon annan metod på enheten för att flasha. Kända bra kärnor inkluderar:
[*]Nästan vilken pepparkakskärna som helst[*]ICS-kärnor byggda från källkoden GT-I9100 Update4
Grundorsaken till detta problem har ännu inte fastställts, men många erkända utvecklare i XDA misstänker att det beror på att Samsung har aktiverat en funktion i påverkade kärnor, MMC_CAP_ERASE - Detta är en prestandafunktion som avsevärt kan öka flash-skrivprestandan, men som verkar ta fram ett fel i flashen chipset. GT-I9100 ICS-kärnor har inte denna funktion aktiverad och verkar säkra. Det är dock inte tillräckligt känt för att deklarera alla kärnor utan denna funktion säkra - den enda enheten som kan bekräfta grundorsaken till detta problem och förklara det åtgärdat utan att ta stor risk (förstöra flera enheter utan att kunna reparera dem) är Samsung sig själva.
I allmänhet, tills vidare, om du kör en Samsung ICS-läcka för någon annan Exynos-baserad enhet än GT-I9100, rekommenderas det starkt att flasha något annat.
Och detta dök precis upp i morse i våra forum också, med tillstånd av XDA-medlem garwynn. Tydligen har Google kontaktats och de är medvetna om problemet, och en ingenjör hoppas kunna arbeta för en lösning.
Tja, det har gått ett tag men tack och lov kom Mr. Sumrall från Android tillbaka till oss på våra frågor. Jag tror att samhället kommer att tycka att detta var värt att vänta.Problem: fwrev inte korrekt inställd.Som vi misstänkte finns buggfixen inte i vår build. (Plåstret tillämpar detta villkorslöst.)Fråga: Revision matchade inte korrigeringen(Betoning min i rött när den diskuterar superbrick-frågan.)Citat:
Ursprungligen postat av Ken Sumrall
Patchen innehåller en rad i mmc.c som sätter fwrev till rättighetsbitarna från cid-registret. Innan denna patch initierades inte filen /sys/class/block/mmcblk0/device/fwrev från CID för emmc-enheter rev 4 och högre, och visade således noll.(På andra förfrågan)fwrev är noll tills plåstret appliceras.
Fråga: Varför /data-partitionen?Citat:
Ursprungligen postat av Ken Sumrall
Du har förmodligen felet, men rev 0x19 var en tidigare version av den fasta programvaran vi hade i våra prototypenheter, men vi fann att den hade ett annat fel som om du utfärdade ett mmc raderingskommando, det kunde skruva upp datastrukturerna i chippet och leda till att enheten låste sig tills den fick ström cyklade. Vi upptäckte detta när många av våra utvecklare gjorde en snabbstartsradering av användardata medan vi utvecklade ICS. Så Samsung fixade problemet och flyttade till firmwareversion 0x25.Ja, det är väldigt irriterande att 0x19 är decimal 25, och det ledde till mycket förvirring när man försökte diagnostisera problem med emmc-firmware. Jag lärde mig äntligen att _ALLTID_ referera till emmc-versionen i hexadecimal, och föregå talet med 0x bara för att vara entydig.Dock, även om 0x19 förmodligen har felet som kan infoga 32 kbyte nollor i blixten, du kan inte använda den här patchen på enheter med firmwareversion 0x19. Denna patch gör ett mycket specifikt hack till två byte kod i versionen 0x25 firmware, och patchen mest kommer sannolikt inte att fungera på 0x19, och kommer förmodligen att orsaka att chippet i bästa fall inte fungerar som det ska och förlorar data vid värst. Det finns en anledning till att urvalskriterierna är så strikta för att applicera den här patchen på emmc-firmwaren.Jag vidarebefordrade våra resultat några dagar senare och nämnde att filsystemet inte korrumperades förrän rensningen. Detta är ett svar på den uppföljningen.Som jag nämnde i förra inlägget har firmware rev 0x19 en bugg där emmc-chippet kan låsa sig efter att ett raderingskommando ges. Inte varje gång, men tillräckligt ofta. Vanligtvis kan enheten starta om efter detta, men sedan låsas under uppstartsprocessen. Mycket sällan kan det låsa sig även innan fastboot laddas. Din testare hade otur. Eftersom du inte ens kan starta fastboot, är enheten förmodligen murad. :-( Om han kunde köra fastboot, då skulle enheten förmodligen kunna återställas med den firmwareuppdateringskod jag har, förutsatt att jag kan dela den. Jag ska fråga.
Fråga: Varför fungerar inte JTAG?Citat:
Ursprungligen postat av Ken Sumrall (Android SE)
Eftersom /data är den plats chipet upplever mest skrivaktivitet. /system skrivs aldrig till (förutom under en systemuppdatering) och /cache används sällan (mest för att ta emot OTA).
Fråga: Kan ett skadat filsystem repareras (på eMMC)?Citat:
Ursprungligen postat av Ken Sumrall
Som jag nämnde ovan hade revisionen 0x19 firmware ett fel som efter ett emmc raderingskommando kunde lämna interna datastrukturer för emmc-chippet i ett dåligt tillstånd som gör att chippet låser sig när en viss sektor åtkomst. Den enda åtgärden var att torka av chippet och uppdatera firmware. Jag har kod för att göra det, men jag vet inte om jag kan dela den. Jag ska fråga.
Så även om korrigeringen inte gäller oss för tillfället, har vi fått en bra inblick i superbrick-problemet samt information om att en åtgärd är redan utvecklat (förhoppningsvis får vi se det släppt!). Felet gäller sannolikt oss och om vi antar att korrigeringen för 0x19-firmwaren ges så skulle den gälla för våra enheter.I en lättare ton, jag ville inkludera hans nära:Citat:
Ursprungligen postat av Ken Sumrall
e2fsck kan reparera filsystemet, men ofta sattes de 32 Kbyte in i början av en blockgrupp, vilket raderade många inoder, och att köra e2fsck skulle därför ofta resultera i att många filer gick vilse.
Citat:
Ursprungligen postat av Ken Sumrall
Du får en inblick i det spännande livet för en Android-kärnautvecklare. :-) Det visar sig att jobbet mestadels är att slåss med buggy hårdvara. Åtminstone verkar det så ibland.
Se till att inte blinka något ICS på dina enheter tills detta har lösts.
Vill du ha något publicerat i portalen? Kontakta vilken nyhetsskribent som helst.
[Tack Entropy512 för allt ditt hårda arbete!!!]