Форум разработчиков электроники ELECTRONIX.ru > Помогите разобраться в девайсе на DA830

Помощь - Поиск - Пользователи - Календарь

Полная версия этой страницы: Помогите разобраться в девайсе на DA830

Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > Linux

sonycman

Nov 16 2014, 16:07

Всем доброго дня!

Есть некая серия аппаратов, использующих аудио SoC на базе TI`шного DA830 для обеспечения основной обработки аудиопотоков\сети\USB сервисов.
Данных на него в сети практически нет, проц закрытый, вот всё, что получилось на него найти: TMS320DA830
Наиболее близким собратом, насколько я понимаю, является OMAP-L137.

Процессор серьёзный, но частенько возникают проблемы с его отказом.
Вероятно, связано это с внутренним преждевременным старением - Digital I/O Buffers Age Prematurely.
Согласно еррате дохнет выходной буфер клоков EMIFB контроллера и отваливается висящая на нём SDRAM.
Это, кстати, затронуло целое семейство процев, TI накосячили по полной

В общем, после замены DA830 аппараты поднимаются не всегда, чаще всего бьётся NAND флеш и приходится её менять\восстанавливать.
На борту SoC не несёт никакой постоянной памяти, согласно даташиту.

Так вот - проблема в том, чтобы правильно разобраться в структуре разделов NAND и правильно их перешить\восстановить.
То есть тема относится не столько к разработке, сколько к reverse engineering. Прошу прощения, если не туда запостил свою тему...

С линуксом я практически с не знаком, всё страшно и непонятно, но вот что вкратце удалось установить, подключившись к UART порту процессора:

Загрузка U-Boot:

Код

U-Boot 1.3.3-svn1998 (Mar  5 2012 - 08:10:29)

DRAM:  64 MB
NAND:  NAND Manufacturer id: 98
NAND Device id: 76
NAND device: Manufacturer ID: 0x98, Chip ID: 0x76 (Toshiba NAND 64MiB 3,3V 8-bit)
Bad block table found at page 131040, version 0x01
Bad block table found at page 131008, version 0x01
64 MiB
In:    serial
Out:   serial
Err:   serial
ARM Clock : 400000000 Hz

Hit any key to stop autoboot:  1

U-Boot > help

?       - alias for 'help'
askenv  - get environment variables from stdin
autoscr - run script from memory
base    - print or set address offset
boot    - boot default, i.e., run 'bootcmd'
bootd   - boot default, i.e., run 'bootcmd'
bootm   - boot application image from memory
bootp    - boot image via network using BootP/TFTP protocol
cmp     - memory compare
coninfo - print console devices and information
cp      - memory copy
crc32   - checksum calculation
dhcp    - invoke DHCP client to obtain IP/boot params
echo    - echo args to console
exit    - exit script
fatinfo - print information about filesystem
fatload - load binary file from a dos filesystem
fatls   - list files in a directory (default /)
forceenv  - force set environment variables
go      - start application at address 'addr'
help    - print online help
iminfo  - print header information for application image
imxtract- extract a part of a multi-image
itest    - return true/false on integer compare
loadb   - load binary file over serial line (kermit mode)
loads   - load S-Record file over serial line
loady   - load binary file over serial line (ymodem mode)
loop    - infinite loop on address range
md      - memory display
mdc     - memory display cyclic
mii     - MII utility commands
mm      - memory modify (auto-incrementing)
mtest   - simple RAM test
mw      - memory write (fill)
mwc     - memory write cyclic
nand    - NAND sub-system
nboot   - boot from NAND device
nfs    - boot image via network using NFS protocol
nm      - memory modify (constant address)
ping    - send ICMP ECHO_REQUEST to network host
printenv- print environment variables
rarpboot- boot image via network using RARP/TFTP protocol
reset   - Perform RESET of the CPU
run     - run commands in an environment variable
saveenv - save environment variables to persistent storage
saves   - save S-Record file over serial line
setenv  - set environment variables
sleep   - delay execution for some time
test    - minimal test like /bin/sh
tftpboot- boot image via network using TFTP protocol
usb     - USB sub-system
usbboot - boot from USB device
version - print monitor version

U-Boot > printenv

baudrate=115200
bootfile="uImage"
verify=n
ethaddr=00:09:b0:47:11:08
filesize=F48000
setparam=ok
bootcmd=nboot.jffs2 0xc0200000 0 0x454000
bootargs=console=ttyS1,115200n8 root=/dev/mtdblock8 rw quiet lpj=999424 rootfstype=yaffs mem=52M ip=off
autostart=yes
bootdelay=1
dspboot=yes
stdin=serial
stdout=serial
stderr=serial
ver=U-Boot 1.3.3-svn1998 (Mar  5 2012 - 08:10:29)

Environment size: 372/16380 bytes

U-Boot > help nand

nand info                  - show available NAND devices
nand device [dev]     - show or set current device
nand read[.jffs2]     - addr off|partition size
nand write[.jffs2]    - addr off|partition size - read/write `size' bytes starting
    at offset `off' to/from memory address `addr'
