خطأ من الطوب الصلب على Galaxy S II وملاحظة نواة ICS المتسربة

click fraud protection

منذ أن وصلت إلينا أحدث التسريبات لمجموعة Samsung Galaxy S2 يمينًا ويسارًا، كان الناس يتنقلون بين ROMs بشكل رئيسي بين عربات التي تجرها الدواب وإصدارات ICS السابقة للإصدار وGB المستقر للغاية. هذا، بعد كل شيء، ما نفعله على XDA كعادة: نرى تسربًا، ونقوم بوميضه، ونستخدمه، ونقوم بتعديله. إذا لم يطير، فإننا ببساطة نتراجع. بالطبع، هناك دائمًا خطر متأصل في تفليش الأشياء التي لا ينبغي أن تكون موجودة على جهازك في المقام الأول، ولكن خطر تعطل الجهاز بالكامل في هذا اليوم وهذا العصر يعد صغيرًا إلى حد ما. خاصة وأن هناك أدوات متاحة لإعادة أجهزتك من الموت، مثل وزارة الدفاع غير قابلة للكسر بواسطة مطور XDA Elite المعترف به AdamOutler.

بعد قولي هذا، لا يبدو أن كل شيء على ما يرام في عالم التسريبات. بفضل مطور XDA Elite المعترف به الانتروبيا512لقد تعلمنا أن معظم الأجهزة التي تتلقى تسريبات معرضة لخطر كبير جدًا بعدم الاستيقاظ أبدًا بعد حدوث وميض. اتضح أن هناك خطأً كبيرًا في نواة ICS المسربة يؤثر على /data القسم الموجود في شريحة eMMC، والذي يبدو أنه يتلف أثناء عمليات معينة مثل المسح والوميض. كان يُعتقد في الأصل أن هذا يؤثر فقط على العمليات التي يتم إجراؤها في عمليات الاسترداد المخصصة مثل CWM. ومع ذلك، كانت هناك تقارير عن إنتاج الطوب الصلب من الوميض

استرداد الأسهم أيضًا. الأجهزة المتضررة هي:

  • الجميع ملحمة 4G اللمس (SPH-D710) تسربات ICS
  • الجميع جالكسي نوت (GT-N7000) تسرب ICS
  • ال ايه تي اند تي جالاكسي اس II (SGH-I777) تسرب UCLD3 - وربما جميع تسربات أخرى
  • الإصدارات الرسمية الكورية SHW-M250S/K/L وأي نواة مبنية من مصدرها

نشرت شركة Entropy وغيرها من المطورين عدة تحذيرات منتشرة في جميع أنحاء الموقع، حيث تشرح بالتفصيل ما يحدث. اقتراحنا هو أنه يجب على المستخدمين الابتعاد عن وميض ICS من التسريبات حتى يتم إصلاح الخلل الموجود في kernel بالكامل ما لم تكن بالطبع تتطلع إلى تثبيت جهازك بقوة. تذكر أن هذا ليس شيئًا يمكن إحياؤه عبر Unbrickable Mod أو حتى عبر JTAG، لأن هذا خطأ في البرنامج الثابت في eMMC. هذا مباشرة من Entropy نفسه لأولئك منكم المهتمين بمزيد من التفاصيل:

خطر: قد يؤدي تسرب العديد من نواة Samsung ICS إلى إتلاف جهازك!

ربما لاحظ أولئك الذين يهتمون بما يحدث مع أجهزة Samsung المختلفة أن بعض الأجهزة تعاني من كمية كبيرة من الطوب الصلب عند استخدام نواة ICS المسربة. هذه الطوب الصلب سيئة بشكل خاص، حيث لم يتمكن بائعو خدمات JTAG من إحياء هذه الأجهزة، على عكس الطوب الصلب البسيط الذي يسبب الفساد في أداة تحميل التشغيل. ويرجع ذلك إلى حقيقة أن هذه النوى تمكنت بالفعل من التسبب في ما يبدو أنه ضرر دائم لجهاز تخزين eMMC.

النواة التي تم التأكد من تأثرها هي:

[*] جميع تسريبات ICS Epic 4G Touch (SPH-D710)[*] جميع تسريبات ICS لجهاز Galaxy Note (GT-N7000)[*] 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 Recovery (يشتبه فيه، ويمسح أيضًا القسم)

حذف الملفات الكبيرة عند تشغيل نواة متأثرة (مشتبه به ولكن غير مؤكد)

إذا كان لديك نواة متأثرة:

