OK linux-next/axs103_smp_defconfig/arcv2 Fri Sep 21, 17:35
http://kisskb.ellerman.id.au/kisskb/buildresult/13518766/
Commit: Add linux-next specific files for 20180921
46c163a036b41a29b0ec3c475bf97515d755ff41
Compiler: arc-linux-gcc.br_real (Buildroot 2016.11-git-00613-ge98b4dd
OK linux-next/axs101_defconfig/arcompact Fri Sep 21, 17:36
http://kisskb.ellerman.id.au/kisskb/buildresult/13518767/
Commit: Add linux-next specific files for 20180921
46c163a036b41a29b0ec3c475bf97515d755ff41
Compiler: arc-buildroot-linux-uclibc-gcc (Buildroot 2015.08.1) 4.8.4
OK linus/axs101_defconfig/arcompact Fri Sep 21, 20:21
http://kisskb.ellerman.id.au/kisskb/buildresult/13519039/
Commit: Merge tag 'drm-fixes-2018-09-21' of
git://anongit.freedesktop.org/drm/drm
a38fd7d808e6a9dcc8fac30fc870ccb88ce07221
Compiler: arc-buildroot-linux-uclibc-gcc (Buildro
OK linus/axs103_smp_defconfig/arcv2 Fri Sep 21, 20:21
http://kisskb.ellerman.id.au/kisskb/buildresult/13519038/
Commit: Merge tag 'drm-fixes-2018-09-21' of
git://anongit.freedesktop.org/drm/drm
a38fd7d808e6a9dcc8fac30fc870ccb88ce07221
Compiler: arc-linux-gcc.br_real (Buildroot 2016.1
I don't like accumulating pending patches for something as key as
binutils, are these actually working their way upstream now?
Ross
On Thu, 20 Sep 2018 at 21:44, Alexey Brodkin
wrote:
>
> Signed-off-by: Alexey Brodkin
> ---
>
> Changes v1 -> v2:
>
> * Added upstream status
>
> meta/recipes-dev
On Thu, 20 Sep 2018 at 21:44, Alexey Brodkin
wrote:
> case ${TARGET_ARCH} in
> aarch64_be) TUPLE=aarch64-unknown-linux-gnu ;;
> + arc)TUPLE=i686-unknown-linux-gnu ;;
> arm)TUPLE=arm-unknown-linux-gnueabi ;;
> armeb) TUPLE=arm-unkn
Hi Ross,
On Fri, 2018-09-21 at 11:43 +0100, Burton, Ross wrote:
> On Thu, 20 Sep 2018 at 21:44, Alexey Brodkin
> wrote:
>
> > case ${TARGET_ARCH} in
> > aarch64_be) TUPLE=aarch64-unknown-linux-gnu ;;
> > + arc)TUPLE=i686-unknown-linux-gnu ;;
> > arm)
Hi Ross,
On Fri, 2018-09-21 at 11:55 +0100, Burton, Ross wrote:
> I don't like accumulating pending patches for something as key as
> binutils, are these actually working their way upstream now?
Sure they are!
Our team development is very upstream targeted, i.e. we try to
submit all our changes
That's good to know, thanks.
Ross
On Fri, 21 Sep 2018 at 12:41, Alexey Brodkin
wrote:
>
> Hi Ross,
>
> On Fri, 2018-09-21 at 11:55 +0100, Burton, Ross wrote:
> > I don't like accumulating pending patches for something as key as
> > binutils, are these actually working their way upstream now?
>
>
On Wed, 19 Sep 2018 22:53, alexey.brod...@synopsys.com said:
> I'd say it looks similar to uClibc version which is below
> as a reference:
Ack. I added it to the list.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
pgpa4CIEdfCYv.pgp
Description: PGP
Hi Ross,
On Fri, 2018-09-21 at 14:31 +0300, Alexey Brodkin wrote:
> Hi Ross,
>
> On Fri, 2018-09-21 at 11:43 +0100, Burton, Ross wrote:
> > On Thu, 20 Sep 2018 at 21:44, Alexey Brodkin
> > wrote:
> >
> > > case ${TARGET_ARCH} in
> > > aarch64_be) TUPLE=aarch64-unknown-linux-gn
Can you check that v3 works with x86-64 targets?
ERROR: libgpg-error-1.32-r0 do_compile: Function failed: do_compile
(log file is located at
/data/poky-tmp/master/work/corei7-64-poky-linux/libgpg-error/1.32-r0/temp/log.do_compile.13345)
ERROR: Logfile of failure stored in:
/data/poky-tmp/master/wo
Hi Ross,
On Fri, 2018-09-21 at 13:53 +0100, Burton, Ross wrote:
> Can you check that v3 works with x86-64 targets?
>
> ERROR: libgpg-error-1.32-r0 do_compile: Function failed: do_compile
> (log file is located at
> /data/poky-tmp/master/work/corei7-64-poky-linux/libgpg-error/1.32-r0/temp/log.do_c
Yes, that fixes it.
Ross
On Fri, 21 Sep 2018 at 14:08, Alexey Brodkin
wrote:
>
> Hi Ross,
>
> On Fri, 2018-09-21 at 13:53 +0100, Burton, Ross wrote:
> > Can you check that v3 works with x86-64 targets?
> >
> > ERROR: libgpg-error-1.32-r0 do_compile: Function failed: do_compile
> > (log file is lo
Signed-off-by: Alexey Brodkin
---
No changes in v3.
Changes v1 -> v2:
* Merged changes in meta/classes/siteinfo.bbclass &
meta/site/arc-common
meta/classes/siteinfo.bbclass | 2 ++
meta/site/arc-common | 11 +++
2 files changed, 13 insertions(+)
create mode 100644 meta/s
Signed-off-by: Alexey Brodkin
---
No changes in v3.
No changes in v2.
meta/recipes-connectivity/openssl/openssl10_1.0.2p.bb | 2 +-
meta/recipes-connectivity/openssl/openssl_1.1.1.bb| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-connectivity/openssl/ope
Signed-off-by: Alexey Brodkin
---
No changes in v3.
Changes v1 -> v2:
* Added upstream status
meta/recipes-devtools/binutils/binutils-2.31.inc | 4 +
...location-where-GOT-information-is-collect.patch | 201 +
...bustness.-Return-FALSE-in-case-of-NULL-po.patch | 38 +
The libitm is not supported on ARC, so disable it
Signed-off-by: Alexey Brodkin
---
No changes in v3.
No changes in v2.
meta/recipes-devtools/gcc/gcc-runtime.inc | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/recipes-devtools/gcc/gcc-runtime.inc
b/meta/recipes-devtools/gcc/gcc-runt
GCC's built-in spec for LD is missing a space after
"--eh-frame-hdr" thus with the next option merged together they
are not understood by LD and so LD fails.
Back-port from upstream GCC, see:
https://github.com/gcc-mirror/gcc/commit/892142379c6b99fe8c3ebdfe0b79e2a435228c1d
Signed-off-by: Alexey B
Signed-off-by: Alexey Brodkin
---
No changes in v3.
No changes in v2.
meta/classes/kernel-arch.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/classes/kernel-arch.bbclass b/meta/classes/kernel-arch.bbclass
index 09793fc9c2..2b52a63c64 100644
--- a/meta/classes/kernel-arch.bbcl
Signed-off-by: Alexey Brodkin
---
No changes in v3.
Changes v1 -> v2:
* Added upstream status
.../icu/icu/0002-Add-ARC-support.patch | 27 ++
meta/recipes-support/icu/icu_62.1.bb | 1 +
2 files changed, 28 insertions(+)
create mode 100644 meta/
DesignWare ARC Processors are a family of 32-bit CPUs from Synopsys.
This series introduces basic support for ARC architecture in
OpenEmbedded.
As of today latest upstream GCC and Binutils are perfectly usable
for building packages for ARC so we just need a couple of fixes.
Glibc for ARC is under
From: Antoine Tenart
[Alexey: Rebased on top of other patches like RiscV, NIOS2 etc]
Signed-off-by: Antoine Tenart
Signed-off-by: Alexey Brodkin
---
No changes in v3.
Changes v1 -> v2:
* Added upstream status
.../nspr/nspr/0004-Add-ARC-support.patch | 88 ++
Signed-off-by: Alexey Brodkin
Cc: Ross Burton
Cc: Werner Koch
---
Changes v2 -> v3:
* Use proper [recently upstreamed] fix for ARC Glibc toolchain
* Fix compilation for x86_64 due to renamed header
Changes v1 -> v2:
* Added upstream status
...port-ARC-CPUs-and-simplify-aliasing-table.pat
24 matches
Mail list logo