_SY_

Добрый день. В процессорах MPC860 конечно уже был JTAG, но это были одни из первых процессоров с поддержкой JTAG, эта поддержка там реализована не очень. К примеру, в дефолтной конфигурации JTAG выключен, и для того чтоб включить надо загрузить особенную (не дефолтную) reset конфигурацию. Кроме того, не поддерживается команда idcode, т.е. нет возможности определить тип процессора и длину boundary scan регистра, надо задавать вручную. Если это все не пугает то - вперед. Если хочется решить эту проблему более простым способом, то вам нужен дебагер и BDM-шнурок для него. Напишите в профиле город, в котором вы находитесь.

Ну да, по-хорошему нада бы еще че-то с железом поделать, т.е. если это LCS[0], то надо прописать регистры BR0 и OR0. Плюс не забыть сделать local bus window в регистрах LBLAWBAR и LBLAWAR "Transfer error ack" это софт попытался полезть по адресу, который не назначен ни на один из мем контролеров, и не получил transfer acknowledge в положенное время.

Ну видимо да. С отладкой U-boot опыта нету, извините. Он обычно как-то работает.

Да, писать самостоятельно dts, потом компилировать с помощью компилятора dtc и получать на выходе dtb.

Вы ядро какой командой Uboot-а запускаете? Если "bootm", то там в явном виде необходимо указать адрес device tree Вот с сайта Uboot-а: http://www.denx.de/wiki/DULG/UBootCmdGroupExec Usage: bootm [addr [arg ...]] - boot application image stored in memory passing arguments 'arg ...'; when booting a Linux kernel, 'arg' can be the address of an initrd image When booting a Linux kernel which requires a flat device-tree a third argument is required which is the address of the device-tree blob. Ядро без dtb не будет работать.

dtb это device tree без него ядро не будет работать. В документации kernel есть документация как писать этот device tree, в каталоге /documentation/powerpc/dts-binding/ Честно говоря нету опыта с кросскомпилятором из openwrt, проще всего по-моему взять готовый BSP на плату 8360.

Напишите более подробно, что собирали, чем собирали, и так далее. Что за инструкция лежит по этому адресу? Какой дебагер? Какой брекпоинт? Софтварный? Софтварный брекпоинт это и есть exception 0x700. Алгоритм отладки линуксового ядра посоветовать не могу. CodeWarrior Linux Platform Edition его вроде бы может дебагать, но ни разу не пробовал.

Uboot и линукс откуда взяты? Из фрискейловского BSP на 8360 плату? Патчи все приложены? Память DDR проверили на работоспособность?

На страничке 8349-го есть пара ссылок на стэки - CMX и MQX http://www.cmx.com/tcpip.htm http://www.embedded-access.com/products/rt...cpip_stack.html Я думаю что можно их перетащить на 8315 при большом желании, разница между этими процессорами не должна быть сильно большой. Производительность линуксового стэка не проверяли, задачи такой небыло, та и так понятно что никто там особо ничего не оптимизировал.

Ну в Линуксе на 8315-ю плату разве нету драйвера? Или вам standalone стэк нужен? Про standalone имплементации стека TCP/IP слышал, но это извращение по-моему, обычно если нужен стек TCP/IP, то используют линукс или любую другую ос и не греют голову.

Ну а куда ему остальную энергию-то деть? Закон сохранения ведь никто не отменял, сколько поглощает столько и излучает в тепло, если работы не совершает. MPC8323 это урезаная версия от MPC8360, которую сделали специально для миграции со старых MPC82xx и MPC8xx девайсов. Сильно большой производительности не ждите. Сапорт. Для старых CPM был специальный Excel файл для оценки CPM performance, а для новой QE - вроде нет.

Э..м-м-м... А что такое КПД проца? Проц - это грелка, он ничего не делает в моем понимании - ни к массе ускорение не прикладывает, ни тяжести не поднимает в поле потенциальных сил. Как оценить полезную работу проца в Ваттах? Думаю что нет. Думаю что он специфичен как к типу флешки, так и к типу DDR-памяти, т.к. скорее всего инициализирует и использует DDR память. Ну драйвер-то их самописаный, насколько я понимаю, кто его должен еще поддерживать? И я не очень понимаю, причем тут Линукс, если честно. Вы хотите железяку заставить принимать/передавать 4 потока TDM по 32 mbps, все это в сыром виде складывать в память (это transparent режим), потом как-то обработать с помощью своего софта самопального и отправить про Ethernet. Ну так и попросите оценить производительность QE для этой конкретной задачи, причем здесь какой-то линукс и какой-то драйвер? Железо прежде всего должно уметь прокачивать, а потом уже будете колупать драйвер, если он криво написан и не работает как вам надо. В документации написано только потребление самого девайса, оно-же его рассеяние. Если у вас какие-то внешние нагрузки к ногам подключены, то соответственно, по 3.3В надо будет что-то добавить, в зависимости от сопротивления ваших нагрузок, их емкостей и частоты с которой вы эти емкости перезаряжаете. Конечно, никто вам полное потребление всех ваших нагрузок считать не будет. Насчет закона ома не очень понял, по-моему вы че-то путаете, закон ома это U=I*R

