Dbox2:CDK YADD Boot Procedure: Unterschied zwischen den Versionen

Aus TuxBoxWIKI
Wechseln zu: Navigation, Suche
(Work at home)
(Änderung 11743 von 173.22.106.92 (Diskussion) wurde rückgängig gemacht.)
Zeile 1: Zeile 1:
−
Work at home, work from home <a href=http://workathome397.vox.com/>work at home</a> job work from home work at home opportunity work at home moms? Job for work at home mom work at home business opportunity http://workathome397.vox.com
+
[[Category:Register]]
 +
[[Category:CDK]]
 +
[[Category:FAQ]]
 +
[[Category:English]]
 +
[[Category:Development]]
 +
[[Category:english]]
 +
{{Development_sidebar}}
 +
__TOC__
 +
{{Deutsch|CDK (YADD) Bootvorgang}}
 +
 
 +
 
 +
=General=
 +
==Prerequisites==
 +
There is a [[DHCP]]-, an [[NFS]]- and a [[TFTP]]-[[Server]] in the network, which of course have to be configured according to the tuxbox environment.
 +
 +
[[DHCP]] is the successor to [[BootP|BOOTP]], the ISC dhcpd on [[Linux]] also knows the bootstrap-protocol ([[BootP|BOOTP]]).
 +
 +
 
 +
=How it works=
 +
