[Denchik 0]

Спасибо. С 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).

[Denchik 0]

Прошивка 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 и имеем счастье.

 

 

 

 

myais.zip

[mukrop 0]

никто не подскажет, как на am1705 после загрузки ядра linux с выводом на ttyS2 ( UART 2 ) далее полноценно использовать UART 2 в своем приложении???

Дело в том, что в своем приложении считывание и запись по данному UART 2 идет с ошибками, такое чувство, что в порт еще что-то системное приложение(или само ядро) пишет/читает.

в интернете почитал, в основном советуют отключить параметр console=ttyS2,115200n8 и закоменчиванием соответствующих строк в inittab(для getty).

пока не помогло((

 

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

[J.Joker 0]

блок 2 страница 0

00 - 0x55424С00 - magic number

...

блок 2 страница 1

собственно u-boot.bin

 

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

Есть несколько вопросов по Вашей технологии.

1- А не делаем ли мы того же, что и AisGen, а если так, то в чем преимущество такого подхода?

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

 

DenchikS PavelG

 

Ресет и плата не стратует (биты OOB не заполнены!)

 

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

 

никто не подскажет, как на am1705 после загрузки ядра linux с выводом на ttyS2 ( UART 2 ) далее полноценно использовать UART 2 в своем приложении???

Дело в том, что в своем приложении считывание и запись по данному UART 2 идет с ошибками, такое чувство, что в порт еще что-то системное приложение(или само ядро) пишет/читает.

в интернете почитал, в основном советуют отключить параметр console=ttyS2,115200n8 и закоменчиванием соответствующих строк в inittab(для getty).

пока не помогло((

 

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

 

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

Изменено 23 марта, 2012 пользователем PavelG

[mukrop 0]

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

да, если не затруднит, скиньте на [email protected]

 

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

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

с остальными портами все нормально, именно что то связано с тем, что ядро выводит в данный порт и что-то еще.

[mukrop 0]

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

 

1. __add_preferred_console() - не используем никакую(или свободную для user app)

2. выключаем system console

3. остальное по мелочи ...

[Denchik 0]

Есть несколько вопросов по Вашей технологии.

1- А не делаем ли мы того же, что и AisGen, а если так, то в чем преимущество такого подхода?

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

 

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

Изменено 27 марта, 2012 пользователем DenchikS

[Denchik 0]

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

 

Образовалась новая проблема:

Имею две платы. Одна работает нормально. Другая не хочет.

Симптомы следующие:

Не стартует PLL. Причем проявляется это при загрузке ais (в котором конфигурируется PLL). После отправки команды конфигурирования PLL

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

 

Что проверял:

кварц генерирует 24МГц как положено.

последовательность подачи питания и сброса в норме (хотя между подачей 1.2В и 3.3В проходит около 1мс).

уровни питания в норме.

на питании PLL стоят ферриты.

микросхема PHY вроде в норме (тут в начале темы был такой трабл).

 

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

 

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

[J.Joker 0]

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

[Denchik 0]

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

2. Параметры для ais выставляете правильные?

 

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

[J.Joker 0]

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

2. Параметры для ais выставляете правильные?

 

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

 

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

Изменено 20 июля, 2012 пользователем PavelG

[J.Joker 0]

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

[Denchik 0]

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

[J.Joker 0]

Однако. У меня этот 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.