Разные. Хотя есть у меня подозрение, что один списан с другого.

Судя по исходникам - at91_ether применим для процессора at91rm9200. он у меня довольно хорошо работает на этом чипе
(board ar91rm9200-dk с PHY Rtl)
А вот на at91sam9g20, я так понимаю, его ипользовать не получится, по крайней мере без изменений (он и хэадеры использует
от at91rm9200)

А вот насчет "замести ошибку под ковер" - хотелось бы попробывать , только вот не знаю как, можите надоумить ?

Кстати, может кто-то пытался отправить в Atmel кляузу на macb ? честно говоря - я пробовал, но ни ответа и привета....(хотя назад письмо не вернулось)

Сами модули у этих процессоров практически идентичные, поэтому должен запуститься с минимальными изменениями.


Попробуйте записать 0x10000 в MATRIX_PRAS3 - это даст приоритет EMAC'у на шине. Не факт, что в этом дело, но возможно.


Ну, тут как бы as is и все такое. Быстрее будет исправить самому. Тем более что атмеловский софт, на мой взгляд, отличается отвратным качеством изначально.

Вклинюсь в вашу беседу. Колега некоторое время назад боролся с аналогичной проблемой на 9260. Его решение - это перенос дескрипторов DMA во внутреннюю SRAM, т.к. доступ к ней несколько быстрее.

Вот этот патч.

Кроме того, на более свежих ядрах это проявляется редко и патч, в принципе, не требуется.

У 9260 был пункт в еррате, касающийся расположения дескрипторов в SDRAM (может слететь передача). Но в 9G20 по этому поводу тишина.

Пробовал поднять приоритет - писал 0x10000 -> MATRIX_PRAS3 - не помогло, посмотрел по доке этот регистр и похоже
туда надо писать 2 разряда, то есть не 0х10000 а 0х30000 (константа M4PR) - записал. по началу вроде ничего было,
overruns-ов не было (на одиночных sip-вызовах), но как только завел sipp - начали копится overruns-ы (это на 100Мбитах),
спустился на 10Мбит - стали копиться ошибки frame. блин, наказание какое-то. похоже не удалось "загнать проблемму под ковер"

А насчет патча - так ведь он вроде передачи касается (буфер на передачу в SRAM переезжает- или я ошибаюсь ? да и размер SRAM у 9260 и g20 разные вроде), а у меня на интерфейсе по передаче не ошибок, так что и не знаю - пробовать его или нет....





а на более свежих это каких ? я уже пробовал даже 3.0.3 - результат тот же (да там и macb старый и похоже не правился
со времен царя гороха).

Мне кажется, корни у underrun'ов и overrun'ов одни - DMA не успевает. Или память. Можно так же попробовать и с буферами для приема.

Сомневаюсь насчет DMA да и памяти тоже (хотя с DMA что-то неладное делается, при попутке перенести буфер на передачу
в SRAM ядро пракитчески сразу падает -> "kernel BUG at arch/arm/mm/dma-mapping.c:426!", что-то видимо я не включил через menuconfig для ядра). При работе через конвертор usb-lan все же нормально и с памятью и с dma (хотя может в этом случае dma
и вовсе не используется)

Свершилось ! Нашелся человек, который вправил мозги атмеловскому драйверу macb. Теперь у меня lan (на at91sam9g20ek) работает отлично !

И? Патч не хотите здесь опубликовать?

патча как такового нет, правили по-живому, но кому надо - дам исправленный исходник macb.c (под 2.6.33)

Надо!!!

ftp://elgato@ltd.com.ua/g20/macb.c_correct.tar.gz
pwd=login
для ядра 2.6.33

Сообщение отредактировал salara - Aug 9 2012, 09:02

Спасибо.
Не ожидал такого объема изменений... Приемная часть чуть ли не переписана заново...
Можете в нескольких словах описать суть сделанных изменений?

Не я автор изменений, могу только сказать что основные изменения претерпели функции macb_rx_frame (на ней
собственно ядро и падало при приеме фрэйма), macb_rx, macb_poll