Добрый день.

Есть плата на AM1705, 16M SDRAM, NAND. Пересобрал u-boot из SDK, добавил поддержку платы, сделал AIS образ AISGen, записал в NAND при помощи CCS4.
Поднял на вирутальной машине tftp сервер, взял образ ядра из SDK. Ядро нормально загружается по сети, разворачивается и ему передается управление. После передачи управления в консоли появляется одна строка мусора. Косоль заведена на UART0;

Подскажите, куда смотреть?

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

В предыдущем выводе так и было.

Пересобрал ядро, включил early debug :



Дополнительно исправил файлы :
debug_macro.S


board-da830-evm.c:


uncompress.h:



После запуска u-boot дополнительно настроил переменные :


Загрузил по tftp и попробовал запустить, получил мусор в консоли.



Как то у меня идеи пока кончились.

в параметрах ядру передайте( добавьте в bootargs ) еще:

и покажите лог

Больше похоже на то что baud rate на uart-ах не совпадает. Если с у четом того что советовали



появится часть нормальных сообщений после


то на инит UART в ядре нужно смотреть и править.

am1808, sasamy Спасибо! Взял стабильное ядро с кернел.орг, добавил опцию earlyprintk, стало видно, что валится при попытке инициализации пинов I2C



Выкинул инициализацию i2c, и ядро загрузилось, теперь буду rootfs over NFS подключать.

Помогите пожалуйста. Пытаюсь загрузить U-boot из NAND (проц. AM1705), по UART грузится нормально, в NAND по tftp тоже все передается, в NAND пишится. Переставляю пины на загрузку из NAND, и ничего не получается. В консоле тишина, потребление по току не меняется в сети не появляется, с перефирийе не общоятся. Проверял осциллографом ножки NAND (CS и данные), какие-то попытки чтения есть. Собираюсь поменять процессор, думаю что я его подпортил, так как других обьяснений нет. Бинарник подготавливал при помощи AisGen (отдельно для UART и отдельно для NAND).

А если прочитать-сравнить?


Не торопитесь: вероятность "подпортить" процессор так, чтобы с NAND проходили любые операции, кроме загрузки, практически нулевая.

Сравнивал, и при помощи комманды cpm и просто глазками читал, нмкаких ошибок, все совпадает.
Настройки CE3CFG регистра тоже проверял и перепроверял, когда делал прошивку для NAND.


Дело в том, что несколько дней назад каратнул питание, после чего плата стала много кушать. Только в режеми простоя порядка 140 мА до этого было 50 мА. (хотя проверял пальцем, никакой из чипов не греется).
И проверенный u-boot, который до этого работал без проблем стал почему-то зависать где-то после 10 минут работы или простоя. Поэтому и грешу на железо... хотя мне только что пришла в голову мысль, что могла испортится NAND...

Но при этом пишется, читается и данные совпадают? Как-то сомнительно.

PavelG таже проблема. Если гружу по UART все ок, все работает. NAND пишется/читается нормально как из под u-boot, так и в linux. Согласно документации NAND висит на CS3. Пины установлены для загрузки из NAND и при старте корректно считываются (JTAG у меня нет поэтому контролировал наличие обращение к NAND по CS3). Осциллографом контролирую тактовый сигнал на SDRAM и собственно он так и не появляется.
А теперь по порядку:
1) подготовка файла u-boot.
Согласно документации возможна загрузка сразу u-boot без использования UBL. Для этого необходимо обработать бинарный файл U-boot при помощи утилиты AisGen. Причем, если испльзуется оконный AisGen, то берется u-boot (файл без расширения, находится в директории куда собирался u-boot) к нему нужно добавить расширение .out. Можно использовать и u-boot.bin, но только с HexAIS и указанием адреса входа.
Делал: HexAis-OMAP-L137.exe -i <файл .ini> -o u-boot.ais -entrypiont 0xc1080000 u-boot.bin@0xc1080000
Редактировал файл ini... Прчем в ini режим загрузки всегда NONE. Включал/отключал настройки переферии.
Ничего не помогает.
2) Загружаю по UART рабочий образ u-boot. Далее по tftp скачиваю образ для nand и записываю его.
#tftp 0xc0700000 u-boot-nand.bin
#nand erase
#nand write 0xc0700000 0x20000 0x40000

