[at91sam9g45] fail to start second kernel via kexec if watchdog is enabled

[at91sam9g45] fail to start second kernel via kexec if watchdog is enabled

[Yegor Yefremov]

Hello,

I have problem booting the second kernel after enabling the watchdog following these steps: http://www.at91.com/index.php?option=com_jfusion&Itemid=57&jfile=viewtopic.php&f=12&t=5551&p=29283&hilit=watchdog+bootstrap#p29283
Bootstrap: don't touch watchdog
U-Boot: configure watchdog and set the timer counter value to 16 seconds
Linux: keep pinging the watchdog

The first kernel (booted from u-boot) is working as expected, but if I start the new one using kexec it gets only till frame buffer init:

....
NetWinder Floating Point Emulator V0.97 (double precision)
Slow work thread pool: Starting up
Slow work thread pool: Ready
JFFS2 version 2.2. (NAND) -? 2001-2006 Red Hat, Inc.
msgmni has been set to 245
io scheduler noop registered
io scheduler anticipatory registered (default)
atmel_lcdfb atmel_lcdfb.0: backlight control is not available
atmel_lcdfb atmel_lcdfb.0: 510KiB frame buffer at 77980000 (mapped at ffa00000)
Start AT91Bootstrap...

Without watchdog there is no problem. Both kernels (2.6.32-rc5) are the same. Any idea?

Best regards,
Yegor

[at91sam9g45] fail to start second kernel via kexec if watchdog is enabled

[Jean-Christophe PLAGNIOL-VILLARD]

On 12:43 Wed 21 Oct     , Yegor Yefremov wrote:
> Hello,
> 
> I have problem booting the second kernel after enabling the watchdog following these steps: http://www.at91.com/index.php?option=com_jfusion&Itemid=57&jfile=viewtopic.php&f=12&t=5551&p=29283&hilit=watchdog+bootstrap#p29283
> Bootstrap: don't touch watchdog
> U-Boot: configure watchdog and set the timer counter value to 16 seconds
> Linux: keep pinging the watchdog
> 
> The first kernel (booted from u-boot) is working as expected, but if I start the new one using kexec it gets only till frame buffer init:
> 
> ....
> NetWinder Floating Point Emulator V0.97 (double precision)
> Slow work thread pool: Starting up
> Slow work thread pool: Ready
> JFFS2 version 2.2. (NAND) -? 2001-2006 Red Hat, Inc.
> msgmni has been set to 245
> io scheduler noop registered
> io scheduler anticipatory registered (default)
> atmel_lcdfb atmel_lcdfb.0: backlight control is not available
> atmel_lcdfb atmel_lcdfb.0: 510KiB frame buffer at 77980000 (mapped at ffa00000)
> Start AT91Bootstrap...
> 
> Without watchdog there is no problem. Both kernels (2.6.32-rc5) are the same. Any idea?
do you enable the watchdog in the send kernel?

Best Regards,
J.

[at91sam9g45] fail to start second kernel via kexec if watchdog is enabled

[Yegor Yefremov]

>> I have problem booting the second kernel after enabling the watchdog following these steps: http://www.at91.com/index.php?option=com_jfusion&Itemid=57&jfile=viewtopic.php&f=12&t=5551&p=29283&hilit=watchdog+bootstrap#p29283
>> Bootstrap: don't touch watchdog
>> U-Boot: configure watchdog and set the timer counter value to 16 seconds
>> Linux: keep pinging the watchdog
>>
>> The first kernel (booted from u-boot) is working as expected, but if I start the new one using kexec it gets only till frame buffer init:
>>
>> ....
>> NetWinder Floating Point Emulator V0.97 (double precision)
>> Slow work thread pool: Starting up
>> Slow work thread pool: Ready
>> JFFS2 version 2.2. (NAND) -? 2001-2006 Red Hat, Inc.
>> msgmni has been set to 245
>> io scheduler noop registered
>> io scheduler anticipatory registered (default)
>> atmel_lcdfb atmel_lcdfb.0: backlight control is not available
>> atmel_lcdfb atmel_lcdfb.0: 510KiB frame buffer at 77980000 (mapped at ffa00000)
>> Start AT91Bootstrap...
>>
>> Without watchdog there is no problem. Both kernels (2.6.32-rc5) are the same. Any idea?
> do you enable the watchdog in the send kernel?

Yes. But as you can see from the bootlog, the system reboots before watchdog driver will be initialized. I'll try to tap watchdog in the board init part. Maybe it will help.

Regards,
Yegor

[at91sam9g45] fail to start second kernel via kexec if watchdog is enabled

[Yegor Yefremov]