First the [[Bootloader#Bmon|Bmon]] is executed. It initializes the [[Hardware]] ([[CPU]], [[LCD]] etc.). After that, network communication follows.
 +
 
 +
 
 +
==Bmon==
 +
===Bmon: whole network<-DBox2===
 +
The [[Bootloader#Bmon|Bmon]] sends a [[BootP|BOOTP]] broadcast request.
 +
 +
 
 +
===Bmon: DHCP->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 [[Bootloader#Bmon|here]]). This way the [[Bootloader#Bmon|Bmon]] receives all neccessary data.  
 +
 +
 
 +
===Bmon: TFTP<-DBox2===
 +
The [[Bootloader#Bmon|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 [[Bootloader#Bmon|Bmon]] requests the bootfile via a [[TFTP]] read-request.
 +
 +
 
 +
===Bmon: TFTP->DBox2===
 +
The bootfile is now being sent to the [[DBox2]]. The [[Bootloader#Bmon|Bmon]] stores it in memory. When the transfer is done, it computes the signature. If the [[Bootloader#Bmon|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#U-Boot.2FPPCBoot|u-boot]].
 +
 +
 
 +
[[U-boot#U-Boot.2FPPCBoot|U-boot]] is much more sophisticated than the [[Bootloader#Bmon|Bmon]], but it knows nothing about what happened until now. It has no knowledge of IP addresses, so the [[DBox2]] does not have one anymore.
 +
 +
 
 +
One thing is important to note: [[U-boot#U-Boot.2FPPCBoot|U-boot]] executes the commands that were built into it when compiling. So The following is only valid for the [[CDK]] configuration.
 +
 +
 
 +
Theoretically, you might as well interrupt the autostart of [[U-boot#U-Boot.2FPPCBoot|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.
 +
 +
 
 +
==U-Boot==
 +
===U-boot: DHCP<-DBox2:===
 +
So [[U-boot#U-Boot.2FPPCBoot|U-boot]] knows the [[BootP|BOOTP]] protocol, but the [[DHCP]] protocol has more features and thus is being preferred. [[U-boot#U-Boot.2FPPCBoot|U-boot]] starts by asking for its [[IP-Address]] via a [[DHCP]] discover.
 +
 +
 
 +
===U-boot: DHCP->DBox2:===
 +
The [[DHCPD]] offers [[U-boot#U-Boot.2FPPCBoot|U-boot]] an [[IP-Address]], and because  [[U-boot#U-Boot.2FPPCBoot|U-boot]] is not bitchy, it accepts that.
 +
 
 +
 +
As we are booting something, the [[DHCPD]] also tells [[U-boot#U-Boot.2FPPCBoot|U-boot]] about a bootfile, just like it did when it answered the request of the [[Bootloader#Bmon|Bmon]]. The problem is, we don't want the [[DHCPD]] to assign our [[U-boot#U-Boot.2FPPCBoot|U-boot]] again. This would create an infinite loop. So, to tell the [[DHCP]]-[[Server]] to act differently, [[U-boot#U-Boot.2FPPCBoot|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 Windows-[[Bootmanager]] does not recognize this option, so it will always serve the [[U-boot#U-Boot.2FPPCBoot|U-boot]] as bootfile. That is why you need a special [[U-boot#U-Boot.2FPPCBoot|U-boot]] for use with the [[Bootmanager]].
 +
 +
 
 +
Next, [[U-boot#U-Boot.2FPPCBoot|U-boot]] tries to load the files "logo-lcd" and "logo-fb" via the [[TFTP]] protocol. This is used for displaying a boot logo and is not critical for booting.
 +
 +
 
 +
===U-boot: TFTP<-DBox2:===
 +
The second-but-last step if the request of the newly assigned bootfile, the  [[Linux-Kernel]].
 +
 +
 
 +
===U-boot: TFTP->DBox2:===
 +
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#U-Boot.2FPPCBoot|U-boot]], as laid out by the [[U-boot#U-Boot.2FPPCBoot|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]].
 +
 +
 
 +
Ultimately, the [[U-boot#U-Boot.2FPPCBoot|U-boot]] executes the command "bootm", which then starts the [[Linux-Kernel]] and passes its parameters in the environment variable "bootargs".
 +
 +
 
 +
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.
 +
 +
 
 +
Booting from [[Flash]] is quite similar, but the root path is not an [[NFS]] share, but an [[MTD]] device.
 +
 
 +
 
 +
 
 +
{{body}}

Version vom 22. September 2009, 17:02 Uhr

Flagge de.jpg Deutsch: CDK (YADD) Bootvorgang


General

Prerequisites

There is a DHCP-, an NFS- and a TFTP-Server in the network, which of course have to be configured according to the tuxbox environment.

DHCP is the successor to BOOTP, the ISC dhcpd on Linux also knows the bootstrap-protocol (BOOTP).


How it works

First the Bmon is executed. It initializes the Hardware (CPU, LCD etc.). After that, network communication follows.


Bmon

Bmon: whole network<-DBox2

The Bmon sends a BOOTP broadcast request.


Bmon: DHCP->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.


Bmon: TFTP<-DBox2

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.


Bmon: TFTP->DBox2

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.


U-boot is much more sophisticated than the Bmon, but it knows nothing about what happened until now. It has no knowledge of IP addresses, so the DBox2 does not have one anymore.


One thing is important to note: U-boot executes the commands that were built into it when compiling. So The following is only valid for the CDK configuration.


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.


U-Boot

U-boot: DHCP<-DBox2:

So U-boot knows the BOOTP protocol, but the DHCP protocol has more features and thus is being preferred. U-boot starts by asking for its IP-Address via a DHCP discover.


U-boot: DHCP->DBox2:

The DHCPD offers U-boot an IP-Address, and because U-boot is not bitchy, it accepts that.


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 Windows-Bootmanager does not recognize this option, so it will always serve the U-boot as bootfile. That is why you need a special U-boot for use with the Bootmanager.


Next, U-boot tries to load the files "logo-lcd" and "logo-fb" via the TFTP protocol. This is used for displaying a boot logo and is not critical for booting.


U-boot: TFTP<-DBox2:

The second-but-last step if the request of the newly assigned bootfile, the Linux-Kernel.


U-boot: TFTP->DBox2:

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.


Ultimately, the U-boot executes the command "bootm", which then starts the Linux-Kernel and passes its parameters in the environment variable "bootargs".


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.


Booting from Flash is quite similar, but the root path is not an NFS share, but an MTD device.



Abgerufen von „https://wiki.tuxbox-neutrino.org/w/index.php?title=Dbox2:CDK_YADD_Boot_Procedure&oldid=11744“