nand erase [clean] [off size] - erase `size' bytes from
    offset `off' (entire device if not specified)
nand bad - show bad blocks
nand dump[.oob] off - dump page
nand scrub - really clean NAND erasing bad blocks (UNSAFE)
nand markbad off - mark bad block at offset (UNSAFE)
nand biterr off - make a bit error at offset (UNSAFE)
nand lock [tight] [status] - bring nand to lock state or display locked pages
nand unlock [offset] [size] - unlock section

Дальше линукс и таблица разделов NAND:

Код

MontaVista(R) Linux(R) Professional Edition 5.0.0 (0802607)

Welcome to MontaVista(R) Linux(R) Professional Edition 5.0.0 (0802607).

Jan 1 00:01:51 login[253]: root login on 'console'

# cat /proc/mtd
dev: size erasesize name
mtd0: 00004000 00004000 "params"
mtd1: 00010000 00004000 "2ndbl"
mtd2: 00040000 00004000 "bootloader"
mtd3: 00200000 00004000 "dsp1"
mtd4: 00200000 00004000 "dsp2"
mtd5: 00200000 00004000 "kernel"
mtd6: 00004000 00004000 "bootconf1"
mtd7: 00004000 00004000 "bootconf2"
mtd8: 01000000 00004000 "filesystem1"
mtd9: 01100000 00004000 "filesystem2"
mtd10: 01100000 00004000 "filesystem3"
mtd11: 00400000 00004000 "filesystem4"
mtd12: 003a4000 00004000 "filesystem5"

Блок NAND насчитывает 32 странички по 512 байт + 16 байт oob\ecc, не знаю, как их правильно обозвать.
На данный момент я сдампил с помощью nanddump содержимое флеш, которое потом попробую залить на затёртый девайс.

Проблема ещё в формате ecc данных. Расположение и формат у них разный, в зависимости от раздела.

Вот oob байты странички NAND образа ядра kernel image:

Код

OOB Data: 08 f7 3c ff ff ff ff ff ff ff ff ff ff ff ff ff

Похоже на 1 bit ecc.

А вот UBoot:

Код

OOB:
OOB Data: ff ff ff ff ff ff 53 66 d5 2b d8 25 aa c3 80 cc

Здесь уже 4 bit ecc и расположение другое.

А вот oob странички одного из разделов файловой системы:

Код

OOB Data: 4f 4f 88 ff ff ff ff ff 00 00 10 00 05 01 04 00

Третий вариант

Пока не понял, что это. Это относится к YAFFS2?

Ещё из под линукса команда nanddump выдаёт кучу предупреждений вида

Код

ECC: 1 corrected bitflip(s) at offset 0x00000200

и этими своими коррекциями бьёт образы разделов, записанных с 4 битным ECC:
2ndbl
bootloader
dsp1
dsp2

Видимо, какая то несовместимость драйверов nand линукса и rombootloader (который грузит эти разделы)?

