[карамболь 0]

Здравствуйте. Столкнулся с такой необычной ситуацией. Есть две самодельные платы на одном и том же чипе Arria 5, платы практически одинаковые, разница в том, что на более свежей разведен USB. 

Есть весь необходимый софт для запуска Линукс. Написан драйвер для своих устройство и пользовательская программа. В последнее время отлаживал софт на новой плате (платы предыдущей разработки все установлены в свои девайсы).

За это время перешел в кернела 3.18 на 5.2, соответственно пересобрал драйвер под новое ядро. Тут пришло время обновить софт на старых платах.

И начались чудеса.

Поменял на Sd карте ядро линукса, накатил драйвер, записал preloader и при insmod ядро зависло. Поставил эту SD карту на новую плату (с заменой preloader) и на ней все отлично работает. Перекидываю карту назад и снова ядро виснет, замена preloader не помогает.

Стал разбираться в драйвере, обвесил его printk-ами и выяснил, что крашится при попытке записи в регистр L3REGS (0xFF800000)

 

    remap = L3REGS_REMAP_LWH2F_BIT | L3REGS_REMAP_H2F_BIT;
 
    printk ("init_hw_interface 8 L3REGS = %x !\n", L3REGS + L3REGS_REMAP_OFF );

    iowrite32(remap, L3REGS + L3REGS_REMAP_OFF);

 

Функции ioremap, request_mem_region присутствуют, там все корректно, да и работал это драйвер годами и этот кусок не правился, добавлялись только новые устройства со своими прерываниями (в DTB вносились соответствующие изменения). 

Причем, если на неработающей плате откатить только ядро до 3.18 (и пересобрать драйвер, соответственно), то все отлично работает.

На что еще обратить внимание ? Я уже себе весь мозг сломал. Спасибо

[Jury093 2]

5 часов назад, карамболь сказал:

Причем, если на неработающей плате откатить только ядро до 3.18 (и пересобрать драйвер, соответственно), то все отлично работает.

На что еще обратить внимание ? Я уже себе весь мозг сломал. Спасибо

а то, что этот регистр write-only не смущает printk?

l3regs 0xFF800000 0xFF800000
Offset: 0x0
Access: WO

по описанию очень смахивает на проблему в прелоадере - откусите из сборки USB и попробуйте собранное на старой плате

еррату смотрели?

[карамболь 0]

10 hours ago, Jury093 said:

а то, что этот регистр write-only не смущает printk?

l3regs 0xFF800000 0xFF800000
Offset: 0x0
Access: WO

по описанию очень смахивает на проблему в прелоадере - откусите из сборки USB и попробуйте собранное на старой плате

еррату смотрели?

Спасибо за ответ. Я в этот регистр только пишу (читать пробовал в качестве эксперимента, было подозрение, что глюк в кернеле и неправильно отрабатывает ioremap). Сейчас у меня прошивка без USB и Handoff от нее, пересобрал прелодер, но ничего не изменилось. Странно, что с другими регистрами такого не происходит. Еррату пока не читал

[Jury093 2]

59 минут назад, карамболь сказал:

Спасибо за ответ. Я в этот регистр только пишу (читать пробовал в качестве эксперимента, было подозрение, что глюк в кернеле и неправильно отрабатывает ioremap). Сейчас у меня прошивка без USB и Handoff от нее, пересобрал прелодер, но ничего не изменилось. Странно, что с другими регистрами такого не происходит. Еррату пока не читал

может забыли в убуте манипуляции сделать, типа бридж дернуть?

у альтеры это штатный код, там не д.б. таких чудес, у нас подобное работает на cyclone5_soc несколько лет

если проблема не решиться, попробуйте взять ядро помладше с упором проверки именно на этот функционал..

[карамболь 0]

Ладно, допустим, что проблема в preloader. Но почему тот же прелодер с ядром 3.18 работает корректно на старой плате ? Вот это меня больше всего интересует

Just now, Jury093 said:

может забыли в убуте манипуляции сделать, типа бридж дернуть?

у альтеры это штатный код, там не д.б. таких чудес, у нас подобное работает на cyclone5_soc несколько лет

если проблема не решиться, попробуйте взять ядро помладше с упором проверки именно на этот функционал..

я ниже ответил уже. С ядром 3.18 эта связка (убут+прелодер+драйвер) работает нормально 

