Date: Mon, 5 Oct 2015 10:38:51 +0300 From: Daniel Braniss <danny@cs.huji.ac.il> To: Ian Lepore <ian@FreeBSD.org> Cc: freebsd-arm@freebsd.org Subject: Re: netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)] Message-ID: <861CCAA5-D71C-44C9-96B4-8D017228CBF7@cs.huji.ac.il> In-Reply-To: <1443716682.66572.29.camel@freebsd.org> 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> <1443716682.66572.29.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 1 Oct 2015, at 7:24 PM, Ian Lepore <ian@FreeBSD.org> wrote: >=20 > 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: >>>=20 >>> 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: >>>>>=20 >>>>> 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: >>>>>>>=20 >>>>>>> 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. >>>>>>>>=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. >>>>>>=20 >>>>>> 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=B4t. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> -- Ian >>>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>=20 >>> 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. >>>=20 >>> 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. :) >>=20 >> there is definitely an issue with the net driver in the newer/ports = u-boot. >> - tftpboot sometimes works :-) >> - same with nfs >> =09 >=20 > 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. can I get a copy ? >=20 >> via dhcp: >> it should not try tftp load filename if none is supplied, i.e. = defaulting to >> <mac-address>.img is wrong! >>=20 >=20 > 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. >=20 evolution is fine, the problem is no cross pollination :-) iPXE, pxeboot, etc do things differently.=20 PXE is a standard, that even though it was defined for MS to be able to = have network boot, it did solve a major problem, standardise the connection = to the network hardware, thus making it much simpler to boot over the network without = having to know what network driver to use. dhcp evolved from bootp, and can provide much more info that is critical = at boot time, (and not necessarily the dynamic part), it provides yet another way to customise the boot environment, and IMHO, = it makes it much simpler to maintain/experiment since one root image can now be = used. >> 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 >>=20 >> my network is quiet busy, may be thats a factor? >> =09 >=20 > 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.) >=20 > 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. >=20 please let me know when this happens? thanks, danny > -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?861CCAA5-D71C-44C9-96B4-8D017228CBF7>