Пока сдампил эти разделы из под UBoot`а, но там неудобно, так как нет поддержки записи дампов на внешний носитель.
Я вообще не уверен, делает ли команда nand read из под UBoot какую то проверку ecc?

Исходников, понятно, нет никаких

Можно ли как то определить таблицу разделов прямо из UBoot?

ЗЫ: модераторам - может быть, лучше перенести тему в раздел по ARMам?

sonycman

Dec 24 2014, 17:30

Вопрос чайника по поводу UBOOT - можно ли его грузить и запускать с любого адреса в SDRAM, или он компилируется не релоцируемым?
Можно ли его загрузить и запустить из встроенной SRAM памяти процессора?

Судя по заголовку бинарника UBOOT, он весьма простой и состоит только из одного модуля.

alx2

Dec 25 2014, 10:16

Цитата(sonycman @ Dec 24 2014, 23:30)

Вопрос чайника по поводу UBOOT - можно ли его грузить и запускать с любого адреса в SDRAM, или он компилируется не релоцируемым?

Зависит от того, как U-boot собран. Как правило, u-boot работает следующим образом:
1. управление передается коду из файла start.S (обычно он находится в ПЗУ);
2. выполняется начальная инициализация железа (главным образом, настройка RAM);
3. U-boot перемещает сам себя в RAM и передает туда управление (это перемещение можно отключить).
Код в start.S написан на ассемблере и, по идее, должен быть перемещаемым. Смотрите start.S в cpu/<ваша архитектура>/.

Цитата(sonycman @ Dec 24 2014, 23:30)

Можно ли его загрузить и запустить из встроенной SRAM памяти процессора?

С учетом вышесказанного, скорее всего, можно, если ваш контроллер вообще позволяет выполнять код из внутреннего ОЗУ, и если сам u-boot его не использует.

Цитата(sonycman @ Dec 24 2014, 23:30)

Судя по заголовку бинарника UBOOT, он весьма простой и состоит только из одного модуля.

Не понял это фразу. Не знаю, что за бинарник Вы смотрите, и что у него там за заголовок, а также что вы называете модулем.
Что U-boot простой - пожалуй, правда.

svss

Dec 25 2014, 11:51

Цитата

На данный момент я сдампил с помощью nanddump содержимое флеш, которое потом попробую залить на затёртый девайс.
Проблема ещё в формате ecc данных. Расположение и формат у них разный, в зависимости от раздела.

Я б сказал, что скопировать NAND - дохлый номер. Проблема именно в ECC. Мала вероятность, что у Вас не будет плохих блоков в NAND. (я - не теоретик, а ел тот кактус)
С удовольствием прочитаю опровержение моего утверждения, основанное на положительном опыте.

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

sonycman

Dec 25 2014, 16:14

Цитата(alx2 @ Dec 25 2014, 14:16)

Процессор очень похож на OMAP-L137.
Загрузка устройства происходит так:
1. Запускается DSP и RBL (ROM bootloader) загружает во внутреннюю SRAM небольшой UBL из NAND - User Bootloader.
2. UBL инициализирует внешнюю SDRAM и загружает в неё из NAND UBoot и приложение для DSP.
3. Запускается ARM и начинает выполнять код юбута в SDRAM по адресу 0xc1080000. DSP выжидает пару секунд в пустом цикле и начинает выполнять приложение для DSP по адресу 0xc3800000.

Размер SDRAM 64 мегабайта начиная с 0xc0000000. То есть юбут лежит со смещением в 16,5 мегабайт от начала а для DSP отводятся последние 8 мегабайт.

Цитата(alx2 @ Dec 25 2014, 14:16)

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

Образы UBoot и DSP имеют хидеры с перечислением секций, из которых они состоят и точку входа Entry Point.
Каждая секция грузится по нужному адресу. То есть, как я понимаю, секция с кодом в одно место, секция с данными - в другое и т.п.

Образ UBoot состоит из одной секции и грузится в память одним куском.
А вот образ (приложение) для DSP состоит из 20 секций и каждая из них при разворачивании UBL`ом дополнительно проходит декомпрессию, значительно увеличивая в размерах.

Код юбута пока не трассировал, возможно, там будет своя распаковка.
Исходников нет, как вы понимаете.

Юбут, как я понимаю, использует кучу, которая инициализируется по строго заданному адресу?

Цитата(svss @ Dec 25 2014, 15:51)

Про NAND мне тоже очень интересно было бы пообщаться!

Именно в данном девайсе NAND не имеет бэдов.
Установлена NAND256W3A2 - 2048 блока с 32-мя страницами по 528 байт (512 + 16 байт OOB).

Плюс я прикупил несколько запасных, и они тоже все читаются как 0xFF.
Тут целая проблема найти чип хотя бы с одним бэдом

Бэды маркируются в области OOB данных первой и второй страницы каждого блока.
1. Код RBL процессора проверяет первые 6 байт - если хоть один не равен 0xFF - то блок битый. ECC аппаратный с возможностью корректировки 4-ёх ошибочных бит, ECC данные занимают 10 байт в области OOB.
Таким образом записаны UBL, UBOOT и образ DSP.

2. Юбут и линукс имеют другую схему ECC - однобитную, ECC данные занимают всего 3 байта в области OOB.
С такой кодировкой записаны ядро линукса и его файловые системы.

Так вот, битые блоки при загрузке UBL, UBOOT и DSP просто скипаются. То есть при копировании исходной NAND в новую (вместе с ECC данными, конечно), при обнаружении бэда тупо скипаем его и берём следующий.
То же самое, думаю, делает и UBOOT при загрузке ядра системы.

А вот с файловыми системами не уверен. Тип FS в bootargs указан как YAFFS, можно ли при записи её дампа точно также пропускать битые блоки?

Tarbal

Jan 9 2015, 00:59

Да. Негусто информации:
http://www.ti.com/sitesearch/docs/universa...0DA830#linkId=1

sonycman

Jan 9 2015, 09:10

Проц очень похож на OMAP-L137. По крайней мере, мне удалось написать небольшую программку под него с инициализацией PLL, PSC, таймера и UART.
Тем более влёт запустился EMIFA с NAND контроллером.

gosha-z

Jan 10 2015, 15:27

Так гораздо более информативно. Особенно в части linux bootup

sonycman

Jan 10 2015, 15:41

Тишный сайт я уже излазил вдоль и поперёк.
В основном разобрался.

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

Не трудно, в общем, но нюансы есть.

Ещё было бы интересно увидеть софтовую реализацию на Си рассчёта 4 бит ECC кода, аппаратная поддержка которого присутствует в DA830.

С рассчётом 1 бит ECC вроде всё просто.

gosha-z

Jan 10 2015, 16:12

Нагуглился вот такой документик...
И еще: U-Boot видит тошибовскую NAND память, а вы ссылаетесь, видимо, на STшную. Чему верить?

Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.