Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
UniFi U6 Plus полностью кирпич – зависает перед U-Boot (MT7981 "BL2: Failed to load image id 3"), UniFi Network
 
Привет всем, я пытаюсь восстановить UniFi U6 Plus, который перестал загружаться после обновления прошивки. После обновления до версии 6.7.31 точка доступа стала отображаться как офлайн в контроллере UniFi. Даже после 10 минут ожидания она осталась офлайн.

Когда я отключил и заново подключил кабель PoE, светодиод загорелся белым примерно на одну секунду, а затем погас. Даже после долгого ожидания точка доступа так и не вернулась в онлайн.

Я попытался выполнить сброс к заводским настройкам (удержание кнопки reset более 10 секунд) без результата, а также не смог перевести устройство в режим восстановления UniFi. Поведение светодиода всегда одинаково: белый свет на одну секунду после подключения PoE, а затем ничего.

Я подключился к плате через UART (AZDelivery CH340G @ 115200 8N1) и получил следующий вывод с последовательного порта:

NOTICE:  CPU: MT7981 (1300MHz)
NOTICE:  EMI: Detected DRAM size: 256MB
ERROR:   MSDC: CRC error occured while reading data with cmd=8, arg=0x0
ERROR:   MSDC: CRC error occured while reading data with cmd=17, arg=0x3400
ERROR:   BL2: Failed to load image id 3 (-5)

U-Boot приглашение отсутствует, и нажатие каких-либо клавиш (пробел, f и т.д.) во время загрузки не помогает.

Похоже, U-Boot или прелоадер повреждены на eMMC, и устройство зависло на ранней стадии загрузки.

Буду признателен за любые советы или опыт восстановления U6 Plus в таком состоянии.
 
За февраль погибло ещё 5 штук, пришлось заменять за свой счёт — по регламенту ЕС это признавалось бы производственным браком и подлежало бы замене, но нам отказывают в RMA. Возраст устройств — от 1 до 3 лет, и для небольшой компании это серьёзный удар по бюджету, времени и репутации.
 
Аналогичная ситуация и здесь.... Ubiquiti отклоняет РМА или затрудняет возврат, вместо того чтобы честно признать, что есть или была проблема с качеством!
 
После того как несколько месяцев назад у меня были проблемы с 11 U6+, которые не обновлялись и пришлось запускать скрипт восстановления u6. Теперь у меня 7 мёртвых U6+. У всех одинаковая проблема — белый круг загрузки и ничего не работает. У меня есть ещё минимум 30 точек доступа из той же партии — предполагаю, что оставшиеся 4 тоже выйдут из строя в ближайшие месяцы после перезагрузки или обновления прошивки. Открыл тикет в поддержке Unifi 5532867. Все они вышли из гарантии 5 месяцев назад. 😡
 
Маловероятно. Доступа к USB-пинам нет. Кроме того, потребуется другая сборка BL2 и/или U-boot, так как это другая конфигурация. Единственное, что я мог бы предложить как крайний способ — припаять контакты "emmc to TF Card" к резисторам (см. предыдущий пост). Однако существующие дорожки к припаянному emmc придётся перерезать. Я знаю, что Ubiquiti отклоняют претензии по гарантии, но здесь явный физический дефект, которого быть не должно, в сочетании с очень чувствительным к помехам emmc. Я бы настаивал на замене по гарантии. Если всё же не удастся добиться RMA, лучше обратиться в сервис для замены emmc и переноса данных. Однако стоит попробовать мой модифицированный BL2 — отключи автоматические обновления и отключи логирование по максимуму. Может, система будет работать стабильно ещё какое-то время. Как только всё загрузится в память успешно, должно работать. Сбросьте factory partition и EEPROM при первой же возможности для подстраховки. Иначе восстановление даже после замены emmc не будет возможным.
 
Вот ещё один...
 
Могу говорить только от себя, но мне приходится платить за доставку, чтобы отправить AP. Кроме того, они не делают кросс-доставку. Интересно, видят ли другие то же самое.
 
Привет, возврат продавцу бесплатный?
 
Когда USB-Serial подключен к UART на материнской плате, я получаю только этот вывод:
 
