Версия hw smc k1 hw v1 какой процессор

Обновлено: 06.07.2024

1. HW платы блока
2. Диагностика CAN/KLine
3. Репрог: CAN/KLine
4. Какая из трех контактов KL используется.

Давайте вместе составим грамотную и правильную таблицу.

I414DE06 M74 11183-1411020-02 HW V3.7 DIA: K-line D2; PRG K-line D2
I414DE07 M74 11183-1411020-02 HW V3.7 DIA: K-line D2; PRG K-line D2

I455AEK3 11186-1411020-08, HW: V4.15_R4

I445GCT2 11186–1411020-43, HW: 4.12, DIA: CAN, PRG: Kline H3(G3)

I445GDT2 11186 – 1411020 - 43 , HW: 6.38.2

I445GBT2 11186 -1411020- 47, HW: V4.15 R4, DIA: CAN, PRG:H3

I455GDT4 11186-1411020-48, HW: V4.15, DIA: CAN, PRG: Kline H3(G3)

I445GBK2 11186-1411020-49, HW: V4.12 R4, DIA: CAN

I445DA01 21116–1411020-50, HW 4.15, DIA: CAN, PRG: Kline
I445DA01 21116–1411020-50 HW 4.15 DIA: CAN, PRG: Kline

I444CC03 11183–1411020-52, HW: V3.7, DIA: KLine, PRG: KLine D2
I444CD04 11183-1411020-52, HW: V3.7 DIA: K-line D2; PRG K-line D2
I444CE06 11183–1411020-52, HW: V6.21, DIA: KLine, PRG: KLine D2

I444GI04 11183 –1411020- 62, HW: V6.36, DIA: CAN, PRG:D2
I444GS10 11183 – 1411020-62 HW6.37R2 DIA: CAN, PRG:D2

I464SG03 21126 -1411020- 77, HW: V6.37 R2, DIA: CAN, PRG:D2

I464AG08 21126 -1411020- 90, HW: V6.37, DIA: CAN, PRG:D2
I467GI09 21126-1411020-90, HW 6.37
I464AE05 21126- 1411020- 90, HW 6.37 DIA:CAN PRG: CAN


I465AGK5 21126-08, DIA: CAN; PRG: K-Line H3

I474DD05 21127-1411020-90, HW: 6.38.2, DIA: CAN, PRG: CAN

I474GH05 21127 -1411020- 62, HW: 6.38.2, DIA: CAN, PRG:D2

I475GBK5 21127 –1411020- 39, HW: 4.15 R4, DIA: CAN, PRG:H3

I484AD06 11186 -1411020- 90, HW: 6.37 R2, DIA: CAN, PRG:D2
I484AD06 11186-1411020-90, HW: 6.37 R2

I484GI06 11186-1411020-22, HW: 6.36, DIA: CAN, PRG: CAN + Kline D2
I484GR15 11186 -1411020- 22, HW: 4.12, DIA: CAN, PRG:H3(G3)
I484GR16 11186 -1411020- 22, HW: 4.12, DIA: CAN, PRG:H3
I484GQ14 11186-1411020-22, HW: 4.12, DIA: CAN, PRG: Kline H3(G3)
I484GR16 11186-1411020-22, HW: 4.12
I484GP12 11186–1411020-22, HW: 4.12 DIA: CAN, PRG: Kline (G3)
I484GG03 11186 –1411020 -22, HW: 6.34, DIA:CAN, PRG:CAN, K-Line:D2

I484DE06, 21116-1411020-12, V3.7, DIA: K-Line D2, PRG: K-Line D2

I484GK08, HW: 6.36, считал флэш 768 кБ.

I445GBK2 11186-1411020-49 плата версии V4.15_R4

I484DG01 21116-1411020-22 плата версии 6.37



M74.5

I427GE05 21127-1411020-22 HW: 6.38.1 DIA: Kline G3, PRG: Kline G3
I427GD04 21127-1411020-22 HW: 6.38.1 DIA: Kline G3, PRG: Kline G3

