<feed xmlns='http://www.w3.org/2005/Atom'>
<title>buildroot/arch/Config.in, branch 2017.02</title>
<subtitle>OpenPOWER buildroot sources</subtitle>
<id>https://git.raptorcs.com/git/buildroot/atom?h=2017.02</id>
<link rel='self' href='https://git.raptorcs.com/git/buildroot/atom?h=2017.02'/>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/'/>
<updated>2017-01-25T21:53:53+00:00</updated>
<entry>
<title>arch: add OpenRISC architecture support</title>
<updated>2017-01-25T21:53:53+00:00</updated>
<author>
<name>Waldemar Brodkorb</name>
<email>wbx@openadk.org</email>
</author>
<published>2017-01-25T06:35:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=a818e29e76d9a083877094ed7bb3e9cfd31f3a46'/>
<id>urn:sha1:a818e29e76d9a083877094ed7bb3e9cfd31f3a46</id>
<content type='text'>
Add support for OpenRISC. See here for more details about
OpenRISC http://openrisc.io.

All buildroot included upstream binutils versions are supported.
Gcc support is not upstream, to be able to enable musl C library
support later, we use the branch with musl support.
At the moment it is possible to build a musl based toolchain,
but bootup in Qemu fails.

Gdb is only working to debug bare-metal code, there is no support
for gdbserver/gdb on Linux, yet.

[Peter: drop ?= for GCC_SOURCE]
Signed-off-by: Waldemar Brodkorb &lt;wbx@openadk.org&gt;
Tested-by: Romain Naour &lt;romain.naour@gmail.com&gt;
Signed-off-by: Peter Korsgaard &lt;peter@korsgaard.com&gt;
</content>
</entry>
<entry>
<title>arch: merge Config.in.aarch64 into Config.in.arm</title>
<updated>2016-12-05T22:07:05+00:00</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2016-11-30T21:12:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=8b7d8b4a4e41acadde27b12191ca6cb0ebd62b33'/>
<id>urn:sha1:8b7d8b4a4e41acadde27b12191ca6cb0ebd62b33</id>
<content type='text'>
The 64 bits ARM processors are capable of running 32 bits ARM code, and
some platforms are indeed using this capability. Due to this, if we were
to keep the separation between Config.in.aarch64 and Config.in.arm, we
would have to duplicate the definition of all 64-bits capable ARM cores
into both files.

Instead of going down this route, let's take the same route as the x86
one: a single Config.in.x86 file, used for both x86 32 bits and x86 64
bits, with the appropriate logic to only show the relevant cores
depending on which architecture is selected.

In order to do this, we:

 - Make the "ARM instruction set" choice only visible on ARM 32 bits,
   since we currently don't support ARM vs. Thumb on AArch64.

 - Add the relevant values for the BR2_ARCH option.

 - Add the relevant values for the BR2_ENDIAN option.

 - Make the "aapcs-linux" BR2_GCC_TARGET_ABI value only used on ARM 32
   bits, since this ABI doesn't mean anything on AArch64.

 - Make the BR2_GCC_TARGET_FPU option depends on ARM 32 bits, since
   there is no -mfpu option on AArch64.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Signed-off-by: Yann E. MORIN &lt;yann.morin.1998@free.fr&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>arch: remove support for sh64</title>
<updated>2016-09-08T20:15:15+00:00</updated>
<author>
<name>Gustavo Zacarias</name>
<email>gustavo@zacarias.com.ar</email>
</author>
<published>2016-09-08T18:38:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=4338a319b72570e433fd7484f8a95e1e0e978941'/>
<id>urn:sha1:4338a319b72570e433fd7484f8a95e1e0e978941</id>
<content type='text'>
It's been deprecated for quite some time now.

Signed-off-by: Gustavo Zacarias &lt;gustavo@zacarias.com.ar&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>m68k: disable BR2_BINFMT_FLAT_SEP_DATA for coldfire</title>
<updated>2016-08-22T22:08:13+00:00</updated>
<author>
<name>Waldemar Brodkorb</name>
<email>wbx@openadk.org</email>
</author>
<published>2016-08-21T20:40:29+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=446177237c98e5f222571f771b8c4dc5c99afb27'/>
<id>urn:sha1:446177237c98e5f222571f771b8c4dc5c99afb27</id>
<content type='text'>
BR2_BINFMT_FLAT_SEP_DATA can be used to create XIP userland and works fine
for m68k. Unfortunately a lot of basic packages as pcre are not compileable
because of a CPU or hardware limitation. The reason for failing are very
big functions used in the libraries or application code.

Typical errors are:

Fatal error: Tried to convert PC relative branch to absolute jump
or
error: value -yyyyy out of range

Add kernel patch from 4ec5542679264bc06a0356ef92f06ad7a0abe06d to make
BR2_BINFMT_FLAT_ONE compiled firmware work fine.

Fixes:
  http://autobuild.buildroot.net/results/20b/20b1586757450d6aad8583ad7a787a7ca11acef1/
  http://autobuild.buildroot.net/results/d31/d311955ada1ffcd7f69e82965c8fe33eabe488cd/