Снял чип и сразу же заметил, что под ним есть потрескавшиеся контакты. Есть некоторые площадки, сильно окисленные (красные), и другие площадки, которые окислены не так сильно (синие), но похоже, что они не обеспечивали хороший контакт, так как припой на них не прилипал, в отличие от остальных хороших площадок. Я проверил несколько подозрительных контактов платы мультиметром, и похоже, что некоторые из них — это линии eMMC, включая один контакт с сигналом nRST. Ранее реализованные обходные решения компенсировали предельные проблемы целостности сигнала, поэтому они и работали. Мой блок также полностью работает с исходной прошивкой теперь, когда чипы переправлены. Итак, в итоге: сценарий 2 был отчасти правильным в том, что eMMC получал плохие данные и, вероятно, постоянно перезагружался, что приводило к отказу (аналогичный тип отказа, как у BBB, вызванный агрессивными функциями управления питанием). Следует отметить, что eMMC MK27 менее устойчив к обработке этих ошибок и постоянных перезагрузок, но, справедливости ради, он пережил нелёгкую жизнь! Я использовал чип M627 примерно месяц и не заметил никаких битовых ошибок, коррупции данных или чего-либо в регистрах extCSD, что указывало бы на проблему. Проблема контроля процесса и контроля качества при производстве привела к этим неудачным припойным соединениям. Это могли быть тепловые прокладки, которые были слишком толстыми и жёсткими, создавая физическое давление и в итоге растрескивая припойные шарики или создавая холодные соединения прямо на заводе. Термоциклирование в итоге приводит к плохому контакту, высокому сопротивлению и плохой целостности сигнала, как только припойные шарики растрескались. Картина теперь совершенно ясна.
 
Да, оригинальная прошивка.
 
С оригинальным BL2? Я откладывал перепайку на конец, если ничего больше не помогало бы, но сейчас я могу попробовать. Треснувший паяный контакт под MT7981 мог бы объяснить ошибки контрольной суммы, так как это нарушает калибровку MSDC задержки (или туning площадок). Я не нашёл никаких физических проблем при проверке линий данных с помощью зонда, но в этой точке кто его знает!
 
Я думаю, что замена конденсатора была ложным следом. Я положил устройство на полку на пару дней, и оказалось, что оно больше не загружается. Так что да, похоже, это были холодные паяные соединения. В итоге я переделал шарики на MT7981 и на микросхеме оперативной памяти рядом с ней — это решило проблему окончательно, уже три недели без сбоев.
 
Кроме того, хочу отметить, что мой раздел "factory" по-прежнему работает несмотря на все ошибки битов. Я не знаю, какие долгосрочные последствия это будет иметь, но все мои радиомодули работают и правильно настроены, насколько я могу судить.
 
Привет всем, я экспериментировал со своим устройством и получил дополнительную информацию. Я учел комментарии @versor и также сумел восстановить свое устройство с модифицированным BL2, однако это не совсем то же самое, и моя собранная версия сохраняет ширину шины 8-бит и полную скорость. Я восстановил свой U6+ путем увеличения силы драйвера на всех линиях при запуске до предположительно 6 мА. Это решило все ошибки CRC, и теперь я могу стабильно загружаться с шириной шины x8 на полной скорости. Кстати, 40 МГц при запуске — это ожидаемое поведение для поддержания стабильности во время настройки силы драйвера. Перед этим я также подавал внешнее питание на все шины питания, чтобы исключить какие-либо проблемы с питанием. На моем конкретном устройстве я наблюдал только 20 мВ пульсаций, что хорошо укладывается в норму, но я также попробовал модификацию конденсатора развязки без каких-либо изменений в поведении.

Логически размышляя, поскольку ошибка отказа eMMC произошла на других устройствах с совершенно другим SoC, микросхемы MK27 действительно имеют проблемы. Я считаю, что в этих устройствах существует многоуровневый каскадный режим отказа. Могут быть верны следующие сценарии:

1) Неисправная микросхема MK27 деградировала и увеличила нагрузку на контроллер MT7981 MSDC (контроллер SD/eMMC), что привело к деградации контроллера SoC.

2) Деградация контроллера MT7981 MSDC создала стресс на контроллер MK27, что привело к ошибкам.

3) Так как я не знаю, какова была исходная сила драйвера оригинального BL2, я не могу с уверенностью сказать, какой была конфигурация Ubiquiti, но она могла быть неправильной для этой конкретной eMMC. MT7981 может быть абсолютно нормальным.

