eCos 3.0 for Microblaze Опции

[KOLOBOK123124356]

Доброго всем времени суток. Работаю над портированием eCos 3.0 для Microblaze 8.2 в EDK 13.2. В качестве примера использовал mONeCos (http://www.monstr.eu/wiki/doku.php?id=ecos:ecos) - это порт eCos 2.0 на Microblaze 7.0. Много чего почерпнул оттуда, подправил код в соответствие со своей конфигурацией. Успешно запустил на своей плате eCos 2.0 из дистрибутива. Для сборки своего образа eCos 3.0 использовал GNU тулзы из дистрибутива mONeCos - microblaze-uclinux. Но при линковке получал ошибку : ../microblaze-uclinux/bin/ld.real: --relax and -r may not be used together. Потому линковал библиотеку extras.o из консоли командой. Затем собрал тесты eCos, но что насторожило, что размер всех тестов от 300 до 500 kb а вот тест, который собственно и нужен а именно tm_basic получился размером 50,5 Mb)) причем основную часть занимает .bss секция. Пробовал залить tm_basic тест и попрыгать по коду через GDB но в итоге Microblaze загибался с ошибкой “Microblaze pipeline stalled on a blocking instruction or invalid bus access”
Какие нибудь идеи по этому поводу?? в частности причины ошибки линовки и какой то чересчур большой размер tm_basic.elf

[KOLOBOK123124356]

Здравствуйте! Возникла новая проблема при портировании eCos на Microblaze - сейчас работает UART, пытаюсь запустить тест tm_basic но при этом в системе не определяются системные тики. На сколько я понял тики генерятся от прерываний таймера, я настроил таймер чтобы давал прерывания каждые 10 мс. Что мне нужно допилить для определения в системе тиков??? Уже неделю бьюсь, помогите люди((

[gosha]

Здравствуйте! Возникла новая проблема при портировании eCos на Microblaze - сейчас работает UART, пытаюсь запустить тест tm_basic но при этом в системе не определяются системные тики. На сколько я понял тики генерятся от прерываний таймера, я настроил таймер чтобы давал прерывания каждые 10 мс. Что мне нужно допилить для определения в системе тиков??? Уже неделю бьюсь, помогите люди((

Обработчик прерывания по таймеру работает?
Должен вызываться.hal_clock_initialize(CYGNUM_HAL_RTC_PERIOD);
Там должен обработчик прерывания по таймеру завеситься на нужное irq при помощи HAL_INTERRUPT_ATTACH()
После прерывания должны размаскироваться HAL_INTERRUPT_UNMASK()

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

Это работает?


Я бы еще поставил печать отладочных сообщений в ф-ии (вызываются они или нет):
void hal_clock_initialize(cyg_uint32 period)
void hal_clock_read(cyg_uint32 *pvalue)
void hal_clock_reset(cyg_uint32 vector, cyg_uint32 period)

[KOLOBOK123124356]

Обработчик прерывания по таймеру работает?
Должен вызываться.hal_clock_initialize(CYGNUM_HAL_RTC_PERIOD);
Там должен обработчик прерывания по таймеру завеситься на нужное irq при помощи HAL_INTERRUPT_ATTACH()
После прерывания должны размаскироваться HAL_INTERRUPT_UNMASK()

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

Это работает?


Я бы еще поставил печать отладочных сообщений в ф-ии (вызываются они или нет):
void hal_clock_initialize(cyg_uint32 period)
void hal_clock_read(cyg_uint32 *pvalue)
void hal_clock_reset(cyg_uint32 vector, cyg_uint32 period)

Спасибо большое - все заработало

[KOLOBOK123124356]

Доброго всем времени суток! Настройка таймера прошла успешно, теперь запускается таймер, соответственно планировщик, появились наконец то системные тики, успешно запускаются тесты ядра, а именно tm_basic, вывод у них осуществляется через diag_printf(). Сейчас стоит задача запустить UART. С этим возникла проблема, а именно с обработчиком прерывания UART. При появлении прерывания от UART проц переходит на выполнение default_interrupt_isr, то есть затычки которая делает только return. Вообще судя по коду должен выполняться cyg_hal_plf_serial_isr, но этого не происходит. При запуске тестов из каталога io процессор просто крутит idle process. Помогите пожалуйста в чем может быть проблема?

[gosha]

Доброго всем времени суток! Настройка таймера прошла успешно, теперь запускается таймер, соответственно планировщик, появились наконец то системные тики, успешно запускаются тесты ядра, а именно tm_basic, вывод у них осуществляется через diag_printf(). Сейчас стоит задача запустить UART. С этим возникла проблема, а именно с обработчиком прерывания UART. При появлении прерывания от UART проц переходит на выполнение default_interrupt_isr, то есть затычки которая делает только return. Вообще судя по коду должен выполняться cyg_hal_plf_serial_isr, но этого не происходит. При запуске тестов из каталога io процессор просто крутит idle process. Помогите пожалуйста в чем может быть проблема?

На требуемый вектор прерывания должен завеситься обработчик isr:

Обработчик завешивается?

http://ecos.sourceware.org/cgi-bin/cvsweb....mp;cvsroot=ecos

CODE

    CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr);
static int
cyg_hal_plf_serial_isr(void *__ch_data, int* __ctrlc,
                       CYG_ADDRWORD __vector, CYG_ADDRWORD __data)
{
    int res = 0;
    channel_data_t* chan = (channel_data_t*)__ch_data;
    char c;
    cyg_uint8 lsr;
    CYGARC_HAL_SAVE_GP();

    cyg_drv_interrupt_acknowledge(chan->isr_vector);

    *__ctrlc = 0;
    HAL_READ_UINT8(chan->base+CYG_DEV_LSR, lsr);
    if ( (lsr & SIO_LSR_DR) != 0 ) {

        HAL_READ_UINT8(chan->base+CYG_DEV_RBR, c);
        if( cyg_hal_is_break( &c , 1 ) )
            *__ctrlc = 1;

    }

    res = CYG_ISR_HANDLED;
    
    CYGARC_HAL_RESTORE_GP();
    return res;
}

Нужна помощь в запуске UART под eCos. На данный момент при появлении прерывания с UART проц переходит к обработчику прерывания по умолчанию - простой затычке, которая делает только return. Вообще должна вызываться функция обработки прерывания UART, которая описана в файле hal_diag.c

cyg_hal_plf_serial_isr(channel_data_t *chan, int *ctrlc,.
CYG_ADDRWORD vector, CYG_ADDRWORD data)
{
chan->ctrlc = ctrlc;
XUartNs550_InterruptHandler(&chan->dev);
HAL_INTERRUPT_ACKNOWLEDGE(chan->isr_vector);
return CYG_ISR_HANDLED;
}

При инициализации channel 0 обявляется этот обработчик

void
cyg_hal_plf_serial_init(void)
{
hal_virtual_comm_table_t* comm;
int cur = CYGACC_CALL_IF_SET_CONSOLE_COMM(CYGNUM_CALL_IF_SET_COMM_ID_QUERY_CURRENT);

// Disable interrupts.
HAL_INTERRUPT_MASK(channels[0].isr_vector);

// Init channels
init_serial_channel(&channels[0]);

// Setup procs in the vector table

// Set channel 0
CYGACC_CALL_IF_SET_CONSOLE_COMM(0);
comm = CYGACC_CALL_IF_CONSOLE_PROCS();
CYGACC_COMM_IF_CH_DATA_SET(*comm, &channels[0]);
CYGACC_COMM_IF_WRITE_SET(*comm, cyg_hal_plf_serial_write);
CYGACC_COMM_IF_READ_SET(*comm, cyg_hal_plf_serial_read);
CYGACC_COMM_IF_PUTC_SET(*comm, cyg_hal_plf_serial_putc);
CYGACC_COMM_IF_GETC_SET(*comm, cyg_hal_plf_serial_getc);
CYGACC_COMM_IF_CONTROL_SET(*comm, cyg_hal_plf_serial_control);
CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr);
CYGACC_COMM_IF_GETC_TIMEOUT_SET(*comm, cyg_hal_plf_serial_getc_timeout);
// Restore original console
CYGACC_CALL_IF_SET_CONSOLE_COMM(cur);
}

Но в итоге при появлении прерывания не проходит подтверждение прерывания (interrupt acknowledge), прерывание не сбрасывается и проц крутит постоянно обработку прерывания в виде return. Помогите разобраться в чем проблема?

Функция обработчика вызывается?
Снимается ли причина прерывания? Флаги наличия прерывания в UART?
Если снимается причина прерывания, я бы посмотрел макрос HAL_INTERRUPT_ACKNOWLEDGE(chan->isr_vector); Флаги прерывания в регистрах контроллера до его вызова и после.
Разбирался бы с логикой работы контроллера прерываний.

Может кто посоветует, где взять порты под ecos на плату at91sam9263-ek?

Под мою плату также не было порта.
Я собирпл порт из кубиков (компонент из комплекта eCos) при помощи GUI утилиты настройки bp rjvgktrnf eCos : ./tools/bin/configtool

http://caxapa.ru/upload/files/58bbd5554bd7...83f4372e73d8f79
Стр 248

[KOLOBOK123124356]

На требуемый вектор прерывания должен завеситься обработчик isr:

Обработчик завешивается?

http://ecos.sourceware.org/cgi-bin/cvsweb....mp;cvsroot=ecos

Код

    CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr);
static int
cyg_hal_plf_serial_isr(void *__ch_data, int* __ctrlc,
                       CYG_ADDRWORD __vector, CYG_ADDRWORD __data)
{
    int res = 0;
    channel_data_t* chan = (channel_data_t*)__ch_data;
    char c;
    cyg_uint8 lsr;
    CYGARC_HAL_SAVE_GP();

    cyg_drv_interrupt_acknowledge(chan->isr_vector);

    *__ctrlc = 0;
    HAL_READ_UINT8(chan->base+CYG_DEV_LSR, lsr);
    if ( (lsr & SIO_LSR_DR) != 0 ) {

        HAL_READ_UINT8(chan->base+CYG_DEV_RBR, c);
        if( cyg_hal_is_break( &c , 1 ) )
            *__ctrlc = 1;

    }

    res = CYG_ISR_HANDLED;
    
    CYGARC_HAL_RESTORE_GP();
    return res;
}

Функция обработчика вызывается?
Снимается ли причина прерывания? Флаги наличия прерывания в UART?
Если снимается причина прерывания, я бы посмотрел макрос HAL_INTERRUPT_ACKNOWLEDGE(chan->isr_vector); Флаги прерывания в регистрах контроллера до его вызова и после.
Разбирался бы с логикой работы контроллера прерываний.




Под мою плату также не было порта.
Я собирпл порт из кубиков (компонент из комплекта eCos) при помощи GUI утилиты настройки bp rjvgktrnf eCos : ./tools/bin/configtool

http://caxapa.ru/upload/files/58bbd5554bd7...83f4372e73d8f79
Стр 248

Здравствуйте, спасибо за ответы. Я понимаю что CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr); привязывает обработчик прерывания, но не совсем понятен механизм привязки. У меня сейчас при появлении прерывания проц переходит на адрес 0x00000010 где содержится команда перехода на стандартный обработчик прерывания, который как я уже писал представляет собой простую затычку. Вопрос в том к какому прерыванию привязывает эта функция CYGACC_COMM_IF_DBG_ISR_SET(*comm, cyg_hal_plf_serial_isr);??? Потому как cyg_hal_plf_serial_isr корректный обработчик прерывания, так как он выполняет HAL_INTERRUPT_ACKNOWLEDGE и по коду должен сбрасывать флаги прерывания и корректно его обрабатывать но нет привязки его к прерыванию от UART.

Насколько я понял в eCos существует 2 так называемых канала связи - консоль и отладочный канал через который как я понял работают стандартные diag_printf для вывода сообщений при выполнении тестов. Вот как раз отладочный канал работает без нареканий, то есть diag_printf выводит)) а вот если проводить запись с помощью API функций типа cyg_io_write то - все глухо, причем API функция cyg_io_lookup находит устройства /dev/ser0, /dev/tty но при записи в в эти устройства ничего не выводится.И еще такой вопрос - физически устройства для консольного и отладочного каналов должны быть разными?? потому как на плате только 1 UART порт, не совсем ясно потому как если они должны работать с разными физическими устройствами то rx tx надо распиновать отдельно и ставить еще один UART компонент, заранее спасибо за любую помощь в понимании вопроса