panic: arm_unmask_irq [was: Re: TI platforms code update: switching to vendor FDT data]

Oleksandr Tymoshenko gonzo at freebsd.org
Mon May 25 00:35:33 UTC 2015


> On May 24, 2015, at 5:16 PM, Ian Lepore <ian at FreeBSD.org> wrote:
> 
> On Sun, 2015-05-24 at 17:12 -0700, Oleksandr Tymoshenko wrote:
>>> On May 24, 2015, at 5:05 PM, Marcel Moolenaar <marcel at xcllnt.net> wrote:
>>> 
>>> 
>>>> On May 21, 2015, at 8:37 PM, Oleksandr Tymoshenko <gonzo at FreeBSD.org> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> I've just committed (r283276) major code update for TI platforms
>>>> support. It gets rid of custom-baked .dts files for
>>>> Beaglebone/Pandaboard and switches to using FDT data provided by
>>>> TI and/or boards/capes manufacturers.
>>> 
>>> *snip*
>>> 
>>> It seems the interrupt controller isn’t been probed and attached
>>> in time on my BBB:
>>> 
>>> Booting [/boot/kernel/kernel]...
>>> Using DTB provided by U-Boot at address 0x80000100.
>>> Kernel entry at 0x80200100...
>>> Kernel args: (null)
>>> KDB: debugger backends: ddb
>>> KDB: current backend: ddb
>>> Copyright (c) 1992-2015 The FreeBSD Project.
>>> Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
>>> 	The Regents of the University of California. All rights reserved.
>>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>>> FreeBSD 11.0-CURRENT #1 r283321M: Sun May 24 16:58:54 PDT 2015
>>>   marcel at fbsdvm64:/usr/obj/arm.armv6/host/head/sys/BEAGLEBONE arm
>>> FreeBSD clang version 3.6.0 (tags/RELEASE_360/final 230434) 20150225
>>> WARNING: WITNESS option enabled, expect reduced performance.
>>> can't re-use a leaf (geom_label)!
>>> module_register: module g_label already exists!
>>> Module g_label failed to register: 17
>>> CPU: Cortex A8-r3 rev 2 (Cortex-A core)
>>> Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext
>>> WB disabled EABT branch prediction enabled
>>> LoUU:2 LoC:3 LoUIS:1
>>> Cache level 1:
>>> 32KB/64B 4-way data cache WT WB Read-Alloc
>>> 32KB/64B 4-way instruction cache Read-Alloc
>>> Cache level 2:
>>> 256KB/64B 8-way unified cache WT WB Read-Alloc Write-Alloc
>>> real memory  = 536870912 (512 MB)
>>> avail memory = 513081344 (489 MB)
>>> Texas Instruments AM335x Processor, Revision ES1.2
>>> random: entropy device infrastructure driver
>>> random: selecting highest priority adaptor <Dummy>
>>> random: SOFT: yarrow init()
>>> random: selecting highest priority adaptor <Yarrow>
>>> ofwbus0: <Open Firmware Device Tree>
>>> simplebus0: <Flattened device tree simple bus> on ofwbus0
>>> am335x_rtc0: <AM335x RTC (power management mode)> mem 0x44e3e000-0x44e3efff irq 75,76 on simplebus0
>>> am335x_rtc0: AM335X RTC v1.0.6
>>> ti_wdt0: <TI Watchdog Timer> mem 0x44e35000-0x44e35fff irq 91 on simplebus0
>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on read
>>> trapframe: 0xc090ac68
>>> FSR=00000005, FAR=00000010, spsr=a0000193
>>> r0 =0000001b, r1 =00000001, r2 =c2952e48, r3 =08000000
>>> r4 =00000040, r5 =00000000, r6 =0000005b, r7 =00000310
>>> r8 =c2ae11c0, r9 =c0605974, r10=00000000, r11=c090ad00
>>> r12=c0788b34, ssp=c090acf8, slr=c05f72a8, pc =c05f72b8
>>> 
>>> [ thread pid 0 tid 100000 ]
>>> Stopped at      arm_unmask_irq+0x30:    ldr     r0, [r5, #0x010]
>>> db>
>>> 
>>> 
>>> I’ll poke at it some more, so for now it’s an FYI.
>> 
>> ti_scm and ti_pinmux should be detected right after simplebus.
>> Could you make sure if dtb loaded by u-boot is not
>> from previous builds? You can decompile it using dtc:
>> dtc -I dtb -O dts beaglebone-black.dtb
> 
> Shouldn't the driver attach order be controlled with BUS_PASS numbers
> now?  That's been required with other socs that moved to the standard
> dts data where we don't control the order of the nodes in the file.

I believe they should (and most likely they do, can't check right now).
My point was - order of devices in dmesg is deterministic, so lack
of ti_scm and ti_pinmux most likely indicates that dtb file is not
the same as my BBB uses (beaglebone-black.dtb compile from FreeBSD
tree). So I wanted to know the content of that file before digging further. 


More information about the freebsd-arm mailing list