From owner-freebsd-arm@FreeBSD.ORG Mon Sep 5 11:07:04 2011 Return-Path: Delivered-To: freebsd-arm@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E65611065675 for ; Mon, 5 Sep 2011 11:07:04 +0000 (UTC) (envelope-from owner-bugmaster@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:4f8:fff6::28]) by mx1.freebsd.org (Postfix) with ESMTP id D41348FC0A for ; Mon, 5 Sep 2011 11:07:04 +0000 (UTC) Received: from freefall.freebsd.org (localhost [127.0.0.1]) by freefall.freebsd.org (8.14.4/8.14.4) with ESMTP id p85B74Bq065822 for ; Mon, 5 Sep 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.14.4/8.14.4/Submit) id p85B74du065820 for freebsd-arm@FreeBSD.org; Mon, 5 Sep 2011 11:07:04 GMT (envelope-from owner-bugmaster@FreeBSD.org) Date: Mon, 5 Sep 2011 11:07:04 GMT Message-Id: <201109051107.p85B74du065820@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: gnats set sender to owner-bugmaster@FreeBSD.org using -f From: FreeBSD bugmaster To: freebsd-arm@FreeBSD.org Cc: Subject: Current problem reports assigned to freebsd-arm@FreeBSD.org X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Sep 2011 11:07:05 -0000 Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description -------------------------------------------------------------------------------- o arm/160431 arm [patch] Disable interrupts during busdma cache sync op o arm/158950 arm arm/sheevaplug fails fsx when mmap operations are enab o arm/156814 arm OpenRD Ultimate does not boot on DB-88F6XXX or SHEEVAP o arm/156496 arm [patch] Minor bugfixes and enhancements to mmc and mmc o arm/155894 arm [patch] Enable at91 booting from SDHC (high capacity) o arm/155214 arm [patch] MMC/SD IO slow on Atmel ARM with modern large o arm/154227 arm [geli] using GELI leads to panic on ARM o arm/154189 arm lang/perl5.12 doesn't build on arm o arm/153380 arm Panic / translation fault with wlan on ARM o arm/150581 arm [irq] Unknown error generates IRQ address decoding err o arm/149288 arm mail/dovecot causes panic during configure on Sheevapl o arm/134368 arm [patch] nslu2_led driver for the LEDs on the NSLU2 p arm/134338 arm [patch] Lock GPIO accesses on ixp425 13 problems total. From owner-freebsd-arm@FreeBSD.ORG Tue Sep 6 12:05:49 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B2E00106566C for ; Tue, 6 Sep 2011 12:05:49 +0000 (UTC) (envelope-from mattia.rossi.mate@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 64BAC8FC17 for ; Tue, 6 Sep 2011 12:05:49 +0000 (UTC) Received: by yxn22 with SMTP id 22so3321296yxn.13 for ; Tue, 06 Sep 2011 05:05:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:reply-to:organization:user-agent:mime-version :to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=80I0PzhLmb/S3FyGTVMu4nud4ZpTpMDQbYaoPOqTuOY=; b=ca9xmUbj7vdKvV4R7E9F8oiBEGtVmHQuBXtZmh6fNq732S6RpPjp76+rRy1HZWTnon CrDXT9DPaILvUyco5MDtf6W08CriIaYautdA97I4YHQMgMvYjegGikHRRwgywpzCcxMR mgBZAashg3RuMFXzvUdh7WZ20zblASkzGKFwo= Received: by 10.90.7.29 with SMTP id 29mr3534973agg.89.1315309036078; Tue, 06 Sep 2011 04:37:16 -0700 (PDT) Received: from [192.168.15.65] (124-148-158-203.dyn.iinet.net.au [124.148.158.203]) by mx.google.com with ESMTPS id p7sm12999988ank.1.2011.09.06.04.37.12 (version=SSLv3 cipher=OTHER); Tue, 06 Sep 2011 04:37:14 -0700 (PDT) Message-ID: <4E6605E8.70903@swin.edu.au> Date: Tue, 06 Sep 2011 21:37:12 +1000 From: Mattia Rossi Organization: Swinburne University of Technology User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110812 Thunderbird/6.0 MIME-Version: 1.0 To: freebsd-arm@freebsd.org References: <20110708120025.5C94210656D9@hub.freebsd.org> <1310178351.5681.4.camel@bmcgover-laptop.beta.com> <4E18403C.8010203@gmail.com> <1310344111.1455.3.camel@bmcgover-laptop.beta.com> <4E1A4F18.5000802@gmail.com> <1310412331.1466.41.camel@bmcgover-laptop.beta.com> <4E1B83F8.3070700@gmail.com> <1310439696.1438.6.camel@bmcgover-laptop.beta.com> <4E1C48EE.3070905@gmail.com> <1310674865.1447.71.camel@bmcgover-laptop.beta.com> <4E1FA4E0.5050703@gmail.com> <1311045159.1508.3.camel@bmcgover-laptop.beta.com> <6E4BB877-4039-41A8-96B7-AB36AE2774C0@gmail.com> <1311808468.1465.10.camel@bmcgover-laptop.beta.com> In-Reply-To: <1311808468.1465.10.camel@bmcgover-laptop.beta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Brian J. McGovern" Subject: Re: Suggestions for arm build for qemu? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: mrossi@swin.edu.au List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 12:05:49 -0000 On 28/07/11 09:14, Brian J. McGovern wrote: > On Wed, 2011-07-27 at 16:08 +0200, Damjan Marion wrote: >> On Jul 19, 2011, at 5:12 AM, Brian J. McGovern wrote: >> >>> That got it. The kernel is now booting, and I'm able to run the >>> applications in /rescue. The other binaries seem to be hit or miss >>> (signal 11s), although the C compiler can build 'hello world', so I'm >>> guessing that either the dynamic linker isn't set up right (/etc isn't >>> populated by the installworld, so I continue to add files by hand) and >>> its having a problem finding all the dynamic libraries it wants, or the >>> 64MB memory limit is a problem, and I need to get swap going. In any >>> event, its enough to get my hacking until Globalscale ships my board. >> >> Hi Brian, >> >> Can you share how did you setup root file system? I tried to play with >> qemu network settings but didn't reach far away from: >> >> Received DHCP Ack packet on smc0 from 10.0.2.2 (accepted) (no root path) >> DHCP/BOOTP timeout for server 255.255.255.255 >> >> Thanks, >> >> Damjan >> >> > Sure. Happy to share what others helped with... I'm going to assume > you've read through http://wiki.freebsd.org/FreeBSDMarvell, have built > and the exported file system. It looks like you're getting hung up on > passing the root filesystem via DHCP. I'm using the isc-dhcp server, so > I had to add > > option root-path "dotted.quad.ip.addr:/path/to/exported root"; > > to the section that will give an address to the device. This will get > the device to mount the NFS export as the root filesystem. > > Once you can boot the device, you can use the standard tools to build > local filesystems if you've defined hard disks or other storage. > Hi Brian, Coming back to this whole qemu issue, following the various posts in this thread, I've been able to boot the kernel and to get a DHCP offer from my DHCP server. It also comes as far as trying to set the NFS root up, using the hint you gave above, but then it will fail with an RPC timeout. I suspect that the NFS server wont bind to the tap0 interface? I start qemu the following way: qemu-system-arm -M connex -m 289 -pflash -nographic -serial tcp::4000,server -net nic,macaddr=,vlan=0,model=smc91c111 -net tap,vlan=0,ifname=tap0,script=no I have a tap0 interface with the IP address, which I point the option root-path to (it's a 10 dot something address). The NFS server is set to listen on the 10 dot something subnet. Do you have some other trick in there to make it working? I've tried to bridge tap0 to em0 as well, but couldn't get any DHCP requests on em0 in that case.. The host system is 8.2, the Qemu arm system is CURRENT. Any help would be highly appreciated! Mat From owner-freebsd-arm@FreeBSD.ORG Tue Sep 6 21:15:59 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 815C91065670 for ; Tue, 6 Sep 2011 21:15:59 +0000 (UTC) (envelope-from freebsd@damnhippie.dyndns.org) Received: from qmta13.emeryville.ca.mail.comcast.net (qmta13.emeryville.ca.mail.comcast.net [76.96.27.243]) by mx1.freebsd.org (Postfix) with ESMTP id 6728B8FC13 for ; Tue, 6 Sep 2011 21:15:58 +0000 (UTC) Received: from omta17.emeryville.ca.mail.comcast.net ([76.96.30.73]) by qmta13.emeryville.ca.mail.comcast.net with comcast id VYmg1h0031afHeLADZ2kVj; Tue, 06 Sep 2011 21:02:44 +0000 Received: from damnhippie.dyndns.org ([24.8.232.202]) by omta17.emeryville.ca.mail.comcast.net with comcast id VYyT1h01R4NgCEG8dYyUeM; Tue, 06 Sep 2011 20:58:28 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id p86L2lwK038796 for ; Tue, 6 Sep 2011 15:02:47 -0600 (MDT) (envelope-from freebsd@damnhippie.dyndns.org) From: Ian Lepore To: freebsd-arm In-Reply-To: <201109031940.p83Je9fo004190@freefall.freebsd.org> References: <201109031940.p83Je9fo004190@freefall.freebsd.org> Content-Type: text/plain Date: Tue, 06 Sep 2011 15:02:47 -0600 Message-Id: <1315342967.1671.21.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.26.0 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Subject: Re: arm/160431: [patch] Disable interrupts during busdma cache sync operations. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 21:15:59 -0000 After thinking more about Mark's question I've come to the conclusion that interrupts should only be disabled in the partial cachline flush case. Basically it comes down to the fact that only that case is special, in that we temporarily duplicate the state of the hardware into a local buffer then restore it, and we can't let the state of the real hardware change during that time. It also occurs to me that if it's necessary to disable interrupts during all cache operations done by the busdma code, then it should be just as necessary during the operations done by the pmap code, and it's not clear to me that those operations are all currently happening only while interrupts are disabled. So, here is a do-over on the patch that only disables interrupts in the partial cacheline case. Considering that the partial case seems to be pretty rare, and tends to involve buffers smaller a single cacheline, this should result in having interrupts disabled a whole lot less often during buffer syncs. Index: busdma_machdep.c =================================================================== RCS file: /local/base/FreeBSD-CVS/src/sys/arm/arm/busdma_machdep.c,v retrieving revision 1.50 diff -u -p -r1.50 busdma_machdep.c --- busdma_machdep.c 11 Mar 2010 21:16:54 -0000 1.50 +++ busdma_machdep.c 6 Sep 2011 19:06:32 -0000 @@ -1106,28 +1106,44 @@ bus_dmamap_sync_buf(void *buf, int len, cpu_l2cache_wbinv_range((vm_offset_t)buf, len); } } + /* + * Interrupts must be disabled if handling a partial cacheline flush, + * otherwise the interrupt handling code could modify data in the + * non-DMA part of a cacheline while we have it stashed away in the + * temporary stack buffer, then we end up restoring the stale value. As + * unlikely as this seems, it has been observed in the real world. + */ if (op & BUS_DMASYNC_POSTREAD) { - if ((vm_offset_t)buf & arm_dcache_align_mask) { - memcpy(_tmp_cl, (void *)((vm_offset_t)buf & ~ - arm_dcache_align_mask), - (vm_offset_t)buf & arm_dcache_align_mask); - } - if (((vm_offset_t)buf + len) & arm_dcache_align_mask) { - memcpy(_tmp_clend, (void *)((vm_offset_t)buf + len), - arm_dcache_align - (((vm_offset_t)(buf) + len) & - arm_dcache_align_mask)); + uint32_t intr; + int partial = (((vm_offset_t)buf) | len) & arm_dcache_align_mask; + + if (partial) { + intr = intr_disable(); + if ((vm_offset_t)buf & arm_dcache_align_mask) { + memcpy(_tmp_cl, (void *)((vm_offset_t)buf & ~ + arm_dcache_align_mask), + (vm_offset_t)buf & arm_dcache_align_mask); + } + if (((vm_offset_t)buf + len) & arm_dcache_align_mask) { + memcpy(_tmp_clend, (void *)((vm_offset_t)buf + len), + arm_dcache_align - (((vm_offset_t)(buf) + len) & + arm_dcache_align_mask)); + } } cpu_dcache_inv_range((vm_offset_t)buf, len); cpu_l2cache_inv_range((vm_offset_t)buf, len); - if ((vm_offset_t)buf & arm_dcache_align_mask) - memcpy((void *)((vm_offset_t)buf & - ~arm_dcache_align_mask), _tmp_cl, - (vm_offset_t)buf & arm_dcache_align_mask); - if (((vm_offset_t)buf + len) & arm_dcache_align_mask) - memcpy((void *)((vm_offset_t)buf + len), _tmp_clend, - arm_dcache_align - (((vm_offset_t)(buf) + len) & - arm_dcache_align_mask)); + if (partial) { + if ((vm_offset_t)buf & arm_dcache_align_mask) + memcpy((void *)((vm_offset_t)buf & + ~arm_dcache_align_mask), _tmp_cl, + (vm_offset_t)buf & arm_dcache_align_mask); + if (((vm_offset_t)buf + len) & arm_dcache_align_mask) + memcpy((void *)((vm_offset_t)buf + len), _tmp_clend, + arm_dcache_align - (((vm_offset_t)(buf) + len) & + arm_dcache_align_mask)); + intr_restore(intr); + } } } From owner-freebsd-arm@FreeBSD.ORG Tue Sep 6 22:34:25 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 889FA1065670 for ; Tue, 6 Sep 2011 22:34:25 +0000 (UTC) (envelope-from marktinguely@gmail.com) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by mx1.freebsd.org (Postfix) with ESMTP id 43CF68FC16 for ; Tue, 6 Sep 2011 22:34:24 +0000 (UTC) Received: by gwb20 with SMTP id 20so5478869gwb.17 for ; Tue, 06 Sep 2011 15:34:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=pBxQjDA7N97cxQDOETbFQHvWPesE2ImYkFixw/GgQa0=; b=XgjKcVksLT0aWjfct9m2MHZN2zD1oi12p9A0yFG+D9n8PXXVSGErieAvgjxeQEA8ua GJAauOTRLxqes2OxgLU3l1y/VyV/zM2BH4cdHaNjQpjxc8xkj5NjtoEHofbCfDPh+a71 7TPEjKhd1stUr+mOldnCzxVsdEuHQTMk/PK4I= Received: by 10.236.189.104 with SMTP id b68mr27874177yhn.13.1315346981636; Tue, 06 Sep 2011 15:09:41 -0700 (PDT) Received: from [192.168.1.111] ([206.188.254.192]) by mx.google.com with ESMTPS id t56sm1284596yhh.20.2011.09.06.15.09.40 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Sep 2011 15:09:41 -0700 (PDT) Message-ID: <4E669A1E.6060307@gmail.com> Date: Tue, 06 Sep 2011 17:09:34 -0500 From: Mark Tinguely User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0.1) Gecko/20110830 Thunderbird/6.0.1 MIME-Version: 1.0 To: Ian Lepore References: <201109031940.p83Je9fo004190@freefall.freebsd.org> <1315342967.1671.21.camel@revolution.hippie.lan> In-Reply-To: <1315342967.1671.21.camel@revolution.hippie.lan> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm Subject: Re: arm/160431: [patch] Disable interrupts during busdma cache sync operations. X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Sep 2011 22:34:25 -0000 On 9/6/2011 4:02 PM, Ian Lepore wrote: > After thinking more about Mark's question I've come to the conclusion > that interrupts should only be disabled in the partial cachline flush > case. Basically it comes down to the fact that only that case is > special, in that we temporarily duplicate the state of the hardware into > a local buffer then restore it, and we can't let the state of the real > hardware change during that time. > > It also occurs to me that if it's necessary to disable interrupts during > all cache operations done by the busdma code, then it should be just as > necessary during the operations done by the pmap code, and it's not > clear to me that those operations are all currently happening only while > interrupts are disabled. > > So, here is a do-over on the patch that only disables interrupts in the > partial cacheline case. Considering that the partial case seems to be > pretty rare, and tends to involve buffers smaller a single cacheline, > this should result in having interrupts disabled a whole lot less often > during buffer syncs. > Rant on. I am not picking on you. I hate the BUS_DMASYNC_POSTREAD code! I want it gone, gone,gone. If the page(s) is shared with another memory space, then we know the page caching will be turned off and this is not needed (and if executed anyway, it is sloooow). BUS_DMASYNC_PREREAD would be enough IF: bus_dmamem_alloc() returns cache aligned space (very easy). Force the device driver writers to cache align their buffers. We could provide a define to make it easy. Rant off. --Mark Tinguely From owner-freebsd-arm@FreeBSD.ORG Wed Sep 7 22:50:07 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 496211065670 for ; Wed, 7 Sep 2011 22:50:07 +0000 (UTC) (envelope-from mcgovern@beta.com) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) by mx1.freebsd.org (Postfix) with ESMTP id E964F8FC15 for ; Wed, 7 Sep 2011 22:50:06 +0000 (UTC) Received: from [199.165.180.39] (dhcp9.beta.com [199.165.180.39]) by spoon.beta.com (8.14.4/8.14.4) with ESMTP id p87Mo3oE016742; Wed, 7 Sep 2011 18:50:04 -0400 (EDT) (envelope-from mcgovern@beta.com) From: "Brian J. McGovern" To: mrossi@swin.edu.au In-Reply-To: <4E6605E8.70903@swin.edu.au> References: <20110708120025.5C94210656D9@hub.freebsd.org> <1310178351.5681.4.camel@bmcgover-laptop.beta.com> <4E18403C.8010203@gmail.com> <1310344111.1455.3.camel@bmcgover-laptop.beta.com> <4E1A4F18.5000802@gmail.com> <1310412331.1466.41.camel@bmcgover-laptop.beta.com> <4E1B83F8.3070700@gmail.com> <1310439696.1438.6.camel@bmcgover-laptop.beta.com> <4E1C48EE.3070905@gmail.com> <1310674865.1447.71.camel@bmcgover-laptop.beta.com> <4E1FA4E0.5050703@gmail.com> <1311045159.1508.3.camel@bmcgover-laptop.beta.com> <6E4BB877-4039-41A8-96B7-AB36AE2774C0@gmail.com> <1311808468.1465.10.camel@bmcgover-laptop.beta.com> <4E6605E8.70903@swin.edu.au> Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Sep 2011 18:50:06 -0400 Message-ID: <1315435806.1456.2.camel@bmcgover-laptop.beta.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.2 required=5.0 tests=RP_MATCHES_RCVD,S25R_6 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on spoon.beta.com Cc: freebsd-arm@freebsd.org Subject: Re: Suggestions for arm build for qemu? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Sep 2011 22:50:07 -0000 On Tue, 2011-09-06 at 21:37 +1000, Mattia Rossi wrote: > On 28/07/11 09:14, Brian J. McGovern wrote: > > On Wed, 2011-07-27 at 16:08 +0200, Damjan Marion wrote: > >> On Jul 19, 2011, at 5:12 AM, Brian J. McGovern wrote: > >> > >>> That got it. The kernel is now booting, and I'm able to run the > >>> applications in /rescue. The other binaries seem to be hit or miss > >>> (signal 11s), although the C compiler can build 'hello world', so I'm > >>> guessing that either the dynamic linker isn't set up right (/etc isn't > >>> populated by the installworld, so I continue to add files by hand) and > >>> its having a problem finding all the dynamic libraries it wants, or the > >>> 64MB memory limit is a problem, and I need to get swap going. In any > >>> event, its enough to get my hacking until Globalscale ships my board. > >> > >> Hi Brian, > >> > >> Can you share how did you setup root file system? I tried to play with > >> qemu network settings but didn't reach far away from: > >> > >> Received DHCP Ack packet on smc0 from 10.0.2.2 (accepted) (no root path) > >> DHCP/BOOTP timeout for server 255.255.255.255 > >> > >> Thanks, > >> > >> Damjan > >> > >> > > Sure. Happy to share what others helped with... I'm going to assume > > you've read through http://wiki.freebsd.org/FreeBSDMarvell, have built > > and the exported file system. It looks like you're getting hung up on > > passing the root filesystem via DHCP. I'm using the isc-dhcp server, so > > I had to add > > > > option root-path "dotted.quad.ip.addr:/path/to/exported root"; > > > > to the section that will give an address to the device. This will get > > the device to mount the NFS export as the root filesystem. > > > > Once you can boot the device, you can use the standard tools to build > > local filesystems if you've defined hard disks or other storage. > > > > Hi Brian, > > Coming back to this whole qemu issue, following the various posts in > this thread, I've been able to boot the kernel and to get a DHCP offer > from my DHCP server. It also comes as far as trying to set the NFS root > up, using the hint you gave above, but then it will fail with an RPC > timeout. I suspect that the NFS server wont bind to the tap0 interface? > > I start qemu the following way: > qemu-system-arm -M connex -m 289 -pflash -nographic -serial > tcp::4000,server -net nic,macaddr= addr>,vlan=0,model=smc91c111 -net tap,vlan=0,ifname=tap0,script=no > > I have a tap0 interface with the IP address, which I point the option > root-path to (it's a 10 dot something address). The NFS server is set to > listen on the 10 dot something subnet. > > Do you have some other trick in there to make it working? > > I've tried to bridge tap0 to em0 as well, but couldn't get any DHCP > requests on em0 in that case.. The host system is 8.2, the Qemu arm > system is CURRENT. > > Any help would be highly appreciated! > > Mat > > Have you tried restarting NFS after you bring up tap0? The RPC messages are often seen when the response is not from the same host the request was sent to. Restarting it should allow the INADDR_ANY binding to include tap0. You may also want to check any export permissions. From owner-freebsd-arm@FreeBSD.ORG Thu Sep 8 01:04:04 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 875A6106567A for ; Thu, 8 Sep 2011 01:04:04 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by mx1.freebsd.org (Postfix) with ESMTP id 17C568FC1A for ; Thu, 8 Sep 2011 01:04:03 +0000 (UTC) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p880RN7q023896; Thu, 8 Sep 2011 10:27:24 +1000 Message-ID: <4E680BEB.7010105@swin.edu.au> Date: Thu, 08 Sep 2011 10:27:23 +1000 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110824 Thunderbird/6.0 MIME-Version: 1.0 To: "Brian J. McGovern" References: <20110708120025.5C94210656D9@hub.freebsd.org> <1310178351.5681.4.camel@bmcgover-laptop.beta.com> <4E18403C.8010203@gmail.com> <1310344111.1455.3.camel@bmcgover-laptop.beta.com> <4E1A4F18.5000802@gmail.com> <1310412331.1466.41.camel@bmcgover-laptop.beta.com> <4E1B83F8.3070700@gmail.com> <1310439696.1438.6.camel@bmcgover-laptop.beta.com> <4E1C48EE.3070905@gmail.com> <1310674865.1447.71.camel@bmcgover-laptop.beta.com> <4E1FA4E0.5050703@gmail.com> <1311045159.1508.3.camel@bmcgover-laptop.beta.com> <6E4BB877-4039-41A8-96B7-AB36AE2774C0@gmail.com> <1311808468.1465.10.camel@bmcgover-laptop.beta.com> <4E6605E8.70903@swin.edu.au> <1315435806.1456.2.camel@bmcgover-laptop.beta.com> In-Reply-To: <1315435806.1456.2.camel@bmcgover-laptop.beta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Suggestions for arm build for qemu? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 01:04:04 -0000 On 08/09/2011 08:50, Brian J. McGovern wrote: > On Tue, 2011-09-06 at 21:37 +1000, Mattia Rossi wrote: >> On 28/07/11 09:14, Brian J. McGovern wrote: >>> On Wed, 2011-07-27 at 16:08 +0200, Damjan Marion wrote: >>>> On Jul 19, 2011, at 5:12 AM, Brian J. McGovern wrote: >>>> >>>>> That got it. The kernel is now booting, and I'm able to run the >>>>> applications in /rescue. The other binaries seem to be hit or miss >>>>> (signal 11s), although the C compiler can build 'hello world', so I'm >>>>> guessing that either the dynamic linker isn't set up right (/etc isn't >>>>> populated by the installworld, so I continue to add files by hand) and >>>>> its having a problem finding all the dynamic libraries it wants, or the >>>>> 64MB memory limit is a problem, and I need to get swap going. In any >>>>> event, its enough to get my hacking until Globalscale ships my board. >>>> >>>> Hi Brian, >>>> >>>> Can you share how did you setup root file system? I tried to play with >>>> qemu network settings but didn't reach far away from: >>>> >>>> Received DHCP Ack packet on smc0 from 10.0.2.2 (accepted) (no root path) >>>> DHCP/BOOTP timeout for server 255.255.255.255 >>>> >>>> Thanks, >>>> >>>> Damjan >>>> >>>> >>> Sure. Happy to share what others helped with... I'm going to assume >>> you've read through http://wiki.freebsd.org/FreeBSDMarvell, have built >>> and the exported file system. It looks like you're getting hung up on >>> passing the root filesystem via DHCP. I'm using the isc-dhcp server, so >>> I had to add >>> >>> option root-path "dotted.quad.ip.addr:/path/to/exported root"; >>> >>> to the section that will give an address to the device. This will get >>> the device to mount the NFS export as the root filesystem. >>> >>> Once you can boot the device, you can use the standard tools to build >>> local filesystems if you've defined hard disks or other storage. >>> >> >> Hi Brian, >> >> Coming back to this whole qemu issue, following the various posts in >> this thread, I've been able to boot the kernel and to get a DHCP offer >> from my DHCP server. It also comes as far as trying to set the NFS root >> up, using the hint you gave above, but then it will fail with an RPC >> timeout. I suspect that the NFS server wont bind to the tap0 interface? >> >> I start qemu the following way: >> qemu-system-arm -M connex -m 289 -pflash -nographic -serial >> tcp::4000,server -net nic,macaddr=> addr>,vlan=0,model=smc91c111 -net tap,vlan=0,ifname=tap0,script=no >> >> I have a tap0 interface with the IP address, which I point the option >> root-path to (it's a 10 dot something address). The NFS server is set to >> listen on the 10 dot something subnet. >> >> Do you have some other trick in there to make it working? >> >> I've tried to bridge tap0 to em0 as well, but couldn't get any DHCP >> requests on em0 in that case.. The host system is 8.2, the Qemu arm >> system is CURRENT. >> >> Any help would be highly appreciated! >> >> Mat >> >> > Have you tried restarting NFS after you bring up tap0? The RPC messages > are often seen when the response is not from the same host the request > was sent to. Restarting it should allow the INADDR_ANY binding to > include tap0. You may also want to check any export permissions. > Thanks, for the reply. I just got everything running. Finally! The problem was twofold. First, tap0 was not up, and most of all wouldn't stay up. So before starting qemu I always have to issue an ifconfig tap0 up, in order to make sure that the tap0-em0 bridge (yes I reverted to that) works, and DHCP offers get through to tap0, and packets get out from the qemu guest. Second, for some reason, /etc/rc.d/nfsserver start does not do anything. I had to manually start nfsd with the necessary options, which are -u -t and -n2. Not sure whether -n2 is actually necessary. Then I had to restart /etc/rc.d lockd and /etc/rc.d/statd as well, as they want nfsd running.. So a bit of a mess. I also added the next-server directive to dhcpd.conf. Not sure if that is necessary either. Btw. the missing init scripts and /etc entries in the ARM world can be installed by a make distrib-dirs distribution So, now everything works, with the exception that trying to ssh into the arm guest makes the guest system crash. Now I'm trying the latest HEAD, maybe that fixes things. Next step is to try to get the whole world installed on a disk attached to the qemu guest, and possibly boot from that in future.. that would be awesome. Any hints? Mat From owner-freebsd-arm@FreeBSD.ORG Thu Sep 8 02:30:41 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9AD61106564A for ; Thu, 8 Sep 2011 02:30:41 +0000 (UTC) (envelope-from mcgovern@beta.com) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4FB518FC13 for ; Thu, 8 Sep 2011 02:30:40 +0000 (UTC) Received: from [199.165.180.39] (dhcp9.beta.com [199.165.180.39]) by spoon.beta.com (8.14.4/8.14.4) with ESMTP id p882UcCa018914; Wed, 7 Sep 2011 22:30:38 -0400 (EDT) (envelope-from mcgovern@beta.com) From: "Brian J. McGovern" To: mrossi@swin.edu.au In-Reply-To: <4E6605E8.70903@swin.edu.au> References: <20110708120025.5C94210656D9@hub.freebsd.org> <1310178351.5681.4.camel@bmcgover-laptop.beta.com> <4E18403C.8010203@gmail.com> <1310344111.1455.3.camel@bmcgover-laptop.beta.com> <4E1A4F18.5000802@gmail.com> <1310412331.1466.41.camel@bmcgover-laptop.beta.com> <4E1B83F8.3070700@gmail.com> <1310439696.1438.6.camel@bmcgover-laptop.beta.com> <4E1C48EE.3070905@gmail.com> <1310674865.1447.71.camel@bmcgover-laptop.beta.com> <4E1FA4E0.5050703@gmail.com> <1311045159.1508.3.camel@bmcgover-laptop.beta.com> <6E4BB877-4039-41A8-96B7-AB36AE2774C0@gmail.com> <1311808468.1465.10.camel@bmcgover-laptop.beta.com> <4E6605E8.70903@swin.edu.au> Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Sep 2011 22:30:41 -0400 Message-ID: <1315449041.1456.4.camel@bmcgover-laptop.beta.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.2 required=5.0 tests=RP_MATCHES_RCVD,S25R_6 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on spoon.beta.com Cc: freebsd-arm@freebsd.org Subject: Re: Suggestions for arm build for qemu? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 02:30:41 -0000 On Tue, 2011-09-06 at 21:37 +1000, Mattia Rossi wrote: > On 28/07/11 09:14, Brian J. McGovern wrote: > > On Wed, 2011-07-27 at 16:08 +0200, Damjan Marion wrote: > >> On Jul 19, 2011, at 5:12 AM, Brian J. McGovern wrote: > >> > >>> That got it. The kernel is now booting, and I'm able to run the > >>> applications in /rescue. The other binaries seem to be hit or miss > >>> (signal 11s), although the C compiler can build 'hello world', so I'm > >>> guessing that either the dynamic linker isn't set up right (/etc isn't > >>> populated by the installworld, so I continue to add files by hand) and > >>> its having a problem finding all the dynamic libraries it wants, or the > >>> 64MB memory limit is a problem, and I need to get swap going. In any > >>> event, its enough to get my hacking until Globalscale ships my board. > >> > >> Hi Brian, > >> > >> Can you share how did you setup root file system? I tried to play with > >> qemu network settings but didn't reach far away from: > >> > >> Received DHCP Ack packet on smc0 from 10.0.2.2 (accepted) (no root path) > >> DHCP/BOOTP timeout for server 255.255.255.255 > >> > >> Thanks, > >> > >> Damjan > >> > >> > > Sure. Happy to share what others helped with... I'm going to assume > > you've read through http://wiki.freebsd.org/FreeBSDMarvell, have built > > and the exported file system. It looks like you're getting hung up on > > passing the root filesystem via DHCP. I'm using the isc-dhcp server, so > > I had to add > > > > option root-path "dotted.quad.ip.addr:/path/to/exported root"; > > > > to the section that will give an address to the device. This will get > > the device to mount the NFS export as the root filesystem. > > > > Once you can boot the device, you can use the standard tools to build > > local filesystems if you've defined hard disks or other storage. > > > > Hi Brian, > > Coming back to this whole qemu issue, following the various posts in > this thread, I've been able to boot the kernel and to get a DHCP offer > from my DHCP server. It also comes as far as trying to set the NFS root > up, using the hint you gave above, but then it will fail with an RPC > timeout. I suspect that the NFS server wont bind to the tap0 interface? > > I start qemu the following way: > qemu-system-arm -M connex -m 289 -pflash -nographic -serial > tcp::4000,server -net nic,macaddr= addr>,vlan=0,model=smc91c111 -net tap,vlan=0,ifname=tap0,script=no > > I have a tap0 interface with the IP address, which I point the option > root-path to (it's a 10 dot something address). The NFS server is set to > listen on the 10 dot something subnet. > > Do you have some other trick in there to make it working? > > I've tried to bridge tap0 to em0 as well, but couldn't get any DHCP > requests on em0 in that case.. The host system is 8.2, the Qemu arm > system is CURRENT. > > Any help would be highly appreciated! > > Mat > > The one other thing that came to mind is check the NFS client you're using in your kernel if you're using FreeBSD 9.x... You'll need to make sure you have the "right" combination of NFS client and mount options (nfs vs. oldnfs). From owner-freebsd-arm@FreeBSD.ORG Thu Sep 8 02:34:13 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5B3F6106564A for ; Thu, 8 Sep 2011 02:34:13 +0000 (UTC) (envelope-from mcgovern@beta.com) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) by mx1.freebsd.org (Postfix) with ESMTP id CAF258FC13 for ; Thu, 8 Sep 2011 02:34:12 +0000 (UTC) Received: from [199.165.180.39] (dhcp9.beta.com [199.165.180.39]) by spoon.beta.com (8.14.4/8.14.4) with ESMTP id p882YAGI018945; Wed, 7 Sep 2011 22:34:10 -0400 (EDT) (envelope-from mcgovern@beta.com) From: "Brian J. McGovern" To: Mattia Rossi In-Reply-To: <4E680BEB.7010105@swin.edu.au> References: <20110708120025.5C94210656D9@hub.freebsd.org> <1310178351.5681.4.camel@bmcgover-laptop.beta.com> <4E18403C.8010203@gmail.com> <1310344111.1455.3.camel@bmcgover-laptop.beta.com> <4E1A4F18.5000802@gmail.com> <1310412331.1466.41.camel@bmcgover-laptop.beta.com> <4E1B83F8.3070700@gmail.com> <1310439696.1438.6.camel@bmcgover-laptop.beta.com> <4E1C48EE.3070905@gmail.com> <1310674865.1447.71.camel@bmcgover-laptop.beta.com> <4E1FA4E0.5050703@gmail.com> <1311045159.1508.3.camel@bmcgover-laptop.beta.com> <6E4BB877-4039-41A8-96B7-AB36AE2774C0@gmail.com> <1311808468.1465.10.camel@bmcgover-laptop.beta.com> <4E6605E8.70903@swin.edu.au> <1315435806.1456.2.camel@bmcgover-laptop.beta.com> <4E680BEB.7010105@swin.edu.au> Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Sep 2011 22:34:13 -0400 Message-ID: <1315449253.1456.6.camel@bmcgover-laptop.beta.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.2 required=5.0 tests=RP_MATCHES_RCVD,S25R_6 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on spoon.beta.com Cc: freebsd-arm@freebsd.org Subject: Re: Suggestions for arm build for qemu? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 02:34:13 -0000 Glad to see you got it mostly working. I never really had a suitable qemu experience - I kept getting random software failures (e.g. a "make" would fail, you'd rerun it, and sometimes it'd fail in the same place, other times elsewhere, and other times not at all). About at that point, my OpenRD Ultimate showed up, so I moved to real hardware. -B On Thu, 2011-09-08 at 10:27 +1000, Mattia Rossi wrote: > On 08/09/2011 08:50, Brian J. McGovern wrote: > > On Tue, 2011-09-06 at 21:37 +1000, Mattia Rossi wrote: > >> On 28/07/11 09:14, Brian J. McGovern wrote: > >>> On Wed, 2011-07-27 at 16:08 +0200, Damjan Marion wrote: > >>>> On Jul 19, 2011, at 5:12 AM, Brian J. McGovern wrote: > >>>> > >>>>> That got it. The kernel is now booting, and I'm able to run the > >>>>> applications in /rescue. The other binaries seem to be hit or miss > >>>>> (signal 11s), although the C compiler can build 'hello world', so I'm > >>>>> guessing that either the dynamic linker isn't set up right (/etc isn't > >>>>> populated by the installworld, so I continue to add files by hand) and > >>>>> its having a problem finding all the dynamic libraries it wants, or the > >>>>> 64MB memory limit is a problem, and I need to get swap going. In any > >>>>> event, its enough to get my hacking until Globalscale ships my board. > >>>> > >>>> Hi Brian, > >>>> > >>>> Can you share how did you setup root file system? I tried to play with > >>>> qemu network settings but didn't reach far away from: > >>>> > >>>> Received DHCP Ack packet on smc0 from 10.0.2.2 (accepted) (no root path) > >>>> DHCP/BOOTP timeout for server 255.255.255.255 > >>>> > >>>> Thanks, > >>>> > >>>> Damjan > >>>> > >>>> > >>> Sure. Happy to share what others helped with... I'm going to assume > >>> you've read through http://wiki.freebsd.org/FreeBSDMarvell, have built > >>> and the exported file system. It looks like you're getting hung up on > >>> passing the root filesystem via DHCP. I'm using the isc-dhcp server, so > >>> I had to add > >>> > >>> option root-path "dotted.quad.ip.addr:/path/to/exported root"; > >>> > >>> to the section that will give an address to the device. This will get > >>> the device to mount the NFS export as the root filesystem. > >>> > >>> Once you can boot the device, you can use the standard tools to build > >>> local filesystems if you've defined hard disks or other storage. > >>> > >> > >> Hi Brian, > >> > >> Coming back to this whole qemu issue, following the various posts in > >> this thread, I've been able to boot the kernel and to get a DHCP offer > >> from my DHCP server. It also comes as far as trying to set the NFS root > >> up, using the hint you gave above, but then it will fail with an RPC > >> timeout. I suspect that the NFS server wont bind to the tap0 interface? > >> > >> I start qemu the following way: > >> qemu-system-arm -M connex -m 289 -pflash -nographic -serial > >> tcp::4000,server -net nic,macaddr= >> addr>,vlan=0,model=smc91c111 -net tap,vlan=0,ifname=tap0,script=no > >> > >> I have a tap0 interface with the IP address, which I point the option > >> root-path to (it's a 10 dot something address). The NFS server is set to > >> listen on the 10 dot something subnet. > >> > >> Do you have some other trick in there to make it working? > >> > >> I've tried to bridge tap0 to em0 as well, but couldn't get any DHCP > >> requests on em0 in that case.. The host system is 8.2, the Qemu arm > >> system is CURRENT. > >> > >> Any help would be highly appreciated! > >> > >> Mat > >> > >> > > Have you tried restarting NFS after you bring up tap0? The RPC messages > > are often seen when the response is not from the same host the request > > was sent to. Restarting it should allow the INADDR_ANY binding to > > include tap0. You may also want to check any export permissions. > > > > Thanks, for the reply. I just got everything running. Finally! > The problem was twofold. First, tap0 was not up, and most of all > wouldn't stay up. So before starting qemu I always have to issue an > ifconfig tap0 up, in order to make sure that the tap0-em0 bridge (yes I > reverted to that) works, and DHCP offers get through to tap0, and > packets get out from the qemu guest. > Second, for some reason, /etc/rc.d/nfsserver start does not do anything. > I had to manually start nfsd with the necessary options, which are -u -t > and -n2. Not sure whether -n2 is actually necessary. > Then I had to restart /etc/rc.d lockd and /etc/rc.d/statd as well, as > they want nfsd running.. So a bit of a mess. > I also added the next-server directive to dhcpd.conf. Not sure if that > is necessary either. > > Btw. the missing init scripts and /etc entries in the ARM world can be > installed by a > > make distrib-dirs distribution > > So, now everything works, with the exception that trying to ssh into the > arm guest makes the guest system crash. Now I'm trying the latest HEAD, > maybe that fixes things. > > Next step is to try to get the whole world installed on a disk attached > to the qemu guest, and possibly boot from that in future.. that would be > awesome. Any hints? > > > Mat > > From owner-freebsd-arm@FreeBSD.ORG Thu Sep 8 02:38:44 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 9EDA9106564A for ; Thu, 8 Sep 2011 02:38:44 +0000 (UTC) (envelope-from mcgovern@beta.com) Received: from spoon.beta.com (spoon.beta.com [199.165.180.2]) by mx1.freebsd.org (Postfix) with ESMTP id 4C30A8FC12 for ; Thu, 8 Sep 2011 02:38:44 +0000 (UTC) Received: from [199.165.180.39] (dhcp9.beta.com [199.165.180.39]) by spoon.beta.com (8.14.4/8.14.4) with ESMTP id p882cglW019057 for ; Wed, 7 Sep 2011 22:38:42 -0400 (EDT) (envelope-from mcgovern@beta.com) From: "Brian J. McGovern" To: freebsd-arm@freebsd.org In-Reply-To: <20110907120028.CED5810656AB@hub.freebsd.org> References: <20110907120028.CED5810656AB@hub.freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Wed, 07 Sep 2011 22:38:45 -0400 Message-ID: <1315449525.1456.11.camel@bmcgover-laptop.beta.com> Mime-Version: 1.0 X-Mailer: Evolution 2.30.2 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.2 required=5.0 tests=RP_MATCHES_RCVD,S25R_6 autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on spoon.beta.com Subject: u-boot version on OpenRD Ultimate/sdio? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 02:38:44 -0000 All, I've been chasing this issue on-again/off-again for a few weeks as I get free time. I've discovered, thanks to a bad NAND flashing event, that the version of u-boot used to fire up hardware is critical to the functioning of the hardware (e.g. its not just a boot loader, but more). With the most recent version of u-boot, I lost the ethernet cards on my OpenRD ultimate, and finally backed it down to the version shipped with the hardware (1.1.4). However, the SD card continues not to work. My questions on the issue in the past have gotten no results, and I've learned to interpret that as I'm doing something so stupid as to not deserve an answer. I now think I've figured out what that is... So, I have to ask, for anyone who has the sdio slot working on the OpenRD Marvell boards... What version of u-boot are you running? 2011-06 seems to break the ethernet cards (with FreeBSD), and I don't want to destroy my NAND by constantly reflashing different versions.... -B From owner-freebsd-arm@FreeBSD.ORG Thu Sep 8 03:34:38 2011 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 6C8F21065670 for ; Thu, 8 Sep 2011 03:34:38 +0000 (UTC) (envelope-from mrossi@swin.edu.au) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) by mx1.freebsd.org (Postfix) with ESMTP id F05648FC14 for ; Thu, 8 Sep 2011 03:34:37 +0000 (UTC) Received: from mrossi.caia.swin.edu.au (mrossi.caia.swin.edu.au [136.186.229.109]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id p883Y6iC029374; Thu, 8 Sep 2011 13:34:09 +1000 Message-ID: <4E6837AE.9050903@swin.edu.au> Date: Thu, 08 Sep 2011 13:34:06 +1000 From: Mattia Rossi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:6.0) Gecko/20110824 Thunderbird/6.0 MIME-Version: 1.0 To: "Brian J. McGovern" References: <20110708120025.5C94210656D9@hub.freebsd.org> <1310178351.5681.4.camel@bmcgover-laptop.beta.com> <4E18403C.8010203@gmail.com> <1310344111.1455.3.camel@bmcgover-laptop.beta.com> <4E1A4F18.5000802@gmail.com> <1310412331.1466.41.camel@bmcgover-laptop.beta.com> <4E1B83F8.3070700@gmail.com> <1310439696.1438.6.camel@bmcgover-laptop.beta.com> <4E1C48EE.3070905@gmail.com> <1310674865.1447.71.camel@bmcgover-laptop.beta.com> <4E1FA4E0.5050703@gmail.com> <1311045159.1508.3.camel@bmcgover-laptop.beta.com> <6E4BB877-4039-41A8-96B7-AB36AE2774C0@gmail.com> <1311808468.1465.10.camel@bmcgover-laptop.beta.com> <4E6605E8.70903@swin.edu.au> <1315435806.1456.2.camel@bmcgover-laptop.beta.com> <4E680BEB.7010105@swin.edu.au> <1315449253.1456.6.camel@bmcgover-laptop.beta.com> In-Reply-To: <1315449253.1456.6.camel@bmcgover-laptop.beta.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-arm@freebsd.org Subject: Re: Suggestions for arm build for qemu? X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Sep 2011 03:34:38 -0000 On 08/09/2011 12:34, Brian J. McGovern wrote: > Glad to see you got it mostly working. I never really had a suitable > qemu experience - I kept getting random software failures (e.g. a "make" > would fail, you'd rerun it, and sometimes it'd fail in the same place, > other times elsewhere, and other times not at all). > > About at that point, my OpenRD Ultimate showed up, so I moved to real > hardware. > Ah, I see.. Well, I had the hardware long before, but the small amount of memory (32M) doesn't really allow me to compile any ports for arm, which I then need to have libraries and binaries to include into BSDBox via crunchgen.. I'll try qemu again later today, otherwise I'll have to start building FreeBSD on my Dreamplug, which has enough power to build everything. Have to check back on the status of NAND support in FreeBSD though. Thanks for the info, Mat