Date: Wed, 30 Sep 2015 13:05:33 +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: <2E1482CA-AD21-4EAC-9BE5-DB9F9468CC86@cs.huji.ac.il> In-Reply-To: <F8DBF136-C4B3-48A4-8B68-67197DFDD31E@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> <F8DBF136-C4B3-48A4-8B68-67197DFDD31E@cs.huji.ac.il>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 30 Sep 2015, at 12:58, Daniel Braniss <danny@cs.huji.ac.il> wrote:
>=20
> last resort, check hardware
>=20
> so I took a brand new rpi, same problems.
> i saw many gpio0: stray interrupts, so I changed power supply, BINGO!
spoken too fast :-(
back to old problems.
> it now works!
> thanks all for your patience.
> cheers,
> danny
>=20
>> On 30 Sep 2015, at 10:39, Daniel Braniss <danny@cs.huji.ac.il> wrote:
>>=20
>>>=20
>>> 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=C2=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
>> via dhcp:
>> it should not try tftp load filename if none is supplied, i.e. =
defaulting to
>> <mac-address>.img is wrong!
>>=20
>> 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
>>>> 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 :-(
>>>>=20
>>>=20
>>> 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.
>>>=20
>>> -- Ian
>>=20
>> _______________________________________________
>> freebsd-arm@freebsd.org <mailto:freebsd-arm@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@freebsd.org =
<mailto:freebsd-arm-unsubscribe@freebsd.org>"
>=20
> _______________________________________________
> freebsd-arm@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2E1482CA-AD21-4EAC-9BE5-DB9F9468CC86>