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

[Daniel Braniss]

last resort, check hardware

so I took a brand new rpi, same problems.
i saw many gpio0: stray interrupts, so I changed power supply, BINGO!
it now works!
thanks all for your patience.
cheers,
	danny

> On 30 Sep 2015, at 10:39, Daniel Braniss <danny at cs.huji.ac.il> 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
> 	
> via dhcp:
> 	it should not try tftp load filename if none is supplied, i.e. defaulting to
> 	<mac-address>.img is wrong!
> 
> 	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?
> 	
>> 
>>> 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
> 
> _______________________________________________
> freebsd-arm at freebsd.org <mailto:freebsd-arm at freebsd.org> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm <https://lists.freebsd.org/mailman/listinfo/freebsd-arm>
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org <mailto:freebsd-arm-unsubscribe at freebsd.org>"