Собрал u-boot 2012.07, бутсрап - с этого форума (который может грузить ядро сам), тестировал минут 20, не знаю сколько сотен раз он перезагрузился (bootcmd=reset) но так и не завис. Проверял на плате SK-AT91SAM9G45
PS штатный uboot который идет с платой виснет как вы описали, независисмо от того какой бутстрап прошит.
2 sasamy
А базовый адрес LCD у вас при этом где был ? В новом u-boot ? В DDR2 ?
Собрал новый u-boot по умолчанию. Зашил, проверил - вышеописанного эффекта нет. Всё работает.
Правлю размеры памяти, докручиваю LCD под нужный девайс, меняю LCD_BASE на SDRAM, докручиваю Ethernet и чото ещё по мелочи - вшиваю получаем теже грабли.
Пока проверяю связку bootstrap+u-boot без ядра.
Работает при следующих вариантах:
1) Отключить SDRAM в любом bootstrap`е. Хоть в KEIL, хоть тот, который умеет всё - ядро грузить сразу из nand или с sd, грузить u-boot и чото там ещё.
2) Если LCD_BASE в DDR2. Делаешь его в SDRAM получаем вышеописанный эффект.
в автозагрузке добавлено ресорсоёмкое QT-приложение и memtester:
С ssh консоли проверем задействие swap командой free.
Top почему то про swap ничего не знает и не показывает.
Наверное busybox староват...
Работает с обеда без зависаний и желаний перескочить на SD карту. ПОхоже баг где-то в LCD-драйвере при использовании SDRAM. Пока оставлю так. Всем спасибо!
Странный эффект. SDR прекрасно работает - проверял на m10, там она для видеодекодера используется и видеобуфер там же был, никаких проблем не было. Ее же использовал в микроядре L4 для буферов DMA перефирии паравиртуальзованного ядра Linux - опять же все нормально было. Надо будет получше посмотреть - может просто внимания на перезагрузку не обращал, да и nand я там не использовал - все на SD было.
Кстати, вспомнил, на плате SK-MAT91SAM9G45 я намеренно отключил в u-boot LCD т.к. он при этом "чудеса чудил" ...
Драйвер LCD уже в ядре тоже со странностями был, 16бит режим намеренно включен, в противном случае его данные каким то чудом залетали в область GPIO регистров, проявилось в том что тачскрин переставал работать и осциллом видно было последовательности на пинах на которых их не должно было быть ...
NAND и SDRAM сидят на EBI.
DDR2 на своём контроллере. Возникает предположение, что lcd драйвер нужно корректно выгружать при использовании буфера на SDRAM. Чтобы не было обращения по шине EBI в момент софтверного ресета. Хотя данный сабж может возникнуть и при нажатии на кнопку reset`а т.е. при аппаратном.
Немножко не в тему возможно.
Достал с полки SD-карту с debian 6 под armel, собранный debootstrap`ом - там вообще при poweroff или halt экран не тухнет и даже курсор мигает... Как правильно "гасить" lcd-драйвер ?
24.08.2012 15:12 
24.08.2012 15:42
