Jump to content

    

Помогите разобраться в девайсе на DA830

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

 

Есть некая серия аппаратов, использующих аудио SoC на базе TI`шного DA830 для обеспечения основной обработки аудиопотоков\сети\USB сервисов.

Данных на него в сети практически нет, проц закрытый, вот всё, что получилось на него найти: TMS320DA830

Наиболее близким собратом, насколько я понимаю, является OMAP-L137.

 

Процессор серьёзный, но частенько возникают проблемы с его отказом.

Вероятно, связано это с внутренним преждевременным старением - Digital I/O Buffers Age Prematurely.

Согласно еррате дохнет выходной буфер клоков EMIFB контроллера и отваливается висящая на нём SDRAM.

Это, кстати, затронуло целое семейство процев, TI накосячили по полной :05:

 

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

На борту SoC не несёт никакой постоянной памяти, согласно даташиту.

 

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

То есть тема относится не столько к разработке, сколько к reverse engineering. Прошу прощения, если не туда запостил свою тему... :blush:

 

С линуксом я практически с не знаком, всё страшно и непонятно, но вот что вкратце удалось установить, подключившись к 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ам?

Share this post


Link to post
Share on other sites

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

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

 

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

Share this post


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

Зависит от того, как U-boot собран. Как правило, u-boot работает следующим образом:

1. управление передается коду из файла start.S (обычно он находится в ПЗУ);

2. выполняется начальная инициализация железа (главным образом, настройка RAM);

3. U-boot перемещает сам себя в RAM и передает туда управление (это перемещение можно отключить).

Код в start.S написан на ассемблере и, по идее, должен быть перемещаемым. Смотрите start.S в cpu/<ваша архитектура>/.

 

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

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

 

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

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

Что U-boot простой - пожалуй, правда.

Share this post


Link to post
Share on other sites
На данный момент я сдампил с помощью nanddump содержимое флеш, которое потом попробую залить на затёртый девайс.

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

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

С удовольствием прочитаю опровержение моего утверждения, основанное на положительном опыте.

 

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

Share this post


Link to post
Share on other sites
Зависит от того, как U-boot собран. Как правило, u-boot работает следующим образом:

1. управление передается коду из файла start.S (обычно он находится в ПЗУ);

2. выполняется начальная инициализация железа (главным образом, настройка RAM);

3. U-boot перемещает сам себя в RAM и передает туда управление (это перемещение можно отключить).

Код в start.S написан на ассемблере и, по идее, должен быть перемещаемым. Смотрите start.S в cpu/<ваша архитектура>/.

 

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

Процессор очень похож на 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 мегабайт.

 

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

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

Каждая секция грузится по нужному адресу. То есть, как я понимаю, секция с кодом в одно место, секция с данными - в другое и т.п.

 

Образ UBoot состоит из одной секции и грузится в память одним куском.

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

 

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

Исходников нет, как вы понимаете.

 

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

 

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

С удовольствием прочитаю опровержение моего утверждения, основанное на положительном опыте.

 

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

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

 

Именно в данном девайсе NAND не имеет бэдов.

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

 

Плюс я прикупил несколько запасных, и они тоже все читаются как 0xFF.

Тут целая проблема найти чип хотя бы с одним бэдом :biggrin:

 

Бэды маркируются в области 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, можно ли при записи её дампа точно также пропускать битые блоки? :blink:

Share this post


Link to post
Share on other sites

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

Тем более влёт запустился EMIFA с NAND контроллером.

Share this post


Link to post
Share on other sites

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

В основном разобрался.

 

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

В частности утилиту для чтения\записи флеши под DA830.

 

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

 

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

 

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

Share this post


Link to post
Share on other sites

Нагуглился вот такой документик...

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

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this