From owner-freebsd-arm@freebsd.org Sun Sep 27 16:14:58 2015 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9416A0A539 for ; Sun, 27 Sep 2015 16:14:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from erouter6.ore.mailhop.org (erouter6.ore.mailhop.org [54.187.213.119]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A7A33AA6 for ; Sun, 27 Sep 2015 16:14:58 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound3.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Sun, 27 Sep 2015 16:13:32 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t8RGEoF1009988; Sun, 27 Sep 2015 10:14:50 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1443370490.1224.392.camel@freebsd.org> Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Ian Lepore To: Daniel Braniss Cc: freebsd-arm@freebsd.org Date: Sun, 27 Sep 2015 10:14:50 -0600 In-Reply-To: <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> References: <20150922052522.GA62140@gmail.com> <00C49FEB-E8EF-4469-85E2-0F901215CD11@cs.huji.ac.il> <20150923050414.GB43653@gmail.com> <91AAC64E-4C38-47AA-8910-48F7654A7524@cs.huji.ac.il> <20150923174445.GE43653@gmail.com> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <1443209159.1224.361.camel@freebsd.org> <12C96F79-2D70-408D-AD4C-F06F6B909AD3@cs.huji.ac.il> <1443276119.1224.382.camel@freebsd.org> <33EFE756-B428-4A72-B3C5-0E764FA8ACC6@cs.huji.ac.il> Content-Type: text/plain; charset="windows-1251" X-Mailer: Evolution 3.12.10 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Sep 2015 16:14:59 -0000 On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: > > On 26 Sep 2015, at 17:01, Ian Lepore wrote: > > > > On Sat, 2015-09-26 at 15:38 +0300, Daniel Braniss wrote: > >>> On Sep 25, 2015, at 10:25 PM, Ian Lepore wrote: > >>> > >>> On Fri, 2015-09-25 at 11:37 +0300, Daniel Braniss wrote: > >>>>> On 25 Sep 2015, at 03:54, Ian Lepore wrote: > >>>>> > >>>>> On Thu, 2015-09-24 at 19:54 +0200, Hans Petter Selasky wrote: > >>>>>> On 09/24/15 18:36, Randy Westlund wrote: > >>>>>>> On Thu, Sep 24, 2015 at 08:37:06AM -0600, Ian Lepore wrote: > >>>>>> > >>> [...stuff about problems netbooting...] > >>>> > >>>> hi Ian, > >>>> can you help me here? > >>>> I need the magics to get ubldr to boot from the net, > >>>> i’m using an image built via crochet. > >>>> > >>>> cheers, > >>>> danny > >>> > >>> I've been struggling with how to set up a new default u-boot environment > >>> in our ports to make netbooting easier. The problem is that there are > >>> as many ways to netboot as there are different people wanting to do it. > >>> What I've been doing for years is loading both ubldr and the kernel from > >>> nfs, by configuring my dhcp server to provide all the info needed (board > >>> ip and netmask, server ip, ubldr file to load, and nfs root path), all > >>> based on the mac address of the board. I've learned that doesn't work > >>> well for most people who don't have easy control over their dhcp server. > >>> > >>> To try to keep this relatively simple, I'm going to assume that what > >>> most folks want to do is: > >>> > >>> * Load ubldr from the sdcard that has u-boot on it (not from nfs). > >>> * Make ubldr load the freebsd kernel from nfs. > >>> * Use an nfs root filesystem. > >>> > >>> So I'm assuming you've got an nfs server already serving up the root > >>> filesystem (I'm not going to detail configuring that here). That > >>> filesystem must contain an /etc/fstab that includes the ip:/rootpath > >>> entry for the root filesystem. In other words, even though the software > >>> must already know the ip:/rootpath to find the fstab file, the file > >>> still must contain a root path entry. (I find this annoying.) > >>> > >>> Now on the u-boot side you need to add a few lines to the uEnv.txt file > >>> on the FAT partition (create the file there if it doesn't already > >>> exist). You can configure a static IP address or get the IP from dhcp: > >>> > >>> For static IP (On RPi only, add one line: UserPreboot=usb start) > >>> > >>> loaderdev=net > >>> rootpath=192.168.0.240:/wand > >>> ipaddr=192.168.0.233 > >>> netmask=255.255.255.0 > >>> > >>> > >>> For DHCP (On RPi only, last line is: UserPreboot=usb start && dhcp) > >>> > >>> loaderdev=net > >>> rootpath=192.168.0.240:/wand > >>> autoload=no > >>> UserPreboot=dhcp > >>> > >>> BTW, you may notice a Netboot command in the standard u-boot env. Do > >>> NOT set bootcmd=run Netboot, that would make u-boot try to load ubldr > >>> over the network, which requires running a tftp server. > >>> > >>> — Ian > >> > >> thanks! > >> it almost worked :-) > >> - UserPreboot didn’t work, probably because I have the wrong u-boot? > >> stoping the boot, then typing > >> usb start > >> boot > >> at the U-Boot> prompt saved the day! > >> > >> - if instead of boot I type dhcp, it tries to tftp u-boot, but I can’t figure out > >> how to start it :-( > >> > >> in any case, great! > >> now it would be nice if we pull resources and get this diskless stuff cleaned up > >> > >> danny > >> > >> > > > > I just committed the diskless fix, r288265. It should only be needed > > for RPi and other systems with a usb-based NIC that initializes late in > > the boot process. > tested, and it works. > > > > > All the u-boot ports have the UserPreboot hook in their env. Are you > > using an old copy of crochet? (Hmmm, or has crochet never been updated > > to use the u-boot ports/packages for all the boards?) > > > I compiled the u-boot-rpi from ports, > the good news: > it understands UserPreboot > the bad news: > the nfs boot gets stuck after a while. > > after much trial and error, this is what I do: > hit a key to enter U-Boot > then type: > setenv loaderdev net > boot > > attaching the console: I was also experiencing intermittant lockups while loader loads the kernel. I just wrote it off to failing hardware (I powered my rpi on for the first time in 6-8 months to work on this), since I've never had a problem with netbooting before (it's the only way I've ever booted the rpi). If it's not just my board going bad, then that's a bit of a mystery. The only other difference here from what I've always done is setting rootpath and other net config in u-boot instead of letting ubldr get it from dhcp. > > Do you want it to load ubldr via tftp instead of from the sdcard? > not sure what i want :-), with traditional pxe capable bioses, the boot/dhcp > has 2 stages, first if vendor id is set to PXEClient it sets filename to pxeboot, > then pxeboot sets vendor id to FreeBSD, and a whole bunch of other stuff > is provided, like root-path, etc. > > in the case of rpi, if dhcp does not provide a filename, it goes an tries > to tftp load a nnnnnnn.img! > That nnnnnnnn stuff is the board's mac address encoded as ascii-hex iirc, (but without the leading 0x), so that you can load a different image per board. > so, for RPI, we don’t need the PXE stuff that deals with the net driver, > but would be nice (and i’m looking into it) to set the vendor id stuff, > but I’m stuck in first base. > I know pretty much nothing about pxe at all. -- Ian > > That's an option, but ubldr doesn't change very often so just using the > > one on the sdcard should be good enough. > > > > If you want u-boot to get an IP address via dhcp without trying to tftp > > an image, do "setenv autoload no" before the dhcp command. > > > > -- Ian > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"