QuantaMesh 5000 Series T5016-LB8D

Specification
================================================================================
 - A powerful Top-of-Rack Switch for Cloud Datacenters
 - 16 40G QSFP+ ports in 1RU
 - 1 RJ-45 out-of-band management port (10/100/1000)
 - 1 RJ-45 console port

How to compile ONIE
================================================================================
  $ cd machine/quanta/quanta_lb8d
  $ ./build.sh all

How to compile demo installer.
================================================================================
  $ cd machine/quanta/quanta_lb8d
  $ ./build.sh demo

How to compile html and pdf documents.
================================================================================
  $ cd machine/quanta/quanta_lb8d
  $ ./build.sh docs

For further information, please take a look at ``machine/quanta/quanta_lb8d/INSTALL``

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
Update onie-server.py

Fixed typo on line 94

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
x86 exec_installer: Fill serial number to HTTP headers

In powerpc platforms, the serial number is passed to kernel by
``bootargs`` from u-boot.  But it is not in x86 platforms.  It
makes wget send an empty serial number field as part of the HTTP
request headers during doing HTTP discover.

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
exec_installer: Check if image format is suitable for current boot reason

ONIE updater image has 'ONIE-UPDATER-COOKIE' which is used to
distinguish from NOS installer image.  Updater shall run in either
'update', 'embed', or 'rescue' mode.  Installer shall run in either
'install' or 'rescue' mode.  And both kinds of image shall not run
in uninstall mode.

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
Disallow install_url or update_url to run at improper situation

install_url (onie-nos-install) is allowed to execute at the situation
with boot reason: install or rescue.  update_url (onie-self-update)
is allowed to execute at the situation with boot reason: update, embed,
or resuce.

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
Disallow uninstaller to run at improper situation

uninstaller (onie-uninstaller) is only allowed to execute at the
situation with boot reason: uninstall or rescue.

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
Accton powerpc platforms: Adjust u-boot boot delay to 10secs

The platforms are including:
- AS5710_54X
- AS6700_32X
- AS6701_32X
- AS6710_32X
- AS7700_32X

u-boot boot delay in these platforms were not consistent in the
past.  We decided to follow ONIE's original design recently.  So
that these boot delay patches in machines are removed now.

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
Accton platforms: Add context of installing u-boot in INSTALL

The platforms are including:
- as4600_54t
- as5600_52x
- as5610_52x
- as5710_54x
- as6700_32x
- as6701_32x
- as6710_32x
- as7700_32x

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
crosstools-ng: back port complib/ppl-0.11.2 with gcc 4.9 patch

This patch back ports an upstream crosstools-ng patch that fixes a
problem building ppl 0.11.2 with gcc 4.9.

See the patch for details about the issue and corrective action.

This patch fixes #104

Testing Done:

Compiled and tested toolchain using Debian stable(wheezy)  (gcc-4.7.2)
Compiled and tested toolchain using Debian testing(jessie) (gcc-4.9.1)
docs: update github pull request instructions

Include additional details about using a topic branch when making a
pull request, instead of using the master branch.
docs: update FAQ regarding ONIE-izing old hardware

Update the FAQ for the commonly asked question: 

  I have a switch from vendor XYZ that does not have ONIE installed.
  Can I install ONIE on it myself?

Short answer: no
Simplier way of building ONIE

Simplier way of building ONIE
Examples:

To run it, you can be either in its directory (ONIE/contrib/autobuild)
or in the ONIE directory.
$ ./build-onie.py -h
usage: build-onie.py [-h] [-l] [-b TARGET] [-n] [-m ARGS]

Build ONIE

optional arguments:
  -h, --help            show this help message and exit
  -l, --list            list all vendors and machines
  -b TARGET, --build TARGET
                        Vendor or Machine to compile
  -n, --dry-run         perform a dry run, do not execute
  -m ARGS, --make-args ARGS
                        additional args to be passed to make

Using the list (-l or --list), you will see all possible vendors and
machines.
$ ./build-onie.py -l
UNKNOWN
        fsl_p2020rdbpca
        im_n29xx_t40n
        kvm_x86_64

accton
        accton_as4600_54t
        accton_as5600_52x
        accton_as5610_52x
        accton_as5710_54x
        accton_as5712_54x
        accton_as6700_32x
        accton_as6701_32x
        accton_as6710_32x
        accton_as6712_32x
        accton_as7700_32x
        accton_as7702_32x

alpha_networks
        alpha_networks_snq6070_320f
        alpha_networks_snq60a0_320f
        alpha_networks_snx6070_486f
        alpha_networks_snx60a0_486f

celestica
        cel_redstone_xp

dell
        dell_s4810_on_p2020
        dell_s6000_s1220

mellanox
        mlnx_x86

quanta
        quanta_lb8d
        quanta_lb9
        quanta_ly2
        quanta_ly3

Now, you can build any targets you want based on either the vendor or
machine names.

$ ./build-onie.py -b mlnx_x86
** Builds the mlnx_x86 machine under mellanox

$ ./build-onie.py -b accton
** Builds all machines under the accton vendor

$ ./build-onie.py -b quanta_lb9 -b cel_redstone_xp
** Builds both the quanta_lb9 and cel_redstone_xp machines

$ ./build-onie.py -b dell_s4810_on_p2020 -b alpha_networks
** Builds the dell_s4810_on_p2020 machine and all alpha_networks
machines

$ ./build-onie.py -b all
** Builds all machines and reference platforms

Update build-onie.

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
xtools: restart build on failure

Today the crosstools-ng build has the bad property that when
restarting a build after a failure the crosstool-ng system believes
the toolchain is built correctly.  This leads to all manner of
downstream build errors and confusion for developers who are trying to
make progress after a crosstool-ng failure.

This patch coaxes the xtools target into being "out of date" whenever
the crosstool-ng build fails.  This is accomplished by removing the
$(XTOOLS_BUILD_DIR)/.config.2 file, which the crosstool-ng system uses
as a prerequisite for building, whenever the crosstool-ng build fails.

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>
x86: include the recovery ISO into the 'all' Makefile target

Reviewed By: Carlos Cardenas

When building the x86 based machine types it is often useful to have
the recovery ISO, though not strictly required all the time.

The build time of the recovery ISO is small compared to everything
else, so including it by default in the 'all' Makefile target has
little impact.

This patch adds building the recovery ISO to the 'all' Makefile target
for x86 machine.

Testing Done:

Compiled the kvm_x86_64 machine using the 'all' target.  Verified the
build was successful, the recovery ISO was created and nothing broke.

Compiled the dell/dell_s6000_s1220 machine using the 'all' target.
This machine is noteworthy because it's machine.make *already*
includes the building of the pxe-efi64 recovery image, which has the
recovery ISO as a dependency.  Verified the build was successful, the
recovery ISO was created and nothing broke.

Signed-off-by: Curt Brune <curt@cumulusnetworks.com>