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