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

[Daniel Braniss]

> On 1 Oct 2015, at 7:24 PM, Ian Lepore <ian at FreeBSD.org> wrote:
> 
> On Wed, 2015-09-30 at 10:39 +0300, Daniel Braniss wrote:
>>> On 29 Sep 2015, at 19:05, Ian Lepore <ian at 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 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. :)
>> 
>> 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.

can I get a copy ?

> 
>> 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.
> 

evolution is fine, the problem is no cross pollination :-)
iPXE, pxeboot, etc do things differently. 
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
>> 
>> 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.
> 
please let me know when this happens?

thanks,
	danny

> -- Ian