From owner-freebsd-arm@freebsd.org Sun Sep 27 16:25:57 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 E52B1A0AB84 for ; Sun, 27 Sep 2015 16:25:57 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from kabab.cs.huji.ac.il (kabab.cs.huji.ac.il [132.65.116.210]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6EC7FFB9; Sun, 27 Sep 2015 16:25:56 +0000 (UTC) (envelope-from danny@cs.huji.ac.il) Received: from e-bsd.cs.huji.ac.il ([132.65.80.241] helo=outmail.cs.huji.ac.il) by kabab.cs.huji.ac.il with esmtp id 1ZgElp-000MGt-W8; Sun, 27 Sep 2015 19:25:50 +0300 Received: from [132.65.179.20] (helo=mbpro2.bs.cs.huji.ac.il) by outmail.cs.huji.ac.il with esmtpsa id 1ZgElp-0006SD-J1; Sun, 27 Sep 2015 19:25:49 +0300 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] From: Daniel Braniss In-Reply-To: <1443370490.1224.392.camel@freebsd.org> Date: Sun, 27 Sep 2015 19:25:49 +0300 Cc: freebsd-arm@freebsd.org, Rick Macklem Message-Id: 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> <1443370490.1224.392.camel@freebsd.org> To: Ian Lepore X-Mailer: Apple Mail (2.2104) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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:25:58 -0000 > On Sep 27, 2015, at 7:14 PM, Ian Lepore wrote: >=20 > On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: >>> On 26 Sep 2015, at 17:01, Ian Lepore wrote: >>>=20 >>> On Sat, 2015-09-26 at 15:38 +0300, Daniel Braniss wrote: >>>>> On Sep 25, 2015, at 10:25 PM, Ian Lepore wrote: >>>>>=20 >>>>> On Fri, 2015-09-25 at 11:37 +0300, Daniel Braniss wrote: >>>>>>> On 25 Sep 2015, at 03:54, Ian Lepore wrote: >>>>>>>=20 >>>>>>> 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: >>>>>>>>=20 >>>>> [...stuff about problems netbooting...] >>>>>>=20 >>>>>> hi Ian, >>>>>> can you help me here? >>>>>> I need the magics to get ubldr to boot from the net, >>>>>> i=E2=80=99m using an image built via crochet.=20 >>>>>>=20 >>>>>> cheers, >>>>>> danny >>>>>=20 >>>>> 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. >>>>>=20 >>>>> To try to keep this relatively simple, I'm going to assume that = what >>>>> most folks want to do is: >>>>>=20 >>>>> * 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. >>>>>=20 >>>>> 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.) >>>>>=20 >>>>> 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: >>>>>=20 >>>>> For static IP (On RPi only, add one line: UserPreboot=3Dusb start) >>>>>=20 >>>>> loaderdev=3Dnet >>>>> rootpath=3D192.168.0.240:/wand >>>>> ipaddr=3D192.168.0.233 >>>>> netmask=3D255.255.255.0 >>>>>=20 >>>>>=20 >>>>> For DHCP (On RPi only, last line is: UserPreboot=3Dusb start && = dhcp) >>>>>=20 >>>>> loaderdev=3Dnet >>>>> rootpath=3D192.168.0.240:/wand >>>>> autoload=3Dno >>>>> UserPreboot=3Ddhcp >>>>>=20 >>>>> BTW, you may notice a Netboot command in the standard u-boot env. = Do >>>>> NOT set bootcmd=3Drun Netboot, that would make u-boot try to load = ubldr >>>>> over the network, which requires running a tftp server. >>>>>=20 >>>>> =E2=80=94 Ian >>>>=20 >>>> thanks!=20 >>>> it almost worked :-) >>>> - UserPreboot didn=E2=80=99t 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! >>>>=20 >>>> - if instead of boot I type dhcp, it tries to tftp u-boot, but I = can=E2=80=99t figure out >>>> how to start it :-( >>>>=20 >>>> in any case, great! >>>> now it would be nice if we pull resources and get this diskless = stuff cleaned up >>>>=20 >>>> danny >>>>=20 >>>>=20 >>>=20 >>> 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. >>=20 >>>=20 >>> 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?) >>>=20 >> 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. >>=20 >> after much trial and error, this is what I do: >> hit a key to enter U-Boot >> then type: >> setenv loaderdev net >> boot >>=20 >> attaching the console: >=20 > 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. with the stuff from crochet it works, same setup! I am sniffing the net = via wireshark, and it stops at different positions in the kernel file, so the settings of rootpath and other configs are irrelevant. the transfer is being done via udp/nfs/v3 (hence added ric :-) maybe he can see something we don=E2=80=99t. >=20 >>> 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. >>=20 >> in the case of rpi, if dhcp does not provide a filename, it goes an = tries >> to tftp load a nnnnnnn.img! >>=20 >=20 > 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. i know, it goes back to SunOS days =E2=80=A6 >=20 >> so, for RPI, we don=E2=80=99t need the PXE stuff that deals with the = net driver, >> but would be nice (and i=E2=80=99m looking into it) to set the vendor = id stuff, >> but I=E2=80=99m stuck in first base. >>=20 >=20 > I know pretty much nothing about pxe at all. >=20 > -- Ian >=20 >>> That's an option, but ubldr doesn't change very often so just using = the >>> one on the sdcard should be good enough. >>>=20 >>> 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. >>>=20 >>> -- Ian >>>=20 >>=20 >> _______________________________________________ >> 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 = "