netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)]

[Ian Lepore]

On Tue, 2015-09-29 at 12:24 +0300, Daniel Braniss wrote:
> > On 27 Sep 2015, at 19:35, Ian Lepore <ian at 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 at 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. :)

> 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 <dhcp parms> && bootelf || go ${loadaddr}" --
if it's ubldr the bootelf command works; if bootelf fails it fails back
to using go.

-- Ian