On ARM-based systems in most cases one of two formats for boot images is used: a) standard Linux zImage-format kernels (vmlinuz) in conjunction with standard Linux initial ramdisks (initrd.gz) or b) uImage-format kernels (uImage) in conjunction with corresponding initial ramdisks (uInitrd). uImage/uInitrd are image formats designed for the U-Boot firmware that is used on many ARM-based systems (mostly 32-bit ones). Older U-Boot versions can only boot files in uImage/uInitrd format, so these are often used on older armel systems. Newer U-Boot versions can - besides booting uImages/uInitrds - also boot standard Linux kernels and ramdisk images, but the command syntax to do that is slightly different from that for booting uImages. For systems using a multiplatform kernel, besides kernel and initial ramdisk a so-called device-tree file (or device-tree blob, dtb) is needed. It is specific to each supported system and contains a description of the particular hardware. The dtb should be supplied on the device by the firmware, but in practice a newer one often needs to be loaded. The netboot tarball (), and the installer SD-card images () use the (platform-specific) default console that is defined by U-Boot in the console variable. In most cases that is a serial console, so on those platforms you by default need a serial console cable to use the installer. On platforms which also support a video console, you can modify the U-Boot console variable accordingly if you would like the installer to start on the video console. The graphical installer is not enabled on the arm64 &d-i; images for stretch so the serial console is used. 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 to console=<device>,<speed> e.g. console=ttyAMA0,115200n8. When finished hit Control x to continue booting with new setting. 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 &url-juno-firmware; 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 &enterkey; will show no kernel output. Set the console to console=ttyAMA0,115200n8 (as described in ). Control x to boot should show you the &d-i; screens, and allow you to proceed with a standard 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 &d-i; 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 (). 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. &boot-installer-intro-net.xml; 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 dhcp 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 saveenv 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 ) or preseeding options (see and ) - 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. &debian; provides a pre-built tarball (&armmp-netboot-tarball;) that can simply be unpacked on your tftp server and contains all files necessary for netbooting. It also includes a boot script that automates all steps to load the installer. Modern U-Boot versions contain a tftp autoboot feature that becomes active if there is no bootable local storage device (MMC/SD, USB, IDE/SATA/SCSI) and then loads this boot script from the tftp server. Prerequisite for using this feature is that you have a dhcp server in your network which provides the client with the address of the tftp server. If you would like to trigger the tftp autoboot feature from the U-Boot commandline, you can use the follwing command: run bootcmd_dhcp To manually load the bootscript provided by the tarball, you can alternatively issue the following commands at the U-Boot prompt: setenv autoload no dhcp tftpboot ${scriptaddr} /debian-installer/armhf/tftpboot.scr source ${scriptaddr} &boot-installer-intro-usb.xml; Many modern U-Boot versions have USB support and allow booting from USB mass storage devices such as USB sticks. Unfortunately the exact steps required to do that can vary quite a bit from device to device. U-Boot v2014.10 has introduced a common commandline handling and autoboot framework. This allows building generic boot images that work on any system implementing this framework. The &d-i; supports installation from a USB stick on such systems, but unfortunately not all platforms have adopted this new framework yet. To build a bootable USB stick for installing &debian;, unpack the hd-media tarball (see ) onto a USB stick formatted with a filesystem supported by the U-Boot version on your device. For modern U-Boot versions, any of FAT16 / FAT32 / ext2 / ext3 / ext4 usually works. Then copy the ISO image file of the first &debian; installation CD or DVD onto the stick. The autoboot framework in modern U-Boot versions works similar to the boot ordering options in a PC BIOS/UEFI, i.e. it checks a list of possible boot devices for a valid boot image and starts the first one it finds. If there is no operating system installed, plugging in the USB stick and powering up the system should result in starting the installer. You can also initiate the USB-boot process any time from the U-Boot prompt by entering the run bootcmd_usb0 command. One problem that can come up when booting from a USB stick while using a serial console can be a console baudrate mismatch. If a console variable is defined in U-Boot, the &d-i; boot script automatically passes it to the kernel to set the primary console device and, if applicable, the console baudrate. Unfortunately the handling of the console variable varies from platform to platform - on some platforms, the console variable includes the baudrate (as in console=ttyS0,115200), while on other platforms the console variable contains only the device (as in console=ttyS0). The latter case leads to a garbled console output when the default baudrate differs between U-Boot and the kernel. Modern U-Boot versions often use 115200 baud while the kernel still defaults to the traditional 9600 baud. If this happens, you should manually set the console variable to contain the correct baudrate for your system and then start the installer with the run bootcmd_usb0 command. For a number of systems, Debian provides SD card images that contain both U-Boot and the &d-i;. These images are provided in two variants - one for downloading the software packages over the network (available at &armmp-netboot-sd-img;) and one for offline installations using a Debian CD/DVD (available at &armmp-hd-media-sd-img;). To save space and network bandwidth, the images consist of two parts - a system-dependent part named firmware.<system-type>.img.gz, and a system-independent part named partition.img.gz. To create a complete image from the two parts on Linux systems, you can use zcat as follows: zcat firmware.<system-type>.img.gz partition.img.gz > complete_image.img On Windows systems, you have to first decompress the two parts separately, which can be done e.g. by using 7-Zip, and then concatenate the decompressed parts together by running the command copy /b firmware.<system-type>.img + partition.img complete_image.img in a Windows CMD.exe window. Write the resulting image onto an SD card, e.g. by running the following command on a Linux system: cat complete_image.img > /dev/SD_CARD_DEVICE After plugging the SD card into the target system and powering the system up, the installer is loaded from the SD card. If you use the hd-media variant for offline installations, you must provide the installer with access to the first &debian; CD/DVD on a separate medium, which can e.g. be a CD/DVD ISO image on a USB stick. When you come to the partitioning step in the installer (see ), you can delete or replace any previous partitions on the card. Once the installer is started, it runs completely in the system's main memory and does not need to access the SD card anymore, so you can use the full card for installing &debian;. The easiest way to create a proper partition layout on the SD card is to let the installer automatically create one for you (see ).