Gentle persons:
I won't repeat here Bas's analysis of the problem we're having with the
BeagleBone/Ubuntu system.
Here is my minimalist solution which requires no new programming, just a
change in several configuration parameters. Please bear with the longish
message. Because of an abrupt turn of events at home, I'm on my way out
the door and I don't know when I'll next get a chance to put out this
information. Someone else may have to deal with the Wiki page if this
approach is found to work generally.
1. The uDev.txt Michael posted is like most I found on the net. It
results in DHCP services being invoked twice. First, U-Boot asks for
parameters it needs for, e.g., tftpboot. Then, while initializing, the
Linux kernel itself uses DHCP services to provision its ip parameter
set. This redundancy is harmless but consider...
if we eliminate that second invocation and instead explicitly pass the
full set of ip parameters in the bootargs then the LinuxCNC system boots
and stays up just fine. Yes, dhclient is still invoked early on but by
then the clock is set and the lease times are valid, at least in testing
on my system.
For example, from the U-Boot command line, the following works (I keep
most of Michael's parameters to maintain verisimilitude. Note though
there is an environment variable "console" already set properly by
U-Boot, so I used it.). I've added comments parenthetically "(... )".
# setenv autoload no
(...I don't have time to demonstrate an alternative to turning off the
autoload feature)
# dhcp
(...provision some environment variables needed by tftp)
# tftp
(...the kernel is loaded to the default loadaddr)
# setenv bootargs console=${console} noinitrd rw debug --no-log
root=/dev/nfs nfsroot=<my nfs server
ip>:/var/lib/tftpboot/rootfs-xenomai ip=<my BB ip>:<my server ip>:<my
gateway ip>:<my netmask>:<my hostname>:eth0:off
(... substitute real strings for all <items>; the nfsroot string is
necessary because we're not letting the kernel obtain that information
via ip=dhcp)
# bootz
(...U-Boot passes control to the kernel at the default loadaddr; the
kernel initializes and mounts the root filesystem from the server)
and away we go.
2. So how do we do this in a uEnv.txt script? In various places in the
source code, U-Boot groks the following environment variables
ipaddr---our device's IP address
serverip---the IP address of the TFTP server
gatewayip---not strictly needed if everything is reachable on the
local subnet
netmask---the usual
hostname---not strictly needed if you set hostname in /etc/hostname
but I like the flexibility
bootfile---the name of the kernel that the TFTP server is going to
pass, relative to the (to pass to the TFTP server)
rootpath---the fully qualified root file system path to pass to the
NFS server
Most of you have probably discovered that, after invoking dhcp or tftp,
some of these environment variables have been provisioned from the dhcp
reply. However, in my system the hosthame and rootpath variables have not.
Yet in the U-Boot README we find the statement (note - for the purpose
of my discussion here, bootp and dhcp are equivalent commands; also,
rarpboot is not included in the BeagleBone executable)
"The following environment variables may be used and automatically
updated by the network boot commands ("bootp" and "rarpboot"),
depending the information provided by your boot server:
bootfile - see above
dnsip - IP address of your Domain Name Server
dnsip2 - IP address of your secondary Domain Name Server
gatewayip - IP address of the Gateway (Router) to use
hostname - Target hostname
ipaddr - see above
netmask - Subnet Mask
rootpath - Pathname of the root filesystem on the NFS server
serverip - see above"
So what's up with that?
3. It turns out my ISP DHCP server is perfectly happy to dish out all
the necessary parameters including those I defined as options in my
dhcpd.conf.
Indeed, running dhcpdump confirms that my server is telling the kernel
everything needed when it exercises the ip=dhcp boot argument, but it's
not telling U-Boot. Why? Because U-Boot is explicitly telling the DHCP
server it wants only certain parameters and the server obliges (look at
the DHCPREQUEST and DHCPREPLY exchanges via dhcpdump).
So here we have the perfect stand off. U-Boot can use the needed
parameters if it gets them and will parse them if sent, but they aren't
sent because it doesn't ask for them.
4. It turns out the ISC DHCP server has a configuration parameter
available that can force the return of stipulated options whether they
are asked for or not. Here's the description from dhcpd-options(5)
option dhcp-parameter-request-list uint16;
This option, when sent by the client, specifies which options the client
wishes the server to return. Normally, in the ISC DHCP client, this is
done using the request statement. If this option is not specified by the
client, the DHCP server will normally return every option that is valid
in scope and that fits into the reply. When this option is specified on
the server, the server returns the specified options. This can be used
to force a client to take options that it hasn't requested, and it can
also be used to tailor the response of the DHCP server for clients that
may need a more limited set of options than those the server would
normally return.
And, of course, U-Boot is stupidly specifying options in its request
statement. As I read the above, if it specified nothing, it would
automatically get everything!?!
5. My no-programming-required workaround to our problem is to add the
following line to my dhcpd.conf stanza for the BeagleBone and restart
the server:
option dhcp-parameter-request-list 1,3,6,12,15,17;
These integers are the IANA-defined tags for (1) subnet mask, (3)
router, e.g., gateway ip, (6) domain (dns) server, (12) hostname, (16)
swap server, (17) rootpath.
This list is overkill on several accounts---several are already sent by
default and some aren't used (yet) but I see them being asked for by the
kernel. I really only want 12 and 17 but this list works for me. It
could do with some refinement.
Once the server is restarted, you can boot the BeagleBone to the U-Boot
command line prompt and invoke dhcp while using dhcpdump to see the
change in the DHCPREPLY. Once dhcp is invoked you can see the additional
environment variables hostname and rootpath have been set because U-Boot
parses them when it gets them.
6. Now using needed environment variables provisioned by the dhcp
command, the relevant U-Boot command line becomes
# setenv bootargs console=${console} noinitrd rw debug --no-log
root=/dev/nfs nfsroot=${rootpath}
ip=${ipaddr}:${serverip}:${gatewayip}:${netmask}:${hostname}:eth0:off
Which is as general as Michael's original uEnv.txt was intended to be.
Full disclosure: this works fine for me from the command line---my BBone
has been up since last night---but I don't have time now to confirm a
cold boot using a new uEnv.txt file. I leave the exercise to interested
parties.
Regards,
Kent
PS - it's entirely possible niggly errors slipped in here---I'm in a big
rush not to mentioned stressed. I apologize if I missed them in
proofreading, but it's this memory core-dump or nothing at all.
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnnow-d2d
_______________________________________________
Emc-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/emc-developers
