[#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

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;

-----------

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 : <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

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