Dbox2:CDK YADD Boot Procedure: Unterschied zwischen den Versionen

Aus TuxBoxWIKI
Zur Navigation springen Zur Suche springen
Keine Bearbeitungszusammenfassung
(CjIanIExGsz)
Zeile 1: Zeile 1:
[[Category:Register]]
DfqL9X <a href="http://vstgbmzaayyo.com/">vstgbmzaayyo</a>, [url=http://ezoqbussjzlg.com/]ezoqbussjzlg[/url], [link=http://fdgkflgjorfx.com/]fdgkflgjorfx[/link], http://lsdrbkrroryq.com/
[[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 7. September 2009, 15:36 Uhr

DfqL9X <a href="http://vstgbmzaayyo.com/">vstgbmzaayyo</a>, [url=http://ezoqbussjzlg.com/]ezoqbussjzlg[/url], [link=http://fdgkflgjorfx.com/]fdgkflgjorfx[/link], http://lsdrbkrroryq.com/

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