[#5476] set panic=3 in bootargs doesn't make kernel reboot when it panics

Document created by Aaronwu Employee on Sep 4, 2013
Version 1Show Document
  • View in full screen mode

[#5476] set panic=3 in bootargs doesn't make kernel reboot when it panics

Submitted By: Mingquan Pan

Open Date

2009-08-31 23:25:28    

Priority:

Medium     Assignee:

Vivi Li

Barry Song

Status:

Open     Fixed In Release:

N/A

Found In Release:

2010R1     Release:

Category:

N/A     Board:

N/A

Processor:

BF537     Silicon Revision:

Is this bug repeatable?:

Yes     Resolution:

Under Debugging

Uboot version or rev.:

    Toolchain version or rev.:

09r1-rc10

App binary format:

N/A     

Summary: set panic=3 in bootargs doesn't make kernel reboot when it panics

Details:

 

set panic=3 in bootargs doesn't make kernel reboot when it panics.

 

U-Boot 2008.10 (ADI-2009R1-rc3) (Jul 16 2009 - 18:02:12)

 

CPU:   ADSP bf537-0.2 (Detected Rev: 0.2) (bypass boot)

Board: ADI BF537 stamp board

       Support: http://blackfin.uclinux.org/

Clock: VCO: 500 MHz, Core: 500 MHz, System: 125 MHz

RAM:   64 MB

Flash:  4 MB

In:    serial

Out:   serial

Err:   serial

Net:   Blackfin EMAC

MAC:   36:FA:F3:8F:8D:FE

Hit any key to stop autoboot:  0

bfin> print

baudrate=57600

loads_echo=1

rootpath=/romfs

hostname=bf537-stamp

loadaddr=0x1000000

ubootfile=u-boot.bin

update=tftp $(loadaddr) $(ubootfile);protect off 0x20000000 0x2003FFFF;erase 0x20000000 0x2003FFFF;cp.b $(loadaddr) 0x20000000 $(filesize)

addip=set bootargs $(bootargs) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname):eth0:off

ramargs=set bootargs root=/dev/mtdblock0 rw earlyprintk=serial,uart0,57600 console=ttyBF0,57600

ramboot=tftp $(loadaddr) uImage;run ramargs;run addip;bootm

nfsargs=set bootargs root=/dev/nfs rw nfsroot=$(serverip):$(rootpath),tcp,nfsvers=3

nfsboot=tftp $(loadaddr) vmImage;run nfsargs;run addip;bootm

flashboot=bootm 0x20100000

ethaddr=36:FA:F3:8F:8D:FE

ethact=Blackfin EMAC

bootcmd=run tftp_boot

bootdelay=1

tftp_boot=tftp 0x2000000 uImage;bootm

booargs=root=/dev/mtdblock0 rw earlyprintk=serial,uart0,57600 console=ttyBF0,57600

bootargs=root=/dev/mtdblock0 rw earlyprintk=serial,uart0,57600 panic=3

filesize=2923C

fileaddr=1000000

gatewayip=192.168.0.1

netmask=255.255.255.0

ipaddr=10.100.4.50

serverip=10.100.4.174

stdin=serial

stdout=serial

stderr=serial

 

Environment size: 1104/8188 bytes

bfin> tftp 0x2000000 uImage

Using Blackfin EMAC device

TFTP from server 10.100.4.174; our IP address is 10.100.4.50

Filename 'uImage'.

Load address: 0x2000000

Loading: #################################################################

         #################################################################

         #################################################################

         #################################################################

         ##########################################################

done

Bytes transferred = 4666817 (4735c1 hex)

bfin> bootm

## Booting kernel from Legacy Image at 02000000 ...

   Image Name:   bf537-2.6.30.5-ADI-2010R1-pre-sv

   Created:      2009-08-29  11:59:02 UTC

   Image Type:   Blackfin Linux Kernel Image (gzip compressed)

   Data Size:    4666753 Bytes =  4.5 MB

   Load Address: 00001000

   Entry Point:  0018b334

   Verifying Checksum ... OK

   Uncompressing Kernel Image ... OK

Starting Kernel at = 0018b334

Linux version 2.6.30.5-ADI-2010R1-pre-svn7247 (test@uclinux50-bf537-ad9960-ad1836) (gcc version 4.1.2 (ADI svn)) #4 Sat Aug 29 19:58:41 CST 2009

bootconsole [early_shadow0] enabled

bootconsole [early_BFuart0] enabled

early printk enabled on early_BFuart0

Limiting kernel memory to 56MB due to anomaly 05000263

Board Memory: 64MB

Kernel Managed Memory: 64MB

Memory map:

  fixedcode = 0x00000400-0x00000490

  text      = 0x00001000-0x00105e00

  rodata    = 0x00105e00-0x0015d4d4

  bss       = 0x0015e000-0x0016eacc

  data      = 0x0016eacc-0x00180000

    stack   = 0x0017e000-0x00180000

  init      = 0x00180000-0x008b5000

  available = 0x008b5000-0x037ff000

  DMA Zone  = 0x03f00000-0x04000000

Hardware Trace Active and Enabled

Boot Mode: 0

Reset caused by Software reset

Blackfin support (C) 2004-2009 Analog Devices, Inc.

Compiled for ADSP-BF537 Rev 0.2

Blackfin Linux support by http://blackfin.uclinux.org/

Processor Speed: 500 MHz core clock and 125 MHz System Clock

NOMPU: setting up cplb tables

Instruction Cache Enabled for CPU0

  External memory: cacheable in instruction cache

Data Cache Enabled for CPU0

  External memory: cacheable (write-back) in data cache

Kernel panic - not syncing: Test early printk

Hardware Trace:

   0 Target : <0x00004c44> { _dump_stack + 0x0 }

     Source : <0x00010798> { _panic + 0x48 } CALL pcrel

   1 Target : <0x00010794> { _panic + 0x44 }

     Source : <0x0001131e> { _printk + 0x16 } RTS

   2 Target : <0x0001131a> { _printk + 0x12 }

     Source : <0x000111b0> { _vprintk + 0x128 } RTS

   3 Target : <0x000111a4> { _vprintk + 0x11c }

     Source : <0x00011196> { _vprintk + 0x10e } IF !CC JUMP

   4 Target : <0x0001118e> { _vprintk + 0x106 }

     Source : <0x000112c8> { _vprintk + 0x240 } JUMP.S

   5 Target : <0x000112c8> { _vprintk + 0x240 }

     Source : <0x00010a86> { _wake_up_klogd + 0x1a } RTS

   6 Target : <0x00010a86> { _wake_up_klogd + 0x1a }

     Source : <0x00010a78> { _wake_up_klogd + 0xc } IF !CC JUMP

   7 Target : <0x00010a6c> { _wake_up_klogd + 0x0 }

     Source : <0x00010e0c> { _release_console_sem + 0xb4 } JUMP.L

   8 Target : <0x00010e06> { _release_console_sem + 0xae }

     Source : <0x00010dec> { _release_console_sem + 0x94 } IF !CC JUMP

   9 Target : <0x00010de2> { _release_console_sem + 0x8a }

     Source : <0x00023b12> { _up + 0x3e } RTS

  10 Target : <0x00023b0c> { _up + 0x38 }

     Source : <0x00023afe> { _up + 0x2a } IF !CC JUMP

  11 Target : <0x00023ad4> { _up + 0x0 }

     Source : <0x00010dde> { _release_console_sem + 0x86 } CALL pcrel

  12 Target : <0x00010dca> { _release_console_sem + 0x72 }

     Source : <0x00010da4> { _release_console_sem + 0x4c } IF !CC JUMP

  13 Target : <0x00010d92> { _release_console_sem + 0x3a }

     Source : <0x00010dba> { _release_console_sem + 0x62 } IF CC JUMP

  14 Target : <0x00010db4> { _release_console_sem + 0x5c }

     Source : <0x00010966> { __call_console_drivers + 0x7a } RTS

  15 Target : <0x00010960> { __call_console_drivers + 0x74 }

     Source : <0x00010922> { __call_console_drivers + 0x36 } IF !CC JUMP

Stack info:

SP: [0x0017ffb4] <0x0017ffb4> /* kernel dynamic memory */

Memory from 0x0017ffb0 to 00180000

0017ffb0: 00000000 [00132090]<0001079c> 00160000  00132090  001633ae  001633ae  001633ae

0017ffd0: 0017fff0  0017fff0 <0018010c> 00000000  00000000  00000000  ffb00000  00000000

0017fff0: 001713f8  0000003f  00198704 <0018b4b8>

Return addresses in stack:

    address : <0x0001079c> { _panic + 0x4c }

    address : <0x0018010c> { _parse_early_options + 0x0 }

    address : <0x0018b4b8> { _real_start + 0x28 }

 

wait here for about 10 minutes, but no reboot.

 

Follow-ups

 

--- Barry Song                                               2009-09-07 04:19:12

Not a bug in this case. The testscript

testsuites/earlyprintk/build_earlyprintk_kernel.exp adds a line in asmlinkage

void __init start_kernel(void):

572         setup_arch(&command_line);

+        panic("Test early printk\");

573         mm_init_owner(&init_mm, &init_task);

But by setup_arch, the panic=3 has not been parsed yet, then kernel param

panic_timeout is still 0:

core_param(panic, panic_timeout, int, 0644);

So in the panic() function, the condition will not be true, then no reset:

96         if (panic_timeout > 0) {

97                 /*

98                  * Delay timeout seconds before rebooting the machine.

99                  * We can't use the "normal" timers since we just

panicked.

100                  */

101                 printk(KERN_EMERG "Rebooting in %d seconds..",

panic_timeout);

102

103                 for (i = 0; i < panic_timeout*1000; ) {

104                         touch_nmi_watchdog();

105                         i += panic_blink(i);

106                         mdelay(1);

107                         i++;

108                 }

109                 /*

110                  * This will not be a clean reboot, with everything

111                  * shutting down.  But if there is a chance of

112                  * rebooting the system it will be rebooted.

113                  */

114                 emergency_restart();

115         }

I tried to make system panic after parse_early_param() is executed, the system

can reset normally.

So reject this item at first, but if somebody can report a case that system

can't reset even after cmdline has been parsed, we can open it again.

 

 

 

 

--- Mingquan Pan                                             2009-09-07 22:43:47

In the toolchain testing on bf548 ezkit, the trunk head kernel would be panic

after lots of testcases being run, but fails to reboot and stucks.

 

logs like following:

 

Instruction fetch misaligned address violation

- Attempted misaligned instruction cache fetch.

Deferred Exception context

CURRENT PROCESS:

COMM=syslogd PID=23636

CPU = 0

TEXT = 0x(null)-0x(null)        DATA = 0x(null)-0x(null)

BSS = 0x(null)-0x(null)  USER-STACK = 0x(null)

 

return address: [0x0026293a]; contents of:

0x00262910:  0000  0538  0010  e300  00a1  3210  43b8  9310

0x00262920:  63f8  2ff6  e800  0004  3008  6000  b0f0  6002

0x00262930:  63f8  e300  1071  e801  0000 [0010] 0578  e800

0x00262940:  0003  e128  0092  00a0  3038  e120  f000  0a07

 

ADSP-BF548-0.2 525(MHz CCLK) 131(MHz SCLK) (mpu off)

Linux version 2.6.30.5-ADI-2010R1-pre-svn7269 (test@44-bf548-toolchain) (gcc

version 4.1.2 (ADI svn)) #4 Mon Sep 7 20:56:58 CST 2009

 

SEQUENCER STATUS:               Not tainted

SEQSTAT: 0006002a  IPEND: 0008  IMASK: ffff  SYSCFG: 0006

  EXCAUSE   : 0x2a

  physical IVG3 asserted : <0xffa00684> { _trap + 0x0 }

RETE: <0x00000000> /* Maybe null pointer? */

RETN: <0x0036c000> /* kernel dynamic memory */

RETX: <0x00000480> /* Maybe fixed code section */

RETS: <0x00005c53> { _peripheral_free_list + 0x7 }

PC  : <0x0026293a> { _bfin_debug_mmrs_init + 0x72e }

DCPLB_FAULT_ADDR: <0x00279e58> { _alsa_sound_last_init + 0x44 }

ICPLB_FAULT_ADDR: <0x0026293a> { _bfin_debug_mmrs_init + 0x72e }

 

PROCESSOR STATE:

R0 : 00000000    R1 : 00000004    R2 : 000000ff    R3 : 002662b0

R4 : 00260f1e    R5 : 00279f54    R6 : 00000000    R7 : 00005c53

P0 : 0000001b    P1 : 00d7ab68    P2 : 00000048    P3 : 002667e4

P4 : 002667e8    P5 : 00005c53    FP : 00262936    SP : 0036bf24

LB0: 0026383b    LT0: 00263828    LC0: ffffffff

LB1: 00000001    LT1: 00000000    LC1: 00000000

B0 : 00000000    L0 : 00000000    M0 : 00000000    I0 : 00d7aaa4

B1 : 00000000    L1 : 00000000    M1 : 00000000    I1 : 00000120

B2 : 00000000    L2 : 00000000    M2 : 00000000    I2 : 00000000

B3 : 00000000    L3 : 00000000    M3 : 00000000    I3 : 00000000

A0.w: 00000000   A0.x: 00000000   A1.w: 00000000   A1.x: 00000000

USP : 00279e60  ASTAT: 00000022

 

Hardware Trace:

Userspace Stack

Stack info:

SP: [0x00279e60] <0x00279e60> { _alsa_sound_last_init + 0x4c }

FP: (0x00279f48)

Memory from 0x00279e60 to 0027a000

00279e60:[002664d4] 00266524  00000001  0026013c  00000000  00000000  00000000

00000000

00279e80: 00000000  00000000  00000000  00000000  00000000  00000000  00000000

00000000

00279ea0: 00000000  00000000  00000000  00000000  00000000  00000000  00000000

00000000

00279ec0: 00000000  00000000  00000000  00000000  00000000  00000000  00000000

00000000

00279ee0: 00000000  00000000  00000000  00000000  00000000  00000000  002665a0

00000001

00279f00: 00000000  00000000  00000000  00000500  00000005  00001cb1  00008a3b

7f1c0300

00279f20: 01000415  1a131100  170f1200  00000016  00000000  00000000  00000000

00000000

00279f40: 00000000  00000000 (00279f68)<00265454> 00000100  00279f84

<0026490c> 00265a24

00279f60: 002667bc  00279fc8 (00000000) 00278000  002659ec  00000001  00000000

00000000

00279f80: 00000000  00000000  00000000  00265a24  00000000  00000000  00000000

00000000

00279fa0: 00000000  00000000  00260db8  00000000  00000000  002659ec  002659fe

00000000

00279fc0: 00000000  00000001  00279fde  00000000 <00279fe4> 00279feb

00000000  692f0000

00279fe0: 0074696e  454d4f48  54002f3d  3d4d5245  756e696c  692f0078  0074696e

00000000

Return addresses in stack:

   frame  1 : <0x00265454> { _bfin_debug_mmrs_init + 0x3248 }

    address : <0x0026490c> { _bfin_debug_mmrs_init + 0x2700 }

    address : <0x00279fe4> { _setup_net + 0x3c }

Instruction fetch misaligned address violation

- Attempted misaligned instruction cache fetch.

Deferred Exception context

CURRENT PROCESS:

COMM=init PID=1

CPU = 0

TEXT = 0x00260040-0x00265a20        DATA = 0x00265a24-0x002667c0

BSS = 0x002667c0-0x00278034  USER-STACK = 0x00279fc4

 

return address: [0x0026293a]; contents of:

0x00262910:  0000  0538  0010  e300  00a1  3210  43b8  9310

0x00262920:  63f8  2ff6  e800  0004  3008  6000  b0f0  6002

0x00262930:  63f8  e300  1071  e801  0000 [0010] 0578  e800

0x00262940:  0003  e128  0092  00a0  3038  e120  f000  0a07

 

ADSP-BF548-0.2 525(MHz CCLK) 131(MHz SCLK) (mpu off)

Linux version 2.6.30.5-ADI-2010R1-pre-svn7269 (test@44-bf548-toolchain) (gcc

version 4.1.2 (ADI svn)) #4 Mon Sep 7 20:56:58 CST 2009

 

SEQUENCER STATUS:               Not tainted

SEQSTAT: 0006002a  IPEND: 0008  IMASK: ffff  SYSCFG: 0006

  EXCAUSE   : 0x2a

  physical IVG3 asserted : <0xffa00684> { _trap + 0x0 }

RETE: <0x00000000> /* Maybe null pointer? */

RETN: <0x009ee000> /* kernel dynamic memory */

RETX: <0x00000480> /* Maybe fixed code section */

RETS: <0x00005c53> { _peripheral_free_list + 0x7 }

PC  : <0x0026293a> { _bfin_debug_mmrs_init + 0x72e }

DCPLB_FAULT_ADDR: <0x00279e58> { _alsa_sound_last_init + 0x44 }

ICPLB_FAULT_ADDR: <0x0026293a> { _bfin_debug_mmrs_init + 0x72e }

 

PROCESSOR STATE:

R0 : 00005c54    R1 : 00279f50    R2 : 00000000    R3 : 00000000

R4 : 00000000    R5 : 00278024    R6 : 00279f50    R7 : 00005c53

P0 : 00000072    P1 : 00d7a0dc    P2 : 00000048    P3 : 002667e4

P4 : 002667e8    P5 : ffffffff    FP : 00262936    SP : 009edf24

LB0: 0026383b    LT0: 00263828    LC0: ffffffff

LB1: 00000001    LT1: 00000000    LC1: 00000000

B0 : 00000000    L0 : 00000000    M0 : 00000000    I0 : 00d7aaa4

B1 : 00000000    L1 : 00000000    M1 : 00000000    I1 : 00000120

B2 : 00000000    L2 : 00000000    M2 : 00000000    I2 : 00000000

B3 : 00000000    L3 : 00000000    M3 : 00000000    I3 : 00000000

A0.w: 00000000   A0.x: 00000000   A1.w: 00000000   A1.x: 00000000

USP : 00279e60  ASTAT: 00000022

 

Hardware Trace:

Userspace Stack

Stack info:

SP: [0x00279e60] <0x00279e60> { _alsa_sound_last_init + 0x4c }

FP: (0x00279f48)

Memory from 0x00279e60 to 0027a000

00279e60:[002664d4] 00266524  00000001  0026013c  00000000  00000000  00000000

00000000

00279e80: 00000000  00000000  00000000  00000000  00000000  00000000  00000000

00000000

00279ea0: 00000000  00000000  00000000  00000000  00000000  00000000  00000000

00000000

00279ec0: 00000000  00000000  00000000  00000000  00000000  00000000  00000000

00000000

00279ee0: 00000000  00000000  00000000  00000000  00000000  00000000  002665a0

00000001

00279f00: 00000000  00000000  00000000  00000500  00000005  00001cb1  00008a3b

7f1c0300

00279f20: 01000415  1a131100  170f1200  00000016  00000000  00000000  00000000

00000000

00279f40: 00000000  00000000 (00279f68)<00265454> 00000007  00279f84

<0026490c> 00265a24

00279f60: 002667bc  00279fc8 (00000000) 00278000  002659ec  00000001  00000000

00000000

00279f80: 00000000  00000000  00000000  00265a24  00000000  00000000  00000000

00000000

00279fa0: 00000000  00000000  00260db8  00000000  00000000  002659ec  002659fe

00000000

00279fc0: 00000000  00000001  00279fde  00000000 <00279fe4> 00279feb

00000000  692f0000

00279fe0: 0074696e  454d4f48  54002f3d  3d4d5245  756e696c  692f0078  0074696e

00000000

Return addresses in stack:

   frame  1 : <0x00265454> { _bfin_debug_mmrs_init + 0x3248 }

    address : <0x0026490c> { _bfin_debug_mmrs_init + 0x2700 }

    address : <0x00279fe4> { _setup_net + 0x3c }

Kernel panic - not syncing: Attempted to kill init!

Rebooting in 3 seconds..

 

And no reboot seen after that.

 

Whole reset log is attached.

 

--- Barry Song                                               2009-09-07 22:55:16

The case is different,  "Rebooting in 3 seconds.." is printed, the

following condition is true:

96         if (panic_timeout > 0) {

97                 /*

98                  * Delay timeout seconds before rebooting the machine.

99                  * We can't use the "normal" timers since we

just

panicked.

100                  */

101                 printk(KERN_EMERG "Rebooting in %d seconds..",

panic_timeout);

102

103                 for (i = 0; i < panic_timeout*1000; ) {

104                         touch_nmi_watchdog();

105                         i += panic_blink(i);

106                         mdelay(1);

107                         i++;

108                 }

109                 /*

110                  * This will not be a clean reboot, with everything

111                  * shutting down.  But if there is a chance of

112                  * rebooting the system it will be rebooted.

113                  */

114                 emergency_restart();

115         }

So the system dies after emergency_restart() is called, let me check the

reason.

 

--- Robin Getz                                               2009-09-08 18:52:14

emergency_restart() is just machine_restart (see

include/asm-generic/emergency-restart.h)

 

which normally is just bfin_reset() (see arch/blackfin/kernel/reboot.c)

 

Otherwise - can you check to see if ANOMALY_05000353 || ANOMALY_05000386 is

set, and if not, if things work properly when they are?

 

-Robin

 

--- Barry Song                                               2009-09-09 03:05:29

Robin,

According to "Silicon Anomaly List

ADSP-BF542/BF544/BF547/BF548/BF549", 05000353 applies to 0.1. And the

document has no description about 05000386 after 0.1. So the macro definition

is:

/* bfrom_SysControl() Firmware Function Performs Improper System Reset */

#define ANOMALY_05000353 (__SILICON_REVISION__ < 2)

/* bfrom_SysControl() Firmware Routine Not Functional */

#define ANOMALY_05000386 (__SILICON_REVISION__ < 1)

 

And we are using BF548-0.2 in the test. So the "if (ANOMALY_05000353 ||

ANOMALY_05000386)" will be false. But if we comments "if

(ANOMALY_05000353 || ANOMALY_05000386)" in bfin_reset():

static void bfin_reset(void)

{

        /* Wait for completion of "system" events such as cache line

         * line fills so that we avoid infinite stalls later on as

         * much as possible.  This code is in L1, so it won't trigger

         * any such event after this point in time.

         */

        __builtin_bfin_ssync();

 

        /* The bootrom checks to see how it was reset and will

         * automatically perform a software reset for us when

         * it starts executing after the core reset.

         */

        //if (ANOMALY_05000353 || ANOMALY_05000386)

        {

                /* Initiate System software reset. */

                bfin_write_SWRST(0x7);

 

                /* Due to the way reset is handled in the hardware, we need

                 * to delay for 10 SCLKS.  The only reliable way to do this is

                 * to calcul

...

}

Reset will work normally.

Without executing the workaround, reboot will not work. It seems one ANOMALY

still exists. How could I confirm it and report it?

 

-Barry

 

--- Barry Song                                               2010-06-10 06:04:51

The logic is wrong in our bfin_reset().

----------

if(anomaly)

  manual_soft_reset();

raise 1;

-----------

"soft_reset() is manual version for bfrom_SysControl() with bug fix to

anomaly 353". So if there is no anomaly, right soft reset is never executed

by us.

So the right logic can be:

Way1

----------

manual_soft_reset();

raise 1;

-----------

 

or

 

Way2

----------

if(anomaly)

  manual_soft_reset();

else

  bfrom_SysControl(SYSCTRL_SYSRESET, 0, NULL);

raise 1;

-----------

 

Way1 is right too, in fact manual_soft_reset() do bfrom_SysControl() manually.

To use way2, we need know the address of bfrom_SysControl.

 

Mike, it is said you know the address for those blackfin processers?

 

-barry

 

--- Mike Frysinger                                           2010-06-12 23:56:50

the logic is correct.  the anomalies mean that either the soft reset doesnt

exist, or it is broken.  the bootrom itself checks the software reset registers

to detect that "raise 1" was executed and if it was, it does the

software reset.

 

that bfrom_syscontrol() simply does a "raise 1", so it's pure

overhead for us.

 

--- Barry Song                                               2010-06-13 00:34:10

Not exactly. raise 1 is only reset core. What you should do is system and core

reset.

bfrom_syscontrol() doesn't only do "raise 1".

 

 

--- Mike Frysinger                                           2010-06-13 00:45:15

i know what "raise 1" does.  read the actual bootrom source and you'll

see that it doesnt do a system reset directly via bfrom_syscontrol().  it does

it *after* the core has reset and while the bfrom is executing before it starts

processing the LDR source.

 

--- Barry Song                                               2010-06-13 02:17:14

Where is the bootrom code? I just read datasheet and know raise 1 only reset

core, we should do system and core reset. The blackfin programming reference

gives a example for reset too.

"

Core and System Reset

To perform a system and core reset, use the code sequence shown in

Listing 3-4.

Listing 3-4. Core and System Reset

/* Issue soft reset */

P0.L = LO(SWRST) ;

P0.H = HI(SWRST) ;

R0.L = 0x0007 ;

W[P0] = R0 ;

SSYNC ;

/* Clear soft reset */

P0.L = LO(SWRST) ;

P0.H = HI(SWRST) ;

R0.L = 0x0000 ;

W[P0] = R0 ;

SSYNC ;

/* Core reset - forces reboot */

RAISE 1 ;

"

 

And it shows

"

A Core-Only Software reset is initiated by executing the RAISE 1 instruction

or by setting the Software Reset (SYSRST) bit in the core Debug

Control register (DBGCTL) via emulation software through the JTAG port.

(DBGCTL is not visible to the memory map.)

A Core-Only Software reset affects only the state of the core. Note the system

resources may be in an undetermined or even unreliable state,

depending on the system activity during the reset period.

"

 

--- Mike Frysinger                                           2010-06-13 12:56:48

the processor hasnt changed behavior, the bootrom has.  the source is included

with VDSP.

 

so while the processor only does a core reset with 'raise 1', the bootrom is

free to do what it wants wrt system reset automatically.

 

--- Barry Song                                               2010-06-22 03:23:35

Why not program reset codes according to programming guide but only according to

what you read in bootrom codes?

"A Core-Only Software reset affects only the state of the core. Note the

system

resources may be in an undetermined or even unreliable state,

depending on the system activity during the reset period".

Suppose what you said is true(that needs confirm from HW guys), i still believe

we should reset according to spec. You can't be sure the status of other

components in chip, broken external components maybe break the bootrom

execution.

We must make sure from hw guys "raise 1" is really enough for the

whole system reset, not only the core jump to the beginning addree.

 

--- Robin Getz                                               2010-06-22 09:04:13

This has been verified and validated by both the silicon team, and the

applications team.

 

The programming guide is out of date on the newer chips with different

functionality in the bootrom.

 

-Robin

 

--- Mike Frysinger                                           2010-06-22 13:45:34

i prefer to follow what the hardware is actually doing rather than what the

out-dated documentation states.  much of the reset hardware behavior information

*is coming from our group* because other people treat it as an after thought.

 

--- Sonic Zhang                                              2010-06-25 04:55:08

Robin, because current testing boards are with old chips, how about always do

the soft reset in kernel reboot function? Doing soft reset twice doesn't break

the reset logic in boot ROM of the newer chips.

 

--- Mike Frysinger                                           2010-06-25 11:30:08

except that sometimes it does.  that's why there is that BF526 ifdef logic in

the middle.

 

--- Barry Song                                               2010-06-28 02:18:07

If so, could we keep the ifdef for 526, and let all others execute system

reset?

-barry

 

--- Robin Getz                                               2010-06-28 09:15:57

Sounds like we need to add run time version checking?

 

Using bfin_revid() rather than __SILICON_REVISION__ in the anomaly.h file?

 

-Robin

 

--- Mike Frysinger                                           2010-06-28 19:51:42

i dont think so.  the anomaly sheet says that the bootrom reset should work on

the BF548 0.2.  Barry/Grace say it does not.  silicon revision checking wouldnt

make a difference since the kernel was compiled for the BF548 0.2.

 

--- Sonic Zhang                                              2010-06-28 23:28:08

Yes, the silicon revision information of this anomaly is not complete according

to the test results. I think we should temporarily walk around this problem by

always do soft reset except for bf526 rev above 0.0.

 

--- Robin Getz                                               2010-06-29 08:14:41

I will start something with processor.support today.

 

-Robin

 

--- Robin Getz                                               2010-06-30 15:07:24

So -- hang on --

 

the orginal bug has to do with ADSP bf537-0.2 - which has no functionality in

the bootrom, and should always be using the software reset.

 

The anomaly 05000353 should always be set on 537. (and it is)

 

mach-bf518/include/mach/anomaly.h:#define ANOMALY_05000353 (0)

mach-bf527/include/mach/anomaly.h:#define ANOMALY_05000353 (_ANOMALY_BF526(<

1))

mach-bf533/include/mach/anomaly.h:#define ANOMALY_05000353 (1)

mach-bf537/include/mach/anomaly.h:#define ANOMALY_05000353 (1)

mach-bf538/include/mach/anomaly.h:#define ANOMALY_05000353 (1)

mach-bf548/include/mach/anomaly.h:#define ANOMALY_05000353

(__SILICON_REVISION__ < 2)

mach-bf561/include/mach/anomaly.h:#define ANOMALY_05000353 (1)

 

 

When did we see the problem on 548? and 526? Exactly what chip/rev is having

problems?

 

 

--- Sonic Zhang                                              2010-06-30 23:42:06

See Grace's comments and we have only bf548 v0.2 in Shanghai.

 

--- Mingquan Pan                                             2009-09-08

10:43:47

In the toolchain testing on bf548 ezkit, the trunk head kernel would be panic

after lots of testcases being run, but fails to reboot and stucks.

 

------------------------------------------------------------------

As to bf518, please refer to bug 5477. Chip version is 0.0.

 

bf526 reboot bug 5832 looks like a different issue. It hangs after watchdog

reset the board, which has no way to work around in kernel except for changing

the chip's bootrom.

 

 

--- Robin Getz                                               2010-07-01 13:12:24

I see the comment - but the first log is for 537 -- does that work now? And the

only problem is on 548-0.2?

 

Thanks

-Robin

 

--- Sonic Zhang                                              2010-07-01 23:56:39

Yes.

 

--- Mike Frysinger                                           2010-07-02 13:35:37

i'm not sure that anyone has looked to find out exactly where the reset is

getting stuck on the bf54x-0.2.  is it in the bootrom ?  or in u-boot because

some system mmr isnt being reset ?  if so, which ?  or is it due to the flash

and some async pins ?

 

--- Barry Song                                               2010-07-08 05:20:00

That can't be repeated too in trunk head after deleting anomaly workaround.

 

make panic:

 

Return addresses in stack:

    address : <0x0000102a> { _do_one_initcall + 0x2a }

    address : <0x0000102a> { _do_one_initcall + 0x2a }

    address : <0xffa008f6> { _system_call + 0x6a }

Rebooting in 3 seconds..

 

U-Boot 2009.08-svn2195 (ADI-2009R2-pre) (Dec 28 2009 - 16:52:58)

 

CPU:   ADSP bf548-0.0 (Detected Rev: 0.2) (parallel flash boot)

Board: ADI BF548 EZ-Kit board

       Support: http://blackfin.uclinux.org/

Clock: VCO: 525 MHz, Core: 525 MHz, System: 131.250 MHz

RAM:   64 MB

Flash: 16 MB

NAND:  256 MiB

MMC:  Blackfin SDH: 0

In:    serial

Out:   serial

Err:   serial

Net:   smc911x-0

Hit any key to stop autoboot:  0

smc911x: initializing

smc911x: detected LAN9218 controller

smc911x: phy initialized

smc911x: MAC 00:e0:22:fe:bf:4c

Using smc911x-0 device

TFTP from server 10.99.29.104; our IP address is 10.99.29.116

Filename 'uImage'.

Load address: 0x1000000

Loading: #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         #################################################################

         ##########################################################

done

Bytes transferred = 5286977 (50ac41 hex)

## Booting kernel from Legacy Image at 01000000 ...

   Image Name:   bf548-2.6.34-ADI-2010R1-pre-svn8

   Created:      2010-07-08   9:06:47 UTC

   Image Type:   Blackfin Linux Kernel Image (gzip compressed)

   Data Size:    5286913 Bytes =  5 MB

   Load Address: 00001000

   Entry Point:  002a2908

   Verifying Checksum ... OK

   Uncompressing Kernel Image ... OK

Starting Kernel at = 002a2908

Linux version 2.6.34-ADI-2010R1-pre-svn8933 (root@roc-desktop) (gcc version

4.3.4 (ADI-trunk/svn-3771) ) #4393 Thu Jul 8 17:06:39 CST 2010

register early platform devices

bootconsole [early_shadow0] enabled

bootconsole [early_BFuart1] enabled

early printk enabled on early_BFuart1

Board Memory: 64MB

Kernel Managed Memory: 64MB

Memory map:

  fixedcode = 0x00000400-0x00000490

  text      = 0x00001000-0x001b9508

  rodata    = 0x001b9508-0x002574a0

  bss       = 0x00258000-0x0026f984

  data      = 0x0026f984-0x00290000

    stack   = 0x0028e000-0x00290000

  init      = 0x00290000-0x009d5000

  available = 0x009d5000-0x03e00000

  DMA Zone  = 0x03e00000-0x04000000

Hardware Trace Active and Enabled

 

...

 

-barry

 

 

 

    Files

    Changes

    Commits

    Dependencies

    Duplicates

    Associations

    Tags

 

File Name     File Type     File Size     Posted By

uImage    application/octet-stream    5286977    Barry Song

reset_board_log.gz    application/x-gzip    2364997    Mingquan Pan

Attachments

Outcomes