I2C eeprom не грузит U-boot, она содержит код флэш программатора, который умеет брать образ флэшки по протоколу Kermit и программировать флэшку. Т.е. с помощью нее можно образ U-boot-а зашить в пустую флешку без использования USB TAP, если у вас нет USB TAP. Про производительность драйвера ucc_tdm спросите в сапорте. Про корявые таблицы - я вам ответил как есть на самом деле. Таблицу можно исправить, если есть желание, то можете туда-же написать, скажут вам спасибо и исправят.

Я не очень понимаю смысл вопроса. Что такое "i2c boot"? TDM интерфейс - железный, он ресурсы процессора или QE не потребляет. Можете щелкать биты туда/сюда как хочется. А дальше вопрос, что именно вы хотите с этими битами делать. Если просто сложить в память без обработки, то нужен transparent протокол. Надо оценивать производительность QE, сможет ли она лопатить transparent протокол с нужной вам скоростью. Если производительности QE хватило, то в память вы сложили. А дальше надо понять, что конкретно нужно сделать, какие конкретно нужны процессорные ресурсы для этого.

Мне не попадались. Да. Этим занимается boot loader, а не линукс. Я думаю что все описано в документации на него. http://www.denx.de/wiki/U-Boot/WebHome Да разные бывают, вот например 2-гиговый модуль Hynix HYMP125S64CR8 сделал из 16-ти чипов по 8 бит, чипы HY5PS1G831C А модули меньшего размера (1G и 512Mb) сделаны на 16-битных чипах. E3 имеет очень сложную канальную структуру, которая не поддерживается. "E3 clear channel" это просто битовый поток со скоростью E3, без поддержки без канальной структуры. Простой битовый поток конечно нет проблем принять.

Нет, MPC8323 DDR контроллер не поддерживает 16-bit, эта поддержка есть в 8313 и 8315 Ну аналоги-то известны - Samsung, Kingston, Hynix Пользоваться удобнее готовыми SODIMM модулями, там где размер платы позволяет. Просто потому что за счет SPD информации появляется некоторая гибкость настройки. Не видел, но я думаю никакого секрета в ней нету, напишите в сапорт - пришлют образ. Ну не совсем "аналогичных", 16-битных чипов вы там скорее всего не найдете. А если найдутся, то что мешает распаять планку? Бывало и такое.

Да, конечно. Если возможна запись только 32-bit целиком, то можно использовать любой из WE[0:3], т.к. при записи 32 бит они все будут активны. Если устройство поддерживает побайтовую запись, т.е. использует сигналы байт-селектов, то либо объединять все 4 вместе по или (точнее - и), либо использовать глобальный LBCTL. Байт-селектов в GPCM нету, только индивидуальные WE. Либо использовать UPM (что вобщем тоже несложно), либо городить на внешней логике схемку из WE[0:3] и OE. Либо третий вариант - принять мужественное решение забить на байт-селекты и обращаться к этой памяти только 32-битными транзакциями. По схемке: 1. Байт-селекты перепутаны. LBS0 соответствует LAD[0:7], LBS1 - LAB[8:15], и т.д. У вас на схеме LBS0 подключен к BE0L, который по всей видимости разрешает первый байт I/O[0:7], а там LAD[24:31]. 2. GPCM не будет работать без пулапа на LGTA 3. LSYNC_IN должен быть соединен с LSYNC_OUT через петлю обратной связи, если local bus будет использоваться на высокой частоте, т.к. там надо будет включать DLL mode. 4. Адресный latch наверное такой большой не нужен, если всего 14 адресов использовать. 5. Стартовать ваш процессор откуда будет, если LCS0 не подключен?

Это вообще для всех. Попробую объяснить, извиняюсь если слишком подробно: Каждое значение адреса адресует 1 байт. Если у вас ваша флешка 8-битная, и вы пишете 8-bit по адресу 0x00000000, то следующие 8-bit будут по адресу +1, т.е 0x00000001 Если у вас ваша флешка 16-битная, и вы пишете 16-bit (2 байта) по адресу 0x00000000, то следующие 16-bit будут по адресу +2, т.е 0x00000002 Ну и так далее: 0x00000000 0x00000002 0x00000004 0x00000006 0x00000008 Видно, что младший бит адреса всегда равен нулю. А со стороны флешки - каждый адрес адресует 16-бит. Т.е. можно записать 16 бит по адресу 0 и следующие 16-бит по адресу 1. Поэтому, младший адрес флешки в таком случае подключают не к первому (младшему) адресу шины, а ко второму. Для 32-bit устройства все аналогично, только не используются два младших адреса. В этом смысле разницы между LAD[] и LA[] нету.

