Sinds de laatste lekken voor de line-up van de Samsung Galaxy S2 ons links en rechts hebben getroffen, zijn mensen tussen ROM's gesprongen, voornamelijk tussen buggy, pre-release ICS-builds en zeer stabiele GB. Dit is tenslotte wat we op XDA als gewoonte doen: we zien een lek, we flashen het, we gebruiken het en we passen het aan. Als het niet vliegt, rollen we gewoon terug. Natuurlijk is er altijd een inherent risico verbonden aan het flashen van dingen die in de eerste plaats niet op je apparaat zouden moeten staan, maar het risico dat je tegenwoordig een apparaat volledig brickt, is vrij klein. Vooral omdat er tools beschikbaar zijn om je apparaten terug uit de dood te halen, zoals OnBrickable Mod door XDA Elite erkende ontwikkelaar AdamOutler.
Dit gezegd hebbende, lijkt niet alles in orde te zijn in de wereld van lekken. Met dank aan XDA Elite erkende ontwikkelaar Entropie512hebben we geleerd dat de meeste apparaten die lekken, een zeer groot risico lopen om nooit meer wakker te worden na een flits. Het blijkt dat er een grote bug in de gelekte ICS-kernel zit die de
- Alle Epische 4G-aanraking (SPH-D710) ICS lekt
- Alle Galaxy Note (GT-N7000) ICS lekt
- De AT&T Galaxy SII (SGH-I777) UCLD3-lek - en waarschijnlijk alle andere
- Koreaanse SHW-M250S/K/L officiële releases en elke kernel die vanaf hun bron is gebouwd
Entropy en andere ontwikkelaars hebben verspreid over de site verschillende waarschuwingen geplaatst, waarin ze in detail uitleggen wat er gebeurt. Onze suggestie is dat gebruikers weg moeten blijven van het flashen van ICS vanwege lekken totdat de bug in de kernel volledig is opgelost, tenzij je natuurlijk je apparaat hard wilt bricken. Houd er rekening mee dat dit niet iets is dat via Unbrickable Mod of zelfs via JTAG weer tot leven kan worden gewekt, aangezien dit een firmwarefout in de eMMC is. Dit is rechtstreeks van Entropy zelf, voor degenen onder u die geïnteresseerd zijn in wat meer details:
GEVAAR: Veel Samsung ICS-lekkende kernels kunnen uw apparaat beschadigen!
Degenen die aandacht besteden aan het reilen en zeilen met verschillende Samsung-apparaten, hebben misschien gemerkt dat sommige apparaten een grote hoeveelheid hardbricks ervaren wanneer ICS-gelekte kernels worden gebruikt. Deze hardbricks zijn bijzonder vervelend, omdat leveranciers van JTAG-services er niet in zijn geslaagd deze apparaten weer tot leven te wekken, in tegenstelling tot eenvoudige hardbricks met bootloader-corruptie. Dit komt door het feit dat deze kernels er feitelijk in slagen om permanente schade aan het eMMC-opslagapparaat te veroorzaken.
Kernels waarvan bevestigd is dat ze getroffen zijn, zijn:
[*]Alle Epic 4G Touch (SPH-D710) ICS lekt[*]Alle Galaxy Note (GT-N7000) ICS lekt[*]De AT&T Galaxy S II (SGH-I777) UCLD3-lek - en waarschijnlijk alle andere[*]Koreaanse SHW-M250S/K/L officiële releases en elke kernel die daaruit is gebouwd bron
Kernels die veilig MOETEN zijn zijn:
[*]GT-I9100 ICS lekt[*]GT-I9100 officiële releases[*]Kernels gebouwd op basis van de GT-I9100 Update4-bronbasis
Bewerkingen die waarschijnlijk schade zullen veroorzaken bij het uitvoeren van een getroffen kernel:
Wissen in CWM (en waarschijnlijk elk ander aangepast herstel) (bevestigd)
Een Nandroid-back-up herstellen in CWM (eerst wissen)
Een andere firmware flashen in CWM (de meeste flitsen worden eerst gewist)
Wissen in voorraad 3e herstel (vermoedelijk, wist ook een partitie)
Grote bestanden verwijderen bij het uitvoeren van een getroffen kernel (vermoedelijk maar niet bevestigd)
Als je een getroffen kernel hebt:
Flash een bekende goede kernel onmiddellijk met Odin/Heimdall. Gebruik GEEN Mobile Odin, CWM of een andere methode op het apparaat om te flashen. Bekende goede kernels zijn onder meer:
[*]Bijna elke Gingerbread-kernel[*]ICS-kernels gebouwd op basis van de GT-I9100 Update4-broncode
De hoofdoorzaak van dit probleem moet nog worden vastgesteld, maar veel erkende ontwikkelaars in XDA vermoeden dat dit te wijten is aan het feit dat Samsung een functie in de getroffen kernels, MMC_CAP_ERASE - Dit is een prestatiefunctie die de flash-schrijfprestaties aanzienlijk kan verbeteren, maar een fout in de flash lijkt naar voren te brengen chipset. Bij GT-I9100 ICS-kernels is deze functie niet ingeschakeld en deze lijken veilig. Er is echter niet genoeg bekend om alle kernels zonder deze functie veilig te verklaren - de enige entiteit die de hoofdoorzaak ervan kan bevestigen dit probleem op te lossen en het opgelost te verklaren zonder groot risico te nemen (meerdere apparaten vernietigen zonder dat ze kunnen worden gerepareerd) is Samsung zich.
Als u een Samsung ICS-lek uitvoert voor een ander Exynos-apparaat dan de GT-I9100, wordt u in het algemeen tot nader order ten zeerste aangeraden iets anders te flashen.
En dit verscheen vanochtend ook op onze forums, met dank aan XDA-lid Garwyn. Blijkbaar is er contact opgenomen met Google en zijn zij op de hoogte van het probleem, en een ingenieur hoopt aan een oplossing te werken.
Nou, het is een tijdje geleden, maar gelukkig heeft meneer Sumrall van Android contact met ons opgenomen op onze vragen. Ik denk dat de gemeenschap zal vinden dat dit het wachten waard was.Probleem: fwrev is niet correct ingesteld.Zoals we al vermoedden, zit de bugfix niet in onze build. (De patch past dit onvoorwaardelijk toe.)Vraag: Revisie kwam niet overeen met de oplossing(Nadruk van mij in het rood omdat het de kwestie van de superbrick bespreekt.)Citaat:
Oorspronkelijk geplaatst door Ken Sumrall
De patch bevat een regel in mmc.c die fwrev instelt op de rechtenbits uit het cid-register. Vóór deze patch werd het bestand /sys/class/block/mmcblk0/device/fwrev niet geïnitialiseerd vanuit de CID voor emmc-apparaten rev 4 en hoger, en toonde dus nul.(Bij tweede onderzoek)fwrev is nul totdat de patch wordt toegepast.
Vraag: Waarom de /data partitie?Citaat:
Oorspronkelijk geplaatst door Ken Sumrall
Waarschijnlijk heb je de bug, maar rev 0x19 was een eerdere versie van de firmware die we hadden in onze prototypeapparaten, maar we ontdekten dat er nog een bug in zat die als je een mmc-wisopdracht uitgaf, zou dit de datastructuren in de chip kunnen verpesten en ertoe kunnen leiden dat het apparaat vastloopt totdat het wordt ingeschakeld gefietst. We ontdekten dit toen veel van onze ontwikkelaars een fastboot-wisactie van gebruikersgegevens uitvoerden terwijl we ICS aan het ontwikkelen waren. Dus Samsung heeft het probleem opgelost en is overgegaan op firmwarerevisie 0x25.Ja, het is erg vervelend dat 0x19 decimaal 25 is, en dat leidde tot veel verwarring bij het diagnosticeren van emmc-firmwareproblemen. Ik heb eindelijk geleerd om _ALTIJD_ naar de emmc-versie in hexadecimaal te verwijzen en het getal vooraf te laten gaan door 0x, alleen maar om ondubbelzinnig te zijn.Echter, ook al bevat 0x19 waarschijnlijk de bug die 32 Kbytes aan nullen in de flash kan invoegen, kunt u deze patch niet gebruiken op apparaten met firmwarerevisie 0x19. Deze patch voert een zeer specifieke hack uit op twee bytes code in de firmwarerevisie 0x25, en de meeste patch zal waarschijnlijk niet werken op 0x19, en zal er in het beste geval waarschijnlijk voor zorgen dat de chip niet goed functioneert en gegevens verliest slechtst. Er is een reden waarom de selectiecriteria zo streng zijn voor het toepassen van deze patch op de emmc-firmware.Een paar dagen later gaf ik onze resultaten door en vermeldde dat het bestandssysteem pas beschadigd raakte toen het werd gewist. Dit is een reactie op dat vervolg.Zoals ik in het vorige bericht al zei, bevat firmware rev 0x19 een bug waarbij de emmc-chip kan vastlopen nadat een wisopdracht is gegeven. Niet elke keer, maar vaak genoeg. Meestal kan het apparaat hierna opnieuw opstarten, maar vervolgens vastlopen tijdens het opstartproces. Zeer zelden kan het vastlopen, zelfs voordat fastboot is geladen. Je tester had pech. Omdat je fastboot niet eens kunt starten, is het apparaat waarschijnlijk gemetseld. :-( Als hij fastboot kon draaien, dan kan het apparaat waarschijnlijk worden hersteld met de firmware-updatecode die ik heb, ervan uitgaande dat ik deze kan delen. Ik zal het vragen.
Vraag: Waarom werkt JTAG niet?Citaat:
Oorspronkelijk geplaatst door Ken Sumrall (Android SE)
Omdat /data de plaats is waar de chip de meeste schrijfactiviteit ervaart. Er wordt nooit naar /system geschreven (behalve tijdens een systeemupdate) en /cache wordt zelden gebruikt (meestal voor het ontvangen van OTA's).
Vraag: Kan een beschadigd bestandssysteem worden gerepareerd (op de eMMC)?Citaat:
Oorspronkelijk geplaatst door Ken Sumrall
Zoals ik hierboven al vermeldde, had de revisie 0x19-firmware een bug waardoor deze na een emmc-wisopdracht de interne datastructuren van de emmc-chip zijn in een slechte staat waardoor de chip vastloopt wanneer een bepaalde sector zich bevindt benaderd. De enige oplossing was het wissen van de chip en het updaten van de firmware. Ik heb code om dat te doen, maar ik weet niet of ik deze kan delen. Ik zal het vragen.
Dus hoewel de oplossing op dit moment niet op ons van toepassing is, hebben we veel inzicht gekregen in het probleem met Superbrick en informatie dat er een oplossing is is al ontwikkeld (hopelijk zien we het uitgebracht!). De bug is waarschijnlijk op ons van toepassing en ervan uitgaande dat de oplossing voor de 0x19-firmware wordt gegeven, zou deze van toepassing zijn op onze apparaten.Op een lichtere toon wilde ik zijn afsluiting opnemen:Citaat:
Oorspronkelijk geplaatst door Ken Sumrall
e2fsck kan het bestandssysteem repareren, maar vaak werden de 32 Kbytes ingevoegd aan het begin van een blokgroep, waardoor veel inodes werden gewist, en dus zou het uitvoeren van e2fsck er vaak toe leiden dat veel bestanden verloren gingen.
Citaat:
Oorspronkelijk geplaatst door Ken Sumrall
Je krijgt een kijkje in het spannende leven van een Android-kernelontwikkelaar. :-) Blijkt dat het werk vooral bestaat uit vechten met hardware met fouten. Tenminste, zo lijkt het soms.
Blijf alsjeblieft weg van het flashen van ICS naar uw apparaten totdat dit is opgelost.
Wilt u iets publiceren in de Portal? Neem contact op met een nieuwsschrijver.
[Bedankt Entropie512 voor al je harde werk!!!]