Add instructions for arm64 machines: Juno, Mustang.

Restrict armel/armhf info to those manual arches
Rewrite 'graphics card' section to 'graphics hardware' to cover arm and x86

4 files changed, 143 insertions, 27 deletions

diff --git a/en/boot-installer/arm.xml b/en/boot-installer/arm.xml
index 1c0152ce9..c9369470c 100644
--- a/en/boot-installer/arm.xml
+++ b/en/boot-installer/arm.xml
@@ -1,7 +1,8 @@
 <!-- retain these comments for translator revision tracking -->
 <!-- $Id$ -->
 
-  <sect2 arch="arm" id="boot-image-formats">
+
+  <sect2 arch="armhf;armel" id="boot-image-formats">
     <title>Boot image formats</title>
     <para>
       On ARM-based systems in most cases one of two formats for boot images
@@ -13,7 +14,7 @@
     </para>
     <para>
       uImage/uInitrd are image formats designed for the U-Boot firmware that
-      is used on many ARM-based systems. Older U-Boot versions can only
+      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,
@@ -24,20 +25,22 @@
       For systems using a multiplatform kernel, besides kernel and initial
       ramdisk a so-called device-tree file (or device-tree blob,
       <quote>dtb</quote>) is needed. It is specific to each supported system
-      and contains a description of the particular hardware.
+      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.
     </para>
   </sect2>
 
   <sect2 arch="armhf" id="armhf-console-setup">
     <title>Console configuration</title>
     <para>
-      The netboot tarball (<xref linkend="boot-armhf-netboot.tar.gz"/>), the
-      hd-media tarball (<xref linkend="boot-hd-media"/>) and the installer
-      SD-card images (<xref linkend="boot-installer-sd-image"/>) use the
-      (platform-specific) default console that is defined by U-Boot in the
-      <quote>console</quote> 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.
+      The netboot tarball (<xref
+      linkend="boot-armhf-netboot.tar.gz"/>), and the installer
+      SD-card images (<xref linkend="boot-installer-sd-image"/>) use
+      the (platform-specific) default console that is defined by
+      U-Boot in the <quote>console</quote> 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.
     </para>
     <para>
       On platforms which also support a video console, you can modify the
@@ -46,6 +49,86 @@
     </para>
   </sect2>
 
+  <sect2 arch="arm64" id="arm64-console-setup">
+    <title>Console configuration</title>
+    <para>
+      The graphical installer is not enabled on the arm64 &d-i; images
+      for jessie so the serial console is used. The console device
+      should be detected automatically from the firmware, but if it not then after
+      you boot linux from the GRUB menu you will see a 'Booting Linux'
+      message then nothing more.
+    </para>
+    <para>
+      If you hit this issue you will need to set a specific console config on the kernel command line.
+      Hit <userinput>e</userinput> for 'Edit Kernel command-line'
+      at the GRUB menu, and change
+      <informalexample><screen>--- quiet</screen></informalexample>
+      to
+      <informalexample><screen>console=&lt;device&gt;,&lt;speed&gt;</screen></informalexample>
+      e.g.
+      <informalexample><screen>console=ttyAMA0,115200n8</screen></informalexample>
+      When finished hit <keycombo><keycap>Control</keycap>
+<keycap>x</keycap></keycombo> to continue booting with new setting.
+    </para>
+  </sect2>
+
+  <sect2 arch="arm64" id="juno-installation">
+    <title>Juno Installation</title>
+    <para>
+      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 <ulink
+      url="&url-juno-firmware;">&url-juno-firmware;</ulink> after March
+      2015 tested OK. Consult Juno documentation on firmware updating.
+    </para>
+    <para>
+      Prepare a standard arm64 CD 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 D on the back. If you need networking (netboot
+      image) plug the ethernet cable into the socket on the front of
+      the machine.
+    </para>
+    <para>
+      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
+      return will show no kernel output. Set the console to  
+<informalexample><screen>console=ttyAMA0,115200n8</screen></informalexample>
+      as described in (<xref linkend="arm64-console-setup"/>). <keycombo><keycap>Control</keycap>
+<keycap>x</keycap></keycombo> to boot should show you the &d-i; screens,
+      and allow you to proceed with a standard installation.
+    </para>
+  </sect2>
+
+  <sect2 arch="arm64" id="apm-installation">
+    <title>Applied Micro Mustang Installation</title>
+    <para>
+      UEFI is available for this machine but it is normally shipped
+      with uboot so you will need to either install UEFI firmware
+      first then use standard boot/install methods, or use uboot boot
+      methods. Also USB is not supported in the jessie kernel so
+      installing from a USB-stick does not work. You must use a serial
+      console to control the installation because the graphical
+      installer is not enabled on the arm64 architecture.
+    </para>
+    <para>
+      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 (<xref linkend="boot-tftp-uboot"/>). After
+      installation, manual changes to boot from the installed image
+      are needed.
+    </para>
+    <para>
+      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
+      uboot commands to load and boot the kernel, dtb and initrd.
+     </para>
+  </sect2>
+
+
   <sect2 arch="arm" id="boot-tftp"><title>Booting by TFTP</title>
 
 &boot-installer-intro-net.xml;
