Спасибо. С 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. Могу выслать вам исходники, может быть чего-нибудь откопаете.

Сообщение отредактировал PavelG - Mar 23 2012, 13:53

да, если не затруднит, скиньте на 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. Когда получиться дальше будет легче.

Сообщение отредактировал DenchikS - Mar 27 2012, 11:25

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

Образовалась новая проблема:
Имею две платы. Одна работает нормально. Другая не хочет.
Симптомы следующие:
Не стартует 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 Ом) сопротивление между выводом и общей "землей").

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

Сообщение отредактировал PavelG - Jul 20 2012, 14:36

Здравсвуйте, нашел более простой способ загрузки из 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.