5.1. Booting the Installer on 64-bit ARM

[Note] Note

For information on how to boot the graphical installer, see Section 5.1.6, “The Graphical Installer”.

5.1.1. Console configuration

The graphical installer is (experimentally) enabled on the arm64 debian-installer images, but on some devices you may still have to use the serial console. The console device should be detected automatically from the firmware, but if it is not then after you boot linux from the GRUB menu you will see a Booting Linux message, then nothing more.

If you hit this issue you will need to set a specific console config on the kernel command line. Hit e for Edit Kernel command-line at the GRUB menu, and change

--- quiet





. When finished hit Control+x to continue booting with new setting.

5.1.2. Juno Installation

Juno has UEFI so the install is straightforward. The most practical method is installing from USB stick. You need up to date firmware for USB-booting to work. Builds from http://releases.linaro.org/members/arm/platforms/latest/ after March 2015 tested OK. Consult Juno documentation on firmware updating.

Prepare a standard arm64 CD/DVD image on a USB stick. Insert it in one of the USB ports on the back. Plug a serial cable into the upper 9-pin serial port on the back. If you need networking (netboot image) plug the ethernet cable into the socket on the front of the machine.

Run a serial console at 115200, 8bit no parity, and boot the Juno. It should boot from the USB stick to a GRUB menu. The console config is not correctly detected on Juno so just hitting Enter will show no kernel output. Set the console to


(as described in Section 5.1.1, “Console configuration”). Control+x to boot should show you the debian-installer screens, and allow you to proceed with a standard installation.

5.1.3. Applied Micro Mustang Installation

UEFI is available for this machine but it is normally shipped with U-Boot so you will need to either install UEFI firmware first then use standard boot/install methods, or use U-Boot boot methods. You must use a serial console to control the installation because the graphical installer is not enabled on the arm64 architecture.

The recommended install method is to copy the debian-installer kernel and initrd onto the hard drive, using the openembedded system supplied with the machine, then boot from that to run the installer. Alternatively use TFTP to get the kernel/dtb/initrd copied over and booted (Section, “TFTP-booting in U-Boot”). After installation, manual changes to boot from the installed image are needed.

Run a serial console at 115200, 8bit no parity, and boot the machine. Reboot the machine and when you see Hit any key to stop autoboot: hit a key to get a Mustang# prompt. Then use U-Boot commands to load and boot the kernel, dtb and initrd.

5.1.4. Booting by TFTP

Booting from the network requires that you have a network connection and a TFTP network boot server (and probably also a DHCP, RARP, or BOOTP server for automatic network configuration).

The server-side setup to support network booting is described in Section 4.4, “Preparing Files for TFTP Net Booting”. TFTP-booting in U-Boot

Network booting on systems using the U-Boot firmware consists of three steps: a) configuring the network, b) loading the images (kernel/initial ramdisk/dtb) into memory and c) actually executing the previosly loaded code.

First you have to configure the network, either automatically via DHCP by running

setenv autoload no

or manually by setting several environment variables

setenv ipaddr <ip address of the client>
setenv netmask <netmask>
setenv serverip <ip address of the tftp server>
setenv dnsip <ip address of the nameserver>
setenv gatewayip <ip address of the default gateway>

If you prefer, you can make these settings permanent by running


Afterwards you need to load the images (kernel/initial ramdisk/dtb) into memory. This is done with the tftpboot command, which has to be provided with the address at which the image shall be stored in memory. Unfortunately the memory map can vary from system to system, so there is no general rule which addresses can be used for this.

On some systems, U-Boot predefines a set of environment variables with suitable load addresses: kernel_addr_r, ramdisk_addr_r and fdt_addr_r. You can check whether they are defined by running

printenv kernel_addr_r ramdisk_addr_r fdt_addr_r

If they are not defined, you have to check your system's documentation for appropriate values and set them manually. For systems based on Allwinner SunXi SOCs (e.g. the Allwinner A10, architecture name sun4i or the Allwinner A20, architecture name sun7i), you can e.g. use the following values:

setenv kernel_addr_r 0x46000000
setenv fdt_addr_r 0x47000000
setenv ramdisk_addr_r 0x48000000

When the load addresses are defined, you can load the images into memory from the previously defined tftp server with

tftpboot ${kernel_addr_r} <filename of the kernel image>
tftpboot ${fdt_addr_r} <filename of the dtb>
tftpboot ${ramdisk_addr_r} <filename of the initial ramdisk image>

The third part is setting the kernel commandline and actually executing the loaded code. U-Boot passes the content of the bootargs environment variable as commandline to the kernel, so any parameters for the kernel and the installer - such as the console device (see Section 5.3.1, “Boot console”) or preseeding options (see Section 5.3.2, “Debian Installer Parameters” and Appendix B, Automating the installation using preseeding) - can be set with a command like

setenv bootargs console=ttyS0,115200 rootwait panic=10

The exact command to execute the previously loaded code depends on the image format used. With uImage/uInitrd, the command is

bootm ${kernel_addr_r} ${ramdisk_addr_r} ${fdt_addr_r}

and with native Linux images it is

bootz ${kernel_addr_r} ${ramdisk_addr_r}:${filesize} ${fdt_addr_r}

Note: When booting standard linux images, it is important to load the initial ramdisk image after the kernel and the dtb as U-Boot sets the filesize variable to the size of the last file loaded and the bootz command requires the size of the ramdisk image to work correctly. In case of booting a platform-specific kernel, i.e. a kernel without device-tree, simply omit the ${fdt_addr_r} parameter.

5.1.5. Booting from USB Memory Stick with UEFI

If your computer will boot from USB, this will probably be the easiest route for installation. Assuming you have prepared everything from Section 3.6.1, “Boot Device Selection” and Section 4.3, “Preparing Files for USB Memory Stick Booting”, just plug your USB stick into some free USB connector and reboot the computer. The system should boot up, and unless you have used the flexible way to build the stick and not enabled it, you should be presented with a graphical boot menu (on hardware that supports it). Here you can select various installer options, or just hit Enter.

5.1.6. The Graphical Installer

The graphical version of the installer is only available for a limited number of architectures, including 64-bit ARM. The functionality of the graphical installer is essentially the same as that of the text-based installer as it basically uses the same programs, but with a different frontend.

Although the functionality is identical, the graphical installer still has a few significant advantages. The main advantage is that it supports more languages, namely those that use a character set that cannot be displayed with the text-based newt frontend. It also has a few usability advantages such as the option to use a mouse, and in some cases several questions can be displayed on a single screen.

Just as with the text-based installer it is possible to add boot parameters when starting the graphical installer.

[Note] Note

The graphical installer requires significantly more memory to run than the text-based installer: 640MB. If insufficient memory is available, it will automatically fall back to the text-based newt frontend.

If the amount of memory in your system is below 260MB, the graphical installer may fail to boot at all while booting the text-based installer would still work. Using the text-based installer is recommended for systems with little available memory.