From owner-freebsd-arm@freebsd.org Tue Sep 29 16:05:22 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 C5598A0C2FF for ; Tue, 29 Sep 2015 16:05:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 A13B41295 for ; Tue, 29 Sep 2015 16:05:22 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from ilsoft.org (unknown [73.34.117.227]) by outbound1.ore.mailhop.org (Halon Mail Gateway) with ESMTPSA; Tue, 29 Sep 2015 16:05:54 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id t8TG5EJL014400; Tue, 29 Sep 2015 10:05:14 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1443542714.1224.445.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, Rick Macklem Date: Tue, 29 Sep 2015 10:05:14 -0600 In-Reply-To: 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> <1443371712.1224.398.camel@freebsd.org> Content-Type: text/plain; charset="iso-8859-13" 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: Tue, 29 Sep 2015 16:05:22 -0000 On Tue, 2015-09-29 at 12:24 +0300, Daniel Braniss wrote: > > On 27 Sep 2015, at 19:35, Ian Lepore wrote: > > > > On Sun, 2015-09-27 at 19:25 +0300, Daniel Braniss wrote: > >>> On Sep 27, 2015, at 7:14 PM, Ian Lepore wrote: > >>> > >>> On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote: > > [...] > >>>> 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. > >> > >> 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˙t. > > > > Hmmm. What stuff from crochet? The two components that are in play > > here are u-boot itself (it contains the low-level network drivers that > > ubldr uses -- it's effectively acting as a bios for ubldr), and ubldr > > which contains the higher-level network code. > > > > In theory ubldr should be the same in both cases; nothing much has > > changed in the loader code for months. But there are different paths > > through the code depending on how it gets the network parms, and I could > > easily have glitched something when I added the feature that lets you > > set the config with u-boot env vars. > > > > The u-boot might be different between a crochet and ports build. They > > both start with gonzo's u-boot 2013.10 sources, but crochet probably has > > a slightly different set of patches it applies. > > > > -- Ian > > > > with the old uboot it boots ok, with the newer/modified it stops at random > places reading via udp/nfs/v3 the kernel. it loads correctly all the *.4th files, > then starts reading the kernel, and hangs after a random time. > I have found that if I let u-boot get an ip address via dhcp then the load of the kernel in ubldr never fails (I've had it reboot-looping for 24 hours now without a hang). But without letting u-boot do the dhcp thing it hangs pretty much every time. Substituting a ping for the dhcp isn't enough to make it reliable. I've stopped debugging that whole mess for now to have a quick check whether the very latest mainline u-boot (2015.10-rc4) is able to netboot. It sure would be nice to use something modern that has already been debugged by others. :) > on another issue, if I type dhcp instead of boot, it loads via TFTP filename, > which I set to ubldr/ubldr.bin, it loads and now prompts again, > what should the command be? I tried go 0, go 20000, in which case execs > the old ubldr :-( > The old ubldr had to be launched using 'bootelf', the new ubldr.bin has to be launched using "go ${loadaddr}". While we transition from old to new I've been using "dhcp && bootelf || go ${loadaddr}" -- if it's ubldr the bootelf command works; if bootelf fails it fails back to using go. -- Ian