summaryrefslogtreecommitdiff
path: root/en/preparing/bios-setup/arm.xml
blob: b35e479bb4d6ae8272cfe0945dd0f507f9e77410 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
<!-- retain these comments for translator revision tracking -->
<!-- $Id$ -->


  <sect2 arch="arm" id="arm-firmware-overview"><title>ARM firmware</title>

    <para>
      As already mentioned before, there is unfortunately no standard for
      system firmware on ARM systems.  Even the behaviour of different
      systems which use nominally the same firmware can be quite different. 
      This results from the fact that a large part of the devices using the
      ARM architecture are embedded systems, for which the manufacturers
      usually build heavily customized firmware versions and include
      device-specific patches.  Unfortunately the manufacturers often do not
      submit their changes and extensions back to the mainline firmware
      developers, so their changes are not integrated into newer versions of
      the original firmware.
    </para>
    <para>
      As a result even newly sold systems often use a firmware that is based
      on a years-old manufacturer-modified version of a firmware whose
      mainline codebase has evolved a lot further in the meantime and offers
      additional features or shows different behaviour in certain aspects. 
      In addition to that, the naming of onboard devices is not consistent
      between different manufacturer-modified versions of the same firmware,
      therefore it is nearly impossible to provide usable
      product-independend instructions for ARM-based systems.
    </para>
  </sect2>

  <sect2 arch="armhf" id="armhf-uboot-images">
    <title>Debian-provided U-Boot (system firmware) images</title>
    <para>
      Debian provides U-Boot images for various armhf systems that can load
      their U-Boot from an SD card at &armmp-uboot-img;.  The U-Boot builds
      are offered in two formats: raw U-Boot components and a ready-made
      card image that can easily be written onto an SD card.  The raw U-Boot
      components are provided for advanced users; the generally recommended
      way is to use one of the ready-made SD card images.  They are named
      &lt;system-type&gt;.sdcard.img.gz and can be written to a card e.g. 
      with

      <informalexample><screen>zcat &lt;system-type&gt;.sdcard.img.gz > /dev/SD_CARD_DEVICE</screen></informalexample>
      
      As with all images, please be aware that writing the image to an SD
      card wipes all previous contents of the card!
    </para>
    <para>
      If Debian provides a U-Boot image for your system, it is recommended
      that you use this image instead of the vendor-provided U-Boot, as the
      version in Debian is usually newer and has more features.
    </para>
  </sect2>

  <sect2 arch="arm" id="uboot-macsetting">
    <title>Setting the ethernet MAC address in U-Boot</title>
    <para>
      The MAC address of every ethernet interface should normally be
      globally unique, and it technically has to be unique within its
      ethernet broadcast domain.  To achieve this, the manufacturer usually
      allocates a block of MAC addresses from a centrally-administered
      pool (for which a fee has to be paid) and preconfigures one of these
      addresses on each item sold.
    </para>
    <para>
      In the case of development boards, sometimes the manufacturer wants to
      avoid paying these fees and therefore provides no globally unique
      addresses.  In these cases the users themselves have to define MAC
      addresses for their systems.  When no MAC address is defined for an
      ethernet interface, some network drivers generate a random MAC address
      that can change on every boot, and if this happens, network access
      would be possible even when the user has not manually set an address,
      but e.g. assigning semi-static IP addresses by DHCP based on the MAC
      address of the requesting client would obviously not work reliably.
    </para>
    <para>
      To avoid conflicts with existing officially-assigned MAC addresses,
      there is an address pool which is reserved for so-called
      <quote>locally administered</quote> addresses. It is defined by
      the value of two specific bits in the first byte of the address (the
      article <quote>MAC address</quote> in the English language Wikipedia gives a 
      good explanation). In practice this means that e.g. any address starting
      with hexadecimal ca (such as ca:ff:ee:12:34:56) can be used as a locally
      administered address. 
    </para>
    <para>
      On systems using U-Boot as system firmware, the ethernet MAC address
      is placed in the <quote>ethaddr</quote> environment variable.
      It can be checked at the U-Boot command prompt with the command
      <quote>printenv ethaddr</quote> and can be set with the command
      <quote>setenv ethaddr ca:ff:ee:12:34:56</quote>.  After setting the value,
      the command <quote>saveenv</quote> makes the assignment permanent.
    </para>
  </sect2>

  <sect2 arch="arm" id="uboot-relocation-issues">
    <title>Kernel/Initrd/Device-Tree relocation issues in U-Boot</title>
    <para>
      On some systems with older U-Boot versions there can be problems with
      properly relocating the Linux kernel, the initial ramdisk and the
      device-tree blob in memory during the boot process.  In this case,
      U-Boot shows the message <quote>Starting kernel ...</quote>,
      but the system freezes
      afterwards without further output.  These issues have been solved with
      newer U-Boot versions from v2014.07 onwards.
    </para>
    <para>
      If the system has originally used a U-Boot version older than
      v2014.07 and has been upgraded to a newer version later, the problem
      might still occur even after upgrading U-Boot.  Upgrading U-Boot
      usually does not modify the existing U-Boot environment variables and
      the fix requires an additional environment variable (bootm_size) to be
      set, which U-Boot does automatically only on fresh installations
      without existing environment data.  It is possible to manually set
      bootm_size to the new U-Boot's default value by running the command
      <quote>env default bootm_size; saveenv</quote> at the U-Boot prompt.
    </para>
    <para>
      Another possibility to circumvent relocation-related problems is to
      run the command <quote>setenv fdt_high ffffffff; setenv initrd_high
      0xffffffff; saveenv</quote> at the U-Boot prompt to completely disable
      the relocation of the initial ramdisk and the device-tree blob.          
    </para>
  </sect2>