Dbox2:CDK YADD Boot Procedure

edit

Development

• Allgemein
  • GDB Einrichten
  • Erstellen eines VMWare-Images
• Neutrino-HD-Entwicklung
  • NeutrinoHD Entwicklung
    • Entwicklungsumgebung einrichten
    • Minicom für serielle Schnittstelle benutzen
    • OPKG-SystemInstall
    • Commitmessages in GIT und SVN
• dbox2 Entwicklung
  • Create Images and Yadd's (english)
    • yBuild (english)
    • 3rdparty Tools (english)
  • Images und Yadd's erstellen (deutsch)
    • yBuild (deutsch)
    • Kernel 2.6 (deutsch)
    • Neutrino für Triple Dragon
    • 3rdparty Tools (deutsch)
  • Plugins
  • FAQ
  • CDK YADD Boot Procedure
  • CDK YADD Bootvorgang
  • Oldmake
    • Development Oldmake (INSTALL.en)
    • Image creation Oldmake (english)
    • 3rdparty Tools Oldmake (english)
    • Image erstellen Oldmake (deutsch)
    • 3rdparty Tools Oldmake (deutsch)
    • Dreambox (Oldmake-Basis)

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.

---

Grundlagen - Installation - Debug-Mode - Hardware - CDK/Development

LCars - Neutrino - Enigma - Plugins - Spiele - Software - Tools - Howto - FAQ - Images

Hauptseite - News - Alle Artikel - Bewertungen - Gewünschte Seiten - Index - Neue Artikel - Impressum - Team

Hilfeportal - Seite bearbeiten - Bilder - Links - Tabellen - Textgestaltung