diff options
Diffstat (limited to 'de/preparing/bios-setup/arm.xml')
| -rw-r--r-- | de/preparing/bios-setup/arm.xml | 99 |
1 files changed, 99 insertions, 0 deletions
diff --git a/de/preparing/bios-setup/arm.xml b/de/preparing/bios-setup/arm.xml new file mode 100644 index 000000000..4ce39ea28 --- /dev/null +++ b/de/preparing/bios-setup/arm.xml @@ -0,0 +1,99 @@ +<!-- retain these comments for translator revision tracking --> +<!-- original version: 43641 untranslated --> + + + <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="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 "MAC address" 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 "Starting kernel ...", 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 + "env default bootm_size; saveenv" at the u-boot prompt. + </para> + <para> + Another possibility to circumvent relocation-related problems is to + run the command "setenv fdt_high ffffffff; setenv initrd_high + 0xffffffff; saveenv" at the u-boot prompt to completely disable + the relocation of the initial ramdisk and the device-tree blob. + </para> + </sect2> |