Jump to content

    

Gemm

Свой
  • Content Count

    62
  • Joined

  • Last visited

Community Reputation

0 Обычный

About Gemm

  • Rank
    Участник
  • Birthday 12/19/1977

Контакты

  • Сайт
    Array
  • ICQ
    Array

Информация

  • Город
    Array
  1. Согласен, уже начали над этим работать :) Тема закрыта.
  2. no-copy API не используем. 60 Мбит - это без LZO и без общения с FPGA, только прием данных по сети.
  3. Ну да, 60 Мбит... С включенным кешем инструкций и данных. Без кешей еще меньше было. DMA на MACе спользуется, bus matrix не трогали. MAC складывает полученные пакеты в SDRAM, шина на 100 МГцах. А какой стек пригоден? По моему, lwip наиболее перспективный... возможно, ошибаюсь. Спасибо за дельный комментарий. )
  4. Поток на входе непостоянный. От сетки удалось выжать 60 Мбит. В самом тяжелом случае вся эта информация - графическая. Компрессор - LZO, никаких аппаратных фич для распаковки пока нет. А вот если не принимать во внимание распаковку, просто сырые данные принимают по сети - и уходят на ПЛИС... Просто требуется максимальная скорость от стека! Вот!
  5. Что значит "могут оказаться..", по каким причинам? Я же описал задачу. TCP/IP стек (физикл RTL8201) + разпаковка полученных данных (никаких операций с плавающей точкой) + отправка их по 32-разрядной шине в ПЛИС. Что ARM7, ARM9, ARM11,....? В вашем предложении нет ни подлежащего, ни сказуемого. Если вы просите уточнить семейство, то я не знаю... Я поэтому и задаю вопрос относительно скорости АРМов в целом. До этого работали с 9м, поэтому имеется куча наработок и опыта по работе с ним.
  6. Считаю, что здесь сбираются достаточно грамотные люди, чтоб завестись от моих слов относительно скорости проца. А что здесь не конкретного? Я спросил про скорость, подразумевая мегагерцы его процессорного клока или мипсы. Не это ли основной показатель скорости его работы? Как еще можно понять мой вопрос??? У нас есть плата на базе SAM9263 (240 МГц). На плате поднят сетевой стек lwip. По нему плата получает графику, декодирует ее и отправляет на видео систему, реализованную на ПЛИС. Пока скорость работы устраивает, но в следующем поколении платы хотелось бы заложить более быстрый проц, если такой существует. Почему сейчас используем Атмел? - исторически так сложилось, возможно это и не совсем подходящий для задачи проц. Почему??? Поясните, пожалуйста...
  7. собственно сабж
  8. Аааа, все понял. Спасибо. Не заметил, что иаровская функция - на асме переклинило...
  9. Строка __asm("MRC p15, 0, ctl, c1, c0, 0"); не прокатывает. Этой инструкции нужно не переменную передать, а явно указать регистр. Вот так получается: __asm("MRC p15, 0, r0, c1, c0, 0"); Я собственно и спрашиваю, как сделать, чтоб заработало с переменной.
  10. Не, не ломать - настроить штатным способом. Если нельзя - то нельзя, хрен с ним... Просто у нас тут по историческим причинам некоторые люди компиляют ИАРом, некоторые - ГЦЦ. Иногда хочется, чтоб код был универсальный... За асмовский код огромное спасибо, постараюсь к вечеру досканально разобраться и внедрить...
  11. А под вышеописанный мной код нельзя адаптировать асм? Не хочу ломать либу. У меня есть свой csturtup с поддержкой всего этого, кроме MMU. Никогда с ним не работал. Поэтому посчитал, что наиболее быстрое решение - воспользоваться примером. Возможно, ошибаюсь.
  12. Начал поднимать data cache-MMU в железке на базе SAM9263. Компилер - IAR 5.1. Нашел на атмеле примерный проектик с драйстоун тестом, где кеши активно используются, но немножко не под мой компилятор :) . И вот такая конструкция не компилится по причине того, что в асмовской инструкции я не могу использовать свою переменную ctl. Хотя это неправильно, она же регистровая... Не хотелось бы ломать красивый код, а настроить свой асм, чтоб он понимал такой синтаксис. И еще вопрос, если кто занимался - у at91rm9200 и at91sam9263 принципиально чем-то отличается работа с MMU и дата кешем? __inline unsigned int AT91F_ARM_ReadControl() { register unsigned int ctl; __asm("MRC p15, 0, ctl, c1, c0, 0"); return ctl; } Спасибо.
  13. Сначала тоже юзали uIP, скорость была еще ниже. Потом подняли lwIP стек, включили все кеши (АТ91RM9200) - сейчас 64 Мбита, больше - никак :(
  14. Блин! Два дня искал причину! Поправил все вектора, чтоб они указывали на корректные адреса после их рамапа в 0. Перестроил AIC - запретил и очистил все, что только можно! - Все равно вылезал старый обработчик. Ну бред, не бывает так....он явно где-то кэшировался, этот старый адрес. Потом сделал такую вещь: mov r0, #0 mcr p15, 0, r0, c1, c0, 0 Записал в CP15 нули. Отключил кеш инструкций в том числе. Все заработало Вообще странно. Я его использовал, но включал позже, после всех ремапов...
  15. Спасибо :) Давайте... Программа из ИАРа грузится в SDRAM по адресу 0x21F00000. Сконфигурил линкер на такой адрес, потому что romboot тоже туда грузит. Т.е., после загрузки ИАРом и romboot'ом программа лежит по этому адресу. В ее начале - вектора. Вот они: __program_start: 21F00000 E59FF018 LDR PC, [PC, #+24] ; [0x21F00020] =?cstartup (0x21F00074) 21F00004 00000000 ANDEQ R0, R0, R0 21F00008 00000000 ANDEQ R0, R0, R0 21F0000C 00000000 ANDEQ R0, R0, R0 ldr pc,[pc,#24]; Branch to data_handler 21F00010 E59FF018 LDR PC, [PC, #+24] ; [0x21F00030] =?data_abort (0x21F0003C) 21F00014 0841A006 STMEQDA R1, {R1,R2,SP,PC}^ ldr PC,[PC,#-0xF20] 21F00018 E51FFF20 LDR PC, [PC, #-3872] ; [0x21EFF100] =0x21F0085C 21F0001C 00000000 ANDEQ R0, R0, R0 21F00020 21F00074 MVNCSS R0, R4, ROR R0 21F00024 00000000 ANDEQ R0, R0, R0 21F00028 00000000 ANDEQ R0, R0, R0 21F0002C 00000000 ANDEQ R0, R0, R0 21F00030 21F0003C MVNCSS R0, R12, LSR R0 21F00034 00000000 ANDEQ R0, R0, R0 21F00038 00000000 ANDEQ R0, R0, R0 А в нулевом адресе - вектора ромбута. Вот они: 00000000 EA000006 B 0x000020 ; RESET 00000004 EA08006D B 0x2001C0 ; UND 00000008 EAFFFFFE B 0x000008 ; SWI 0000000C EA08005F B 0x200190 ; P ABT 00000010 EA080053 B 0x200164 ; D ABT 00000014 0841A018 STMEQDA R1, {R3,R4,SP,PC}^ 00000018 E51FFF20 LDR PC, [PC, #-3872] ; IRQ [AIC_IVR (0xFFFFF100)] =0x20012C 0000001C EA080071 B 0x2001E8 ; FIQ 00000020 E3A00981 MOV R0, #0x204000 ; 0x204028 00000024 E321F0D1 MSR CPSR_c, #0xD1 00000028 E1A0D000 MOV SP, R0 0000002C E2400004 SUB R0, R0, #0x4 00000030 E321F0D2 MSR CPSR_c, #0xD2 00000034 E1A0D000 MOV SP, R0 00000038 E2400010 SUB R0, R0, #0x10 В самом начале cstartup, до ремапа, беру их и копирую в начало ОЗУ - в 0x200000 (сейчас копирую все, а не один, как раньше, но особо ничего не поменялось). Далее делаю ремап, если нужно. Вот после этого, по идее, я перетер все ромбутовские вектора. Ну никак его обработчики не должны вызываться! Кстати, окошко дизасемблера ИАРа показывает старый контент (???) - нужно смотреть в память. Все дальше работает замечательно. Далее искусственно вызываю data abort *((int*)0x01) = 1; - попадаю в свой (0x21F0003C) обработчик. Но если бинарник загрузить во флешку, откуда его romboot переписывает в 0x21f00000 и запускает - то ничего не работает.... запускается ромбутовский обработчик -F- Data Abort detected... все... Иногда, очень редко вызывался мой обработчик (если не отключать питание платы, а сделать ресет - и сразу залить прогу через ромбут - видимо, оставались правильные вектора после отладки из ИАРа). А не может ли ромбут как-нибудь блокировать запись в свои вектора...