@@ -180,7 +263,14 @@ source ${scriptaddr}
   </sect2> 
 
 
-  <sect2 arch="arm" id="boot-hd-media">
+  <sect2 condition="bootable-usb" id="usb-boot">
+  <title>Booting from USB Memory Stick with UEFI</title>
+
+&boot-installer-intro-usb.xml;
+
+  </sect2>
+
+  <sect2 arch="armel;armhf" id="boot-hd-media">
     <title>Booting from a USB stick in U-Boot</title>
     <para>
     
diff --git a/en/boot-installer/intro-usb.xml b/en/boot-installer/intro-usb.xml
index c4a75ffdc..243e7b927 100644
--- a/en/boot-installer/intro-usb.xml
+++ b/en/boot-installer/intro-usb.xml
@@ -8,6 +8,7 @@ route for installation. Assuming you have prepared everything from
 linkend="boot-usb-files"/>, 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. Here
-you can select various installer options, or just hit &enterkey;.
+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 &enterkey;.
 </para>
diff --git a/en/hardware/hardware-supported.xml b/en/hardware/hardware-supported.xml
index 2425ecc44..e7f8fb87e 100644
--- a/en/hardware/hardware-supported.xml
+++ b/en/hardware/hardware-supported.xml
@@ -345,22 +345,46 @@ section of the kernel config.</phrase>
 </para>
   </sect2>
 
-  <sect2 id="gfx" arch="not-s390"><title>Graphics Card Support</title>
+  <sect2 id="gfx" arch="not-s390"><title>Graphics Hardware Support</title>
+<para>  
+&debian;'s support for graphical interfaces is determined by the
+underlying support found in X.Org's X11 system, and the kernel. Basic
+framebuffer graphics is provided by the kernel, whilst desktop
+environments use X11. Whether advanced graphics card features such as
+3D-hardware acceleration or hardware-accelerated video are available,
+depends on the actual graphics hardware used in the system and in some
+cases on the installation of additional <quote>firmware</quote> images
+(see <xref linkend="hardware-firmware"/>).
+
+</para>
+
 <para arch="x86">
 
-&debian;'s support for graphical interfaces is determined by the
-underlying support found in X.Org's X11 system. On modern PCs,
-having a graphical display usually works out of the box. Whether
-advanced graphics card features such as 3D-hardware acceleration
-or hardware-accelerated video are available, depends on the 
-actual graphics hardware used in the system and in some cases
-on the installation of additional <quote>firmware</quote> images (see <xref
-linkend="hardware-firmware"/>). In very few cases there have
-been reports about hardware on which installation of additional graphics
-card firmware was required even for basic graphics support, but
-these have been rare exceptions.
-</para><para>
-Details on supported graphics cards and pointing devices can be found at
+On modern PCs, having a graphical display usually works out of the
+box.  In very few cases there have been reports about hardware on
+which installation of additional graphics card firmware was required
+even for basic graphics support, but these have been rare exceptions.
+For quite a lot of hardware, 3D acceleration also works well out of
+the box, but there is still some hardware that needs binary blobs to
+work well.
+</para>
+
+<para arch="arm">
+
+Nearly all ARM machines have the graphics hardware built-in, rather
+than being on a plug-in card. Some machines do have expansion slots
+which will take graphics cards, but that is a rarity. Hardware
+designed to be headless with no graphics at all is quite common.
+Whilst basic framebuffer video provided by the kernel should work on
+all devices that have graphics, fast 3D graphics invariably needs
+binary drivers to work. The situation is changing quickly but at
+the time of the &releasename; release free drivers for nouveau (Nvidia
+Tegra K1 SoC) and freedreno (Qualcomm Snapdragon SoCs) are available in
+the release. Other hardware needs non-free drivers from 3rd parties.
+
+</para>
+<para>
+Details on supported graphics hardware and pointing devices can be found at
 <ulink url="&url-xorg;"></ulink>.  &debian; &release; ships
 with X.Org version &x11ver;.
 
diff --git a/en/hardware/supported/arm.xml b/en/hardware/supported/arm.xml
index cdbc1b4ae..fef14d560 100644
--- a/en/hardware/supported/arm.xml
+++ b/en/hardware/supported/arm.xml
@@ -110,6 +110,7 @@ hardware. They are also common in the x86 PC world.
         <term>Applied Micro (APM) Mustang/X-Gene</term>
         <listitem>
           <para>
+ 
 	    The APM Mustang was the first Linux-capable ARMv8 system
 	    available. It uses the X-gene SoC, which has since also
 	    been used in other machines. It is an 8-core CPU, with