Signed-off-by: Waldemar Brodkorb &lt;wbx@openadk.org&gt;
[Thomas: add comment in Config.in file about sep-data existing on m68k,
but being disabled due to build issues with numerous packages.]
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>m68k: flat one memory region works with small kernel patch</title>
<updated>2016-08-22T22:05:37+00:00</updated>
<author>
<name>Waldemar Brodkorb</name>
<email>wbx@openadk.org</email>
</author>
<published>2016-08-17T06:37:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=f9aee4b5819809b18b51189f3593c074af58fc3b'/>
<id>urn:sha1:f9aee4b5819809b18b51189f3593c074af58fc3b</id>
<content type='text'>
Greg Ungerer fixed recently a bug in the Linux kernel, which
allows to use one memory region again.

Signed-off-by: Waldemar Brodkorb &lt;wbx@openadk.org&gt;
[Thomas: cherry-picked from next to master, in order to be able to use
BR2_BINFMT_FLAT_ONE by default on m68k, since BR2_BINFMT_FLAT_SEP_DATA
causes too much problems.]
Signed-off-by: Peter Korsgaard &lt;peter@korsgaard.com&gt;
</content>
</entry>
<entry>
<title>arch: define dependencies for the binfmt flat formats</title>
<updated>2016-07-05T07:48:19+00:00</updated>
<author>
<name>Waldemar Brodkorb</name>
<email>wbx@openadk.org</email>
</author>
<published>2016-07-04T18:51:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=49d97993d83f92bb975110a7ff49ea75a84ee2c2'/>
<id>urn:sha1:49d97993d83f92bb975110a7ff49ea75a84ee2c2</id>
<content type='text'>
The situation looks like following for elf2flt and binfmt FLAT:

 * Only gcc for bfin/m68k implements
   -msep-data (BR2_BINFMT_FLAT_SEP_DATA) and
   -mid-shared-library (BR2_BINFMT_FLAT_SHARED), so the corresponding
   options are made only visible on those architectures.

 * When the default of BR2_BINFMT_FLAT_ONE is used on m68k, broken
   binaries are produced, which mainly end up in SIGILL, so do not use
   it for m68k.

Signed-off-by: Waldemar Brodkorb &lt;wbx@openadk.org&gt;
[Thomas:
 - also add the dependencies on m68k/bfin to BR2_BINFMT_FLAT_SHARED
 - rework commit log.]
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>toolchain: add coldfire support</title>
<updated>2016-04-30T16:50:46+00:00</updated>
<author>
<name>Waldemar Brodkorb</name>
<email>wbx@openadk.org</email>
</author>
<published>2016-04-29T17:51:23+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=015322fccb0b785af3f7dd62618aa717f8aca064'/>
<id>urn:sha1:015322fccb0b785af3f7dd62618aa717f8aca064</id>
<content type='text'>
Add support for m68k/coldfire. A gcc patch is required
to avoid gcc ICE.

Signed-off-by: Waldemar Brodkorb &lt;wbx@openadk.org&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>arch/m68k: re-enable the architecture</title>
<updated>2016-03-20T14:28:44+00:00</updated>
<author>
<name>Waldemar Brodkorb</name>
<email>wbx@openadk.org</email>
</author>
<published>2016-03-19T19:04:10+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=7ea0f64dc33a31d7a8a70594babd822db8e04188'/>
<id>urn:sha1:7ea0f64dc33a31d7a8a70594babd822db8e04188</id>
<content type='text'>
This allows to build a m68k toolchain with uClibc.

Signed-off-by: Waldemar Brodkorb &lt;wbx@openadk.org&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
<entry>
<title>arch: remove BR2_ARCH_HAS_ATOMICS option</title>
<updated>2016-02-06T10:16:00+00:00</updated>
<author>
<name>Thomas Petazzoni</name>
<email>thomas.petazzoni@free-electrons.com</email>
</author>
<published>2016-02-02T15:31:32+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=4a3f597a0ea3392bbd1063c40291743955309472'/>
<id>urn:sha1:4a3f597a0ea3392bbd1063c40291743955309472</id>
<content type='text'>
Now that BR2_ARCH_HAS_ATOMICS is no longer used anywhere, we can
remove it from arch/Config.in*, as well as from the documentation.

Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
Acked-by: "Yann E. MORIN" &lt;yann.morin.1998@free.fr&gt;
</content>
</entry>
<entry>
<title>toolchain: add sparc64 architecture support</title>
<updated>2015-10-10T10:51:45+00:00</updated>
<author>
<name>Waldemar Brodkorb</name>
<email>wbx@openadk.org</email>
</author>
<published>2015-08-29T07:57:33+00:00</published>
<link rel='alternate' type='text/html' href='https://git.raptorcs.com/git/buildroot/commit/?id=4a92f6754a39d8dc22a8285fef36b0b58619cb24'/>
<id>urn:sha1:4a92f6754a39d8dc22a8285fef36b0b58619cb24</id>
<content type='text'>
Introduce sparc64 architecture to buildroot.

Signed-off-by: Waldemar Brodkorb &lt;wbx@openadk.org&gt;
Acked-by: Gustavo Zacarias &lt;gustavo@zacarias.com.ar&gt;
Tested-by: Gustavo Zacarias &lt;gustavo@zacarias.com.ar&gt;
Signed-off-by: Thomas Petazzoni &lt;thomas.petazzoni@free-electrons.com&gt;
</content>
</entry>
</feed>
