מאז שההדלפות האחרונות של סדרת ה-Samsung Galaxy S2 פגעו בנו ימינה ושמאלה, אנשים קפצו בין ROM בעיקר בין רכיבי ICS של באגי, טרום-שחרור ו-GB יציב מאוד. זה, אחרי הכל, מה שאנחנו עושים ב-XDA כהרגל: אנחנו רואים דליפה, אנחנו מבזיקים אותה, משתמשים בה ומצמצמים אותה. אם הוא לא עף, אנחנו פשוט מתגלגלים אחורה. כמובן, תמיד קיים סיכון מובנה בדברים מהבהבים שלא אמורים להיות במכשיר שלך מלכתחילה, אבל הסיכון של בנייה מלאה של מכשיר בימינו הוא קטן למדי. במיוחד, מכיוון שיש כלים זמינים להחזיר את המכשירים שלך מהמתים, כגון מוד בלתי ניתן ללבנה מאת מפתח מוכר XDA Elite אדם אאוטלר.
אחרי שאמרתי את זה, נראה שלא הכל בסדר בעולם ההדלפות. תודה למפתח מוכר XDA Elite אנטרופיה512, למדנו שרוב המכשירים שמקבלים דליפות נמצאים בסיכון גבוה מאוד לא להתעורר לעולם לאחר הבזק. מסתבר שיש באג גדול בליבת ה-ICS שדלפה שמשפיעה על /data מחיצה בשבב eMMC, שככל הנראה נפגם במהלך פעולות מסוימות כגון ניגוב והבהוב. במקור האמינו שהדבר משפיע רק על פעולות שבוצעו בשחזורים מותאמים אישית כגון CWM. עם זאת, היו דיווחים על לבנים קשות שהופקו מההבהוב מ התאוששות מניות גם כן. המכשירים המושפעים הם:
- את כל Epic 4G Touch (SPH-D710) דליפות ICS
- את כל Galaxy Note (GT-N7000) דליפות ICS
- ה AT&T Galaxy S II (SGH-I777) דליפת UCLD3 - וכנראה כל השאר
- מהדורות רשמיות של SHW-M250S/K/L קוריאניות וכל ליבה שנבנתה מהמקור שלהן
אנטרופי ומפתחים אחרים פרסמו כמה אזהרות הפזורות באתר, בהן הם מסבירים בפירוט מה קורה. ההצעה שלנו היא שמשתמשים צריכים להתרחק מהבהב של ICS מדליפות עד שהבאג בקרנל תוקן לחלוטין, אלא אם כן, כמובן, אתה מחפש לעצב את המכשיר שלך. זכור, זה לא משהו שניתן להחיות דרך Unbrickable Mod או אפילו דרך JTAG, מכיוון שזוהי שגיאת קושחה ב-eMMC. זה ישירות מאנטרופי עצמו לאלו מכם המעוניינים בקצת יותר פרטים:
סכנה: גרעיני דליפת ICS רבים של Samsung עלולים להזיק למכשיר שלך!
מי ששם לב להתרחשויות עם מכשירי סמסונג שונים אולי שם לב שחלק מהמכשירים חווים כמות גדולה של לבנים קשיחות כאשר נעשה שימוש בגרעיני ICS שדלפו. הלבנים הקשיחים הללו מגעילים במיוחד, בכך שספקי שירותי JTAG לא הצליחו להחיות את המכשירים הללו, בניגוד לבבנים פשוטות של מטעני אתחול-שחיתות. זה נובע מהעובדה שהגרעינים הללו מצליחים למעשה לגרום לנזק קבוע להתקן האחסון eMMC.
הגרעינים שאושרו שהושפעו הם:
[*]כל הדלפות ICS של Epic 4G Touch (SPH-D710)[*]כל הדלפות של Galaxy Note (GT-N7000) ICS[*]ה-AT&T Galaxy S II (SGH-I777) דליפת UCLD3 - וכנראה כל השאר[*]מהדורות רשמיות של SHW-M250S/K/L הקוריאניות וכל ליבה שנבנתה מהן מָקוֹר
גרעינים שצריכים להיות בטוחים הם:
[*]דליפות GT-I9100 ICS[*]מהדורות רשמיות של GT-I9100[*]גרעינים הבנויים מבסיס המקור של GT-I9100 Update4
פעולות שעלולות לגרום לנזק בעת הפעלת ליבה מושפעת:
ניגוב ב-CWM (וכנראה כל שחזור מותאם אישית אחר) (אושר)
שחזור גיבוי Nandroid ב-CWM (מגבים תחילה)
מהבהב קושחה אחרת ב-CWM (רוב ההבזקים נמחקים קודם)
ניגוב במלאי 3e שחזור (חשוד, גם מנגב מחיצה)
מחיקת קבצים גדולים בעת הפעלת ליבה מושפעת (חשוד אך לא אושר)
אם יש לך ליבה מושפעת:
הבזק גרעין טוב ידוע באמצעות Odin/Heimdall באופן מיידי. אל תשתמש ב-Mobile Odin, CWM או כל שיטה במכשיר להבהב. גרעינים טובים ידועים כוללים:
[*]כמעט כל ליבת Gingerbread[*]גרעיני ICS שנבנו מקוד המקור GT-I9100 Update4
הסיבה השורשית לבעיה זו טרם נקבעה, עם זאת, מפתחים מוכרים רבים ב-XDA חושדים שזה נובע מכך שסמסונג מאפשרת תכונה ב- גרעינים מושפעים, MMC_CAP_ERASE - זוהי תכונת ביצועים שיכולה להגביר במידה ניכרת את ביצועי הכתיבה של פלאש, אך נראה שהיא מוציאה פגם בפלאש ערכת שבבים. לגרעיני GT-I9100 ICS אין תכונה זו מופעלת והם נראים בטוחים. עם זאת, לא ידוע מספיק כדי להכריז על כל הגרעינים ללא תכונה זו בטוחה - הישות היחידה שיכולה לאשר את סיבת השורש של בעיה זו ולהכריז עליה כפתורה מבלי לקחת סיכון גדול (להרוס מספר מכשירים ללא דרך לתקן אותם) היא סמסונג עצמם.
באופן כללי, עד להודעה חדשה, אם אתה מפעיל דליפה של Samsung ICS עבור כל מכשיר מבוסס Exynos מלבד ה-GT-I9100, מומלץ מאוד להבהב משהו אחר.
וזה רק הופיע הבוקר גם בפורומים שלנו, באדיבות חבר XDA גארווין. ככל הנראה, יצרו קשר עם גוגל והם מודעים לבעיה, ומהנדס אחד מקווה לעבוד לקראת תיקון.
ובכן, עבר זמן מה אבל למרבה המזל, מר Sumrall מאנדרואיד חזר אלינו בשאלותינו. אני חושב שהקהילה תגלה שזה היה שווה לחכות.בעיה: fwrev לא מוגדר כראוי.כפי שחשדנו, תיקון הבאגים אינו במבנה שלנו. (התיקון מחיל זאת ללא תנאי.)שאלה: העדכון לא תאם את התיקון(הדגש את שלי באדום כשהוא דן בסוגיית הלבנים העל.)ציטוט:
פורסם במקור על ידי קן סומרל
התיקון כולל שורה ב-mmc.c בהגדרת fwrev לסיביות הזכויות מ-cid register. לפני התיקון הזה, הקובץ /sys/class/block/mmcblk0/device/fwrev לא אותחל מה-CID עבור התקני emmc rev 4 ומעלה, ולכן הראה אפס.(בבירור שני)fwrev הוא אפס עד להחלת התיקון.
שאלה: מדוע מחיצת /data?ציטוט:
פורסם במקור על ידי קן סומרל
כנראה שיש לך את הבאג, אבל rev 0x19 הייתה גרסה קודמת של הקושחה שהייתה לנו במכשירי האב-טיפוס שלנו, אבל מצאנו שיש לה באג אחר שאם אתה הוציא פקודת מחיקת mmc, זה יכול לדפוק את מבני הנתונים בשבב ולהוביל לכך שהמכשיר יינעל עד שהוא יופעל רכב על אופניים. גילינו זאת כאשר רבים מהמפתחים שלנו ביצעו מחיקת נתוני משתמש מהיר אתחול בזמן שפיתחנו ICS. אז סמסונג תיקנה את הבעיה ועברה לגרסה 0x25 של קושחה.כן, זה מאוד מעצבן ש-0x19 הוא 25 עשרוני, וזה הוביל להרבה בלבול בעת ניסיון לאבחן בעיות קושחה של emmc. סוף סוף למדתי _תמיד_ להתייחס לגרסת emmc בהקסדצימלית, ולהקדים את המספר ב-0x רק כדי להיות חד משמעי.למרות זאת, למרות ש-0x19 כנראה מכיל את הבאג שיכול להכניס 32 Kbytes של אפסים לתוך הפלאש, אינך יכול להשתמש בתיקון זה במכשירים עם גרסת קושחה 0x19. תיקון זה מבצע פריצה מאוד ספציפית לשני בתים של קוד בקושחה גרסה 0x25, והתיקון רוב סביר להניח שלא יעבוד על 0x19, וכנראה יגרום לשבב להתקלקל במקרה הטוב, ולאבד נתונים ב- הכי גרוע. יש סיבה שקריטריוני הבחירה כל כך מחמירים להחלת התיקון הזה על קושחת emmc.העברתי את התוצאות שלנו כמה ימים לאחר מכן וציינתי שמערכת הקבצים לא פגומה עד למחיקה. זו תגובה למעקב הזה.כפי שציינתי בפוסט הקודם, לקושחה rev 0x19 יש באג שבו שבב emmc יכול להינעל לאחר מתן פקודת מחיקה. לא בכל פעם, אבל מספיק פעמים. בדרך כלל, המכשיר יכול לאתחל לאחר מכן, אך לאחר מכן להינעל במהלך תהליך האתחול. לעתים רחוקות מאוד, זה יכול להינעל אפילו לפני טעינת fastboot. הבוחן שלך לא היה מזל. מכיוון שאתה אפילו לא יכול להפעיל את fastboot, כנראה שהמכשיר הוא לבנים. :-( אם הוא היה יכול להפעיל Fastboot, אז כנראה ניתן יהיה לשחזר את המכשיר עם קוד עדכון הקושחה שיש לי, בהנחה שאוכל לשתף אותו. אני אשאל.
שאלה: מדוע JTAG לא יעבוד?ציטוט:
פורסם במקור על ידי Ken Sumrall (אנדרואיד SE)
כי /data הוא המקום שבו השבב חווה הכי הרבה פעילות כתיבה. ל-/system אף פעם לא נכתב (למעט במהלך עדכון מערכת) ולעתים רחוקות נעשה שימוש ב-/cache (בעיקר לקבלת OTAs).
שאלה: האם ניתן לתקן מערכת קבצים פגומה (ב-eMMC)?ציטוט:
פורסם במקור על ידי קן סומרל
כפי שציינתי לעיל, לקושחת הגרסה 0x19 היה באג שאחרי פקודת מחיקת emmc, היא עלולה להשאיר את מבני נתונים פנימיים של שבב emmc במצב רע שגורמים לשבב להינעל כאשר מגזר מסוים היה ניגש. התיקון היחיד היה למחוק את השבב ולעדכן את הקושחה. יש לי קוד לעשות את זה, אבל אני לא יודע אם אני יכול לשתף אותו. אני אשאל.
אז, למרות שהתיקון לא חל עלינו כרגע, קיבלנו תובנה מצוינת לגבי נושא הסופרבריק כמו גם מידע שמתקן הוא כבר פותח (בתקווה שנראה אותו משוחרר!). הבאג כנראה חל עלינו ובהנחה שהתיקון עבור הקושחה 0x19 יינתן אז הוא יחול על המכשירים שלנו.בנימה קלה יותר, רציתי לכלול את הסגירה שלו:ציטוט:
פורסם במקור על ידי קן סומרל
e2fsck יכול לתקן את מערכת הקבצים, אך לעתים קרובות ה-32 Kbytes הוכנסו בתחילת קבוצת בלוק, שמחקה אינודות רבות, ולפיכך הפעלת e2fsck תוביל לאיבוד של קבצים רבים.
ציטוט:
פורסם במקור על ידי קן סומרל
אתה מקבל הצצה לחייו המרגשים של מפתח ליבת אנדרואיד. :-) מסתבר שהעבודה היא בעיקר לחימה עם חומרת באגי. לפחות, לפעמים זה נראה ככה.
אנא הימנעו מהבהב של כל ICS במכשירים שלכם עד שהדבר ייפתר.
רוצים שמשהו יפורסם בפורטל? צור קשר עם כל כותב חדשות.
[תודה אנטרופיה512 על כל העבודה הקשה שלך!!!]