Дамп доступен на ссылка скрыта от публикации

Информация Неисправность Прошивки Схемы Справочники Маркировка Корпуса Сокращения и аббревиатуры Частые вопросы Полезные ссылки

Справочная информация

Этот блок для тех, кто впервые попал на страницы нашего сайта. В форуме рассмотрены различные вопросы возникающие при ремонте бытовой и промышленной аппаратуры. Всю предоставленную информацию можно разбить на несколько пунктов:

  • Диагностика
  • Определение неисправности
  • Выбор метода ремонта
  • Поиск запчастей
  • Устранение дефекта
  • Настройка

Неисправности

Все неисправности по их проявлению можно разделить на два вида - стабильные и периодические. Наиболее часто рассматриваются следующие:

  • не включается
  • не корректно работает какой-то узел (блок)
  • периодически (иногда) что-то происходит

О прошивках

Большинство современной аппаратуры представляет из себя подобие программно-аппаратного комплекса. То есть, основной процессор управляет другими устройствами по программе, которая может находиться как в самом чипе процессора, так и в отдельных микросхемах памяти.

На сайте существуют разделы с прошивками (дампами памяти) для микросхем, либо для обновления ПО через интерфейсы типа USB.

Схемы аппаратуры

Начинающие ремонтники часто ищут принципиальные схемы, схемы соединений, пользовательские и сервисные инструкции. Это могут быть как отдельные платы (блоки питания, основные платы, панели), так и полные Service Manual-ы. На сайте они размещены в специально отведенных разделах и доступны к скачиванию гостям, либо после создания аккаунта:

Справочники

На сайте Вы можете скачать справочную литературу по электронным компонентам (справочники, таблицу аналогов, SMD-кодировку элементов, и тд.).

Marking (маркировка) - обозначение на электронных компонентах

Современная элементная база стремится к миниатюрным размерам. Места на корпусе для нанесения маркировки не хватает. Поэтому, производители их маркируют СМД-кодами.

Package (корпус) - вид корпуса электронного компонента

При создании запросов в определении точного названия (партномера) компонента, необходимо указывать не только его маркировку, но и тип корпуса. Наиболее распостранены:

  • DIP (Dual In Package) – корпус с двухрядным расположением контактов для монтажа в отверстия
  • SOT-89 - пластковый корпус для поверхностного монтажа
  • SOT-23 - миниатюрный пластиковый корпус для поверхностного монтажа
  • TO-220 - тип корпуса для монтажа (пайки) в отверстия
  • SOP (SOIC, SO) - миниатюрные корпуса для поверхностного монтажа (SMD)
  • TSOP (Thin Small Outline Package) – тонкий корпус с уменьшенным расстоянием между выводами
  • BGA (Ball Grid Array) - корпус для монтажа выводов на шарики из припоя

Краткие сокращения

При подаче информации, на форуме принято использование сокращений и аббревиатур, например:

Сокращение Краткое описание
LEDLight Emitting Diode - Светодиод (Светоизлучающий диод)
MOSFETMetal Oxide Semiconductor Field Effect Transistor - Полевой транзистор с МОП структурой затвора
EEPROMElectrically Erasable Programmable Read-Only Memory - Электрически стираемая память
eMMCembedded Multimedia Memory Card - Встроенная мультимедийная карта памяти
LCDLiquid Crystal Display - Жидкокристаллический дисплей (экран)
SCLSerial Clock - Шина интерфейса I2C для передачи тактового сигнала
SDASerial Data - Шина интерфейса I2C для обмена данными
ICSPIn-Circuit Serial Programming – Протокол для внутрисхемного последовательного программирования
IIC, I2CInter-Integrated Circuit - Двухпроводный интерфейс обмена данными между микросхемами
PCBPrinted Circuit Board - Печатная плата
PWMPulse Width Modulation - Широтно-импульсная модуляция
SPISerial Peripheral Interface Protocol - Протокол последовательного периферийного интерфейса
USBUniversal Serial Bus - Универсальная последовательная шина
DMADirect Memory Access - Модуль для считывания и записи RAM без задействования процессора
ACAlternating Current - Переменный ток
DCDirect Current - Постоянный ток
FMFrequency Modulation - Частотная модуляция (ЧМ)
AFCAutomatic Frequency Control - Автоматическое управление частотой