То, что nand пишется - проверено.
3) Выключаю питание
4) Устанавливаю перемычки для загрузки из nand
5) Включаю питание
6) Активность на CS3 есть (по документации должен считываться блок), тактовой на SDRAM нет, UART молчит как рыба об лед.

Что не так?
- NAND из поддерживаемых. Код по таблице 0xF1 (Micron 128MiB 2048 на страницу, 64 страницы на блок). Может адрес 0х20000 (куда кладу образ) не верен?
- Мне кажется, что застревает где-то на обработке сценария Ais загрузчиком RBL.
- Делал парсинг образа (aisparse.exe) все - вроде нормально.
Уже идеи кончились.

А у Вас, DenchikS, уже и ядро лежит во флешке?

Нет. ядро и файловая подтягиваются u-bootом по сети с tftp сервера. Тут проблем нет.
ПС: Если не стартует u-boot, то смысл писать во флешку ядро?

DenchikS PavelG
Для процессора 1705 у меня получилось записать u-boot в NAND память и загрузиться из NAND памяти :
1. Собрал u-boot
2. Обработал elf файл u-boot AISGen-ном, получил AIS образ
3. Записал образ в NAND при помощи Code Composer Studio и проекта NANDWriter (из пакета OMAP-L137_FlashAndBootUtils_2_20)

Если писать образ u-boot самим u-boot то не заполняются биты OOB: (не работает ECC?). Я очень хочу отказаться от ССS, но пока не получается.

Лог записи образа в NAND память при помощи Code Composer Stodio (через программатор BlackHawk):

Из лога видно, что писать он начинает с блока 1, у моей памяти размер блока 16К, т.е. смещение от начала NAND памяти 0х4000
После старта u-boot я посмотрел дамп NAND



Если я пишу образ u-boot средствами u-boot, дамп отличается и процессор не стартует.
Как я пишу в u-boot
1. Гружу u-boot через uart
slh_OMAP-L137.exe -v -waitForDevice -p COM1 u-boot_ti_1705_test.bin
2. Загружаю образ u-boot по сети, протокол tftp
setenv netmask 255.0.0.0
setenv ipaddr 192.168.0.10
setenv serverip 192.168.0.5
tftp u-boot_ti_1705_test.bin
3. Пишу в NAND
nand erase 0x4000 0x40000
nand write.e 0xc0700000 0x4000 0x40000
4. Ресет и плата не стратует (биты OOB не заполнены!)

Спасибо Иван, видно тоже придется через JTAG шить, заодно я узнал как все-таки начальный адрес выбирать, а то я считал, что он должен быть 0x20000 (читал старый мануал по U-boot, и там была карта памяти NAND).
Есть один вопрос к Вам, какую версию U-boot Вы используете? Дело в том, что последнюю версию как-то модифицировали, и при компиляции elf файл другого формата получается и AisGen (тот что в GUI) уже не может с ними работать, а с консольным прощивальщиком я так и не познакомился. Можно-ли у Вас попросить inf файл для консоли, с настройками, или совет по его созданию?

Спасибо за информацию. Однако прискорбно. Обнаружил еще один момент:
1) загрузка u-boot - обнаруживает отсутствие таблицы bad block и создает ее.
2) если перезагрузится из того же u-boot, то при следующей загрузке таблицы находятся. Но если загрузить ядро, то оно типа тоже определяет отсутствие таблицы (хотя u-boot как бы ее создал) и создает ее, а при перезагрузке уже u-boot не видит таблицу созданую ядром.
Чувствую косяк в настройках, но u-boot или kernel?

PavelG
Сейчас я использую версию из sdk_1_10_00_01, uboot-03.20.00.12. Более новые версии у меня не получалось конвертировать в AIS образ, но сегодня я нашел следующий способ :

Попробую свежую версию запустить, вроде там больше команд для работы с NAND памятью. Особенно меня интересует команда "nandecc hw".

