Date: Thu, 01 Oct 2015 10:24:42 -0600 From: Ian Lepore <ian@freebsd.org> To: Daniel Braniss <danny@cs.huji.ac.il> Cc: freebsd-arm@freebsd.org Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] Message-ID: <1443716682.66572.29.camel@freebsd.org> In-Reply-To: <7DBAE39E-55B2-4685-9C5E-2933B1DDFEF4@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> <CFAAFAE2-F0B2-431B-93C6-61D66464B7FD@cs.huji.ac.il> <1443105426.1224.272.camel@freebsd.org> <20150924163658.GC32257@gmail.com> <560438C5.3090404@selasky.org> <1443142468.1224.322.camel@freebsd.org> <FE458AF3-A9EE-46B1-89E3-1FB82E413E17@cs.huji.ac.il> <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> <B7B0FD1E-5AA5-43DB-B494-2F5D594C43D7@cs.huji.ac.il> <1443371712.1224.398.camel@freebsd.org> <AEE426FD-3BAA-4DFB-BC5D-8CB8ECB0819D@cs.huji.ac.il> <1443542714.1224.445.camel@freebsd.org> <7DBAE39E-55B2-4685-9C5E-2933B1DDFEF4@cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 2015-09-30 at 10:39 +0300, Daniel Braniss wrote: > > On 29 Sep 2015, at 19:05, Ian Lepore <ian@FreeBSD.org> wrote: > > > > On Tue, 2015-09-29 at 12:24 +0300, Daniel Braniss wrote: > >>> On 27 Sep 2015, at 19:35, Ian Lepore <ian@FreeBSD.org> wrote: > >>> > >>> On Sun, 2015-09-27 at 19:25 +0300, Daniel Braniss wrote: > >>>>> On Sep 27, 2015, at 7:14 PM, Ian Lepore <ian@FreeBSD.org> 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 <serverip> > > 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. :) > > there is definitely an issue with the net driver in the newer/ports u-boot. > - tftpboot sometimes works :-) > - same with nfs > I've got the 2015.10-rc4 u-boot for rpi working now. It had some cache flushing problems which I think the u-boot folks have not noticed because the path through the code to launch a linux image is right, but the 'bootelf' and 'go' paths are not. I think the rc4 will turn into an actual release pretty soon and we'll have a new u-boot for rpi. > via dhcp: > it should not try tftp load filename if none is supplied, i.e. defaulting to > <mac-address>.img is wrong! > That's just not how they've defined u-boot to work. There is a whole lot of "it wasn't really designed, it just evolved over time" in u-boot. The original design was that if you left off the filename it tried to load a name based on the mac address. Then when people wanted to use dhcp just to get an IP but not load anything, the mechanism they set up for that is that you have to do "setenv autoload no" before using the dhcp or bootp commands. > i got ubldr loaded via tftp and then bootelf got it running. > the loaded kernel complained: > No valid device tree blob found! > I guess some of the environmet variables got lost > > my network is quiet busy, may be thats a factor? > If this is for rpi, u-boot should have set up an fdt_addr variable referencing the dtb blob it loads and modifies. (This is an rpi only thing, other platforms just leave the dtb loading to ubldr by setting fdt_name instead of fdt_addr, but that won't work on rpi.) So all in all I'd say the problem here is that u-boot 2013.10 for rpi just barely works under some conditions for netbooting, and it's probably not worth putting much more effort into it, because we should have the final 2015.10 release soon and then we can just update the port to use it. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1443716682.66572.29.camel>