Date: Mon, 4 Nov 2013 15:33:14 +1100 From: David Cheney <david.cheney@canonical.com> To: Ian Lepore <ian@freebsd.org> Cc: freebsd-arm@freebsd.org Subject: Re: freebsd/pandaboard Spurious interrupt detected [0x000003ff] Message-ID: <CAHPQsESmBRKS1ihFdarisG0VfbBtFWjAwGJkXXj8LpXjhct-8w@mail.gmail.com> In-Reply-To: <CAHPQsERHkRfzeF7yV-sygXu_=e4yOmQBvPLYk4t4MhiMkKdmVQ@mail.gmail.com> References: <CAHPQsESP2aQxYDj0J=BdDUDhQdWnxMuAJ5fPNELGqLPsR==Ktg@mail.gmail.com> <1383526716.31172.131.camel@revolution.hippie.lan> <CAHPQsEQQ%2BZ29vZj%2BasoWB3mFPo-wU%2BJJ7LytGJ=q8BmPSozd_w@mail.gmail.com> <1383532405.31172.137.camel@revolution.hippie.lan> <CAHPQsERHkRfzeF7yV-sygXu_=e4yOmQBvPLYk4t4MhiMkKdmVQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@canonical.com> wrote: > On Mon, Nov 4, 2013 at 1:33 PM, Ian Lepore <ian@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 >> >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAHPQsESmBRKS1ihFdarisG0VfbBtFWjAwGJkXXj8LpXjhct-8w>