DenchikS
Да, есть такое дело. Как я думаю это проблема в том что в ядре и u-boot разные таблицы ECC. По идее более свежая версия u-boot должна решить эту проблему. Обсуждалось ТУТ

Поправил таблицу как описано в http://processors.wiki.ti.com/index.php/DM...Nand_ECC_layout. Стал запускаться такт на SDRAM. Но UART вообще ничего не передает в линию.
Все же интересно было бы глянуть Ваш ini.

Что еще любопытно, когда запускал плату были проблемы с загрузкой по UART (у меня используется UART0). Если включить настройку LPCS, вообще не грузится. Отсюда сделал вывод, что модули UART по умолчанию включены. Возможно, что начальный загрузчик после определения источника загрузки выключает остальную периферию?

То PavelG: Если я правильно понимаю, то адрес куда кладется u-boot определяется геометрией самой флеш. У меня каждый блок это 64 страницы по 2048 байт каждая, таким образом адрес должен быть 64*2048=131072= 0х20000.

DenchikS Спасибо за ссылку, очень помогло! У есть проверенный u-boot, который работает через UART0, могу переслать на почту. До меня дошло сегодня фразы с форума что uboot-тов должно быть два, а именно : первый чтобы загрузиться, второй который пишется во флеш память.
Для генерации AIS образа я использовал AISGen for D800K003, он имеет GUI интерфейс, также при работе он создает ini файл настроек, который я использовал как пример для HexAIS_OMAP-L137.exe; Тут есть одна тонкость : если брать последний u-boot, то AISGen отказывается делать для него AIS образ и приходится пользоваться HexAIS_OMAP-L137.exe

Как писать AIS образ в NAND память, при помощи консольных утилит

1. По ссылке на первой странице этой ветки нужно пересобрать консольные утилиты Как пересобрать flash утилиты
2. Нужно собрать u-boot, в котором поправить таблицы по ссылке постом выше nand_ecclayout nand_davinci_4bit_layout_oobfirst
3. Подготовить ДВА образа AIS, первый с загрузкой по UART, второй по NAND
4. Загрузить образ первый образ по UART (выставить правильно конфигурацию загрузки bootmode pins)
slh_OMAP-L137.exe -v -waitForDevice -p COM1 u-boot_ti_1705_test.bin
5. В uboot записать второй образ в NAND память.

Нажмите для просмотра прикрепленного файла - настройки для AISGen
Нажмите для просмотра прикрепленного файла - конфигурация для HexAIS_OMAP-L137.exe

Спасибо. С UART разобрался :-).
А Вы используете именно такую последовательность? И работает?


В процессе поиска подправил ubl из комплекта 03.20.00.14. Затем компилирую его с параметром USE_NAND. Полученный на выходе .out обрабатываю AisGen. А вот тут внимание: настройки те же что и для u-boot для загрузки по UART (изменение режима не влияет). Затем загружаю u-boot по UART и с его помощью заливаю полученный ubl в NAND по адресу 0х20000. Устанавливаю загрузку из NAND и ubl успешно загружается! Но u-boot (предварительно положенный следом за ubl) не подтягивает, так как не видит некоего MAGIC WORD (упоминается в Вашей первой ссылке). Основное отличие ubl от uboot - ubl грузится во внутренюю ОЗУ (80000000) а u-boot во внешнюю (с1080000).

Прошивка NAND и загрузка с нее (для потомков так сказать):
1) Подготовка u-boot:
a - настройка, редактирование под себя и т.д.
б - компиляция (использую CodeSoucery Lite 2007q3 - как показала жизнь наименее косячный toolchain)
в - обрабатываем u-boot (имя файла получившегося при компиляции, второй файл - "u-boot.bin" понадобиться дальше) при помощи AisGen для OMAP-L137 (v.0.7.0.0) для загрузки по UART
г - собственно тестируем u-boot. при необходимости повторяем а - г.

