Date: Sun, 24 May 2015 17:34:55 -0700 From: Oleksandr Tymoshenko <gonzo@freebsd.org> To: Ian Lepore <ian@FreeBSD.org> Cc: "freebsd-arm@freebsd.org List" <freebsd-arm@freebsd.org> Subject: Re: panic: arm_unmask_irq [was: Re: TI platforms code update: switching to vendor FDT data] Message-ID: <CF67856C-FDB3-45C1-A063-AA08FA23F83D@freebsd.org> In-Reply-To: <1432512966.1200.15.camel@freebsd.org> References: <C9791C97-D5B1-433A-9AC0-CA2707C6137F@freebsd.org> <72E1D87A-1CEF-4719-907E-CF8E9D720FD1@xcllnt.net> <3741A6A7-1185-4E5A-9E98-22F5A6C730DC@freebsd.org> <1432512966.1200.15.camel@freebsd.org>
index | next in thread | previous in thread | raw e-mail
> On May 24, 2015, at 5:16 PM, Ian Lepore <ian@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@xcllnt.net> wrote: >>> >>> >>>> On May 21, 2015, at 8:37 PM, Oleksandr Tymoshenko <gonzo@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@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.help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CF67856C-FDB3-45C1-A063-AA08FA23F83D>