netboot configuration [was: Re: NFS Root with Raspberry Pi (nfs_diskless: no interface)]
Ian Lepore
ian at freebsd.org
Sun Sep 27 16:14:59 UTC 2015
On Sun, 2015-09-27 at 14:15 +0300, Daniel Braniss wrote:
> > On 26 Sep 2015, at 17:01, Ian Lepore <ian at FreeBSD.org> wrote:
> >
> > On Sat, 2015-09-26 at 15:38 +0300, Daniel Braniss wrote:
> >>> On Sep 25, 2015, at 10:25 PM, Ian Lepore <ian at FreeBSD.org> wrote:
> >>>
> >>> On Fri, 2015-09-25 at 11:37 +0300, Daniel Braniss wrote:
> >>>>> On 25 Sep 2015, at 03:54, Ian Lepore <ian at FreeBSD.org> wrote:
> >>>>>
> >>>>> On Thu, 2015-09-24 at 19:54 +0200, Hans Petter Selasky wrote:
> >>>>>> On 09/24/15 18:36, Randy Westlund wrote:
> >>>>>>> On Thu, Sep 24, 2015 at 08:37:06AM -0600, Ian Lepore wrote:
> >>>>>>
> >>> [...stuff about problems netbooting...]
> >>>>
> >>>> hi Ian,
> >>>> can you help me here?
> >>>> I need the magics to get ubldr to boot from the net,
> >>>> i’m using an image built via crochet.
> >>>>
> >>>> cheers,
> >>>> danny
> >>>
> >>> I've been struggling with how to set up a new default u-boot environment
> >>> in our ports to make netbooting easier. The problem is that there are
> >>> as many ways to netboot as there are different people wanting to do it.
> >>> What I've been doing for years is loading both ubldr and the kernel from
> >>> nfs, by configuring my dhcp server to provide all the info needed (board
> >>> ip and netmask, server ip, ubldr file to load, and nfs root path), all
> >>> based on the mac address of the board. I've learned that doesn't work
> >>> well for most people who don't have easy control over their dhcp server.
> >>>
> >>> To try to keep this relatively simple, I'm going to assume that what
> >>> most folks want to do is:
> >>>
> >>> * Load ubldr from the sdcard that has u-boot on it (not from nfs).
> >>> * Make ubldr load the freebsd kernel from nfs.
> >>> * Use an nfs root filesystem.
> >>>
> >>> So I'm assuming you've got an nfs server already serving up the root
> >>> filesystem (I'm not going to detail configuring that here). That
> >>> filesystem must contain an /etc/fstab that includes the ip:/rootpath
> >>> entry for the root filesystem. In other words, even though the software
> >>> must already know the ip:/rootpath to find the fstab file, the file
> >>> still must contain a root path entry. (I find this annoying.)
> >>>
> >>> Now on the u-boot side you need to add a few lines to the uEnv.txt file
> >>> on the FAT partition (create the file there if it doesn't already
> >>> exist). You can configure a static IP address or get the IP from dhcp:
> >>>
> >>> For static IP (On RPi only, add one line: UserPreboot=usb start)
> >>>
> >>> loaderdev=net
> >>> rootpath=192.168.0.240:/wand
> >>> ipaddr=192.168.0.233
> >>> netmask=255.255.255.0
> >>>
> >>>
> >>> For DHCP (On RPi only, last line is: UserPreboot=usb start && dhcp)
> >>>
> >>> loaderdev=net
> >>> rootpath=192.168.0.240:/wand
> >>> autoload=no
> >>> UserPreboot=dhcp
> >>>
> >>> BTW, you may notice a Netboot command in the standard u-boot env. Do
> >>> NOT set bootcmd=run Netboot, that would make u-boot try to load ubldr
> >>> over the network, which requires running a tftp server.
> >>>
> >>> — Ian
> >>
> >> thanks!
> >> it almost worked :-)
> >> - UserPreboot didn’t work, probably because I have the wrong u-boot?
> >> stoping the boot, then typing
> >> usb start
> >> boot
> >> at the U-Boot> prompt saved the day!
> >>
> >> - if instead of boot I type dhcp, it tries to tftp u-boot, but I can’t figure out
> >> how to start it :-(
> >>
> >> in any case, great!
> >> now it would be nice if we pull resources and get this diskless stuff cleaned up
> >>
> >> danny
> >>
> >>
> >
> > I just committed the diskless fix, r288265. It should only be needed
> > for RPi and other systems with a usb-based NIC that initializes late in
> > the boot process.
> tested, and it works.
>
> >
> > All the u-boot ports have the UserPreboot hook in their env. Are you
> > using an old copy of crochet? (Hmmm, or has crochet never been updated
> > to use the u-boot ports/packages for all the boards?)
> >
> 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.
> > Do you want it to load ubldr via tftp instead of from the sdcard?
> not sure what i want :-), with traditional pxe capable bioses, the boot/dhcp
> has 2 stages, first if vendor id is set to PXEClient it sets filename to pxeboot,
> then pxeboot sets vendor id to FreeBSD, and a whole bunch of other stuff
> is provided, like root-path, etc.
>
> in the case of rpi, if dhcp does not provide a filename, it goes an tries
> to tftp load a nnnnnnn.img!
>
That nnnnnnnn stuff is the board's mac address encoded as ascii-hex
iirc, (but without the leading 0x), so that you can load a different
image per board.
> so, for RPI, we don’t need the PXE stuff that deals with the net driver,
> but would be nice (and i’m looking into it) to set the vendor id stuff,
> but I’m stuck in first base.
>
I know pretty much nothing about pxe at all.
-- Ian
> > That's an option, but ubldr doesn't change very often so just using the
> > one on the sdcard should be good enough.
> >
> > If you want u-boot to get an IP address via dhcp without trying to tftp
> > an image, do "setenv autoload no" before the dhcp command.
> >
> > -- Ian
> >
>
> _______________________________________________
> freebsd-arm at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscribe at freebsd.org"
More information about the freebsd-arm
mailing list