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