Harvester

Спасибо, буду копать дальше

Во-первых это не так - прошивка DSP грузится в один процессор, а ядро - в другой. :) Во-вторых, меня интересует именно параметры запуска загрузчика DSP.

М-да, а слона-то я и не заметил... Тогда другая проблема - в файловой системе устройства нет файла "dsp_load". :( Что же тогда запускается?

Так в этом-то и вопрос. Вот лог: Hit any key to stop autoboot: 0 NAND read: device 0 offset 0x7e00000, size 0x100000 1048576 bytes read: OK dsp_load: DSP HPI probe passed dsp_load: Upload DSP Loader Я вижу только результат выполнения команды, а мне нужно знать с какими параметрами она запускается (они есть, это я знаю 100%). Где может лежать скрипт, запускающий команду при загрузке системы?

root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs ubi.mtd=opt console=ttyPSC0,115200 ro Т.е. содержимое bootargs. Это не то, что мне нужно.

Вот что получилось: bootcmd=run nandboot nandboot=setenv bootargs "root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs ubi.mtd=opt console=$consdev,$baudrate ro" && nand read $kernel_laddr $dsp_prg_naddr $dsp_prg_nsize && dsp_load $kernel_laddr; nand read $kernel_laddr $kernel_naddr $kernel_nsize && bootm $kernel_laddr Получается, что в убуте просто задается переменная bootargs. Содержимое переменной обрабатывается уже ядром, при этом в bootargs я не вижу интересующую меня команду. Получается, что она запускается позже. Отсюда следующий вопрос - как узнать, что исполняется ядром после обработки bootargs?

Интересует что и с какими параметрами запускается убутом.

Добрый день. Имеется плата с кастомным Linux-ом. Вот начало лога консольного вывода: U-Boot 2009.03-svn201 CPU: MPC5125 rev. 1.0, Core e300c4 at 400 MHz, CSB at 200 MHz board: xxxx I2C: ready DRAM: 128 MB NAND: 128 MiB In: serial Out: serial Err: serial Bad block table found at page 65472, version 0x01 Bad block table found at page 65408, version 0x01 for update u-boot: run uboot_update for update linux: run linux_update Hit any key to stop autoboot: 0 NAND read: device 0 offset 0x7e00000, size 0x100000 1048576 bytes read: OK dsp_load: DSP HPI probe passed dsp_load: Upload DSP Loader Насколько я понимаю, после строки "Hit any key to stop autoboot" u-boot начинает выполнять некий скрипт начальной загрузки. Нашел в исходниках файл uboot-installer.sh, который, похоже, имеет отношение к процессу загрузки: # # U-boot environment installer # setenv led_resetst 0 1 0 1 # setenv dsp_prg_naddr 7e00000 setenv dsp_prg_nsize 100000 setenv nandboot 'setenv bootargs "root=ubi0:rootfs rootfstype=ubifs ubi.mtd=rootfs ubi.mtd=opt console=$consdev,$baudrate ro" && nand read $kernel_laddr $dsp_prg_naddr $dsp_prg_nsize && dsp_load $kernel_laddr; nand read $kernel_laddr $kernel_naddr $kernel_nsize && bootm $kernel_laddr' # saveenv Но здесь просто задаются переменные среды :( Попробовал пройти "grep -rl nandboot ./" по исходникам - выдает только вышеуказанный файл. Подскажите пожалуйста, как точно узнать, что и с какими параметрами запускается при загрузке?

Это не защитный диод, а паразитный. Обусловлен конструкцией полевика.

Разобрался. Похоже, что линкер пытался обратиться к объектным файлам, когда их еще не было. В make-файле ошибки компиляции/сборки перенаправлялись в соответствующие файлы: $(BINDIR)/%.obj: %.c $(CC_TI5) $(CFLAGS) --output_file $@ $< \ </dev/null &> $@.err Заменил последнюю строчку на </dev/null > $@.err 2>&1 и все заработало.

Добрый день. Среда - Linux Mint в виртуалке, компилятор - TMS320C55x C/C++ Compiler v4.4.1 Имеется обычный make-файл - сначала компилируются исходные файлы, потом полученные объектные модули компонуются вместе. Объектные файлы создаются нормально, а при линковке выдаются сообщения "/tmp/xxxxxx", line 14: error: cannot find file "bin/xxxxxx.obj" для каждого из файлов сборки. С путями все в порядке: текущая папка при запуске линкера - <project>, в командной строке линкера указаны файлы bin/xxxxxx.obj, сами объектные файлы находятся в папке <project>/bin. При запуске линкера непосредственно из оболочки линковка проходит успешно. В чем может быть проблема? PS. Запуск того же make-файла в среде cygwin также проходит нормально.

Если бы только это... Почему-то поведение процессора даже с мануалом не совпадает. :( В доках написано (Table 6-12. EDMA Synchronization Events): Event 2 - McBSP0 Receive, Event 3 - McBSP0 Transmit. Соответственно, 1. Включаю BFIFO; 2. Загружаю PaRAM PaRAM set 2: источник - 0x01F10000 (FIFO RBUF), приемник - буфер в памяти, TCC = 12 PaRAM set 3: источник - буфер в памяти, приемник - 0x01F10000 (FIFO XBUF), TCC = 13 3. Разрешаю прерывания DMA для заданных TCC: IESR = (1 << 12) | (1 << 13) 4. Разрешаю события DMA: EESR = (1 << 2) | (1 << 3) 5. Запускаю McBSP SPCR |= 1 << GRST; SPCR |= (1 << XRST) | (1 << RRST); SPCR |= (1 << FRST); 6. В обработчике прерывания DMA ловлю оба события (по идее они должны наступить практически одновременно и обработаться в одном заходе в обработчик): while ((ipr = HWREG(EDMA3_0CC0_BASE_ADDR + EDMA3CC_IPR)) != 0) { // check flags dmaBusFlags |= ipr; // clear setted IPR bits HWREG(EDMA3_0CC0_BASE_ADDR + EDMA3CC_ICR) |= ipr; } Но на самом деле получается ерунда. Для каждого последующего запуска (пп 1...5) поочередно получаем следующее 1. Ловится прерывание Rx (IPR = 0x1000) 2. Ловится прерывание DMA Error, EMR = 0x04 - пропущено событие 2 либо 1. Ловится прерывание Tx (IPR = 0x2000) 2. Ловится прерывание DMA Error, EMR = 0x08 - пропущено событие 3 Если же я формирую PaRAM наоборот, т.е. [2] - для передачи, а [3] - для приема, то все работает как требуется: сначала ловится Tx (IPR = 0x1000), потом Rx (IPR = 0x2000). Правда, после этого всегда почему-то ловится прерывание DMA Error, EMR = 0x04 - пропущено событие 2 :( Как говорится, кто виноват и что делать? :)

Спасибо, я почему-то не думал в этом направлении. Если что-то не учли, сдвиг действительно может оказаться больше запланированного. Убедиться в этом можно только одним способом - ткнуться анализатором на шину. Пока у меня нет такой возможности, как появится - попробую. А насчет неправильного алгоритма - что есть. Работает не первый год, множество изделий, в обозримом будущем менять никто не будет. Кстати, а какой алгоритм Вы могли бы предложить?

Слейв(ы) - модуль I2S в TMS320С5532. Их может быть несколько В каждом фрейме I2S передается номер (адрес) слейва. Если адрес в фрейме совпадает с адресом слейва, то последний формирует данные (для этого и нужна задержка), через 2 фрейма после получения команды подключается к шине и передает ответ. В исходниках слейва действительно задана задержка в 2 фрейма и по ней вопросов нет. Вопрос в том, что данные приходят с дополнительной задержкой в 3 фрейма, поэтому размер пакета пришлось увеличить на 3. Т.е. должно быть так Tx: XXXXXXXX00 Rx: 00XXXXXXXX а получается так Tx: XXXXXXXX00000 Rx: 00000XXXXXXXX

Ну, насчет "гнать" это не в моей компетенции. Тем более как-то все работает и далеко не первый год. А по существу - можете ли Вы на основании своего опыта предположить причины такой работы периферии? В какую сторону копать?