Печать

Пожалуйста, войдите или зарегистрируйтесь.
1 час 1 день 1 неделя 1 месяц Навсегда

[speculzzz]

Добрый день.
Имеется железка, сердцем которой является модуль Тион. На Тионе установлено ядро 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 в основном старт ядра "зависает"... но случается, что все отрабатывается нормально.

[asv]

Посмотрите как сделана перезагрузка в 32, если не через watchdog, то стоит переделать, будет немного надёжней.

[speculzzz]

Посмотрите как сделана перезагрузка в 32, если не через watchdog, то стоит переделать, будет немного надёжней.

Где посмотреть??? Т.е. я так понял надо проверить код reboot-а и с чем-то сравнить???
И вот что интересно:
1) при сбросе по питанию ос грузится всегда
2) загрузчик запускается при любых условиях
3) при сбросе по кнопке ресет зависания есть но редкие
4) при программном перезапуске почти всегда зависает и кнопка ресет может уже не спасти от зависания... только сборос питания все вылечивается.
5) все зависания происходят всегда после "Starting kernel ...": при этом до распаковки ядра может и не дойти даже...

Может со sdram-ом или системной частотой что-то происходит при перезагрузках?! (чего не случается при влючении питания)

[asv]

> Где посмотреть???

В Linux

[asv]

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);
}

[speculzzz]

> Где посмотреть???

В 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)
;
}

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

[asv]

> (последнее что у меня есть для этой ветви)

Я всё никак не выложу.


> т.е. оба варианта не работают на 100% :(

Да, как и с кнопкой, тоже не 100%.

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

Возможно связано с MMU или I/D-кешами.

[speculzzz]

Переписал 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)
"Мы знаем об этой проблеме... сейчас думаем о более лучшем способе
сброса."
И так с тех пор ничего не изменилось?

[asv]

>И так с тех пор ничего не изменилось?

Нет.

[speculzzz]

В итоге пришлось в прошивку навесной платы добавлять логику по отслеживанию зависаний - аля программный ватчдог...
Жаль что в циррусе никак от этого бага не избавятся...

Засим считаю тему закрытой. Всем спасибо.

[asv]

На Тион-Про2 можно завести GPIO на X19.3 и получить сброс эквивалентный аппаратному, но он тоже не 100%.