Одновременно может быть верно несколько вещей: неисправная микросхема MK27 и другие дополнительные проблемы, приводящие к отказу. Тот факт, что регистры CSD показывают ускоренный износ, а также битовые ошибки в самой файловой системе указывают на то, что микросхема eMMC неисправна во всех сценариях. По сути, это капризная микросхема: стоит только посмотреть на нее неправильно, не говоря уже о неправильной подаче напряжения, как она сама развалится и заберет ваши деньги с собой!

Снижение ширины шины до x1 определенно сработает, так как это помогает с перекрестными помехами и целостностью сигнала на уровне платы, но это как запускать свою RAM DDR5 на 8000 МТс на 4800 МТс. Конечно, это будет стабильно, но это не соответствует спецификации.

Я также попробовал установить резисторы подтягивания на свободные площадки на линиях данных, чтобы получить более чистые фронты, но это не помогло.

Я использовал интерпозер eMMC, чтобы иметь возможность быстро менять микросхему eMMC. Я обнаружил, что использование eMMC марки Samsung было немного лучше с оригинальным BL2, но это все равно не решило проблему.

Еще раз, единственное, что помогло, — это увеличение силы драйвера при запуске. Мой модифицированный BL2 можно найти на github "/sam-413/Bricked-U6Plus-eMMC-Workaround/". Используйте на свой риск. Все, что сказал @versor о том, что любые последующие обновления могут нарушить функциональность, по-прежнему применимо.

Имейте в виду, что MK27 по-прежнему, вероятно, неисправна, и все вышесказанное относится к замененной микросхеме eMMC.
 
У меня то же самое, обновление не проходило, поэтому я попробовал перезагрузку, а с тех пор устройство не может выполнить сброс к заводским настройкам или перейти в режим TFTP — просто горит белый светодиод сразу после включения. Устройство вышло из гарантии около 6 месяцев назад, и они отказали в RMA-претензии. Обидно, что, похоже, обновление окончательно повредило устройство и мы не можем ничего с этим поделать, кроме как купить другую точку доступа.
 
Ещё один "кирпич" U6+ здесь. После кратковременного отключения электричества на пару секунд он перестал загружаться. Единственный признак жизни — короткая вспышка светодиода менее чем на 1 секунду после перезагрузки питания, а потом ничего. Невозможно выполнить сброс к заводским настройкам или перейти в режим TFTP.
 
На мой взгляд, компании Ubiquiti следует признать, что с довольно большим количеством точек доступа U6+ что-то серьёзно не так, исходя из нашего опыта. Либо проблема в микросхеме NVRAM, либо прошивка слишком часто записывает в неё данные. Влияет ли включение инструментов отладки на количество операций записи?

Кстати, и, возможно, это совершенно не связано — на одном объекте мы заметили, что точки доступа отказывают намного чаще. Мы уже заменили все U6+ в прошлом году, так как они все вышли из строя. Теперь замены тоже начинают отказывать, то есть отказ происходит примерно через год после установки.

На этом объекте есть кое-что странное — начиная с зимы 2024 года (их установили летом) мы получили много жалоб, когда только поставили U6+. Люди жаловались, что не могут подключиться к сети. В интерфейсе управления показывались высокие помехи на всех точках доступа с большим количеством повторных передач на частоте 2,4 ГГц. Учитывая, что рядом со зданием практически ничего нет, это казалось очень странным. После некоторого расследования мы выяснили, что все обогреватели в здании работают в режиме обнаружения Wi-Fi (около 30 устройств). Они заполняли частоту 2,4 ГГц и не давали пользователям подключиться. Как только мы добавили их все в приложение Tuya, всё вернулось в норму. К сожалению, люди постоянно включали и выключали обогреватели через выключатель питания, что приводило к потере настроек, и проблема начиналась заново каждый раз, когда кто-нибудь включал обогреватель!

Это единственное странное на этом объекте... На этом объекте у нас включены инструменты отладки. Где-нибудь логируется количество операций записи в микросхемы NVRAM? Означает ли включение инструментов отладки сохранение журналов в NVRAM?
 
Насколько вероятно, что USB флешку или SD карту можно использовать в качестве загрузочного устройства? Не каждый сможет переделать микросхемы, но припаять несколько проводов под силу большинству.
 
Добавляю себя в список... РМА отправлена, но я понял, что мой U6+ уже 2,5 года в использовании и куплен через дистрибьютора, поэтому РМА вряд ли будет одобрена без споров. Ubiquity должна это признать, потому что я не уверен, смогу ли я убедить себя покупать у них ещё точки доступа, если такое будет повторяться.
Страницы: 1 2 След.
Читают тему (гостей: 1)