Частые вопросы

Как мне дополнить свой вопрос по теме База прошивок эфирных DVB-T2 ресиверов?

После регистрации аккаунта на сайте Вы сможете опубликовать свой вопрос или отвечать в существующих темах. Участие абсолютно бесплатное.

Кто отвечает в форуме на вопросы ?

Ответ в тему База прошивок эфирных DVB-T2 ресиверов как и все другие советы публикуются всем сообществом. Большинство участников это профессиональные мастера по ремонту и специалисты в области электроники.

Как найти нужную информацию по форуму ?

Возможность поиска по всему сайту и файловому архиву появится после регистрации. В верхнем правом углу будет отображаться форма поиска по сайту.

По каким еще маркам можно спросить ?

По любым. Наиболее частые ответы по популярным брэндам - LG, Samsung, Philips, Toshiba, Sony, Panasonic, Xiaomi, Sharp, JVC, DEXP, TCL, Hisense, и многие другие в том числе китайские модели.

Какие еще файлы я смогу здесь скачать ?

При активном участии в форуме Вам будут доступны дополнительные файлы и разделы, которые не отображаются гостям - схемы, прошивки, справочники, методы и секреты ремонта, типовые неисправности, сервисная информация.

Полезные ссылки

Здесь просто полезные ссылки для мастеров. Ссылки периодически обновляемые, в зависимости от востребованности тем.

Год релиза 2017

Поддержка сетей 4G (LTE) нет

Количество SIM-карт 2 SIM

Диагональ экрана (дюйм) 5"

Разрешение экрана 854x480

Технология изготовления экрана IPS

Модель процессора MediaTek MT6580

Объем оперативной памяти 1 ГБ

Объем встроенной памяти 8 ГБ

Слот для карты памяти есть

Максимальный объем карты памяти 32 ГБ

Количество мегапикселей основной камеры (Мп) 5

Разрешение снимков 2592x1944

Версия Bluetooth 4.0

Стандарт WiFi 802.11b, 802.11g, 802.11n

Бесконтактная технология оплаты нет

Интерфейс micro USB

Разъем для наушников Mini Jack 3.5 мм

Тип аккумулятора Li-Ion

Емкость аккумулятора (мАч) 2200 мАч

Прикрепленное изображение

Причина редактирования: Восстановил бутлуп, полос больше нет

Аппараты Vertex Impress Luck имеют две ревизии.
Типы серийных номеров ревизии 1:
VLCK0517
VLCKHW10917
VLCKHW11017
VLCKHW10118
VLCKHW10218
Прошивка HW1.R2M.V21 в шапке.

Типы серийных номеров ревизии 2:
VLCK0518

Прошивка HW1.R1N.V03 в шапке