[Jury093 2]

1 час назад, карамболь сказал:

Ладно, допустим, что проблема в preloader. Но почему тот же прелодер с ядром 3.18 работает корректно на старой плате ? Вот это меня больше всего интересует

я ниже ответил уже. С ядром 3.18 эта связка (убут+прелодер+драйвер) работает нормально 

если это не баг силикона, то значит что-то упустили, все же прыжок с 3.хх на 5.х довольно резок, могли где-то имена поменять или еще что-то не очевидное..

а где храниться окружение убута? на той же uSD?

в таких случаях помогает последовательная замена бинарников, от модуля до прелоадера и поиск проблемного места в момент когда заработает..

[карамболь 0]

15 minutes ago, Jury093 said:

если это не баг силикона, то значит что-то упустили, все же прыжок с 3.хх на 5.х довольно резок, могли где-то имена поменять или еще что-то не очевидное..

а где храниться окружение убута? на той же uSD?

в таких случаях помогает последовательная замена бинарников, от модуля до прелоадера и поиск проблемного места в момент когда заработает..

окружение убута тоже на карте хранится. Кстати, вспомнил, что в DTB не выпилил USB... Может из-за этого глючить ? Но все равно непонятно, почему с 3.18 работает... 

Изменено 26 февраля, 2020 пользователем карамболь

[Jury093 2]

1 час назад, карамболь сказал:

окружение убута тоже на карте хранится. Кстати, вспомнил, что в DTB не выпилил USB... Может из-за этого глючить ? Но все равно непонятно, почему с 3.18 работает... 

 

если я правильно понял - платы идентичны, кроме как в новой добавлена поддержка USB, остальное одинаково - память, порты, периферия.

старый и новый прелоадер работают на обеих платах, ядро 3.18 и модули аналогично, проблема нового ядра, точнее модуля на его основе и старой платы

остается немногое: отсечь идентификацию платы (если она есть) и поискать костыли в виде дефайнов, типа "если ядро старее чем делаем то, иначе другое", в теории новый кросскомпилятор может добавить проблем. больше идей пока не вижу..

[карамболь 0]

3 minutes ago, Jury093 said:

если я правильно понял - платы идентичны, кроме как в новой добавлена поддержка USB, остальное одинаково - память, порты, периферия.

старый и новый прелоадер работают на обеих платах, ядро 3.18 и модули аналогично, проблема нового ядра, точнее модуля на его основе и старой платы

остается немногое: отсечь идентификацию платы (если она есть) и поискать костыли в виде дефайнов, типа "если ядро старее чем делаем то, иначе другое", в теории новый кросскомпилятор может добавить проблем. больше идей пока не вижу..

все практически так, как вы описали. Только один нюанс, на новой плате тоже происходит зависание с новым ядром, но лечится заменой прелодера. А старая плата работает только с ядром 3.18, от прелодера не зависит

[R6L-025 1]

А регистр в который пишете, он расположен в HPS, или через мост в FPGA пишется? Я к тому что нет возможности посмотреть сигналтапом на процесс записи? Может waitrequest бесконечно висит, или еще что...

[карамболь 0]

3 hours ago, R6L-025 said:

А регистр в который пишете, он расположен в HPS, или через мост в FPGA пишется? Я к тому что нет возможности посмотреть сигналтапом на процесс записи? Может waitrequest бесконечно висит, или еще что...

извините, что не ответил сразу. Да, это регистр HPS, так что сигналтапом не посмотреть 

[R6L-025 1]

 dtb файл Вы же изменяли? Т.е. на старой плате убирали описание usb? 

А ядро кросскомпилятором собираете? Может (если есть возможность) попробовать на плате собрать?

[карамболь 0]

2 hours ago, R6L-025 said:

 dtb файл Вы же изменяли? Т.е. на старой плате убирали описание usb? 

А ядро кросскомпилятором собираете? Может (если есть возможность) попробовать на плате собрать?

dtb не менял в части USB, только новые прерывания добавлял по мере необходимости. Ядро собираю кросскомпилятором

[gosha-z 2]

33 minutes ago, карамболь said:

Ядро собираю кросскомпилятором

А каким? (Версия gcc?)

[карамболь 0]

44 minutes ago, gosha-z said:

А каким? (Версия gcc?)

Linaro GCC 4.9-2016.02    (4.9.4 20151028 prerelease)