docs/avr/at90usb: Migrate README.txt

Migrated teensy 2.0 README.txt to RST format. Moved common tool-chain
information to the chip page and provided back-link.

Signed-off-by: Matteo Golin <matteo.golin@gmail.com>

Author: linguini1

Documentation/platforms/avr/at90usb/boards/micropendous3/index.rst

@@ -162,6 +162,11 @@ Then you can use FLIP to load code into FLASH (available at the Atmel Web Site).
 The DFU USB driver for the DFU bootload is available in the usb subdirectory in
 the FLIP installation location.
 
+Toolchains
+==========
+
+Read about the tool chains at :doc:`../../index`.
+
 Serial Console
 ==============
 
@@ -188,279 +193,9 @@ PIN SIGNAL                  BOARD CONNECTION
 28  (TXD1/INT3) PD3           J3-39 D3
 === ======================= =============================================
 
-Toolchains
-==========
-
-There are several toolchain options. However, testing has been performed using
-*only* the NuttX buildroot toolchain described below. Therefore, the NuttX
-buildroot toolchain is the recommended choice.
-
-The toolchain may be selected using the kconfig-mconf tool (via ``make
-menuconfig``), by editing the existing configuration file (``defconfig``), or by
-overriding the toolchain on the make commandline with
-``CONFIG_AVR_TOOLCHAIN=<toolchain>``.
-
-The valid values for ``<toolchain>`` are ``BUILDROOT``, ``CROSSPACK``,
-``LINUXGCC`` and ``WINAVR``.
-
-Buildroot
----------
-
-There is a DIY buildroot version for the AVR boards here:
-http://bitbucket.org/nuttx/buildroot/downloads/. See the following section for
-details on building this toolchain.
-
-Before building, make sure that the path to the new toolchain is included in
-your ``PATH`` environment variable.
-
-After configuring NuttX, make sure that ``CONFIG_AVR_BUILDROOT_TOOLCHAIN=y`` is
-set in your ``.config`` file.
-
-WinAVR
-------
-
-For Cygwin development environment on Windows machines, you can use WinAVR:
-http://sourceforge.net/projects/winavr/files/
-
-Before building, make sure that the path to the new toolchain is included in
-your ``PATH`` environment variable.
-
-After configuring NuttX, make sure that ``CONFIG_AVR_WINAVR_TOOLCHAIN=y`` is set
-in your ``.config`` file.
-
-.. warning::
-
-   There is an incompatible version of ``cygwin.dll`` in the ``WinAVR/bin``
-   directory! Make sure that the path to the correct ``cygwin.dll`` file
-   precedes the path to the WinAVR binaries!
-
-Linux
------
-
-For Linux, there are widely available avr-gcc packages.  On Ubuntu, use:
-sudo apt-get install gcc-avr gdb-avr avr-libc
-
-After configuring NuttX, make sure that CONFIG_AVR_LINUXGCC_TOOLCHAIN=y is set in your
-.config file.
-
-macOS
------
-
-For macOS, the CrossPack for AVR toolchain is available from:
-http://www.obdev.at/products/crosspack/index.html
-
-This toolchain is functionally equivalent to the Linux GCC toolchain.
-
-Windows Native Toolchains
-=========================
-
-The WinAVR toolchain is a Windows native toolchain. There are several
-limitations to using a Windows native toolchain in a Cygwin environment. The
-three biggest are:
-
-1. The Windows toolchain cannot follow Cygwin paths.  Path conversions are
-   performed automatically in the Cygwin makefiles using the ``cygpath`` utility
-   but you might easily find some new path problems.  If so, check out ``cygpath
-   -w``
-
-2. Windows toolchains cannot follow Cygwin symbolic links.  Many symbolic links
-   are used in NuttX (e.g., ``include/arch``).  The make system works around
-   these problems for the Windows tools by copying directories instead of
-   linking them.  But this can also cause some confusion for you:  For example,
-   you may edit a file in a "linked" directory and find that your changes had no
-   effect. That is because you are building the copy of the file in the "fake"
-   symbolic directory.  If you use a Windows toolchain, you should get in the
-   habit of making like this:
-
-   .. code:: console
-
-      $ make clean_context all
-
-   An alias in your ``.bashrc`` file might make that less painful.
-
-An additional issue with the WinAVR toolchain, in particular, is that it
-contains an incompatible version of the Cygwin DLL in its ``bin/`` directory.
-You must take care that the correct Cygwin DLL is used.
-
-NuttX buildroot toolchain
-=========================
-
-If NuttX buildroot toolchain source tarball cne can be downloaded from the NuttX
-Bitbucket download site (https://bitbucket.org/nuttx/nuttx/downloads/). This GNU
-toolchain builds and executes in the Linux or Cygwin environment.
-
-1. You must have already configured NuttX in ``<some-dir>/nuttx``.
-
-   .. code:: console
-
-      $ tools/configure.sh micropendous3:<sub-dir>
-
-   .. note::
-
-      You also must copy avr-libc header files into the NuttX include directory
-      with a command perhaps like:
-
-      .. code:: console
-
-         $ cp -a /cygdrive/c/WinAVR/include/avr include/.
-
-2. Download the latest buildroot package into ``<some-dir>``
-
-3. Unpack the buildroot tarball.  The resulting directory may have versioning
-   information on it like ``buildroot-x.y.z``.  If so, rename
-   ``<some-dir>/buildroot-x.y.z`` to ``<some-dir>/buildroot``.
-
-   .. code:: console
-
-      $ cd <some-dir>/buildroot
-      $ cp boards/avr-defconfig-4.5.2 .config
-      $ make oldconfig
-      $ make
-
-4. Make sure that the ``PATH`` variable includes the path to the newly built
-   binaries.
-
-See the file ``boards/README.txt`` in the buildroot source tree.That has more
-detailed PLUS some special instructions that you will need to follow if you are
-building a toolchain for Cygwin under Windows.
-
-avr-libc
-========
-
-Header Files
-------------
-
-In any case, header files from avr-libc are required:
-http://www.nongnu.org/avr-libc/. A snapshot of avr-lib is included in the WinAVR
-installation. For Linux development platforms, avr-libc package is readily
-available (and would be installed in the apt-get command shown above). But if
-you are using the NuttX buildroot configuration on Cygwin, then you will have to
-build get avr-libc from binaries.
-
-Header File Installation
-------------------------
-
-The NuttX build will required that the AVR header files be available via the
-NuttX include directory. This can be accomplished by either copying the
-avr-libc header files into the NuttX include directory:
-
-.. code:: console
-
-   $ cp -a <avr-libc-path>/include/avr <nuttx-path>/include/.
-
-Or simply using a symbolic link:
-
-.. code:: console
-
-   $ ln -s <avr-libc-path>/include/avr <nuttx-path>/include/.
-
-Build Notes
------------
-
-It may not be necessary to have a built version of avr-lib; only header files
-are required. But if you choose to use the optimized library functions of the
-floating point library, then you may have to build avr-lib from sources. Below
-are instructions for building avr-lib from fresh sources:
-
-1. Download the avr-libc package from
-   http://savannah.nongnu.org/projects/avr-libc/. I am using
-   avr-lib-1.7.1.tar.bz2
-
-2. Unpack the tarball and ``cd`` into it:
-
-   .. code:: console
-
-      $ tar jxf avr-lib-1.7.1.tar.bz2
-      $ cd avr-lib-1.7.1
-
-3. Configure avr-lib. Assuming that WinAVR is installed at the following
-   location:
-
-   .. code:: console
-
-      $ export PATH=/cygdrive/c/WinAVR/bin:$PATH
-      $ ./configure --build=`./config.guess` --host=avr
-
-   This takes a *long* time.
-
-4. Make avr-lib.
-
-   .. code:: console
-
-      $ make
-
-   This also takes a long time because it generates variants for nearly
-   all AVR chips.
-
-5. Install avr-lib.
-
-   .. code:: console
-
-      $ make install
-
 Micropendous 3 Configuration Options
 ====================================
 
-* ``CONFIG_ARCH``: Identifies the ``arch/`` subdirectory.  This should be set
-  to:
-
-  * ``CONFIG_ARCH=avr``
-
-* ``CONFIG_ARCH_family``: For use in C code:
-
-  * ``CONFIG_ARCH_AVR=y``
-
-* ``CONFIG_ARCH_architecture``: For use in C code:
-
-  * ``CONFIG_ARCH_CHIP_AT90USB=y``
-
-* ``CONFIG_ARCH_CHIP``: Identifies the ``arch/*/chip`` subdirectory
-
-  * ``CONFIG_ARCH_CHIP=at90usb``
-
-* ``CONFIG_ARCH_CHIP_name``: For use in C code to identify the exact chip. This
-  should be exactly one of:
-
-  * ``CONFIG_ARCH_CHIP_AT90USB646=y``
-  * ``CONFIG_ARCH_CHIP_AT90USB647=y``
-  * ``CONFIG_ARCH_CHIP_AT90USB1286=y``
-  * ``CONFIG_ARCH_CHIP_AT90USB1287=y``
-
-  Depending on which Micropendous3 version you have.
-
-* ``CONFIG_ARCH_BOARD``: Identifies the ``boards/`` subdirectory and hence, the
-  board that supports the particular chip or SoC.
-
-  * ``CONFIG_ARCH_BOARD=micropendous3``
-
-* ``CONFIG_ARCH_BOARD_name``: For use in C code
-
-  * ``CONFIG_ARCH_BOARD_MICROPENOUS3=y``
-
-* ``CONFIG_ARCH_LOOPSPERMSEC``: Must be calibrated for correct operation of
-  delay loops
-
-* ``CONFIG_ENDIAN_BIG``: define if big endian (default is little endian)
-
-* ``CONFIG_RAM_SIZE``: Describes the installed DRAM.  One of:
-
-  * ``CONFIG_RAM_SIZE=(4*1024)``: (4Kb)
-  * ``CONFIG_RAM_SIZE=(8*1024)``: (8Kb)
-
-* ``CONFIG_RAM_START``: The start address of installed SRAM
-
-  * ``CONFIG_RAM_START=0x800100``
-
-* ``CONFIG_ARCH_LEDS``: Use LEDs to show state. Unique to boards that have LEDs
-
-* ``CONFIG_ARCH_INTERRUPTSTACK``: This architecture supports an interrupt stack.
-  If defined, this symbol is the size of the interrupt stack in bytes.  If not
-  defined, the user task stacks will be used during interrupt handling.
-
-* ``CONFIG_ARCH_STACKDUMP``: Do stack dumps after assertions
-
-* ``CONFIG_ARCH_LEDS``:  Use LEDs to show state. Unique to board architecture.
-
 Individual subsystems can be enabled:
 
 * ``CONFIG_AVR_INT0=n``