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>
next in thread | previous in thread | raw e-mail | index | archive | help
> On May 24, 2015, at 5:16 PM, Ian Lepore <ian@FreeBSD.org> wrote: >=20 > 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: >>>=20 >>>=20 >>>> On May 21, 2015, at 8:37 PM, Oleksandr Tymoshenko = <gonzo@FreeBSD.org> wrote: >>>>=20 >>>> Hello, >>>>=20 >>>> 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. >>>=20 >>> *snip* >>>=20 >>> It seems the interrupt controller isn=E2=80=99t been probed and = attached >>> in time on my BBB: >>>=20 >>> 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 =3D 536870912 (512 MB) >>> avail memory =3D 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=3D00000005, FAR=3D00000010, spsr=3Da0000193 >>> r0 =3D0000001b, r1 =3D00000001, r2 =3Dc2952e48, r3 =3D08000000 >>> r4 =3D00000040, r5 =3D00000000, r6 =3D0000005b, r7 =3D00000310 >>> r8 =3Dc2ae11c0, r9 =3Dc0605974, r10=3D00000000, r11=3Dc090ad00 >>> r12=3Dc0788b34, ssp=3Dc090acf8, slr=3Dc05f72a8, pc =3Dc05f72b8 >>>=20 >>> [ thread pid 0 tid 100000 ] >>> Stopped at arm_unmask_irq+0x30: ldr r0, [r5, #0x010] >>> db> >>>=20 >>>=20 >>> I=E2=80=99ll poke at it some more, so for now it=E2=80=99s an FYI. >>=20 >> 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 >=20 > 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.=20=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CF67856C-FDB3-45C1-A063-AA08FA23F83D>