Когда u-boot устраивает и необходимо грузиться из NAND переходим к шагу 2:
2) Загрузка с NAND
2.1) Подготовим загрузчик UBL (использую armubl-03.20.00.14 из соответствующего PSP):
а - скачиваем и устанавливаем CodeComposerStudio 3.3 (можно и другую версию, но эта меньше весит :-) и проще). В качестве цели указываем TMS470R2x. (Если CCS будет ругаться - просто игнорируем)
б - распаковываем armubl
в - в CCS открываем проект armubl (для omap-l1x7) и в настройках Build Options указываем UBL_NAND и DEVICE UART0_FOR_DEBUG (номер UART естественно свой). В конфигурации проекта указываете BOOT_NAND.
г - теперь поправим исходники: (указываю файл/функция)
device.c/DEVICE_SDRAM_init - указываете свои настройки памяти SDRAM
device.h - в определение типа структуры _DEVICE_UART_REGS_ дописываете: VUint32 MDR;
device.c/DEVICE_UARTInit - в каждой настройке UART указываете (после UARTx->LCR |= 0x3;) UARTx->MDR &= 0;
device.c/DEVICE_init - можно убрать инициализацию лишней периферии (например чипа питателя и т.д.)
nandboot.c/NANDBOOT_copy - строки:
// If the application is already in binary format, then our
// received buffer can point to the specified load address
// instead of the temp location used for storing an S-record
// Checking for the UBL_MAGIC_DMA guarantees correct usage with the
// Spectrum Digital CCS flashing tool, flashwriter_nand.out
if ((magicNum == UBL_MAGIC_BIN_IMG) || (magicNum == UBL_MAGIC_DMA))
{
// Set the copy location to final run location
rxBuf = (Uint8 *)gNandBoot.ldAddress;
}
заменить на: rxBuf = (Uint8 *)gNandBoot.ldAddress;
д - собираем проект
е - полученный ubl-nand.out обрабатываем AisGen.
Загрузчик UBL готов.

2.2 Подготовим u-boot.bin (обращаю внимание - именно бинарник!) для заливки в NAND
а - для того чтобы UBL правильно считал u-boot из NAND необходимо следующее:
в NAND UBL должен лежать начиная со страницы 0 блока 1, а вот с u-boot не так просто. UBL ищет u-boot (кстати, это не обязательно должен быть u-boot) начиная со страницы 0 блока 2. Причем данные там должны лежать следующие:

блок 2 страница 0
00 - 0x55424С00 - magic number
04 - 0хс1080000 - точка входа entrypoint
08 - кол-во строк необходимы для хранения u-boot.bin (<размер файла>/<кол-во байт в странице вашей NAND> + 1 для выравнивания)
0C - номер блока где начинается u-boot.bin (в общем случае это 2)
10 - номер страницы с которой начинается u-boot.bin (в общем случае 1)
14 - 0xc1080000 - адрес куда UBL будет писать считанные из NAND данные
... - остальное до конца страницы не имеет значения.
блок 2 страница 1
собственно u-boot.bin

б - для того чтобы правильно и аккуратно это все легло в NAND лучше сделать все одним файлом .

Теперь мы записываем NAND (на примере мой платы)
UBL кладем nand write 0xc0700000 0x20000 0x20000 - занимаем весь блок 1
u-boot.bin (тот самый файл с волшебной структурой) - nand write 0xc0700000 0x40000 0x40000

выключаем питание переходим на загрузку из nand и имеем счастье.

