Прошивка. Не остановить загрузку u-boot RVI-IPC43M3 (AT88SC)

08-01-2018 23:28

Помогите определить, что с камерой RVI-IPC43M3, для дальнейших действий.
Есть две камеры с одинаковыми симптомами, похожих на слёт прошивки. Т.е. Комп видит сеть несколько секунд, потом отвал соединения, и так по кругу (похоже на цикличный ресет).
Подключался к камере через USB-TTL + tftp+ NCOM для её прошивки. Примерно так советует производитель. Но, не как не могу остановить загрузку u-boot для изменения адреса tftp- сервера. Пробовал нажатия снежинки * в разных последовательностях и ctrl-c и многое другое. Теперь думаю, что дело в слетевшем u-boot или в еппром с крипто защитой (AT88SC0104CA). А в чём конкретно, и какие возможно предпринять действия с данной еппром, обращаюсь за помощью к вам. Думаю, что по логу, что то скажите. Спасибо.
Лог снятый NCOM:[/img]

ncom.txt 14,1 КБ Скачано: 42 раз(а)

09-01-2018 09:11

AT88SC0104CA ни при чем. Если бы бут слетел, то вы бы не получили этот лог. Бут останавливается только в первый момент старта. Попробуйте другой TTL-адаптер или другую терминальную программу.
PS. покажите лог в читабельном виде, например:
U-Boot 2010.06-svn1316 (Jul 11 2014 - 17:28:55)

DRAM: 512 MiB
Check spi flash controller v350... Found
Spi(cs1) ID: 0xC2 0x20 0x18 0xC2 0x20 0x18
Spi(cs1): Block:64KB Chip:16MB Name:"MX25L128XX"
the size of spi flash is 0x1000000
In: serial
Out: serial
Err: serial
user init finish.cpu type: hi3535
can't find corresponding entry
### CRAMFS LOAD ERROR for /bmp_logo.bmp!
load log failed
Hit any key to stop autoboot: 0
netup time out: 1000
Timeout
TFTP from server 192.168.254.254; our IP address is 192.168.1.108
Download Filename 'upgrade_info_7db780a713a4.txt'.
Download to address: 0x80100000
Downloading: *
ARP Retry count exceeded; starting again
Failed to get info.txt
### JFFS2 loading '/boot/uImage' to 0x82000000
squashfs use lzma
### squashfs loading '/boot/uImage' to 0x82000000
squashfs use lzma
### squashfs load complete: 2544536 bytes loaded to 0x82000000
## Booting kernel from Legacy Image at 82000000 ...
Image Name: Linux-3.4.35_hi3535
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2544472 Bytes = 2.4 MiB
Load Address: 80008000
Entry Point: 80008000
Loading Kernel Image ... OK
OK

Starting kernel ...

т.к. не понятно почему у вас идет стирание и запись во флешь.

09-01-2018 13:05

Vladimir26, извиняюсь за лог, сам не посмотрел чё там выложил. Сегодня наконец то ответила поддержка rvi и скинула другую прошивку. Вечером повожусь. Смущает то, что нет строки с возможностью остановки бута.

Цитата:

U-Boot 2010.06-svn (Jun 09 2014 - 08:55:39)
I2C: ready
DRAM: 254 MiB
NAND: 128 MiB
state:ff,err_count:02
Net: Detected MACID:90:02:a9:6b:c1:15
PHY:0x00221513,addr:0x00
TFTP from server 192.168.254.254; our IP address is 192.168.1.108; sending through gateway 192.168.1.1
Filename 'upgrade_info_7db780a713a4.txt'.
Load address: 0xc5000000
Loading: *
Retry count exceeded; starting again
Fail to get info file!
Init error!
TFTP from server 192.168.254.254; our IP address is 192.168.1.108; sending through gateway 192.168.1.1
Filename 'failed.txt'.
Load address: 0xc2000000
Loading: *
Retry count exceeded; starting again
## Booting kernel from Legacy Image at c2000000 ...
Image Name: Linux-2.6.38.8
Created: 2014-04-26 4:22:35 UTC
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 2546876 Bytes = 2.4 MiB
Load Address: c0208000
Entry Point: c0208000
Verifying Checksum ... OK
Loading Kernel Image ...OK
OK
crashflasg:1, logmagic:54410011.
Starting kernel ...
1..2..3..boot_from:normal

09-01-2018 20:26

С прошивкой от поддержки RVI - всё также. Лишь выяснил по файлам прошивки, что они используются в камерах Dahua: IPC-HFW5202CP-L;IPC-HFW5302CP-L (Group_IPC-HX5(4)XXX_RusEng_P_Stream3_V2.420.GP00.0.R.20150108)
После просмотра моего лога, поддержка написала, что скорее всего у камеры слетела загрузочная область и мне необходимо обратиться в сервисный центр.
Возможно ли такое, что загрузчик слетел частично, и по этому нет возможности его остановить?
Если всё таки дело в загрузчике, если возможность его восстановить?
Вот как я вижу это решение.
1. Перепаять с убитой камеры, рабочую AT88SC с живым загрузчиком, т.к. слить не получиться (еепром с защитой). - не вариант.
2. Найти в сети, либо запросить у поддержки содержимое еепром, необходимого для данной камеры, залить его в пустую at88sc0104ca, либо в любую другую еепром необходимого размера (если это прокатит), запаять на место.
Поправьте, что не так. Или направьте в нужном направлении. Спасибо

