ЗАО «ЗЭО»
Техническая поддержка пользователей => Тион, Тион-Про, Тион-Про v2, Сириус => Тема начата: speculzzz от 02 Июня, 2010, 08:49:50
-
Добрый день.
Имеется железка, сердцем которой является модуль Тион. На Тионе установлено ядро Linux-2.6.32.3, загрузчик U-Boot 1.3.3 и rootfs, собранный в buildroot 2010.02.
Происходит непонятное зависание при старте ядра после выполнения команды reboot в линуксе.
Поясню: включаем питание - все нормально грузится... далее логинимся в систему и набираем reboot - происходит завершение работы (все как и ожидается)... после управление снова переходит загрузчику, который стартует ядро... и тут все повисает :(...
Лог загрузки:
U-Boot 1.3.3 (Feb 17 2010 - 10:32:30)
CPU: Cirrus Logic EP9315 rev. E2
DRAM: 64 MB
Flash: 8 MB
mac: aa:bb:cc:dd:ee:f2 (from SPI flash)
Hit any key to stop autoboot: 0
## Booting kernel from Legacy Image at 60080000 ...
Image Name: Linux-2.6.32.3
Image Type: ARM Linux Kernel Image (uncompressed)
Data Size: 1842432 Bytes = 1.8 MB
Load Address: 00008000
Entry Point: 00008000
Verifying Checksum ... OK
Loading Kernel Image ... OK
OK
Starting kernel ...
Uncompressing Linux.............................................................
..................................................... done, booting the kernel.
После этого тишина...
Нажимаем кнопку reset - происходит нормальная загрузка линукса. Если опять выполнить reboot - получаем теже грабли :(.
Самое интересное то, что если после загрузки по включению питания сперва перегрузиться по кнопке reset, то последующие вызовы reboot не приводят к зависанию.
Может кто сталкивался с подобной проблемой или знает как можно диагностировать ее... отзовитесь, плиз.
З.Ы. Провел больше тестов... после reboot в основном старт ядра "зависает"... но случается, что все отрабатывается нормально.
-
Посмотрите как сделана перезагрузка в 32, если не через watchdog, то стоит переделать, будет немного надёжней.
-
Посмотрите как сделана перезагрузка в 32, если не через watchdog, то стоит переделать, будет немного надёжней.
Где посмотреть??? Т.е. я так понял надо проверить код reboot-а и с чем-то сравнить???
И вот что интересно:
1) при сбросе по питанию ос грузится всегда
2) загрузчик запускается при любых условиях
3) при сбросе по кнопке ресет зависания есть но редкие
4) при программном перезапуске почти всегда зависает и кнопка ресет может уже не спасти от зависания... только сборос питания все вылечивается.
5) все зависания происходят всегда после "Starting kernel ...": при этом до распаковки ядра может и не дойти даже...
Может со sdram-ом или системной частотой что-то происходит при перезагрузках?! (чего не случается при влючении питания)
-
> Где посмотреть???
В Linux
-
2.6.20 это была функция arch_reset() в include/asm-arm/arch-ep93xx/system.h
static inline void arch_reset(char mode)
{
local_irq_disable();
/* Watchdog reset */
__raw_writew(0xaaaa, EP93XX_WATCHDOG_BASE);
while(1);
}
-
> Где посмотреть???
В Linux
Ясно... просто выражение "посмотрите ... в 32" с толку сбило... что такое 32... :)
2.6.20 это была функция arch_reset() в include/asm-arm/arch-ep93xx/system.h
static inline void arch_reset(char mode)
{
local_irq_disable();
/* Watchdog reset */
__raw_writew(0xaaaa, EP93XX_WATCHDOG_BASE);
while(1);
}
Странно... смотрю linux-2.6.20.21_tion_svn861.patch (последнее что у меня есть для этой ветви). В arch_reset много чего позакаментчено, но суть такая:
#if 0
/* Turn LED's on */
outl(0x3, GPIO_PEDR);
outl(0x3, GPIO_PEDDR);
/* Not work, even with LED's on */
/* Enable watchdog */
__raw_writel(0xaaaa, EP93XX_WATCHDOG_BASE);
#else
/* Not work 100 % */
/* Software reset */
devicecfg = __raw_readl(EP93XX_SYSCON_DEVICE_CONFIG);
__raw_writel(0xaa, EP93XX_SYSCON_SWLOCK);
__raw_writel(devicecfg | 0x80000000, EP93XX_SYSCON_DEVICE_CONFIG);
__raw_writel(0xaa, EP93XX_SYSCON_SWLOCK);
__raw_writel(devicecfg & ~0x80000000, EP93XX_SYSCON_DEVICE_CONFIG);
#endif
т.е. оба варианта не работают на 100% :(
В 2.6.32.3 делают так:
static inline void arch_reset(char mode, const char *cmd)
{
local_irq_disable();
/*
* Set then clear the SWRST bit to initiate a software reset
*/
ep93xx_devcfg_set_bits(EP93XX_SYSCON_DEVCFG_SWRST);
ep93xx_devcfg_clear_bits(EP93XX_SYSCON_DEVCFG_SWRST);
while (1)
;
}
Настораживает все же тот момент, что зависание происходит не в момент перезагрузки, а в момент старта ядра...
-
> (последнее что у меня есть для этой ветви)
Я всё никак не выложу.
> т.е. оба варианта не работают на 100% :(
Да, как и с кнопкой, тоже не 100%.
> что зависание происходит не в момент перезагрузки, а в момент старта ядра...
Возможно связано с MMU или I/D-кешами.
-
Переписал arch_reset() на сброс через ватчдог... ситуация значительно улучшилась, но проблема не устранилась (просто стало реже зависать). Добавил принтф в "бесконечный цикл" после взвода ватчдога: т.е. пока ждем срабатывания ватчдога получаем в консоле
[ 25.060000] Restarting system.
[ 25.060000] *
....
[ 25.060000] *
[ 25.
И так получается 119 "*", а на 120 все останавливается.
В гугловской группе tion_sbc некто Roman в 2008 писал (http://groups.google.com/group/tion_sbc/browse_thread/thread/c273d2edafc20ead/2b6e35e9c134b2d4?lnk=gst&q=reboot#2b6e35e9c134b2d4 (http://groups.google.com/group/tion_sbc/browse_thread/thread/c273d2edafc20ead/2b6e35e9c134b2d4?lnk=gst&q=reboot#2b6e35e9c134b2d4))
"Мы знаем об этой проблеме... сейчас думаем о более лучшем способе
сброса."
И так с тех пор ничего не изменилось?
-
>И так с тех пор ничего не изменилось?
Нет.
-
В итоге пришлось в прошивку навесной платы добавлять логику по отслеживанию зависаний - аля программный ватчдог...
Жаль что в циррусе никак от этого бага не избавятся...
Засим считаю тему закрытой. Всем спасибо.
-
На Тион-Про2 можно завести GPIO на X19.3 и получить сброс эквивалентный аппаратному, но он тоже не 100%.