никто не подскажет, как на am1705 после загрузки ядра linux с выводом на ttyS2 ( UART 2 ) далее полноценно использовать UART 2 в своем приложении???
Дело в том, что в своем приложении считывание и запись по данному UART 2 идет с ошибками, такое чувство, что в порт еще что-то системное приложение(или само ядро) пишет/читает.
в интернете почитал, в основном советуют отключить параметр console=ttyS2,115200n8 и закоменчиванием соответствующих строк в inittab(для getty).
пока не помогло((

кто нибудь может что посоветовать? в какую сторону курить?

Есть несколько вопросов по Вашей технологии.
1- А не делаем ли мы того же, что и AisGen, а если так, то в чем преимущество такого подхода?
2- Вы выложили свою программу для подготовки u-boot, но она данные блока 2 страницы 0 записывает с инверсией, получается, например, вместо с1080000 пишет 000008с1, это просто баг, или так и надо? Я написал свою прогу для патча бинарника (без инверсии), но ни с моей не с Вашей у меня плата из NAND все равно не стартует.



Я проверял на своей плате, у меня с OOB пишется...точнее есть какое-то заполнение отличное от ff.



Скорости uarta и ПК одинаковые? У меня отладка есть для AM1808, с откомпилированными бинарниками. Там и программирование и непосредственное общение с Linux'ом идет через UART2. Могу выслать вам исходники, может быть чего-нибудь откопаете.

да, если не затруднит, скиньте на embedded@yandex.ru

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

если кому интересно, то проблема решается следующим способом

1. __add_preferred_console() - не используем никакую(или свободную для user app)
2. выключаем system console
3. остальное по мелочи ...

1 - AisGen делает совершенно другое. Тут мой косяк. Надо было назвать не myais (так как ais тут не причем),
а например magicnand.
Ais - это набор команд для внутреннего загрузчика (RBL) для инициализации периферии, PLL.
Дальше используется вторичный загрузчик (UBL).
И вот для него и необходимо выполнить подготовку u-boot.bin для загрузки из nand.

Уже не помню где, но видел (или пришел к такому выводу) настоятельные рекомендации TI для загрузки из nand использовать UBL.

2 - Нет это не баг. Действительно так и должно быть.

Для успешной загрузки из NAND хоть чего нибудь (записаного при промощи u-boot) обязательно необходимо изменить алгоритм расчета ECC в u-boot и kernel!!!
Иначе RBL просто будет считать, что вычитывает битый образ.

Nand из которой грузитесь должна быть подключена на CS3!

Еще у вас другая NAND, а значит другие размеры страницы и блока.
------------------------------------------------------------------------------------------------------------

Еше раз, так как чудес не бывает.

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

Далее попробую обьяснить другими словами:
1) немного терминологии
u-boot.elf - при компиляции u-boot получаются несколько файлов и один из них "u-boot" (без расширения).
u-boot.bin - при компиляции u-boot получаются несколько файлов и один из них "u-boot.bin" (так сказать бинарник).
u-boot.ais - файл сгенерированный AisGen из u-boot.elf для загрузки по UART.
u-boot.magic - файл после обработки u-boot.bin при помощи myais (не призываю слепо использовать, важен сам алгоритм).
ubl.elf - файл "ubl" полученный в результате компиляции проекта UBL в CodeComposerStudio
ubl.ais - файл сгенерированный AisGen из ubl.elf.

Предположим, что у Вас рабочий u-boot.ais (с исправленным алгоритмом ECC),
который вы можете загружать через UART и работать с nand (включена поддержка nand в u-boot).

Делаем следующее (команды и адреса относительно моего железа - RAM 64MB, FLASH 128MB Micron pagesize 2048):
- правим UBL под себя (настройки NAND, UART, дебагерный вывод и т.д.) + изменения которые приводил раньше.
- собираем UBL и полученный файл обрабатываем AisGen.

- генерируем файл u-boot.magic.

- загружаем по UART u-boot.ais.
- по tftp (опять же на моем примере) подтягиваем ubl.ais.
tftp 0xc0700000 ubl.ais
- стираем nand блок 1 (целиком) и записываем в него ubl.ais.
nand erase 0x20000 0x20000
nand write 0xc0700000 0x20000 0x20000
- теперь подтягиваем u-boot.magic и кладем его в блок 2 (т.к. размер файла больше 128К то потребуется 2 блока)
tftp 0xc0700000 u-boot.magic
nand erase 0x40000 0x40000
nand write 0xc0700000 0x40000 0x40000
- вот теперь если все правильно то при установке загрузки из nand все должно работать.


Давайте еще раз по шагам загрузки:
1 - При включении питания запускается внутренний загрузчик (RBL),
который согласно пинам определяет откуда грузится (NAND, UART ...).
В нашем случае с Nand, которая висит на CS3 (обязательно!!!).
Блок 0 в NAND загрузчик не смотрит (там обычно лежат переменные u-boot).
А смотрит блок 1. В нем лежит вторичный загрузчик (UBL), который (ВНИМАНИЕ) обработан AisGen.
Если в AisGen были правильно установлены настройки, то в UBL инициализации вообще можно не делать.

2 - Итак RBL вычитал из NAND UBL (обычно во внутреннюю RAM) и передает ему (UBL) управление.
Все что будет дальше ais не требует вообще!

3 - Для того, чтобы UBL смог вычитать из nand образ u-boot.bin этот самый u-boot должен лежать в
определенном месте и определеным образом.
Это расписано в исходниках UBL (в том числе и как я раньше писал).
Еще раз хочу обратить внимание на то, что тут мы должны оперировать НЕ ELF файлом u-boot,
а именно u-boot.bin, полученным при компиляции u-boot.



А вообще попробуйте сначала запустить из NAND загрузчик UBL. Когда получиться дальше будет легче.

Что-то тема заглохла.

Образовалась новая проблема:
Имею две платы. Одна работает нормально. Другая не хочет.
Симптомы следующие:
Не стартует PLL. Причем проявляется это при загрузке ais (в котором конфигурируется PLL). После отправки команды конфигурирования PLL
от процессора ответы не приходят. Если в ais не конфигурировать PLL (т.е. работать на штатных 24МГц) все загружается и переданая прошивка работает. Если конфигурировать PLL не в ais, а моей программе, то зависание происходит сразу после подачи команды на переход из режима bypass в режим PLL. Причем процессор именно зависает. Дальнейший код не выполняется. Ощущение, что PLL не работает вообще!

Что проверял:
кварц генерирует 24МГц как положено.
последовательность подачи питания и сброса в норме (хотя между подачей 1.2В и 3.3В проходит около 1мс).
уровни питания в норме.
на питании PLL стоят ферриты.
микросхема PHY вроде в норме (тут в начале темы был такой трабл).

Уже голову сломал. Не очень хочется выпаивать обвязку процессора.

Может у кого похожее было?

Здравствуйте, возникла проблема. Собрал плату с AM1705. BOOTME в консоли получаю. Загрузка по UART Boot host'у проходит нормально, но в консоли ничего не появляется, если смотреть осциллографом, тоже глухо. Есть еще одна плата, отладка на этом же процессоре, там тот-же код работает нормально, в чем могут быть грабли? Платы различаются только кварцами, у моей 24МГц, а на отладке 25МГц (Я это учитывал когда собирал U-boot и генерил ais). СРАМ на свою поставил ту же что и на отладке. Образ собирал без флешек и EMAC контроллера.

1. U-boot тот же? Ничего не меняли? (кроме частоты кварца и откл. EMAC и Flash)
2. Параметры для ais выставляете правильные?

ПС: Постом выше описывал свою проблему. Оказалось фиговая земля на общем выводе кондеров кварца (высокое (~20 Ом) сопротивление между выводом и общей "землей").

Вспоминая что электроника- наука о контактах, решил повторно пройтись по ножкам паяльником, помогло. =)

Здравсвуйте, нашел более простой способ загрузки из NAND (как альтернатива предложенная товарищем DenchikS), добавление в файл da830evm.h строчки #define CONFIG_NAND_DAVINCI позволяет грузить u-boot из NAND без использования ubl.

Однако. У меня этот define и так прописан, но это не помогает :-(. Какая у вас версия U-boot, и откуда брали?

Версия 3.20.00.14 брал из SDK для AM17xx: DaVinci-PSP-SDK-03.20.00.14.

Подскажите пожалуйста, столкнулся со следующей проблемой. Есть проверенная файловая система для nand, есть мое ядро Linux 2.6.34.12. Ядро зависает при попытке подключить блок mtdblok4: Waiting for root device /dev/mtdblock4... Поддержка MTD, NAND и jffs2 есть (делал исходя из документов TI). Из U-boot ядру передается следующая комманда: mem=32M consoleblank=0 console=ttyS2,115200n8 rw rootwait earlyprintk root=/dev/mtdblock4 rw rootfstype=jffs2 ip=off

Подскажите что можно сделать?

P.S.
Файловая система проверялась на купленной отладке, с их ядром версии 3.1.