>>> I have problem booting the second kernel after enabling the watchdog following these steps: http://www.at91.com/index.php?option=com_jfusion&Itemid=57&jfile=viewtopic.php&f=12&t=5551&p=29283&hilit=watchdog+bootstrap#p29283
>>> Bootstrap: don't touch watchdog
>>> U-Boot: configure watchdog and set the timer counter value to 16 seconds
>>> Linux: keep pinging the watchdog
>>>
>>> The first kernel (booted from u-boot) is working as expected, but if I start the new one using kexec it gets only till frame buffer init:
>>>
>>> ....
>>> NetWinder Floating Point Emulator V0.97 (double precision)
>>> Slow work thread pool: Starting up
>>> Slow work thread pool: Ready
>>> JFFS2 version 2.2. (NAND) -? 2001-2006 Red Hat, Inc.
>>> msgmni has been set to 245
>>> io scheduler noop registered
>>> io scheduler anticipatory registered (default)
>>> atmel_lcdfb atmel_lcdfb.0: backlight control is not available
>>> atmel_lcdfb atmel_lcdfb.0: 510KiB frame buffer at 77980000 (mapped at ffa00000)
>>> Start AT91Bootstrap...
>>>
>>> Without watchdog there is no problem. Both kernels (2.6.32-rc5) are the same. Any idea?
>> do you enable the watchdog in the send kernel?
> 
> Yes. But as you can see from the bootlog, the system reboots before watchdog driver will be initialized. I'll try to tap watchdog in the board init part. Maybe it will help.


It works! I just inserted watchdog reset statement into arch/arm/mach-at91/board-sam9m10g45ek.c->ek_board_init() routine:

static void __init ek_board_init(void)
{
	/* Serial */
	at91_add_device_serial();
.....
	/* LEDs */
	at91_gpio_leds(ek_leds, ARRAY_SIZE(ek_leds));
	at91_pwm_leds(ek_pwm_led, ARRAY_SIZE(ek_pwm_led));
	at91_sys_write(AT91_WDT_CR, AT91_WDT_KEY | AT91_WDT_WDRSTT);
}

It is actually a workaround, but till the real reason is figures out, it keeps the system working.

Regards,
Yegor

[at91sam9g45] fail to start second kernel via kexec if watchdog is enabled

[Jean-Christophe PLAGNIOL-VILLARD]

On 10:06 Fri 23 Oct     , Yegor Yefremov wrote:
> >>> I have problem booting the second kernel after enabling the watchdog following these steps: http://www.at91.com/index.php?option=com_jfusion&Itemid=57&jfile=viewtopic.php&f=12&t=5551&p=29283&hilit=watchdog+bootstrap#p29283
> >>> Bootstrap: don't touch watchdog
> >>> U-Boot: configure watchdog and set the timer counter value to 16 seconds
> >>> Linux: keep pinging the watchdog
> >>>
> >>> The first kernel (booted from u-boot) is working as expected, but if I start the new one using kexec it gets only till frame buffer init:
> >>>
> >>> ....
> >>> NetWinder Floating Point Emulator V0.97 (double precision)
> >>> Slow work thread pool: Starting up
> >>> Slow work thread pool: Ready
> >>> JFFS2 version 2.2. (NAND) -? 2001-2006 Red Hat, Inc.
> >>> msgmni has been set to 245
> >>> io scheduler noop registered
> >>> io scheduler anticipatory registered (default)
> >>> atmel_lcdfb atmel_lcdfb.0: backlight control is not available
> >>> atmel_lcdfb atmel_lcdfb.0: 510KiB frame buffer at 77980000 (mapped at ffa00000)
> >>> Start AT91Bootstrap...
> >>>
> >>> Without watchdog there is no problem. Both kernels (2.6.32-rc5) are the same. Any idea?
> >> do you enable the watchdog in the send kernel?
> > 
> > Yes. But as you can see from the bootlog, the system reboots before watchdog driver will be initialized. I'll try to tap watchdog in the board init part. Maybe it will help.
> 
> 
> It works! I just inserted watchdog reset statement into arch/arm/mach-at91/board-sam9m10g45ek.c->ek_board_init() routine:
> 
> static void __init ek_board_init(void)
> {
> 	/* Serial */
> 	at91_add_device_serial();
> .....
> 	/* LEDs */
> 	at91_gpio_leds(ek_leds, ARRAY_SIZE(ek_leds));
> 	at91_pwm_leds(ek_pwm_led, ARRAY_SIZE(ek_pwm_led));
> 	at91_sys_write(AT91_WDT_CR, AT91_WDT_KEY | AT91_WDT_WDRSTT);
> }
> 
> It is actually a workaround, but till the real reason is figures out, it keeps the system working.
I would sugest to mesure how many time to you need to go to the driver init

if it's less than the watchdog I'd supposed that just before the jump to the second
kernel the watchdog was not reset

Best Regards,
J.