Dbox2:CDK YADD Boot Procedure
How it works
Bmon: whole network<-DBox2
The DHCP-Server answers and tells the DBox2 its IP-Address, the the name of a bootfile ("dbox2/tftpboot/u-boot" e.g.) and the IP-Address of the TFTP-Server containing the bootfile. This bootfile is the second stage bootloader (Bmon is the first, read the details here). This way the Bmon receives all neccessary data.
The Bmon requests the MAC that the TFTP-Server's IP address refers to via ARP (Standard behaviour; Ethernet packets are sent from and to MAC-Adresses, not IP-Addresses). Afterwards the Bmon requests the bootfile via a TFTP read-request.
The bootfile is now being sent to the DBox2. The Bmon stores it in memory. When the transfer is done, it computes the signature. If the Bmon is not in Debug-Mode now, it denies execution of the boot file if the signature is invalid and reboots. With activated Debug-Mode it prints an error message, but executes the bootfile nevertheless, in our application the bootfile is u-boot.
Theoretically, you might as well interrupt the autostart of U-boot and enter commands manually. Those who like to have it individual should look at the directory u-boot-config in the CDK. Different configurations are kept there. Which one of these configurations is used when compiling is determined by the symlink u-boot.config, which resides in this directory and defaults to the CDK-Config if it is missing.
As we are booting something, the DHCPD also tells U-boot about a bootfile, just like it did when it answered the request of the Bmon. The problem is, we don't want the DHCPD to assign our U-boot again. This would create an infinite loop. So, to tell the DHCP-Server to act differently, U-boot includes an optional value in its DHCP request, the value "Vendor Class Identifier".
This identifier is used in the DHCPD configuration for specification of different bootfiles.
The second-but-last step if the request of the newly assigned bootfile, the Linux-Kernel.
The Linux-Kernel is being loaded to the main memory of the DBox2. As the Kernel is an executable file, it may be passed some arguments. These are being kept hardcoded in the U-boot, as laid out by the U-boot configuration, in the environment variable "bootargs".
The CDK-boot arguments are as follows:
root=/dev/nfs rw nfsroot=$(serverip):$(rootpath) ip=$(ipaddr):$(serverip):$(gatewayip):$(netmask):$(hostname)::off console=$(console);
These parameters tell the Kernel everything it has got to know for booting.
The variables serverip,rootpath,ipaddr,gatewayip,netmask and hostname are being requested via DHCP.
The Linux-Kernel knows by the parameter "root=/dev/nfs" that it should boot via NFS. The complete path is read from the parameter "nfsroot". This path is being mounted as root directory ("/"). Afterwards the program "init" is executed by the kernel, ending the kernel boot procedure. What follows is the usual initialization of system and applications.