قم بتحديث نواة جيدة معروفة باستخدام Odin/Heimdall على الفور. لا تستخدم Mobile Odin أو CWM أو أي طريقة موجودة على الجهاز للفلاش. تشمل النوى الجيدة المعروفة ما يلي:

[*]تقريبًا أي نواة Gingerbread[*]تم إنشاء نواة ICS من كود مصدر GT-I9100 Update4

لم يتم تحديد السبب الجذري لهذه المشكلة بعد، ومع ذلك، يشتبه العديد من المطورين المعترف بهم في XDA في أن السبب يرجع إلى تمكين Samsung لميزة في النوى المتأثرة، MMC_CAP_ERASE - هذه ميزة أداء يمكن أن تزيد بشكل كبير من أداء الكتابة بالفلاش، ولكن يبدو أنها تظهر خللًا في الفلاش شرائح. لا تحتوي نواة GT-I9100 ICS على هذه الميزة ممكّنة وتبدو آمنة. ومع ذلك، ليس هناك ما يكفي من المعلومات لإعلان أن جميع النوى التي لا تحتوي على هذه الميزة آمنة - الكيان الوحيد الذي يمكنه تأكيد السبب الجذري للمشكلة. هذه المشكلة والإعلان عن حلها دون المخاطرة الكبيرة (تدمير أجهزة متعددة دون أي وسيلة لإصلاحها) هو Samsung أنفسهم.

بشكل عام، حتى إشعار آخر، إذا كنت تقوم بتشغيل تسريب Samsung ICS لأي جهاز يعتمد على Exynos بخلاف GT-I9100، فننصح بشدة بفلاش شيء آخر.

وقد ظهر هذا في منتدياتنا هذا الصباح أيضًا، بفضل عضو XDA جاروين. من الواضح أنه تم الاتصال بشركة Google وهم على علم بالمشكلة، ويأمل أحد المهندسين في العمل على حل هذه المشكلة.

حسنًا، لقد مر بعض الوقت ولكن لحسن الحظ، قام السيد Sumrall من Android بالرد علينا بشأن أسئلتنا. أعتقد أن المجتمع سيجد أن هذا كان يستحق الانتظار.المشكلة: لم يتم ضبط fwrev بشكل صحيح.كما كنا نشك في أن الخطأ ليس موجودًا في بنيتنا. (يطبق التصحيح هذا دون قيد أو شرط.)

يقتبس:

المشاركة الأصلية كتبت بواسطة كين سومرال

يتضمن التصحيح سطرًا في إعداد mmc.c fwrev لبتات الحقوق من سجل cid. قبل هذا التصحيح، لم تتم تهيئة الملف /sys/class/block/mmcblk0/device/fwrev من CID لأجهزة emmc rev 4 وما فوق، وبالتالي أظهر صفرًا.(في الاستفسار الثاني)fwrev يساوي صفرًا حتى يتم تطبيق التصحيح.

سؤال: المراجعة لم تتطابق مع الإصلاح(قم بالتركيز على رسالتي باللون الأحمر أثناء مناقشة قضية الطوب الفائق.)

يقتبس:

المشاركة الأصلية كتبت بواسطة كين سومرال

