How to trap external abort to monitor mode exception handler in IMX53 Sabre?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

How to trap external abort to monitor mode exception handler in IMX53 Sabre?

1,040 Views
rijurekhasen
Contributor I

I am booting Android on an IMX53 Sabre tablet. The last few lines seen on serial port as android boots up normally and the screen gets suspended due to inactivity is as follows:

warning: `rild' uses 32-bit capabilities (legacy support in use)

pmem: request for physical address of pmem region from process 2262.
request_suspend_state: on (3->0) at 12032459753 (2000-01-03
01:08:28.336600001 U
TC)
Unhandled fault: external abort on non-linefetch (0x1018) at 0x40a85054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x40a85054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x41063054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x41100054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x41152054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x411ef054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x41352054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x413ef054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x41452054
Unhandled fault: external abort on non-linefetch (0x1018) at 0x414ef054
Not all allocated memory blocks were freed. Doing it now.
Freeing list entry #0, gpuaddr=84456000
Freeing list entry #2, gpuaddr=84467000
Freeing list entry #3, gpuaddr=84499000
Freeing list entry #6, gpuaddr=8449a000
Freeing list entry #7, gpuaddr=844ba000
Freeing list entry #8, gpuaddr=844da000
Freeing list entry #77, gpuaddr=844ea000
Freeing list entry #84, gpuaddr=8449c000
request_suspend_state: mem (0->3) at 75724147503 (2000-01-03
01:09:32.028284751
UTC)
isl29023 2-0044: isl29023 early_syspend
mag3110 1-000e: mag3110 early_syspend
PM: Syncing filesystems ... done.
dvfs: disable dvfs before suspend
Freezing user space processes ... (elapsed 0.01 seconds) done.
Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Suspending console(s) (use no_console_suspend to debug)

Now I wanted to trap external aborts to monitor. In initialization of secure monitor, I do the following:

mrc p15, 0, r4, c1, c1, 0
bic r4, #0x66 @ clear AW, IRQ, FIQ
orr r4, #0x19 @ set FW, EA, NS
//orr r4, #0x01 @ previously, just set NS
mcr p15, 0, r4, c1, c1, 0

My monitor vector table looks as follows:

.global tz_monitor
.align 5
tz_monitor:
@ Monitor
   b _monitor_reset @ Reset
   b _monitor_undef @ Undef
   b smc_handler @ SMC
   b _monitor_prefetch @ Prefetch
   b _monitor_da @ Data abort
   nop @ RESERVED
   b _monitor_irq @IRQ
   b _monitor_fiq @FIQ

An example exception handler function just prints a statement and looks as follows: In assembly:

.global _monitor_prefetch
_monitor_prefetch:
   push {lr}
   bl monitor_prefetch
   pop {lr}
   movs pc, lr

In C:

void monitor_prefetch(void) {
   printf("In Monitor's Prefetch Handler\n");
}

I add this vector table in initialization of secure monitor as follows:

ldr r0, =tz_monitor @ Get address of Monitors vector table
mcr p15, 0, r0, c12, c0, 1 @ Write Monitor Vector Address Register

But the external abort as seen with the Android boot previously does not come to the monitor (the print statement doesn't happen). I get the following output on serial now, when booting Android:

warning: `rild' uses 32-bit capabilities (legacy support in use)

pmem: request for physical address of pmem region from process 2262.
request_suspend_state: on (3->0) at 12005333628 (2000-01-03
00:38:52.322241626 UTC)
Bad mode in prefetch abort handler detected
Internal error: Oops - bad mode: 0 [#1] PREEMPT
last sysfs file: /sys/devices/platform/pwm-backlight.0/backlight/pwm-
backlight.0/brightness
Modules linked in:
CPU: 0 Not tainted (2.6.35.3-01265-g8f56f17 #6)
PC is at 0x77802570
LR is at 0xafd0bf6c
pc : [<77802570>] lr : [<afd0bf6c>] psr: 200001d6
sp : ce0e7fb0 ip : 8151c780 fp : 00000001
r10: 00000000 r9 : 40a85000 r8 : 00000002
r7 : 4090ae64 r6 : 8151c890 r5 : 00000018 r4 : 40207000
r3 : 40a85000 r2 : 00000001 r1 : 60000010 r0 : 00000000
Flags: nzCv IRQs off FIQs off Mode UK6_32 ISA ARM Segment user
Control: 10c5387d Table: 83668019 DAC: 00000015
Process Binder Thread # (pid: 2307, stack limit = 0xce0e62e8)
Stack: (0xce0e7fb0 to 0xce0e8000)
7fa0: 00000000 60000010 00000001
40a85000
7fc0: 40207000 00000018 8151c890 4090ae64 00000002 40a85000 00000000
00000001
7fe0: 8151c780 ce0e7fb0 afd0bf6c 77802570 200001d6 ffffffff ffc75a9a
dfd4eed7
Code: bad PC value
---[ end trace d8447dd37d1d45d8 ]---
Kernel panic - not syncing: Fatal exception
[<c003e58c>] (unwind_backtrace+0x0/0xf0) from [<c04862f0>]
(panic+0x6c/0xe0)
[<c04862f0>] (panic+0x6c/0xe0) from [<c003d420>] (die+0x2b4/0x304)
[<c003d420>] (die+0x2b4/0x304) from [<c003d4ac>] (bad_mode+0x3c/0x5c)
[<c003d4ac>] (bad_mode+0x3c/0x5c) from [<afd0bf6c>] (0xafd0bf6c)

Do I need some other setting to trap the abort to monitor mode? Eventually I will set CSU to make peripherals like I2C0/IPU secure and trap and emulate aborts there. But I need to do this first step of directing an abort to a monitor handler function. Can someone please help?

Thanks!

Riju

Labels (3)
0 Kudos
1 Reply

723 Views
b36401
NXP Employee
NXP Employee

I can suggest to run dmesg via adb:

adb shell dmesg
adb shell cat /proc/kmsg

Also you can see kmsg:

adb shell cat /proc/kmsg

Have a great day,
Victor

-----------------------------------------------------------------------------------------------------------------------
Note: If this post answers your question, please click the Correct Answer button. Thank you!
-----------------------------------------------------------------------------------------------------------------------

0 Kudos