Go to file
Peter Korsgaard 80e4060908 arch/Config.in.x86: drop BR2_x86_generic
The fuzzy generic x86 variant doesn't make much sense in the context of
Buildroot, and the recent change to use -march instead of -mtune broke it.

From the GCC manual:

https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/i386-and-x86-64-Options.html#i386-and-x86-64-Options:

-mtune=cpu-type
    Tune to cpu-type everything applicable about the generated code,
    except for the ABI and the set of available instructions. While
    picking a specific cpu-type schedules things appropriately for that
    particular chip, the compiler does not generate any code that cannot
    run on the default machine type unless you use a -march=cpu-type
    option. For example, if GCC is configured for i686-pc-linux-gnu then
    -mtune=pentium4 generates code that is tuned for Pentium 4 but still
    runs on i686 machines.

    The choices for cpu-type are the same as for -march. In addition,
    -mtune supports 2 extra choices for cpu-type:

    ‘generic’
        Produce code optimized for the most common IA32/AMD64/EM64T
        processors. If you know the CPU on which your code will run,
        then you should use the corresponding -mtune or -march option
        instead of -mtune=generic. But, if you do not know exactly what
        CPU users of your application will have, then you should use
        this option.

        As new processors are deployed in the marketplace, the behavior
        of this option will change. Therefore, if you upgrade to a newer
        version of GCC, code generation controlled by this option will
        change to reflect the processors that are most common at the
        time that version of GCC is released.

        There is no -march=generic option because -march indicates the
        instruction set the compiler can use, and there is no generic
        instruction set applicable to all processors. In contrast,
        -mtune indicates the processor (or, in this case, collection of
        processors) for which the code is optimized.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2014-11-07 19:51:06 +01:00
arch arch/Config.in.x86: drop BR2_x86_generic 2014-11-07 19:51:06 +01:00
board board: add support for Minnowboard MAX 2014-11-02 22:04:22 +01:00
boot barebox: bump to version 2014.11.0 2014-11-06 09:13:28 +01:00
configs board: add support for Minnowboard MAX 2014-11-02 22:04:22 +01:00
docs docs: responsive web design website 2014-11-01 14:37:51 +01:00
fs
linux
package bash: switch to release tarball 2014-11-07 19:32:00 +01:00
support
system
toolchain toolchain-external: do not use BR2_GCC_TARGET_TUNE anymore 2014-11-07 00:15:56 +01:00
.defconfig
.gitignore
CHANGES
Config.in
Config.in.legacy
COPYING
Makefile
Makefile.legacy
README

To build and use the buildroot stuff, do the following:

1) run 'make menuconfig'
2) select the packages you wish to compile
3) run 'make'
4) wait while it compiles
5) Use your shiny new root filesystem. Depending on which sort of
    root filesystem you selected, you may want to loop mount it,
    chroot into it, nfs mount it on your target device, burn it
    to flash, or whatever is appropriate for your target system.

You do not need to be root to build or run buildroot.  Have fun!

Offline build:
==============

In order to do an offline-build (not connected to the net), fetch all
selected source by issuing a
$ make source

before you disconnect.
If your build-host is never connected, then you have to copy buildroot
and your toplevel .config to a machine that has an internet-connection
and issue "make source" there, then copy the content of your dl/ dir to
the build-host.

Building out-of-tree:
=====================

Buildroot supports building out of tree with a syntax similar
to the Linux kernel. To use it, add O=<directory> to the
make command line, E.G.:

$ make O=/tmp/build

And all the output files (including .config) will be located under /tmp/build.

More finegrained configuration:
===============================

You can specify a config-file for uClibc:
$ make UCLIBC_CONFIG_FILE=/my/uClibc.config

And you can specify a config-file for busybox:
$ make BUSYBOX_CONFIG_FILE=/my/busybox.config

To use a non-standard host-compiler (if you do not have 'gcc'),
make sure that the compiler is in your PATH and that the library paths are
setup properly, if your compiler is built dynamically:
$ make HOSTCC=gcc-4.3.orig HOSTCXX=gcc-4.3-mine

Depending on your configuration, there are some targets you can use to
use menuconfig of certain packages. This includes:
$ make HOSTCC=gcc-4.3 linux-menuconfig
$ make HOSTCC=gcc-4.3 uclibc-menuconfig
$ make HOSTCC=gcc-4.3 busybox-menuconfig

Please feed suggestions, bug reports, insults, and bribes back to the
buildroot mailing list: buildroot@buildroot.org