من المحتمل أن يكون لديك الخلل، لكن rev 0x19 كان إصدارًا سابقًا من البرنامج الثابت الذي كان لدينا في أجهزتنا النموذجية، لكننا وجدنا أنه يحتوي على خطأ آخر إذا إصدار أمر مسح MMC، فقد يؤدي ذلك إلى إتلاف هياكل البيانات في الشريحة ويؤدي إلى قفل الجهاز حتى يتم تشغيله تدويرها. لقد اكتشفنا ذلك عندما كان العديد من المطورين لدينا يقومون بمسح بيانات المستخدم باستخدام Fastboot أثناء قيامنا بتطوير ICS. لذلك أصلحت Samsung المشكلة وانتقلت إلى مراجعة البرامج الثابتة 0x25.نعم، من المزعج جدًا أن يكون الرقم 0x19 هو الرقم العشري 25، مما أدى إلى الكثير من الارتباك عند محاولة تشخيص مشكلات البرامج الثابتة emmc. لقد تعلمت أخيرًا أن أشير دائمًا إلى إصدار emmc بالنظام الست عشري، وأن أسبق الرقم بـ 0x فقط لكي أكون واضحًا.لكن، على الرغم من أن 0x19 ربما يحتوي على خطأ يمكنه إدخال 32 كيلو بايت من الأصفار في الفلاش، لا يمكنك استخدام هذا التصحيح على الأجهزة التي تحتوي على مراجعة البرامج الثابتة 0x19. يقوم هذا التصحيح باختراق محدد للغاية لوحدتي بايت من التعليمات البرمجية في النسخة الثابتة 0x25، والتصحيح الأكثر شيوعًا من المحتمل ألا تعمل على 0x19، ومن المحتمل أن تتسبب في تعطل الشريحة في أحسن الأحوال، وفقدان البيانات في أسوأ. هناك سبب وراء كون معايير الاختيار صارمة للغاية لتطبيق هذا التصحيح على البرامج الثابتة emmc.لقد مررت نتائجنا بعد بضعة أيام مع الإشارة إلى أن نظام الملفات لم يفسد حتى عملية المسح. وهذا رد على تلك المتابعة.كما ذكرت في المنشور السابق، يحتوي البرنامج الثابت rev 0x19 على خطأ حيث يمكن قفل شريحة emmc بعد إعطاء أمر المسح. ليس في كل مرة، ولكن في كثير من الأحيان بما فيه الكفاية. عادةً، يمكن إعادة تشغيل الجهاز بعد ذلك، ولكن بعد ذلك يتم قفله أثناء عملية التمهيد. نادرًا جدًا، يمكن قفله حتى قبل تحميل Fastboot. كان المختبر الخاص بك سيئ الحظ. نظرًا لأنه لا يمكنك حتى بدء التشغيل السريع، فمن المحتمل أن يكون الجهاز معطوبًا. :-( إذا كان بإمكانه تشغيل Fastboot، فمن المحتمل أن يتم استرداد الجهاز باستخدام رمز تحديث البرنامج الثابت الموجود لدي، على افتراض أنه يمكنني مشاركته. سأسأل.

السؤال: لماذا قسم / البيانات؟

يقتبس:

المشاركة الأصلية كتبت بواسطة كين سومرال (Android SE)

لأن /data هو المكان الذي تشهد فيه الشريحة معظم أنشطة الكتابة. لا تتم كتابة /system أبدًا (إلا أثناء تحديث النظام) ونادرًا ما يتم استخدام /ذاكرة التخزين المؤقت (في الغالب لتلقي وكالات السفر عبر الإنترنت).

سؤال: لماذا لن تعمل JTAG؟

يقتبس:

المشاركة الأصلية كتبت بواسطة كين سومرال

كما ذكرت أعلاه، كان لدى البرنامج الثابت للمراجعة 0x19 خطأ أنه بعد أمر مسح emmc، يمكن أن يترك هياكل البيانات الداخلية لشريحة emmc في حالة سيئة تتسبب في قفل الشريحة عندما يكون هناك قطاع معين الوصول إليها. كان الإصلاح الوحيد هو مسح الشريحة وتحديث البرنامج الثابت. لدي رمز للقيام بذلك، ولكن لا أعرف إذا كان بإمكاني مشاركته. سأسأل.

سؤال: هل يمكن إصلاح نظام الملفات التالف (على eMMC)؟

يقتبس:

المشاركة الأصلية كتبت بواسطة كين سومرال

يمكن لـ e2fsck إصلاح نظام الملفات، ولكن غالبًا ما يتم إدراج 32 كيلو بايت في بداية مجموعة الكتل، مما يؤدي إلى مسح العديد من inodes، وبالتالي فإن تشغيل e2fsck غالبًا ما يؤدي إلى فقدان العديد من الملفات.

لذلك، على الرغم من أن الإصلاح لا ينطبق علينا في الوقت الحالي، فقد حصلنا على نظرة ثاقبة حول مشكلة الطوب الفائق بالإضافة إلى معلومات تفيد بأن الإصلاح يكون تم تطويره بالفعل (نأمل أن نرى إصداره!). من المحتمل أن ينطبق الخطأ علينا وبافتراض أن الإصلاح الخاص بالبرنامج الثابت 0x19 قد تم تطبيقه على أجهزتنا.في ملاحظة أخف، أردت أن أذكر وثيقته:

يقتبس:

المشاركة الأصلية كتبت بواسطة كين سومرال

أنت تحصل على لمحة عن الحياة المثيرة لمطور Android kernel. :-) تبين أن المهمة تتعارض في الغالب مع الأجهزة التي تجرها الدواب. على الأقل، يبدو الأمر كذلك في بعض الأحيان.

يرجى الابتعاد عن وميض أي شيء ICS على أجهزتك حتى يتم حل هذه المشكلة.

هل تريد نشر شيء ما في البوابة؟ اتصل بأي كاتب أخبار.

[شكرًا الانتروبيا512 على كل ما تبذلونه من العمل الشاق !!!]