Перейти к содержанию
    

Зависает (?) ARM1136, требуются идеи

Гость impatt

Привет всем.

Вожусь с написанием загрузчика для iMX35(ARM1136), не зная толком архитектуры, так получилось. Блуждаю в потёмках :)

Использую JTAG-отладчик (если можно его так назвать) OpenOCD, суть которого в том, что он даёт возможность из консоли пошагово исполнять команды, ставить брекпоинты, смотреть содержимое регистров и ещё немного всякого.

Сам загрузчик состоит из нескольких частей, здесь коснусь только одну; работать она должна так: после сброса микроконтроллер читает страницу NAND-флэш в SRAM буфер, и начинает его исполнять. Тут-то я, как программер, должен извернутся и проинициализировать всякую периферию и собственно ARM1136. Если с периферией местами понятно, то с ARM1136 - совсем нет. Мой представление об этой тёмной части инициализации следующее:

1. Надо отключить все кэши, MMU и прочие замороченые вещи (хотя я предполагаю, что после сброса оно и так отключено, но не уверен).

2. Надо настроить шины, мосты между ними и прочую заумь :)

Касательно первого пункта на свой страх и риск поставил кусок из, кажется, u-boot:

 

/*
* flush v4 I/D caches
*/
mov     r0, #0
mcr     p15, 0, r0, c7, c7, 0   /* flush v3/v4 cache */
mcr     p15, 0, r0, c8, c7, 0   /* flush v4 TLB */

/*
* disable MMU stuff and caches
*/
mrc     p15, 0, r0, c1, c0, 0
bic     r0, r0, #0x00002300     @ clear bits 13, 9:8 (--V- --RS)
bic     r0, r0, #0x00000087     @ clear bits 7, 2:0 (B--- -CAM)
orr     r0, r0, #0x00000002     @ set bit 2 (A) Align
orr     r0, r0, #0x00001000     @ set bit 12 (I) I-Cache
mcr     p15, 0, r0, c1, c0, 0

Касательно шин: то место, где исполняется код загрузчика (тот самый SRAM-буфер NAND-контроллера), оно находится в юрисдикции периферийной шины. В документации про неё понаписано много, но мой слабый мозг это всё осознать не может (по крайней мере, на настоящий момент). Вот что сказано, например:

 

The PPMRR in the ARM1136 CPU, could be programmed to 0x40000014 or 0x40000015 for the

ARM1136 platform. These values corresponds to a base address of 0x40000000 with total peripheral

region of 512 Mbytes and 1 Gbyte, respectively.

 

Я делаю так:

 

ldr r0, PPMRR_value
mcr p15, 0 ,r0, c15, c2, 4
PPMRR_value:
.word 0x40000015

 

Это похоже на то, что надо или вообще мимо ? :)

 

Нда, ну и проделывая это, после пошагово выполняю код в SRAM-буфере NAND-контроллера и OpenOCD отваливается на определённом адресе, мол, таймаут чего-то там. Мож, проц завис ? Мож, какой-нибудь Abort произошёл - не могу вкурить. Равно как не знаю, как в этом случае выжать что-то более подробное с помощью OpenOCD. Но сперва хочется понять - вообще, так надо инициализировать или что-то ещё надо или вовсе иное надо ?

Спасибо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Но сперва хочется понять - вообще

отключить всё с чем не умеете работать. Кусок кода точно поместился в память? Со светодиодом проще в чём то но дольше.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если зависает, то скорее всего какая то из предыдущих команд была неверна или из-за неправильной настройки чего то из периферии, вот на этой команде и зависло.... (хотя обычно виснет вроде как на следующей команде после вызвавшей ошибку)

У меня было (правда не в openOCD) зависание когда все нормально даже... так как сообщения в терминал по UART выдавались далее...

Совет пожалуй 1 - или светодиод, а лучше настройте UART и отлаживайтесь :-) будет проще

 

А jtag у вас какой?

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Гость impatt
отключить всё с чем не умеете работать. Кусок кода точно поместился в память? Со светодиодом проще в чём то но дольше.

Спасибо за ответ. Не мог сразу прореагировать - маленько мне тут прикрыли кислород.

По сути вопроса: описание того, чем можно управляь с помощью сопроцессора #15 занимает страниц 150 чистого английского языка :) ПРичём темы, там обсуждаемые - совсем космические. Посему я бы и рад отключить, да не знаю как :) Там слишком много непонятного понаписано.

 

Если зависает, то скорее всего какая то из предыдущих команд была неверна или из-за неправильной настройки чего то из периферии, вот на этой команде и зависло.... (хотя обычно виснет вроде как на следующей команде после вызвавшей ошибку)

У меня было (правда не в openOCD) зависание когда все нормально даже... так как сообщения в терминал по UART выдавались далее...

Совет пожалуй 1 - или светодиод, а лучше настройте UART и отлаживайтесь :-) будет проще

 

А jtag у вас какой?

Зависает даже в произвольным местах. Похоже на эффект неотключенного и несброшенного кэша.

К сожалению, я плохо понимаю, как работает ARM в режиме отладки: например, возможно ли, что через JTAG в режиме отладки я вижу в памяти одно значение, а при работе без режима отладки (например, ещё и со включенным кэшем) процессор читает из "памяти" (т.е. замусоренного кэша) совсем другое значение ?..

Насчёт UART: даже попытка настройки его иногда заканчивалась зависанием :) В общем, атас.

Сейчас это как-то преодолено с помощью заклинаний на ассемблере, взятых из разных загрузчиков. Надеюсь, что положительный эффект не случайный и устойчивый :)

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...