On Wed, Dec 23, 2020 at 8:40 PM Alexey Brodkin
<alexey.brod...@synopsys.com> wrote:
>
> Hi Rosen, Hauke!
>
> > On Wed, Dec 23, 2020 at 6:54 AM Hauke Mehrtens <ha...@hauke-m.de> wrote:
> > >
> > > Hi,
> > >
> > > ARC was switched from uClibc to glibc here:
> > > https://git.openwrt.org/?p=openwrt/openwrt.git;a=commitdiff;h=95f1002acab574c24ad78f4453f091bf5a6731c7
> > > uClibc support was removed from OpenWrt in the next commit.
> > >
> > > It looks like arc700 is not supported by glibc 2.32, only ARC HS38 is
> > > supported.
>
> Correct, upstream glibc v2.32 only supports ARCv2 as of today.
> I forgot about that fact during discussion about uClibc removal here
> https://github.com/openwrt/openwrt/pull/3673#issuecomment-747373099
> because we used to add support for ARCompact ISA (i.e. ARC700 cores)
> via off-the-tree-patch, see
> https://github.com/foss-for-synopsys-dwc-arc-processors/glibc/commit/571c4c3df73bddbbb012b792a62f03e76b980ef3
> and note how simple it is fixing exactly the issue reported here.
Great. My current patch against glibc is:
--- a/sysdeps/arc/atomic-machine.h
+++ b/sysdeps/arc/atomic-machine.h
@@ -64,6 +64,10 @@ typedef uintmax_t uatomic_max_t;
__atomic_val_bysize (__arch_compare_and_exchange_val, int, \
mem, new, old, __ATOMIC_ACQUIRE)
+#ifdef __ARC700__
+#define atomic_full_barrier() ({ asm volatile ("sync":::"memory"); })
+#else
#define atomic_full_barrier() ({ asm volatile ("dmb 3":::"memory"); })
+#endif
#endif /* _ARC_BITS_ATOMIC_H */
--- a/sysdeps/unix/sysv/linux/arc/syscall.S
+++ b/sysdeps/unix/sysv/linux/arc/syscall.S
@@ -24,8 +24,13 @@ ENTRY (syscall)
mov_s r1, r2
mov_s r2, r3
mov_s r3, r4
+#ifdef __ARC700__
+ mov r4, r5
+ mov r5, r6
+#else
mov_s r4, r5
mov_s r5, r6
+#endif
ARC_TRAP_INSN
brhi r0, -4096, L (call_syscall_err)
--- a/sysdeps/unix/sysv/linux/arc/sysdep.h
+++ b/sysdeps/unix/sysv/linux/arc/sysdep.h
@@ -128,7 +128,11 @@ L (call_syscall_err):
ASM_LINE_SEP \
mov r8, __NR_##syscall_name ASM_LINE_SEP \
ARC_TRAP_INSN ASM_LINE_SEP
+# ifdef __ARC700__
+# define ARC_TRAP_INSN trap0
+# else
# define ARC_TRAP_INSN trap_s 0
+# endif
#else /* !__ASSEMBLER__ */
@@ -139,7 +143,11 @@ extern long int __syscall_error (long int);
hidden_proto (__syscall_error)
# endif
+# ifdef __ARC700__
+# define ARC_TRAP_INSN "trap0 \n\t"
+# else
# define ARC_TRAP_INSN "trap_s 0 \n\t"
+#endif
# undef INTERNAL_SYSCALL_NCS
# define INTERNAL_SYSCALL_NCS(number, nr_args, args...) \
Initial results look promising. I'll test compilation before submitting.
>
> > > On the arc770 target I am getting this compiler errors in the glibc:
> > > -----------------
> > > msort.c: Assembler messages:
> > > msort.c:201: Error: opcode 'dmb' not supported for target arc700
> > > -----------------
> > > http://buildbot.openwrt.org/master/images/builders/arc770%2Fgeneric/builds/749
> > >
> > > After this one is fixed I get this one:
> > > -----------------
> > > ../sysdeps/unix/sysv/linux/arc/syscall.S: Assembler messages:
> > > ../sysdeps/unix/sysv/linux/arc/syscall.S:27: Error: register must be
> > > either r0-r3 or r12-r15 for instruction 'mov_s'
> > > ../sysdeps/unix/sysv/linux/arc/syscall.S:28: Error: register must be
> > > either r0-r3 or r12-r15 for instruction 'mov_s'
> > > ---------------------
> > >
> > > Does anyone plan to fix glibc with arc700 or should we just remove the
> > > arc770 target, the arhs38 target is compiling?
>
> So indeed what we may do here is either to retrofit ARC700 into existing glibc
> via aforementioned patch in OpenWrt or remove support of ARC700 at all.
>
> I'd suggest for a moment to stop building for ARC700 while this discussion
> is in progress and some people who's opinion I'd like to hear also are
> on the Christmas break.
ARC700 can be marked as BROKEN which means disabled by default.
>
> > I'll look into it. My vote is to remove support for ARC altogether as
> > it doesn't seem any hardware uses it except for some dev kits.
>
> Well that I'd prefer to not do. Even though in upstream OpenWrt indeed we
> only have 2 development boards which we support, there might be other users
> (and here I mean companies, not even individuals) which use or plan to use
> OpenWrt on their ARC-based SoCs/boards.
>
> The fact those boards are not exposed to wider audience and are not sold
> as affordable consumer Wi-Fi routers doesn't mean they don't exist.
Right. The OpenWrt project began to service WiFi routers. That's still
most of the userbase.
>
> Moreover with recent introduction of ARCv3 processors which include
> 64-bit cores we're planning to add their support in OpenWrt as well
> as soon as our toolchain matures a little bit so that we're confident
> majority of packages could be built with it normally.
That's great to hear.
>
> So if ARC doesn't add a lot of troubles for the community, let's keep it
> in the project.
Not having hardware is quite limiting. That is, we can compile
binaries but there's no way to test if anything compiled actually
runs. I don't think even QEMU supports ARC.
No musl support is also irksome. Nobody wants uClibc-ng in here and
only a few want glibc in here. If glibc goes, ARC will go with it.
>
> > > I think the archs38 target was not runtime tested with glibc, could
> > > someone with access to the hardware please check if it is still working
> > > with glibc in master. gdbserver also got ARC support please also check
> > > if this now works and we can remove the dependency on !arc.
>
> Right, there's a chance we haven't run glibc flavor of OpenWrt on ARC,
> previously focused on uClibc. But we'll do that now, thanks for the hint!
>
> -Alexey
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