09-01-2018 21:39

в AT88SC нет никакого загрузчика...для других целей она. Загрузчик в другой флеши и, судя по логу, она у вас NAND. Можете фото платы в качестве выложить куда-нить? И полный дамп этой флеши не помешало бы. Частичный слет бута не встречал, хотя, наверное, все возможно. Если есть 100% родная прошивка, то бут восстановить можно, но, повторюсь, надо смотреть полный дамп и дальше - программатор.

14-01-2018 11:27

Здравствуйте!
Стыдно признаться, но с остановкой бута, решил проблему другой комп. Накрылись ещё 2 камеры: у одной аналог трабл., вторая - напруги в норме, но даже не видно её через сом порт. Да, ладно... чёрт с ней. Т.е. сейчас имеется 3 камеры с одинаковыми проблемами.
Короче, после процедуры обновления tftp + ncom( run up) , процесс минут 7 идёт, и пошел процесс только через свитч, на прямую не видит нормально камеру. Перезагружаю, и всё как было так и осталось - ребутится и по кругу., на ресет не реагирует. Смотрел процесс загрузки в рабоче камере - доходит до загрузки kernel и всё ( дальше наверное грузится прошивка).
Дайте дельный совет, что ещё можно сделать и в чём возможно дело. Лог прилагаю - с начала процесс обновления, потом команда help, потом printenv. Спасибо.

ncom_20180113.1350_194.txt 26,25 КБ Скачано: 28 раз(а)

15-01-2018 21:11

freeman_81 писал:

Накрылись ещё 2 камеры: у одной аналог трабл., вторая - напруги в норме, но даже не видно её через сом порт. Да, ладно... чёрт с ней. Т.е. сейчас имеется 3 камеры с одинаковыми проблемами.

Решил глянуть, что же с камерой которая даже через rs232 не откликается. Т.к. напруги, потребление аналогичны остальным камерам, то решил перекинуть nand F59L1G81A с полудохлой камеры. Итог - дохлая камера стала как все остальные (полудохлой) .
Вот теперь и думаю, возможно ли, что дело в F59L1G81A, т.к. большинство нанд дохли частично, а одна полностью? По этому и перепрошивка 3 камер, не дала результата.

16-01-2018 07:50

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

16-01-2018 12:59

Vladimir26, а возможно ли слить содержимое с нанд-флеши на ПК с помощью загрузчика, т.е. выполнив определённые команды? Если да, то какие?

16-01-2018 20:58

Да, возможно, только что это вам даст? Ведь вы же считаете данные вместе с бэдами, а как вы их потом определите? Объясните, пожалуйста, смысл этого действа

17-01-2018 01:38

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

17-01-2018 08:23

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

17-01-2018 09:35

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

17-01-2018 13:41

Как я понял, мне дамп пойдет даже с бэдами, лиж бы они не касались загрузчика т.е. подойдёт и дамп с моей нанд (загрузчик вроде как работает). Дамп этот залить в новую флеш, а исправный загрузчик уже распакует вайлы прошивки туда куда надо, тем самым перепишит файлы на не прочитанные сектора, т.к. флеш будет исправна. Или я что то не понемаю? Спасибо

17-01-2018 22:50

Выкладываю лог:
set dh_keyboard 0
saveenv
https://yadi.sk/i/wf_ICnpo3RYe7M
В конце лога загрузки, перед рестартом - вот какие вылазят ошибки. Не связанны ли они с крипто-памятью? т.е. AT88sc? Замечал, что батарейки на платах, были сильно высаженные.

Цитата:

[m[0;32;32m00:00:10|[pdc] PDC Driver Initial OK !
[m[0;35m00:00:10|[OSA-DRV] recordTsk Task pid=842 tid=842
[m[0;32;32m00:00:10|[pdc] SramFile_devRelease OK!
[mCATEGORY = 2
IPC Device
[0;32;32m00:00:10|[crypt] platType = [1], DM36X = [0], A5S_CRYPT = [1], hi351x=[2].
[m[0;32;32m00:00:10|[crypt] major = [231], minor = [0]
[m[0;32;32m00:00:10|[crypt] CRYPT_setChipOps ......
[m[0;32;32m00:00:10|[crypt] CRYPT_authenticate ......
[merror: write byte error
error: write_nbytes failed
error: authentication failed
error: authenticate failed
[0;32;31m00:00:10|[crypt] ERROR (/home/fang_qipin/test/test/P_2013.02.22_CryptoMemory_DM8127_IPC/build/../src/crypt.c|crypt_init|1203): CRYPT_authenticate failed!
[m[0;32;31m00:00:10|[crypt] ERROR (/home/fang_qipin/test/test/P_2013.02.22_CryptoMemory_DM8127_IPC/build/../src/crypt.c|crypt_init|1204): reboot........
[m
U-Boot 2010.06-svn (Nov 22 2014 - 14:59:40)
DRAM: 254 MiB
NAND: 128 MiB