freebsd/pandaboard Spurious interrupt detected [0x000003ff]

Mon Nov 4 22:26:12 UTC 2013

I'm guessing that the pandaboard fdt manifest didn't match the
ti_sdhci driver. I had a quick probe around but couldn't see an easy
way to fix that problem. If you have a patch you want to try I'm happy
to experiment on my pandaboard.

On Mon, Nov 4, 2013 at 3:33 PM, David Cheney <david.cheney at canonical.com> wrote:
> Nope, no luck with the sdhci driver
>
> Copyright (c) 1992-2013 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 #0 r257599M: Mon Nov  4 14:10:54 EST 2013
>
>     root at deadwood.local:/root/crochet-freebsd/work/obj/arm.armv6/root/crochet-freebsd/src/sys/PANDABOARD
> arm
>
> FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610
>
> CPU: Cortex A9-r1 rev 3 (Cortex-A core)
>
>  Supported features: ARM_ISA THUMB2 JAZELLE THUMBEE ARMv4 Security_Ext
>
>  WB disabled EABT branch prediction enabled
>
> LoUU:2 LoC:1 LoUIS:2
>
> Cache level 1:
>
>  32KB/32B 4-way data cache WB Read-Alloc Write-Alloc
>
>  32KB/32B 4-way instruction cache Read-Alloc
>
> real memory  = 1073741824 (1024 MB)
>
> avail memory = 1042800640 (994 MB)
>
> Texas Instruments OMAP4430 Processor, Revision ES2.3
>
> random device not loaded; using insecure entropy
>
> random: <Software, Yarrow> initialized
>
> fdtbus0: <Flattened Device Tree>
>
> simplebus0: <Flattened device tree simple bus> on fdtbus0
>
> gic0: <ARM Generic Interrupt Controller> mem
> 0x48241000-0x48241fff,0x48240100-0x482401ff on simplebus0
>
> gic0: pn 0x390, arch 0x1, rev 0x0, implementer 0x43b nirqs 160
>
> omap4_prcm0: <TI OMAP Power, Reset and Clock Management> mem
> 0x4a306000-0x4a307fff,0x4a004000-0x4a004fff,0x4a008000-0x4a00ffff on
> simplebus0
>
> l2cache0: <PL310 L2 cache controller> mem 0x48242000-0x48242fff irq 32
> on simplebus0
>
> l2cache0: Part number: 0x3, release: 0x4
>
> l2cache0: L2 Cache: 1024KB/32B 16 ways
>
> mp_tmr0: <ARM Generic MPCore Timers> mem
> 0x48240200-0x482402ff,0x48240600-0x482406ff irq 27,29 on simplebus0
>
> Timecounter "ARM MPCore Timecounter" frequency 504000000 Hz quality 1000
>
> Event timer "ARM MPCore Eventtimer" frequency 504000000 Hz quality 1000
>
> uart0: <16750 or compatible> mem 0x48020000-0x48020fff irq 106 on simplebus0
>
> uart0: console (115384,n,8,1)
>
> ti_scm0: <TI Control Module> mem 0x4a100000-0x4a100fff on simplebus0
>
> gpio0: <TI General Purpose I/O (GPIO)> mem
> 0x4a310000-0x4a310fff,0x48055000-0x48055fff,0x48057000-0x48057fff,0x48059000-0x48059fff,0x4805b000-0x4805bfff,0x4805d000-0x4805dfff
> irq 61,62,63,64,65,66 on simplebus0
>
> gpioc0: <GPIO controller> on gpio0
>
> gpiobus0: <GPIO bus> on gpio0
>
> ehci0: <TI OMAP USB 2.0 controller> mem
> 0x4a064c00-0x4a064cff,0x4a064000-0x4a0646ff,0x4a062000-0x4a062fff irq
> 109 on simplebus0
>
> ehci0: Starting TI EHCI USB Controller
>
> ehci0: UHH revision 0x50700100
>
> ehci0: OMAP_UHH_SYSCONFIG: 0x00000014
>
> ehci0: UHH setup done, uhh_hostconfig=0x8000001c
>
> usbus0: EHCI version 1.0
>
> usbus0 on ehci0
>
> iichb0: <TI I2C Controller> mem 0x48070000-0x480700ff irq 88 on simplebus0
>
> iichb0: I2C revision 4.0
>
> iicbus0: <OFW I2C bus> on iichb0
>
> iic0: <I2C generic I/O> on iicbus0
>
> ti_sdma0: <TI sDMA Controller> mem 0x4a056000-0x4a056fff irq
> 44,45,46,47 on simplebus0
>
> ti_sdma0: sDMA revision 00010900
>
> sdhci_ti0: <TI MMCHS (SDHCI 2.0)> mem 0x4809c000-0x4809cfff irq 115 on
> simplebus0
>
> Timecounters tick every 10.000 msec
>
> usbus0: 480Mbps High Speed USB v2.0
>
> ugen0.1: <Texas Instruments> at usbus0
>
> uhub0: <Texas Instruments EHCI root HUB, class 9/0, rev 2.00/1.00,
> addr 1> on usbus0
>
> random: unblocking device.
>
> Root mount waiting for: usbus0
>
> Root mount waiting for: usbus0
>
> uhub0: 3 ports with 3 removable, self powered
>
> Root mount waiting for: usbus0
>
> ugen0.2: <vendor 0x0424> at usbus0
>
> uhub1: <vendor 0x0424 product 0x9514, class 9/0, rev 2.00/2.00, addr
> 2> on usbus0
>
> uhub1: MTT enabled
>
> Root mount waiting for: usbus0
>
> uhub1: 5 ports with 4 removable, self powered
>
> ugen0.3: <vendor 0x0424> at usbus0
>
> smsc0: <vendor 0x0424 product 0xec00, rev 2.00/2.00, addr 3> on usbus0
>
> Trying to mount root from ufs:/dev/mmcsd0s2 [rw,noatime]...
>
> mountroot: waiting for device /dev/mmcsd0s2 ...
>
> smsc0: chip 0xec00, rev. 0002
>
> miibus0: <MII bus> on smsc0
>
> ukphy0: <Generic IEEE 802.3u media interface> PHY 1 on miibus0
>
> ukphy0:  none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>
> ue0: <USB Ethernet> on smsc0
>
> ue0: Ethernet address: 76:ed:d8:c2:d4:6f
>
> Mounting from ufs:/dev/mmcsd0s2 failed with error 19.
>
>
> Loader variables:
>
>   vfs.root.mountfrom=ufs:/dev/mmcsd0s2
>
>   vfs.root.mountfrom.options=rw,noatime
>
>
> Manual root filesystem specification:
>
>   <fstype>:<device> [options]
>
>       Mount <device> using filesystem <fstype>
>
>       and with the specified (optional) option list.
>
>
>     eg. ufs:/dev/da0s1a
>
>         zfs:tank
>
>         cd9660:/dev/acd0 ro
>
>           (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /)
>
>
>   ?               List valid disk boot devices
>
>   .               Yield 1 second (for background tasks)
>
>   <empty line>    Abort manual input
>
>
> mountroot> ?
>
>
> List of GEOM managed disk devices:
>
>
>
> mountroot>
>
> On Mon, Nov 4, 2013 at 1:36 PM, David Cheney <david.cheney at canonical.com> wrote:
>> On Mon, Nov 4, 2013 at 1:33 PM, Ian Lepore <ian at freebsd.org> wrote:
>>> On Mon, 2013-11-04 at 13:19 +1100, David Cheney wrote:
>>>> Thanks Ian, try now.
>>>>
>>>> As a question to the group, I have the following hardware
>>>>
>>>> Pandaboard
>>>> BeagleBone Black
>>>> RPi
>>>>
>>>> And I am trying to bring up Freebsd/arm so I can get our Go builder
>>>> working again[1]. Of these candidates, which is the one you would
>>>> recommend ?
>>>>
>>>> Cheers
>>>>
>>>> Dave
>>>>
>>>> [1] build.golang.org
>>>
>>> The pandaboard is the fastest of those I think, but the Beaglebone may
>>> be the best combo of speed and well-supported if these pandaboard
>>> problems don't go away quickly for you.
>>
>> Thanks Ian.
>>
>> I got the BBB recently because it appeared to be the best supported,
>> but it appears to be suffering from the issue of selecting a very low,
>> ~550mhz clock speed no matter what source it is connected too, leading
>> to build times for ports and go of many hours.
>>
>>>
>>> -- Ian
>>>
>>>