Для 32-bit шины LAD[0:31] надо цеплять на DATA[31:0], именной в обратной последовательности, нулевой к 31-му и т.д. При этом старший байт LAD[0:7] будет соответствовать DATA[31:24], и это именно старший байт, не младший. Для 16-bit - LAD[0:7] надо цеплять на DATA[15:8], LAD[8:15] на DATA[7:0] Для 8-bit - LAD[0:7] надо цеплять на DATA[7:0] В этих процессорах (традиционно) используется обратная нумерация, как шины адреса, так и шины данных. Т.е. внутри группы LAD[0:31] старшим значащим является LAD[0], младшим - LAD[31]. Поэтому при подключении, допустим, к обычной флешке - все адресные веревки должны быть перевернуты. Для 8-bit шины LAD[0:31] надо цеплять (через адресный latch) на ADDR[31:0], именно в обратной последовательности, нулевой к 31-му и т.д. При этом если флешка меньше размером, то старшие LAD[0], LAD[1] и т.д. остаются висеть в воздухе. Для 16-bit - LAD[31] не используется, надо цеплять LAD[0:30] на ADDR[30:0], тоже в обратной последовательности Для 32-bit - не используются LAD[31] и LAD[30], надо цеплять начиная с LAD[29], т.е. LAD[0:29] на ADDR[29:0], и тоже в обратной последовательности

UPD: Протупил, извиняюсь. Схема платы лежит внутри ISO-шника с Linux BSP на эту плату, ISO-шник можно скачать с сайта: http://www.freescale.com/webapp/sps/site/o...5XX&tid=CWH Называется так: "MPC8536DS Linux Board Support Package - LTIB (DVD 4)" Ну 2 гига весит, к сожалению, но схема там точно есть внутри, в директории /help/hardware/DS В принципе это справедливо для всех плат - схема платы лежит внутри ISO-шника с линуксом. Да, для 8-bit устройства. Зачем так сделано - не знаю, всегда так было в PowerQUICC. Не обязательно, можно использовать LA. Только их всего 5 штук, не очень понимаю что вы на этом можете съэкономить. В мануале везде написано LA[7:31], так вот это неправда, на самом деле LA[27:31]. На самом деле вопрос об использовании не-мультиплексированных адресов вовсе не простой. В случае, если вы используете UPM и пытаетесь burst-транзакции делать - можно будет делать инкрементацию адреса без вставки LALE-циклов. Но для обычной флешки подключенной через GPCM об этом можно не думать.

У Freescale есть плата на базе MPC8536, называется MPC8536DS, либо "Calamari". Схема от нее наверное должна быть доступна всем желающим, только на сайте почему-то не вижу. Можно спросить в сапорте, наверное пришлют.

Работал, немного. Референс-дизайнов там всего два, MPC8360E-MDS и MPC8360E-RDK. Второй по-моему разработан какой-то левой фирмой, как все дешевые платки. Посоветую конечно MDS, но лучше посмотреть конечно на схемы обоих и понять, что вам больше подойдет. Че-нить наверное найдется, но может быть на 8323, а не на 8360. И не уверен что до ума доведено. Да, тут есть подводный камень - само ядро никак нельзя заставить. Там есть инструкции типа stmv, но даже эти инструкции burst не генерят. В общем случае - да, либо DMA либо любой другой bus master кроме ядра, например cache-контроллер. Т.е. при включенном кэше ядро будет лазить в память бурстами через cache-контроллер. Только имейте ввиду, что кэш без MMU включать нельзя. В вашем же конкретном случае - никак, ибо по одному и тому же адресу burst невозможен. Бурст подразумевает последовательное чтение 32-х последовательных адресов, причем выровненных по модулю 32. Надо имитировать ситуацию, как будто у вас burst по 32-м последовательным адресам, ну а внутри вашего target-девайса просто игнорировать младшие 5 адресов. Т.е., если конкретно, то вы допустим читаете бурстом начиная с адреса 0, т.е. будет выполнены последовательные чтения с адресами 0, 2, 4, 6, 8, и т.д. всего 16 раз. Это все на шине пройдет как одна бурстовая транзакция. А внутри вашего девайса все эти адреса должны ссылаться в одно место. Только так можно получить бурст. Внутри самого UPM-ного цикла адреса никак трогать не надо, достаточно 16 раз дернуть transfer acknowledge.

У пользователя VladA отключен личный ящик, поэтому отвечаю здесь. Честно говоря, я создавал эту тему для того, чтобы как-то помочь людям разобраться с powerquicc. У меня нету цели как-то рекламировать себя и я не ищу себе какие-то дополнительные подработки. Поэтому - я готов бесплатно ответить на ваши вопросы в этой теме, если они у вас есть. Если нет желания разбираться самостоятельно, то лучше создать тему в разделе "Предлагаю работу".

Конечно могу, опыт с LB есть, а в чем собственно проблема?

Первое что пришло в голову - W. Richard Stevens, Advanced Programming in the UNIX Environment Ну вобщем да, в редакторе. Если тебе прям край надо красивую среду разработки по типу CodeWarrior IDE и прочих, то во-первых сам CodeWarrior, потом еще у Виндривера что-то есть, ну и из бесплатных Eclipse, Netbeans, и т.д. UPD: Ну и вот тебе еще вдогонку пример на "что нить с использованием драйверов" http://www.mjmwired.net/kernel/Documentati...c/dev-interface