Позвонил оператору "Теле2" - про такой номер не знают.
Забил в гугл - вроде как это продавец платного мобильного контента . в Индии.
Пойду ща возвращать. (( Хотя смартфон сам относительно шустренький.

не могу забыл все пароль и т.д гугл мешает попасть в меню все перепробовал но спасет прошивка через флеш тул но прошивки не найти ( Купил сегодня, через 4 часа первый косяк - телефон сам отправляет смс на номер 56060.
У меня было:
for sale tracker test string text358882080456444.

Странно, у меня такого не было.

Про СМС ничего такого нет.. Динамик очень тихий. Что разговорный, что мультимедийный. Шустрый, ничего в прошивку и не надо добавлять. Поднял немного громкости через инженерку, скачал Volume+, стало получше. Кажется, не работает датчик приближения. Вообще не знаю что спереди за датчик. Больше на светодиодную вспышку похож. Во время звонка экран не гаснет. Выключаю кнопкой питания. Сенсор работает немного кривовато, но это не порок для такой цены. А так в целом аппаратом доволен.

Да, проблемы со стандартной звонилкой. В номеронабирателе вечная ошибка, что "приложение дало сбой и было остановлено". Лечится путём скачивания с Маркета другой звонилки. Больше проблем не нашёл.

Hostes, у меня вот с микрофоном проблема была, был очень тихий, решил через инженерное меню. А вот со звонилкой проблем у меня нету.

Наверное, ни для кого не секрет, что в последнее время облачные сервисы видеонаблюдения набирают популярность. И понятно почему так происходит, видео — это "тяжелый" контент, для хранения которого необходима инфраструктура и большие объемы дискового хранилища. Использование локальной системы видеонаблюдения требует средств на эксплуатацию и поддержку, как в случае организации, использующей сотни камер наблюдения, так и в случае индивидуального пользователя с несколькими камерами.


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

Есть несколько технологических способов подключения камер к облаку. Бесспорно, наиболее удобный и дешевый способ — камера напрямую подключается и работает с облаком, без участия дополнительного оборудования типа сервера или регистратора.

Для этого необходимо, чтобы на камере был установлен модуль ПО работающий с облаком. Однако, если говорить про дешевые камеры, то у них очень ограничены аппаратные ресурсы, которые почти на 100% занимает родная прошивка вендора камеры, а ресурсов необходимых для облачного плагина — нет. Этой проблеме разработчики из ivideon посвятили статью, в которой говорится почему они не могут установить плагин на дешевые камеры. Как итог, минимальная цена камеры — 5000р ($80 долларов) и миллионы потраченных денег на оборудование.

Мы эту проблему успешно решили. Если интересно как — велком под кат

В 2016 году мы стартовали разработку платформы облачного видеонаблюдения для Ростелекома.

В части ПО камер на первом этапе пошли "стандартным" для таких задач путем: разработали свой плагин, который устанавливается в штатную прошивку камеры вендора и работает с нашим облаком. Однако, стоит отметить, что при проектировании мы использовали наиболее легковесные и эффективные решения (например, plain C реализацию protobuf, libev, mbedtls и полностью отказались от удобных, но тяжелых библиотек типа boost)

Сейчас на рынке IP камер нет универсальных решений по интеграции: у каждого вендора свой способ установки плагина, свой набор API для работы прошивки и уникальный механизм обновления.

Это означает, что для каждого вендора камер необходимо индивидуально разрабатывать объемный слой интеграционного ПО. И на момент старта разработки целесообразно работать только с 1-ним вендором, что бы сосредоточить усилия команды на разработке логики работы с облаком.

Первым вендором был выбран Hikvision — один из мировых лидеров на рынке камер, предоставляющий хорошо документированное API и грамотную инженерную техническую поддержку.

На камерах Hikvision мы и запустили наш первый пилотный проект облачное видеонаблюдение Видеокомфорт.

Практически сразу после запуска наши пользователи стали задавать вопросы о возможности подключении к сервису более дешевых камер других производителей.

Вариант с реализацией слоя интеграции под каждого вендора я отбросил практически сразу — как плохо масштабируемый и предъявляющий к железу камеры серьезные технические требования. Стоимость камеры, удовлетворяющий таким требованиям на входе:

Поэтому, я принял решение копать глубже — сделать полностью свою прошивку для камер любых вендоров. Этот подход существенно снижает требования к аппаратным ресурсам камеры — т.к. слой работы с облаком на порядок более эффективно интегрирован с video application, и в прошивке нет лишнего не используемого жирка.

И что важно, при работе с камерой на низком уровне есть возможность использовать аппаратный AES, который шифрует данные, не создавая дополнительной нагрузки на маломощный CPU.


В тот момент у нас не было вообще ничего. Вообще ничего.

Практически все вендоры не были готовы работать с нами на таком низком уровне. Информации о схемотехнике и компонентах — нет, официальных SDK чипсетов и документации сенсоров — нет.
Технической поддержки так же нет.

Ответы на все вопросы приходилось получать реверс инжинирингом — методом проб и ошибок. Но мы справились.

Первыми моделями камер, на которых мы набивали шишки стали камеры Xiaomi Yi Ants, Hikvision, Dahua, Spezvision, D-Link и несколько сверх дешевых безымянных китайских камер.

Камеры на чипсете Hisilicon 3518E. Аппаратные характеристики камер такие:


Xiaomi Yi Ants Noname
SoC Hisilicon 3518E Hisilicon 3518E
RAM 64MB 64MB
FLASH 16MB 8MB
WiFi mt7601/bcm43143 -
Sensor ov9732 (720p) ov9712 (720p)
Ethernet - +
MicroSD + +
Microphone + +
Speaker + +
IRLed + +
IRCut + +

С них мы начинали.

Сейчас поддерживаем чипсеты Hisilicon 3516/3518, а так же Ambarella S2L/S2LM. Количество моделей камер — десятки.

uboot

uboot — это начальный загрузчик, после включения питания загружается первым, инициализирует оборудование и загружает ядро linux.

Скрипт загрузки камеры достаточно тривиален:

Из особенностей — два раза вызывается bootm , подробнее об этом чуть позже, когда дойдем до подсистемы обновления.

Обратите внимание на строчку mem=38M . Да, да, это не опечатка — ядру Linux и всем-всем-всем приложениям доступно всего лишь 38 мегабайт оперативной памяти.

Так же рядом с uboot находится специальный блок, называемый reg_info , в котором находится низкоуровневый скрипт инициализации DDR и ряда системных регистров SoC. Содержимое reg_info зависит от модели камеры, и если оно будет не корректным, то камера даже не сможет загрузить uboot, а зависнет на самом раннем этапе загрузки.

Первое время, когда мы работали без поддержки вендоров, мы просто копировали этот блок из оригинальной прошивки камеры.

Ядро linux и rootfs

На камерах используется ядро Linux, входящее в состав SDK чипа, обычно это не самые свежие ядра из ветки 3.x, поэтому часто приходится сталкиваться с тем, что драйвера дополнительного оборудования не совместимы с используемым ядром, и нам приходится их бэк-портировать под ядро камеры.

Другая проблема — это размер ядра. Когда размер FLASH всего 8MB, то каждый байт на счет и наша задача — аккуратно отключить все не используемые функции ядра, что бы сократить размер до минимума.

Rootfs — это базовая файловая система. В нее включены busybox , драйвера wifi модуля, набор стандартных системных библиотек, типа libld и libc , а так же ПО нашей разработки, отвечающее за логику управления светодиодами, управление сетевыми подключениями и за обновление прошивки.

Корневая файловая система подключена к ядру как initramfs и в результате сборки мы получаем один файл uImage , в котором есть и ядро и rootfs.

Video application

Наиболее сложная и ресурсоемкая часть прошивки — приложение, которое обеспечивает видео-аудио захват, кодирование видео, настраивает параметры картинки, реализует видео-аналитики, например, детекторы движения или звука, управляет PTZ и отвечает за переключения дневного и ночного режимов.

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

В традиционных решениях 'прошивка вендора + облачный плагин', которые не могут работать на дешевом железе, видео внутри камеры передается по протоколу RTSP — а это огромный оверхед: копирование и передача данных через socket, лишние syscall-ы.

Мы в этом месте используем механизм shared memory — видео не копируется и не пересылается через socket между компонентами ПО камеры, тем самым оптимально и бережно используя скромные аппаратные возможности камеры.


Подсистема обновления

Предмет отдельной гордости — подсистема fault-tolerant онлайн обновления прошивки.

Поясню проблематику. Обновление прошивки — это технически не атомарная операция и в случае если посередине обновления произойдет сбой питания, то на флеш памяти будет часть "недозаписанной" новой прошивки. Если не предпринять специальных мер, то камера после этого станет "кирпичом", который нужно нести в сервисный центр.

Мы справились и с этой проблемой. Даже если камеру выключить в момент обновления, она автоматически и без участия пользователя скачает прошивку из облака и восстановит работу.

Разберем технику подробнее:

Наиболее уязвимый момент — перезапись раздела с ядром Linux и корневой файловой системой. В случае, если один из этих компонентов окажется поврежденным, то камера вообще не загрузиться дальше начального загрузчика uboot, который не умеет скачивать прошивку из облака.

Значит, нам нужно обеспечить гарантию наличия на камере работоспособного ядра и rootfs в любой момент процесса обновления. Казалось бы самым простым решением было бы постоянно хранить на флеш памяти две копии ядра с rootfs и в случае повреждения основного ядра загружать его из резервной копии.

Годное решение — однако, ядро с rootfs занимает около 3.5MB и для постоянной резервной копии нужно выделить 3.5MB. На самых дешевых камерах просто нет столько свободного места под backup ядра.

Поэтому для backup ядра во время обновления прошивки используем application партицию.
А для выбора нужной партиции с ядром как раз и используется две команды bootm в uboot — в начале пытаемся загрузить основное ядро и если оно повреждено, то резервное.


Это гарантирует, что в любой момент времени на камере будет корректное ядро с rootfs, и она сможет загрузиться и восстановить прошивку.

CI/CD система сборки и деплоя прошивок

Для сборки прошивок мы используем gitlab CI, в котором автоматически собираются прошивки под все поддерживаемые модели камер, после сборки прошивки автоматически деплоятся на сервис обновления ПО камер.


Из сервиса обновления ПО прошивки доставляются на тестовые камеры наших QA, а по завершению всех этапов тестирования и на камеры пользователей.

Информационная безопасность

Ни для кого не секрет, что в наше время информационная безопасность — это важнейший аспект любого IoT устройства, в том числе и камеры. По интернету гуляют ботнеты типа Mirai, поражающие миллионы камер со стандартными прошивками от вендоров. При всем уважении к вендорам камер, не могу не отметить, что в стандартных прошивках заложено много функционала, который не востребован для работы с облаком, однако содержит в себе много уязвимостей, которыми пользуются ботнеты.

Поэтому, весь не используемый функционал в нашей прошивке отключен, все tcp/udp порты закрыты и при обновлении прошивки проверяется цифровая подпись ПО.

И кроме этого, прошивка проходит регулярное тестирование в лаборатории информационной безопасности.

Сейчас наша прошивка активно используется в проектах по видеонаблюдению. Пожалуй самый масштабный из них — трансляция голосования в день выборов Президента Российской Федерации.
В проекте было задействовано более 70 тысяч камер с нашей прошивкой, которые были установлены по избирательным участкам нашей страны.

Решив ряд сложных, а местами, даже на тот момент практически невозможных задач, мы, конечно, получили огромное удовлетворение как инженеры, но кроме этого, и сэкономили миллионы долларов на закупке камер. И в данном случае, экономия — это не только слова и теоретические расчёты, а результаты уже случившегося тендера на закупку оборудования. Соответственно, если говорить про облачное видеонаблюдение: есть два подхода — стратегически заложиться на низкоуровневую экспертизу и разработку, получив на выходе огромную экономию на оборудовании или использовать дорогое оборудование, которое, если смотреть именно на потребительские характеристики, практически ничем не отличается от аналогичного дешевого.

Почему стратегически важно принять решение относительно выбора подхода к способу интеграции как можно раньше? При разработке плагина, разработчики закладываются на те или иные технологии (библиотеки, протоколы, стандарты). И если выбран набор технологий только под дорогое оборудование, то в дальнейшем попытка перехода на дешевые камеры с большой вероятностью, как минимум, займет безумно большое время или вообще потерпит неудачу и произойдет возврат к дорогому оборудованию.

Читайте также: