[PATCH] ARC: [plat-hsdk]: Remove misplaced interrupt-cells property
"gmac" node stands for just an ordinary Ethernet controller, which is by no means a provider of interrupts, i.e. it doesn't serve as an interrupt controller, thus "#interrupt-cells" property doesn't belong to it and so we remove it. Fixes: >8 DTC arch/arc/boot/dts/hsdk.dtb arch/arc/boot/dts/hsdk.dts:207.23-235.5: Warning (interrupt_provider): /soc/ethernet@8000: '#interrupt-cells' found, but node is not an interrupt provider arch/arc/boot/dts/hsdk.dtb: Warning (interrupt_map): Failed prerequisite 'interrupt_provider' >8---- Reported-by: Vineet Gupta Signed-off-by: Alexey Brodkin --- arch/arc/boot/dts/hsdk.dts | 1 - 1 file changed, 1 deletion(-) diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts index 6691f4255077..41b980df862b 100644 --- a/arch/arc/boot/dts/hsdk.dts +++ b/arch/arc/boot/dts/hsdk.dts @@ -205,7 +205,6 @@ dmac_cfg_clk: dmac-gpu-cfg-clk { }; gmac: ethernet@8000 { - #interrupt-cells = <1>; compatible = "snps,dwmac"; reg = <0x8000 0x2000>; interrupts = <10>; -- 2.34.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] arc: Explicitly include correct DT includes
Hi Rob, > On Fri, Jul 14, 2023 at 11:39:49AM -0600, Rob Herring wrote: > > The DT of_device.h and of_platform.h date back to the separate > > of_platform_bus_type before it as merged into the regular platform bus. > > As part of that merge prepping Arm DT support 13 years ago, they > > "temporarily" include each other. They also include platform_device.h > > and of.h. As a result, there's a pretty much random mix of those include > > files used throughout the tree. In order to detangle these headers and > > replace the implicit includes with struct declarations, users need to > > explicitly include the correct includes. > > > > Signed-off-by: Rob Herring > > --- > > arch/arc/plat-axs10x/axs10x.c | 1 - > > 1 file changed, 1 deletion(-) > > Ping! Thanks for the enhancement! Tested-by: Alexey Brodkin > > > > > diff --git a/arch/arc/plat-axs10x/axs10x.c b/arch/arc/plat-axs10x/axs10x.c > > index b821df7b0089..1feb990a56bc 100644 > > --- a/arch/arc/plat-axs10x/axs10x.c > > +++ b/arch/arc/plat-axs10x/axs10x.c > > @@ -6,7 +6,6 @@ > > */ > > > > #include > > -#include > > #include > > > > #include > > -- > > 2.40.1 > > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Debian: openssl: Add ARC target
On Thu, 3 Jun 2021 19:14:24 + Vineet Gupta wrote: > Source: openssl > Severity: normal > Tags: patch > > Hi, > > This is needed to bootstrap arc port. > Patch attached. Ping! -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Debian: jemalloc: add arc support
On Thu, 3 Jun 2021 21:10:28 + Vineet Gupta wrote: > Update: upstream change has just now been merged. Ping! -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Debian: libffi: update symbols for ARC
On Thu, 3 Jun 2021 19:51:25 + Vineet Gupta wrote: > Source: libffi > Severity: normal > Tags: patch > > Hi, > > This is needed to bootstrap arc port. > Patch attached. Ping! -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: python3.9: Add arc-linux-gnu triplet
On Wed, 11 Aug 2021 15:34:09 +0300 Alexey Brodkin wrote: > Source: python3.9 > Severity: normal > Tags: patch upstream > > Dear Maintainer, > > There's a new triplet for ARCv2 processors "arc-linux-gnu" > defined here https://wiki.debian.org/Multiarch/Tuples. > > With addition of this triplet to Python3 it becomes buildable for ARC. > Attaching a simple diff that implements proposed change. > > -- System Information: > Debian Release: bullseye/sid > APT prefers focal-updates > APT policy: (500, 'focal-updates'), (500, 'focal-security'), (500, >'focal-proposed'), (500, 'focal'), (100, 'focal-backports') > Architecture: amd64 (x86_64) > > Kernel: Linux 5.4.72-microsoft-standard-WSL2 (SMP w/12 CPU cores) > Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 > (charmap=UTF-8) > Shell: /bin/sh linked to /usr/bin/dash > Init: unable to detect Ping! -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Debian: gmp: add support for arc
On Thu, 3 Jun 2021 19:00:30 + Vineet Gupta wrote: > Source: gmp > Severity: normal > Tags: patch > > Hi, > > To bootstrap arc port we need symbols file update in gmp. > Patch attached. Ping! -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2] dhcpcd: add ARC support
This retrofits ARC support from upstream [1]. Should be a part of the next release of "dhcpcd". https://github.com/NetworkConfiguration/dhcpcd/commit/82386110e67cf75c224e9817fce55e6b0f143266 Signed-off-by: Alexey Brodkin Cc: Alexandre Belloni --- Changes in v2: * Added "Upstream-Status" tag in the patch * Added my SoB in the patch meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb | 1 + ...rc-privsep-linux.c-add-support-for-arc-28.patch | 63 ++ 2 files changed, 64 insertions(+) create mode 100644 meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch diff --git a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb index 56fcf5cc0b..5be480eb03 100644 --- a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb +++ b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb @@ -13,6 +13,7 @@ UPSTREAM_CHECK_URI = "https://roy.marples.name/downloads/dhcpcd/"; SRC_URI = "https://roy.marples.name/downloads/${BPN}/${BPN}-${PV}.tar.xz \ file://0001-remove-INCLUDEDIR-to-prevent-build-issues.patch \ + file://0002-src-privsep-linux.c-add-support-for-arc-28.patch \ file://dhcpcd.service \ file://dhcpcd@.service \ " diff --git a/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch new file mode 100644 index 00..045f06a9aa --- /dev/null +++ b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch @@ -0,0 +1,63 @@ +From 82386110e67cf75c224e9817fce55e6b0f143266 Mon Sep 17 00:00:00 2001 +From: Fabrice Fontaine +Date: Mon, 8 Feb 2021 07:23:54 +0100 +Subject: [PATCH] src/privsep-linux.c: add support for arc (#28) + +Fix the following build failure: + +privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet" + # error "Platform does not support seccomp filter yet" +^ +In file included from privsep-linux.c:36: +privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'? + BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0), + ^~ + +It should be noted that AUDIT_ARCH_{ARCOMPACT,ARCV2} is only defined +since kernel 5.2 and +https://github.com/torvalds/linux/commit/67f2a8a29311841ba6ab9b0e2d1b8f1e9978cd84 + +Detection of arc compact and arc v2 have been "copy/pasted" from +https://github.com/wbx-github/uclibc-ng/commit/afab56958f1cbb47b831ee3ebff231dfbae74af2 + +Fixes: + - http://autobuild.buildroot.org/results/d29083700a80dd647621eed06faeeae03f0587d3 + +Upstream-Status: Backport [https://github.com/NetworkConfiguration/dhcpcd/commit/82386110e67cf75c224e9817fce55e6b0f143266] + +Signed-off-by: Fabrice Fontaine +Signed-off-by: Alexey Brodkin +--- + src/privsep-linux.c | 16 + 1 file changed, 16 insertions(+) + +diff --git a/src/privsep-linux.c b/src/privsep-linux.c +index 402667af..21d41a9a 100644 +--- a/src/privsep-linux.c b/src/privsep-linux.c +@@ -149,6 +149,22 @@ ps_root_sendnetlink(struct dhcpcd_ctx *ctx, int protocol, struct msghdr *msg) + # define SECCOMP_AUDIT_ARCH AUDIT_ARCH_I386 + #elif defined(__x86_64__) + # define SECCOMP_AUDIT_ARCH AUDIT_ARCH_X86_64 ++#elif defined(__arc__) ++# if defined(__A7__) ++#if (BYTE_ORDER == LITTLE_ENDIAN) ++# define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCOMPACT ++#else ++# define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCOMPACTBE ++#endif ++# elif defined(__HS__) ++#if (BYTE_ORDER == LITTLE_ENDIAN) ++# define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCV2 ++#else ++# define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCV2BE ++#endif ++# else ++#error "Platform does not support seccomp filter yet" ++# endif + #elif defined(__arm__) + # ifndef EM_ARM + #define EM_ARM 40 +-- +2.16.2 + -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [OE-core] [PATCH] dhcpcd: add ARC support
Hi Alexandre, > > I did run that through the autobuilders and it is working fine but this > is missing an Upstream-Status tag. > I was a bit surprised by your response being under impression that I did add "Upstream-Status" tag in the patch. So I went to check... and indeed, I added it, but just locally, never "git add . && git commit --amend", thus still have it as: --->8-- $ git diff diff --git a/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch index ec895143d8..045f06a9aa 100644 --- a/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch +++ b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch @@ -23,7 +23,10 @@ https://github.com/wbx-github/uclibc-ng/commit/afab56958f1cbb47b831ee3ebff231dfb Fixes: - http://autobuild.buildroot.org/results/d29083700a80dd647621eed06faeeae03f0587d3 +Upstream-Status: Backport [https://github.com/NetworkConfiguration/dhcpcd/commit/82386110e67cf75c224e9817fce55e6b0f143266] + Signed-off-by: Fabrice Fontaine +Signed-off-by: Alexey Brodkin --->8-- So thanks a lot for spotting that, will send a re-spin in a moment! -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] dhcpcd: add ARC support
This retrofits ARC support from upstream [1]. Should be a part of the next release of "dhcpcd". https://github.com/NetworkConfiguration/dhcpcd/commit/82386110e67cf75c224e9817fce55e6b0f143266 Signed-off-by: Alexey Brodkin --- meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb | 1 + ...rc-privsep-linux.c-add-support-for-arc-28.patch | 60 ++ 2 files changed, 61 insertions(+) create mode 100644 meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch diff --git a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb index 56fcf5cc0b..5be480eb03 100644 --- a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb +++ b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.0.bb @@ -13,6 +13,7 @@ UPSTREAM_CHECK_URI = "https://roy.marples.name/downloads/dhcpcd/"; SRC_URI = "https://roy.marples.name/downloads/${BPN}/${BPN}-${PV}.tar.xz \ file://0001-remove-INCLUDEDIR-to-prevent-build-issues.patch \ + file://0002-src-privsep-linux.c-add-support-for-arc-28.patch \ file://dhcpcd.service \ file://dhcpcd@.service \ " diff --git a/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch new file mode 100644 index 00..ec895143d8 --- /dev/null +++ b/meta/recipes-connectivity/dhcpcd/files/0002-src-privsep-linux.c-add-support-for-arc-28.patch @@ -0,0 +1,60 @@ +From 82386110e67cf75c224e9817fce55e6b0f143266 Mon Sep 17 00:00:00 2001 +From: Fabrice Fontaine +Date: Mon, 8 Feb 2021 07:23:54 +0100 +Subject: [PATCH] src/privsep-linux.c: add support for arc (#28) + +Fix the following build failure: + +privsep-linux.c:206:4: error: #error "Platform does not support seccomp filter yet" + # error "Platform does not support seccomp filter yet" +^ +In file included from privsep-linux.c:36: +privsep-linux.c:213:38: error: 'SECCOMP_AUDIT_ARCH' undeclared here (not in a function); did you mean 'SECCOMP_ALLOW_ARG'? + BPF_JUMP(BPF_JMP + BPF_JEQ + BPF_K, SECCOMP_AUDIT_ARCH, 1, 0), + ^~ + +It should be noted that AUDIT_ARCH_{ARCOMPACT,ARCV2} is only defined +since kernel 5.2 and +https://github.com/torvalds/linux/commit/67f2a8a29311841ba6ab9b0e2d1b8f1e9978cd84 + +Detection of arc compact and arc v2 have been "copy/pasted" from +https://github.com/wbx-github/uclibc-ng/commit/afab56958f1cbb47b831ee3ebff231dfbae74af2 + +Fixes: + - http://autobuild.buildroot.org/results/d29083700a80dd647621eed06faeeae03f0587d3 + +Signed-off-by: Fabrice Fontaine +--- + src/privsep-linux.c | 16 + 1 file changed, 16 insertions(+) + +diff --git a/src/privsep-linux.c b/src/privsep-linux.c +index 402667af..21d41a9a 100644 +--- a/src/privsep-linux.c b/src/privsep-linux.c +@@ -149,6 +149,22 @@ ps_root_sendnetlink(struct dhcpcd_ctx *ctx, int protocol, struct msghdr *msg) + # define SECCOMP_AUDIT_ARCH AUDIT_ARCH_I386 + #elif defined(__x86_64__) + # define SECCOMP_AUDIT_ARCH AUDIT_ARCH_X86_64 ++#elif defined(__arc__) ++# if defined(__A7__) ++#if (BYTE_ORDER == LITTLE_ENDIAN) ++# define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCOMPACT ++#else ++# define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCOMPACTBE ++#endif ++# elif defined(__HS__) ++#if (BYTE_ORDER == LITTLE_ENDIAN) ++# define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCV2 ++#else ++# define SECCOMP_AUDIT_ARCH AUDIT_ARCH_ARCV2BE ++#endif ++# else ++#error "Platform does not support seccomp filter yet" ++# endif + #elif defined(__arm__) + # ifndef EM_ARM + #define EM_ARM 40 +-- +2.16.2 + -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] dpkg: Add ARC support
This back-ports ARC support which was added after the most recent tag 1.20.9 was cut. So on the next version bump this change to be reverted. Signed-off-by: Alexey Brodkin --- .../dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch | 68 ++ meta/recipes-devtools/dpkg/dpkg_1.20.9.bb | 1 + 2 files changed, 69 insertions(+) create mode 100644 meta/recipes-devtools/dpkg/dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch diff --git a/meta/recipes-devtools/dpkg/dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch b/meta/recipes-devtools/dpkg/dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch new file mode 100644 index 00..ece18a33ac --- /dev/null +++ b/meta/recipes-devtools/dpkg/dpkg/0014-arch-Add-support-for-ARCv2-CPU.patch @@ -0,0 +1,68 @@ +From c6acfba64b470c7e919fd5bd29124d7228492537 Mon Sep 17 00:00:00 2001 +From: Guillem Jover +Date: Fri, 28 May 2021 04:07:49 +0200 +Subject: [PATCH] arch: Add support for ARCv2 CPU + +This is based on the ARCv2 32-bit little-endian hard-float ISA. + +Closes: #980963 + +Upstream-Status: Backport [https://salsa.debian.org/dpkg-team/dpkg/-/commit/0d134cdcb0dcc6b21fa7926964c1426a5821181d] + +Based-on-patch-by: Alexey Brodkin +Signed-off-by: Alexey Brodkin +--- + data/cputable | 1 + + scripts/Dpkg/Shlibs/Objdump.pm | 1 + + scripts/t/Dpkg_Arch.t | 4 ++-- + 3 files changed, 4 insertions(+), 2 deletions(-) + +diff --git a/data/cputable b/data/cputable +index 9f2a8e0e4..277bed88f 100644 +--- a/data/cputable b/data/cputable +@@ -20,6 +20,7 @@ i386 i686(i[34567]86|pentium)32 little + ia64 ia64ia6464 little + alpha alpha alpha.* 64 little + amd64 x86_64 (amd64|x86_64) 64 little ++arc arc arc 32 little + armeb armeb arm.*b 32 big + arm arm arm.* 32 little + arm64 aarch64 aarch64 64 little +diff --git a/scripts/Dpkg/Shlibs/Objdump.pm b/scripts/Dpkg/Shlibs/Objdump.pm +index 4cee866e7..93319d1eb 100644 +--- a/scripts/Dpkg/Shlibs/Objdump.pm b/scripts/Dpkg/Shlibs/Objdump.pm +@@ -100,6 +100,7 @@ use constant { + ELF_MACH_OR1K => 92, + ELF_MACH_XTENSA => 94, + ELF_MACH_MICROBLAZE => 189, ++ELF_MACH_ARCV2 => 195, + ELF_MACH_AVR_OLD=> 0x1057, + ELF_MACH_OR1K_OLD => 0x8472, + ELF_MACH_ALPHA => 0x9026, +diff --git a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t +index a3a9e6fee..f0bba272a 100644 +--- a/scripts/t/Dpkg_Arch.t b/scripts/t/Dpkg_Arch.t +@@ -16,7 +16,7 @@ + use strict; + use warnings; + +-use Test::More tests => 16836; ++use Test::More tests => 18407; + + use_ok('Dpkg::Arch', qw(debarch_to_debtuple debarch_to_multiarch + debarch_eq debarch_is debarch_is_wildcard +@@ -174,7 +174,7 @@ is(gnutriplet_to_debarch(undef), undef, 'undef gnutriplet'); + is(gnutriplet_to_debarch('unknown-unknown-unknown'), undef, 'unknown gnutriplet'); + is(gnutriplet_to_debarch('x86_64-linux-gnu'), 'amd64', 'known gnutriplet'); + +-is(scalar get_valid_arches(), 539, 'expected amount of known architectures'); ++is(scalar get_valid_arches(), 554, 'expected amount of known architectures'); + + { + local $ENV{CC} = 'false'; +-- +2.16.2 + diff --git a/meta/recipes-devtools/dpkg/dpkg_1.20.9.bb b/meta/recipes-devtools/dpkg/dpkg_1.20.9.bb index 60ae3ff736..18ca0e310b 100644 --- a/meta/recipes-devtools/dpkg/dpkg_1.20.9.bb +++ b/meta/recipes-devtools/dpkg/dpkg_1.20.9.bb @@ -15,6 +15,7 @@ SRC_URI = "git://salsa.debian.org/dpkg-team/dpkg.git;protocol=https;branch=1.20. file://pager.patch \ file://0001-Add-support-for-riscv32-CPU.patch \ file://0013-scripts-dpkg-fsys-usrunmess.pl-correct-shebang.patch \ + file://0014-arch-Add-support-for-ARCv2-CPU.patch \ " SRC_URI_append_class-native = " file://0001-build.c-ignore-return-of-1-from-tar-cf.patch" -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] default-distrovars.inc: Remove seccomp for ARC
libseccomp needs too be ported to ARC first Signed-off-by: Alexey Brodkin Cc: Khem Raj --- meta/conf/distro/include/default-distrovars.inc | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/conf/distro/include/default-distrovars.inc b/meta/conf/distro/include/default-distrovars.inc index ac10245767..e0726fa3bb 100644 --- a/meta/conf/distro/include/default-distrovars.inc +++ b/meta/conf/distro/include/default-distrovars.inc @@ -13,6 +13,9 @@ LOCALE_UTF8_IS_DEFAULT_class-nativesdk = "0" # seccomp is not yet ported to rv32 DISTRO_FEATURES_DEFAULT_remove_riscv32 = "seccomp" +# seccomp is not yet ported to ARC +DISTRO_FEATURES_DEFAULT_remove_arc = "seccomp" + DISTRO_FEATURES_DEFAULT ?= "acl alsa argp bluetooth debuginfod ext2 ipv4 ipv6 largefile pcmcia usbgadget usbhost wifi xattr nfs zeroconf pci 3g nfc x11 vfat seccomp" DISTRO_FEATURES ?= "${DISTRO_FEATURES_DEFAULT}" IMAGE_FEATURES ?= "" -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] gcc: Apply multilib fix to ARC as well
W/o that hack target GCC assume existence of per-mcpu folders, which are missing. In particular G++ failed to find "bits/c++config.h": -->8-- root@hsdk:~# cat test.cc #include int myfunc(void) { } root@hsdk:~# g++ -c test.cc -v Using built-in specs. COLLECT_GCC=g++ Target: arc-oe-linux Configured with: ../../../../../../work-shared/gcc-11.1.0-r0/gcc-11.1.0/configure --build=x86_64-linux --host=arc-oe-linux --target=arc-oe-linux --prefix=/usr --exec_prefix=/usr -x Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.1.1 20210523 (GCC) COLLECT_GCC_OPTIONS='-c' '-v' '-shared-libgcc' '-mcpu=hs38_linux' /usr/libexec/gcc/arc-oe-linux/11.1.1/cc1plus -quiet -v -imultilib hs38_linux -D_GNU_SOURCE test.cc -quiet -dumpbase test.cc -dumpbase-ext .cc -mcpu=hs38_linux -version -o /tmp/ccs GNU C++17 (GCC) version 11.1.1 20210523 (arc-oe-linux) compiled by GNU C version 11.1.1 20210523, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version none GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129242 ignoring nonexistent directory "/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/arc-oe-linux/hs38_linux" ignoring nonexistent directory "/usr/lib/arc-oe-linux/11.1.1/include" ignoring nonexistent directory "/usr/local/include" ignoring nonexistent directory "/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../arc-oe-linux/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1 /usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/backward /usr/lib/gcc/arc-oe-linux/11.1.1/include /usr/lib/gcc/arc-oe-linux/11.1.1/include-fixed /usr/include End of search list. GNU C++17 (GCC) version 11.1.1 20210523 (arc-oe-linux) compiled by GNU C version 11.1.1 20210523, GMP version 6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version none GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129242 Compiler executable checksum: 6df2f07a822bfbbb80a61414b712b75d In file included from test.cc:1: /usr/include/c++/11.1.1/cstdlib:41:10: fatal error: bits/c++config.h: No such file or directory 41 | #include | ^~ compilation terminated. -->8-- Note "ignoring nonexistent directory "/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/arc-oe-linux/hs38_linux" message which is being used by GCC due to the fact of implicit "-mcpu=hs38_linux". In fact this header "bits/c++config.h" is located in "/usr/lib/gcc/arc-oe-linux/11.1.1/../../../../include/c++/11.1.1/arc-oe-linux" on target. Signed-off-by: Alexey Brodkin --- .../gcc/gcc/0004-64-bit-multilib-hack.patch| 23 +++--- 1 file changed, 20 insertions(+), 3 deletions(-) diff --git a/meta/recipes-devtools/gcc/gcc/0004-64-bit-multilib-hack.patch b/meta/recipes-devtools/gcc/gcc/0004-64-bit-multilib-hack.patch index 789f57343b..8184e68743 100644 --- a/meta/recipes-devtools/gcc/gcc/0004-64-bit-multilib-hack.patch +++ b/meta/recipes-devtools/gcc/gcc/0004-64-bit-multilib-hack.patch @@ -1,4 +1,4 @@ -From 28e7c312b1292ca216d4b54ec9f6b7ac055907a8 Mon Sep 17 00:00:00 2001 +From 2fa5c93641b75a662839c1b6eee172b6c481c70e Mon Sep 17 00:00:00 2001 From: Khem Raj Date: Fri, 29 Mar 2013 09:10:06 +0400 Subject: [PATCH] 64-bit multilib hack. @@ -19,7 +19,7 @@ and be able to patch these entries with a complete set of correct paths but this don't have such code at this point. This is something the target gcc recipe should do and override these platform defaults in its build config. -Do same for riscv64 and aarch64 +Do same for riscv64, aarch64 & arc RP 15/8/11 @@ -30,11 +30,12 @@ Signed-off-by: Elvis Dowson Signed-off-by: Mark Hatle --- gcc/config/aarch64/t-aarch64-linux | 8 + gcc/config/arc/t-multilib-linux| 4 ++-- gcc/config/i386/t-linux64 | 6 ++ gcc/config/mips/t-linux64 | 10 +++--- gcc/config/riscv/t-linux | 6 -- gcc/config/rs6000/t-linux64| 5 ++--- - 5 files changed, 15 insertions(+), 20 deletions(-) + 6 files changed, 17 insertions(+), 22 deletions(-) diff --git a/gcc/config/aarch64/t-aarch64-linux b/gcc/config/aarch64/t-aarch64-linux index 241b0ef20b6..a7dadb2d64f 100644 @@ -53,6 +54,22 @@ index 241b0ef20b6..a7dadb2d64f 100644 -MULTILIB_OSDIRNAMES += mabi.ilp32=../libilp32$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu_ilp32) +#MULTILIB_OSDIRNAMES += mabi.ilp32=../libilp32$(call if_multiarch,:aarch64$(AARCH_BE)-linux-gnu_ilp32) +diff --git a/gcc/config/arc/t-multilib-linux b/gcc/config/arc/t-multilib-linux +index fc3fff640a2..d58e28f6df8 100644 +--- a/gc
[PATCH] gdb: Add native GDB support for ARC
This adds support of so-called "native" GDB for ARC processors. It was submitted upstream a bit late for inclusion in v10.x, but already in the upstream "master" branch and will be an essential part of v11.1 whenever it happens. These are the changes from upstream "master": * https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=b4e3cd0440109d0a5552d3313ccbd35c8103335b * https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=d4af727286e3a9f177ba11677fbd3a012d36558a * https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=46023bbe81355230b4e7b76d3084337823d02362 * https://sourceware.org/git?p=binutils-gdb.git;a=commit;h=04c9f85efcd8df5fc482ce97c0104cc7dd5d19e6 Thanks a bunch to Anton & Shahab who made it possible! Signed-off-by: Alexey Brodkin --- meta/recipes-devtools/gdb/gdb-10.2.inc | 4 + .../0012-arc-Add-support-for-signal-handlers.patch | 218 +++ ...pport-for-signal-frames-for-Linux-targets.patch | 232 ...to-account-the-REGNUM-in-supply-collect-g.patch | 104 ++ ...b-Add-native-support-for-ARC-in-GNU-Linux.patch | 414 + 5 files changed, 972 insertions(+) create mode 100644 meta/recipes-devtools/gdb/gdb/0012-arc-Add-support-for-signal-handlers.patch create mode 100644 meta/recipes-devtools/gdb/gdb/0013-arc-Add-support-for-signal-frames-for-Linux-targets.patch create mode 100644 meta/recipes-devtools/gdb/gdb/0014-arc-Take-into-account-the-REGNUM-in-supply-collect-g.patch create mode 100644 meta/recipes-devtools/gdb/gdb/0015-gdb-Add-native-support-for-ARC-in-GNU-Linux.patch diff --git a/meta/recipes-devtools/gdb/gdb-10.2.inc b/meta/recipes-devtools/gdb/gdb-10.2.inc index 0a7df54e9f..0d275075e6 100644 --- a/meta/recipes-devtools/gdb/gdb-10.2.inc +++ b/meta/recipes-devtools/gdb/gdb-10.2.inc @@ -15,5 +15,9 @@ SRC_URI = "${GNU_MIRROR}/gdb/gdb-${PV}.tar.xz \ file://0009-resolve-restrict-keyword-conflict.patch \ file://0010-Fix-invalid-sigprocmask-call.patch \ file://0011-gdbserver-ctrl-c-handling.patch \ + file://0012-arc-Add-support-for-signal-handlers.patch \ + file://0013-arc-Add-support-for-signal-frames-for-Linux-targets.patch \ + file://0014-arc-Take-into-account-the-REGNUM-in-supply-collect-g.patch \ + file://0015-gdb-Add-native-support-for-ARC-in-GNU-Linux.patch \ " SRC_URI[sha256sum] = "aaa1223d534c9b700a8bec952d9748ee1977513f178727e1bee520ee000b4f29" diff --git a/meta/recipes-devtools/gdb/gdb/0012-arc-Add-support-for-signal-handlers.patch b/meta/recipes-devtools/gdb/gdb/0012-arc-Add-support-for-signal-handlers.patch new file mode 100644 index 00..6a98b65766 --- /dev/null +++ b/meta/recipes-devtools/gdb/gdb/0012-arc-Add-support-for-signal-handlers.patch @@ -0,0 +1,218 @@ +From bfee93403b46ae4f050282b7721ba39073905c69 Mon Sep 17 00:00:00 2001 +From: Anton Kolesov +Date: Mon, 22 Aug 2016 19:39:46 +0300 +Subject: [PATCH 1/4] arc: Add support for signal handlers + +This patch adds the necessary infrastructure to handle signal frames for +ARC architecture. It is fairly similar to what any other architecture +would have. Linux specific parts will be in a separate patch. + +v2 [1]: +- Make the logic of "arc_sigtramp_frame_sniffer ()" simpler. + +[1] Tom's remark for the first version +https://sourceware.org/pipermail/gdb-patches/2020-November/173221.html + +gdb/ChangeLog: + + * arc-tdep.c (arc_make_sigtramp_frame_cache): New function. + (arc_sigtramp_frame_this_id): Likewise. + (arc_sigtramp_frame_prev_register): Likewise. + (arc_sigtramp_frame_sniffer): Likewise. + (arc_siftramp_frame_unwind): New global variable. + (arc_gdbarch_init): Use sigtramp capabilities. + (arc_dump_tdep): Print sigtramp fields. + * arc-tdep.h (gdbarch_tdep): Add sigtramp fields. + +Upstream-Status: Backport [https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=b4e3cd0440109d0a5552d3313ccbd35c8103335b] + +Signed-off-by: Anton Kolesov +Signed-off-by: Shahab Vahedi +Signed-off-by: Alexey Brodkin +--- + gdb/arc-tdep.c | 123 + + gdb/arc-tdep.h | 13 ++ + 2 files changed, 136 insertions(+) + +diff --git a/gdb/arc-tdep.c b/gdb/arc-tdep.c +index 93e2fd88a9a..3356252525d 100644 +--- a/gdb/arc-tdep.c b/gdb/arc-tdep.c +@@ -1843,6 +1843,104 @@ arc_dwarf2_frame_init_reg (struct gdbarch *gdbarch, int regnum, + reg->how = DWARF2_FRAME_REG_CFA; + } + ++/* Signal trampoline frame unwinder. Allows frame unwinding to happen ++from within signal handlers. */ ++ ++static struct arc_frame_cache * ++arc_make_sigtramp_frame_cache (struct frame_info *this_frame) ++{ ++ if (arc_debug) ++debug_printf ("arc: sigtramp_frame_cache\n"); ++ ++ struct gdbarch_tdep *tdep = gdbarch_tdep (get_frame_arch (this_frame)); ++ ++ /* Allocate new frame cache
[PATCH] gcc: Fixes for ARC
A couple of fixes to be a part of 11.2 whenever it happens 1. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0061fabeb9393c362601486105202cfe837a5a68 Fixes "harfbuzz" build, see https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/382 for all the gory details. 2. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4186b7e93be73f8d68dc0fcc00a4cc8cc83e99a8 Fixes ext4 run-time issue: ->8--- Path: /bin/busybox CPU: 0 PID: 1 Comm: init Not tainted 5.13.0-rc2-dirty #23 Invalid Read @ 0x41c9e600 by insn @ __bio_try_merge_page+0x4e/0xfc ECR: 0x00050100 EFA: 0x41c9e600 ERET: 0x80159656 STAT: 0x80080202 [IE K ] BTA: 0x80159648 SP: 0x80821b88 FP: 0x0008 BLK: bio_add_page+0x22/0x5c LPS: 0x801a6a94 LPE: 0x801a6a98 LPC: 0x r00: 0x80823300 r01: 0xbfb85e38 r02: 0x2000 r03: 0x r04: 0x80821b9b r05: 0x80821bfc r06: 0x r07: 0x0700 r08: 0x r09: 0x r10: 0x r11: 0x r12: 0x8080b300 Stack Trace: __bio_try_merge_page+0x4e/0xfc bio_add_page+0x22/0x5c do_mpage_readpage+0x534/0x65c mpage_readahead+0x30/0xdc read_pages+0x34/0x194 page_cache_ra_unbounded+0x56/0x154 filemap_fault+0x25a/0x5d8 __do_fault+0x94/0xe8 handle_mm_fault+0x4de/0xbd4 do_page_fault+0x108/0x21c ret_from_exception+0x0/0x8 ->8--- 3. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5a9b6a004f89fdd95b0470e1324dc4dee8c41d24 Precautious fix for rare corner cases which we don't wnat to really end-up in. Signed-off-by: Alexey Brodkin --- meta/recipes-devtools/gcc/gcc-11.1.inc | 3 + ...0038-arc-Update-64bit-move-split-patterns.patch | 290 + .../gcc/gcc/0039-arc-Fix-u-maddhisi-patterns.patch | 127 + .../gcc/0040-arc-Update-doloop_end-patterns.patch | 105 4 files changed, 525 insertions(+) create mode 100644 meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch create mode 100644 meta/recipes-devtools/gcc/gcc/0039-arc-Fix-u-maddhisi-patterns.patch create mode 100644 meta/recipes-devtools/gcc/gcc/0040-arc-Update-doloop_end-patterns.patch diff --git a/meta/recipes-devtools/gcc/gcc-11.1.inc b/meta/recipes-devtools/gcc/gcc-11.1.inc index bf29879ded..69e4c8bacc 100644 --- a/meta/recipes-devtools/gcc/gcc-11.1.inc +++ b/meta/recipes-devtools/gcc/gcc-11.1.inc @@ -69,6 +69,9 @@ SRC_URI = "\ file://0036-mingw32-Enable-operation_not_supported.patch \ file://0037-libatomic-Do-not-enforce-march-on-aarch64.patch \ file://0001-Revert-libstdc-Install-libstdc-gdb.py-more-robustly-.patch \ + file://0038-arc-Update-64bit-move-split-patterns.patch \ + file://0039-arc-Fix-u-maddhisi-patterns.patch \ + file://0040-arc-Update-doloop_end-patterns.patch \ " SRC_URI[sha256sum] = "4c4a6fb8a8396059241c2e674b85b351c26a5d678274007f076957afa1cc9ddf" SRC_URI[backports.sha256sum] = "69274bebd6c069a13443d4af61070e854740a639ec4d66eedf3e80070363587b" diff --git a/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch b/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch new file mode 100644 index 00..37fe95d711 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch @@ -0,0 +1,290 @@ +From 0061fabeb9393c362601486105202cfe837a5a68 Mon Sep 17 00:00:00 2001 +From: Claudiu Zissulescu +Date: Wed, 9 Jun 2021 12:12:57 +0300 +Subject: [PATCH] arc: Update 64bit move split patterns. + +ARCv2HS can use a limited number of instructions to implement 64bit +moves. The VADD2 is used as a 64bit move, the LDD/STD are 64 bit loads +and stores. All those instructions are not baseline, hence we need to +provide alternatives when they are not available or cannot be generate +due to instruction restriction. + +This patch is cleaning up those move patterns, and updates splits +instruction lengths. + +This is a backport from mainline gcc. + +gcc/ +2021-06-09 Claudiu Zissulescu + + * config/arc/arc-protos.h (arc_split_move_p): New prototype. + * config/arc/arc.c (arc_split_move_p): New function. + (arc_split_move): Clean up. + * config/arc/arc.md (movdi_insn): Clean up, use arc_split_move_p. + (movdf_insn): Likewise. + * config/arc/simdext.md (mov_insn): Likewise. + +Upstream-Status: Backport [https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0061fabeb9393c362601486105202cfe837a5a68] + +Signed-off-by: Claudiu Zissulescu +(cherry picked from commit c0ba7a8af5366c37241f20e8be41e362f7260389) +Signed-off-by: Alexey Brodkin +--- + gcc/config/arc/arc-protos.h | 1 + + gcc/config/arc/arc.c| 44 -- + gcc/config/arc/arc.md | 91 +
[PATCH] gcc: Fixes for ARC
A couple of fixes to be a part of 11.2 whenever it happens 1. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0061fabeb9393c362601486105202cfe837a5a68 Fixes "harfbuzz" build, see https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/issues/382 for all the gory details. 2. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=4186b7e93be73f8d68dc0fcc00a4cc8cc83e99a8 Fixes ext4 run-time issue: ->8--- Path: /bin/busybox CPU: 0 PID: 1 Comm: init Not tainted 5.13.0-rc2-dirty #23 Invalid Read @ 0x41c9e600 by insn @ __bio_try_merge_page+0x4e/0xfc ECR: 0x00050100 EFA: 0x41c9e600 ERET: 0x80159656 STAT: 0x80080202 [IE K ] BTA: 0x80159648 SP: 0x80821b88 FP: 0x0008 BLK: bio_add_page+0x22/0x5c LPS: 0x801a6a94 LPE: 0x801a6a98 LPC: 0x r00: 0x80823300 r01: 0xbfb85e38 r02: 0x2000 r03: 0x r04: 0x80821b9b r05: 0x80821bfc r06: 0x r07: 0x0700 r08: 0x r09: 0x r10: 0x r11: 0x r12: 0x8080b300 Stack Trace: __bio_try_merge_page+0x4e/0xfc bio_add_page+0x22/0x5c do_mpage_readpage+0x534/0x65c mpage_readahead+0x30/0xdc read_pages+0x34/0x194 page_cache_ra_unbounded+0x56/0x154 filemap_fault+0x25a/0x5d8 __do_fault+0x94/0xe8 handle_mm_fault+0x4de/0xbd4 do_page_fault+0x108/0x21c ret_from_exception+0x0/0x8 ->8--- 3. https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5a9b6a004f89fdd95b0470e1324dc4dee8c41d24 Precautious fix for rare corner cases which we don't wnat to really end-up in. Signed-off-by: Alexey Brodkin --- meta/recipes-devtools/gcc/gcc-11.1.inc | 3 + ...0038-arc-Update-64bit-move-split-patterns.patch | 290 + .../gcc/gcc/0039-arc-Fix-u-maddhisi-patterns.patch | 127 + .../gcc/0040-arc-Update-doloop_end-patterns.patch | 105 4 files changed, 525 insertions(+) create mode 100644 meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch create mode 100644 meta/recipes-devtools/gcc/gcc/0039-arc-Fix-u-maddhisi-patterns.patch create mode 100644 meta/recipes-devtools/gcc/gcc/0040-arc-Update-doloop_end-patterns.patch diff --git a/meta/recipes-devtools/gcc/gcc-11.1.inc b/meta/recipes-devtools/gcc/gcc-11.1.inc index bf29879ded..69e4c8bacc 100644 --- a/meta/recipes-devtools/gcc/gcc-11.1.inc +++ b/meta/recipes-devtools/gcc/gcc-11.1.inc @@ -69,6 +69,9 @@ SRC_URI = "\ file://0036-mingw32-Enable-operation_not_supported.patch \ file://0037-libatomic-Do-not-enforce-march-on-aarch64.patch \ file://0001-Revert-libstdc-Install-libstdc-gdb.py-more-robustly-.patch \ + file://0038-arc-Update-64bit-move-split-patterns.patch \ + file://0039-arc-Fix-u-maddhisi-patterns.patch \ + file://0040-arc-Update-doloop_end-patterns.patch \ " SRC_URI[sha256sum] = "4c4a6fb8a8396059241c2e674b85b351c26a5d678274007f076957afa1cc9ddf" SRC_URI[backports.sha256sum] = "69274bebd6c069a13443d4af61070e854740a639ec4d66eedf3e80070363587b" diff --git a/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch b/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch new file mode 100644 index 00..37fe95d711 --- /dev/null +++ b/meta/recipes-devtools/gcc/gcc/0038-arc-Update-64bit-move-split-patterns.patch @@ -0,0 +1,290 @@ +From 0061fabeb9393c362601486105202cfe837a5a68 Mon Sep 17 00:00:00 2001 +From: Claudiu Zissulescu +Date: Wed, 9 Jun 2021 12:12:57 +0300 +Subject: [PATCH] arc: Update 64bit move split patterns. + +ARCv2HS can use a limited number of instructions to implement 64bit +moves. The VADD2 is used as a 64bit move, the LDD/STD are 64 bit loads +and stores. All those instructions are not baseline, hence we need to +provide alternatives when they are not available or cannot be generate +due to instruction restriction. + +This patch is cleaning up those move patterns, and updates splits +instruction lengths. + +This is a backport from mainline gcc. + +gcc/ +2021-06-09 Claudiu Zissulescu + + * config/arc/arc-protos.h (arc_split_move_p): New prototype. + * config/arc/arc.c (arc_split_move_p): New function. + (arc_split_move): Clean up. + * config/arc/arc.md (movdi_insn): Clean up, use arc_split_move_p. + (movdf_insn): Likewise. + * config/arc/simdext.md (mov_insn): Likewise. + +Upstream-Status: Backport [https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=0061fabeb9393c362601486105202cfe837a5a68] + +Signed-off-by: Claudiu Zissulescu +(cherry picked from commit c0ba7a8af5366c37241f20e8be41e362f7260389) +Signed-off-by: Alexey Brodkin +--- + gcc/config/arc/arc-protos.h | 1 + + gcc/config/arc/arc.c| 44 -- + gcc/config/arc/arc.md | 91 +
Re: [linux-yocto] [PATCH] ARC: Rename nSIM HS to HAPS HS
> > > The author as it comes in on your patches is rejected by the yocto git > > > servers, so yes, it had to be fixed up. > > > > Do you know what needs to be done to get that fixed? > > I hope to keep sending patches from time to time > > (and was about to send yet another one just now), > > so would be good to make things simpler and exclude > > that manual fix-up step. > > Did you send the patch via git-send email ? And what smtp relay did > you use (if that's the case). I did sent it with "git send-email" as I always do. That was exactly my command: >8--- git send-email --to linux-yo...@lists.yoctoproject.org --cc linux-snps-arc@lists.infradead.org HEAD~1 >8--- I used our corporate SMPT server, again as I always used to do. > The patch had a "via lists.yoctoproject.org" in the author, and that > is what caused the server's pre-commit hook to reject it. I think what might be wrong - on my first attempt to send it, it was discarded by the mailing list as I didn't have my email alias properly set in the mailing list settings. The thing is my internal and SoB email is "abrod...@synopsys.com", while our email servers nicely convert that "shorter and supposedly ugly form" into more beautiful "alexey.brod...@synopsys.com" once email leaves company's premises. So I added the latter email as an alias and on the second attempt it was accepted by the mailing list. Let's see. I'm going to post another patch now and hopefully it will work as it should. If of any interest, I may add you as a Cc for it (it's for OE/gcc). -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [linux-yocto] [PATCH] ARC: Rename nSIM HS to HAPS HS
Hi Bruce, > The author as it comes in on your patches is rejected by the yocto git > servers, so yes, it had to be fixed up. Do you know what needs to be done to get that fixed? I hope to keep sending patches from time to time (and was about to send yet another one just now), so would be good to make things simpler and exclude that manual fix-up step. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: Rename nSIM HS to HAPS HS
In v5.5 kernel we merged "nsim_hs" config into "haps_hs", see [1], and from then on we use the same one "haps_hs" for everything simulated: nSIM/QEMU/FPGA. Of important notes: * We switched from legacy ARC UART to a standard DW UART * QEMU port for ARC is under review upstream, see [2]. But even today with WIP version from our GitHub fork [3] its possible to run this image for "hapshs" machine as simple as: ->8-- $ qemu-system-arc -cpu archs -M virt -nographic -no-reboot -monitor none \ -kernel build/tmp-glibc/deploy/images/hapshs/vmlinux-initramfs-hapshs.bin ->8-- [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1681baa713aa138d3f0f77f05c3de1cd6416c7d6 [2] https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg00458.html [3] https://github.com/foss-for-synopsys-dwc-arc-processors/qemu Signed-off-by: Alexey Brodkin --- .../nsimhs-standard.scc => hapshs/hapshs-standard.scc} | 4 ++-- bsp/hapshs/hapshs.cfg| 12 bsp/{nsimhs/nsimhs.scc => hapshs/hapshs.scc} | 2 +- bsp/nsimhs/nsimhs.cfg| 10 -- 4 files changed, 15 insertions(+), 13 deletions(-) rename bsp/{nsimhs/nsimhs-standard.scc => hapshs/hapshs-standard.scc} (72%) create mode 100644 bsp/hapshs/hapshs.cfg rename bsp/{nsimhs/nsimhs.scc => hapshs/hapshs.scc} (54%) delete mode 100644 bsp/nsimhs/nsimhs.cfg diff --git a/bsp/nsimhs/nsimhs-standard.scc b/bsp/hapshs/hapshs-standard.scc similarity index 72% rename from bsp/nsimhs/nsimhs-standard.scc rename to bsp/hapshs/hapshs-standard.scc index 3201ca52..1842b00c 100644 --- a/bsp/nsimhs/nsimhs-standard.scc +++ b/bsp/hapshs/hapshs-standard.scc @@ -1,8 +1,8 @@ # SPDX-License-Identifier: MIT -define KMACHINE nsimhs +define KMACHINE hapshs define KTYPE standard define KARCH arc include ktypes/standard/standard.scc -include nsimhs.scc +include hapshs.scc diff --git a/bsp/hapshs/hapshs.cfg b/bsp/hapshs/hapshs.cfg new file mode 100644 index ..adcc0531 --- /dev/null +++ b/bsp/hapshs/hapshs.cfg @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: MIT +# ARCv2 ISA +CONFIG_ISA_ARCV2=y + +# Serial port +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_DW=y +CONFIG_SERIAL_OF_PLATFORM=y + +# Built-in .dtb +CONFIG_ARC_BUILTIN_DTB_NAME="haps_hs" diff --git a/bsp/nsimhs/nsimhs.scc b/bsp/hapshs/hapshs.scc similarity index 54% rename from bsp/nsimhs/nsimhs.scc rename to bsp/hapshs/hapshs.scc index 3c1613a6..ea2b8b6c 100644 --- a/bsp/nsimhs/nsimhs.scc +++ b/bsp/hapshs/hapshs.scc @@ -1,2 +1,2 @@ # SPDX-License-Identifier: MIT -kconf hardware nsimhs.cfg +kconf hardware hapshs.cfg diff --git a/bsp/nsimhs/nsimhs.cfg b/bsp/nsimhs/nsimhs.cfg deleted file mode 100644 index 34580a39.. --- a/bsp/nsimhs/nsimhs.cfg +++ /dev/null @@ -1,10 +0,0 @@ -# SPDX-License-Identifier: MIT -# ARCv2 ISA -CONFIG_ISA_ARCV2=y - -# Legacy ARC UART -CONFIG_SERIAL_ARC=y -CONFIG_SERIAL_ARC_CONSOLE=y - -# Built-in .dtb -CONFIG_ARC_BUILTIN_DTB_NAME="nsim_hs" -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: Rename nSIM HS to HAPS HS
In v5.5 kernel we merged "nsim_hs" config into "haps_hs", see [1], and from then on we use the same one "haps_hs" for everything simulated: nSIM/QEMU/FPGA. Of important notes: * We switched from legacy ARC UART to a standard DW UART * QEMU port for ARC is under review upstream, see [2]. But even today with WIP version from our GitHub fork [3] its possible to run this image for "hapshs" machine as simple as: ->8-- $ qemu-system-arc -cpu archs -M virt -nographic -no-reboot -monitor none \ -kernel build/tmp-glibc/deploy/images/hapshs/vmlinux-initramfs-hapshs.bin ->8-- [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1681baa713aa138d3f0f77f05c3de1cd6416c7d6 [2] https://lists.gnu.org/archive/html/qemu-devel/2021-04/msg00458.html [3] https://github.com/foss-for-synopsys-dwc-arc-processors/qemu Signed-off-by: Alexey Brodkin --- .../nsimhs-standard.scc => hapshs/hapshs-standard.scc} | 4 ++-- bsp/hapshs/hapshs.cfg| 12 bsp/{nsimhs/nsimhs.scc => hapshs/hapshs.scc} | 2 +- bsp/nsimhs/nsimhs.cfg| 10 -- 4 files changed, 15 insertions(+), 13 deletions(-) rename bsp/{nsimhs/nsimhs-standard.scc => hapshs/hapshs-standard.scc} (72%) create mode 100644 bsp/hapshs/hapshs.cfg rename bsp/{nsimhs/nsimhs.scc => hapshs/hapshs.scc} (54%) delete mode 100644 bsp/nsimhs/nsimhs.cfg diff --git a/bsp/nsimhs/nsimhs-standard.scc b/bsp/hapshs/hapshs-standard.scc similarity index 72% rename from bsp/nsimhs/nsimhs-standard.scc rename to bsp/hapshs/hapshs-standard.scc index 3201ca52..1842b00c 100644 --- a/bsp/nsimhs/nsimhs-standard.scc +++ b/bsp/hapshs/hapshs-standard.scc @@ -1,8 +1,8 @@ # SPDX-License-Identifier: MIT -define KMACHINE nsimhs +define KMACHINE hapshs define KTYPE standard define KARCH arc include ktypes/standard/standard.scc -include nsimhs.scc +include hapshs.scc diff --git a/bsp/hapshs/hapshs.cfg b/bsp/hapshs/hapshs.cfg new file mode 100644 index ..adcc0531 --- /dev/null +++ b/bsp/hapshs/hapshs.cfg @@ -0,0 +1,12 @@ +# SPDX-License-Identifier: MIT +# ARCv2 ISA +CONFIG_ISA_ARCV2=y + +# Serial port +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +CONFIG_SERIAL_8250_DW=y +CONFIG_SERIAL_OF_PLATFORM=y + +# Built-in .dtb +CONFIG_ARC_BUILTIN_DTB_NAME="haps_hs" diff --git a/bsp/nsimhs/nsimhs.scc b/bsp/hapshs/hapshs.scc similarity index 54% rename from bsp/nsimhs/nsimhs.scc rename to bsp/hapshs/hapshs.scc index 3c1613a6..ea2b8b6c 100644 --- a/bsp/nsimhs/nsimhs.scc +++ b/bsp/hapshs/hapshs.scc @@ -1,2 +1,2 @@ # SPDX-License-Identifier: MIT -kconf hardware nsimhs.cfg +kconf hardware hapshs.cfg diff --git a/bsp/nsimhs/nsimhs.cfg b/bsp/nsimhs/nsimhs.cfg deleted file mode 100644 index 34580a39.. --- a/bsp/nsimhs/nsimhs.cfg +++ /dev/null @@ -1,10 +0,0 @@ -# SPDX-License-Identifier: MIT -# ARCv2 ISA -CONFIG_ISA_ARCV2=y - -# Legacy ARC UART -CONFIG_SERIAL_ARC=y -CONFIG_SERIAL_ARC_CONSOLE=y - -# Built-in .dtb -CONFIG_ARC_BUILTIN_DTB_NAME="nsim_hs" -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: Bug#980963: dpkg: Please add ARC architecture
Hi Helmut, > On Sat, Feb 06, 2021 at 07:25:35PM +0000, Alexey Brodkin wrote: > > Any chances to get updates on this one some time soon? > > No. The triplet cannot be changed once added. Therefore, the addition is > often deferred. The absence of the triplet can easily be worked around. > A bootstrap can be prototyped already. A major missing piece though is > glibc 2.32 being packaged in Debian. That likely is a prerequisite for > resolving this bug. Well not sure why there's a dependency on glibc as w/o ARC target support in dpkg nothing could be built for ARC. For example I did built Binutils with fixed dpkg. > Things that often need architecture-specific support for a new > architecture include: > * guile-X.Y (cross support) > * libgc Above 2 are not [yet] supported but seems to be easy ones. > * libxcrypt (symbols) Not sure about "libxcrypt" (whatver that means), but libgpg-error supports ARC since 2018, see: https://github.com/gpg/libgpg-error/commit/48c8f8ddfc80551db7615e1eb3555c1dc3f6a657 > * nspr Done in 2019, see https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76 > * openssl (packaging) Not sure what needs to be done here as I know we build a lot of complex things with OpenEmbedded/Yocto and openssl libs are being built for sure. > Are any of these fixed or confirmed working for arc? See above, quite some do work. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: dpkg: Please add ARC architecture
Hello, Any chances to get updates on this one some time soon? Regards, Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH 18/20] arch: dts: Fix EHCI/OHCI DT nodes name
Hi Sergey, > arch/arc/boot/dts/axs10x_mb.dtsi | 4 ++-- > arch/arc/boot/dts/hsdk.dts | 4 ++-- > arch/arc/boot/dts/vdk_axs10x_mb.dtsi | 2 +- For ARC boards Acked-by: Alexey Brodkin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH] ARC: [plat-hsdk]: Switch ethernet phy-mode to rgmii-id
Hi Vineet, Evgeniy! > From: Vineet Gupta > Sent: Tuesday, September 1, 2020 9:41 PM > To: Evgeniy Didin ; linux-snps-arc@lists.infradead.org > > Cc: Alexey Brodkin ; Eugeniy Paltsev > > Subject: Re: [PATCH] ARC: [plat-hsdk]: Switch ethernet phy-mode to rgmii-id > > On 7/7/20 8:38 AM, Evgeniy Didin wrote: > > HSDK board has Micrel KSZ9031, recent commit > > bcf3440c6dd ("net: phy: micrel: add phy-mode support for the KSZ9031 PHY") > > caused a breakdown of Ethernet. > > Using 'phy-mode = "rgmii"' is not correct because accodring RGMII > > specification it is necessary to have delay on RX (PHY to MAX) > > which is not generated in case of "rgmii". > > Using "rgmii-id" adds necessary delay and solves the issue. > > > > Also adding name of PHY placed on HSDK board. > > > > Signed-off-by: Evgeniy Didin > > Cc: Eugeniy Paltsev > > Cc: Alexey Brodkin > > @Alexey - u ok with this change ? Sure, Acked-by: Alexey Brodkin > > -Vineet > > > --- > > arch/arc/boot/dts/hsdk.dts | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts > > index 9acbeba832c0..d6427d47e5a1 100644 > > --- a/arch/arc/boot/dts/hsdk.dts > > +++ b/arch/arc/boot/dts/hsdk.dts > > @@ -208,7 +208,7 @@ > > reg = <0x8000 0x2000>; > > interrupts = <10>; > > interrupt-names = "macirq"; > > - phy-mode = "rgmii"; > > + phy-mode = "rgmii-id"; > > snps,pbl = <32>; > > snps,multicast-filter-bins = <256>; > > clocks = <&gmacclk>; > > @@ -226,7 +226,7 @@ > > #address-cells = <1>; > > #size-cells = <0>; > > compatible = "snps,dwmac-mdio"; > > - phy0: ethernet-phy@0 { > > + phy0: ethernet-phy@0 { /* Micrel KSZ9031 */ > > reg = <0>; > > }; > > }; > ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH v2 1/4] ARC: allow to override default mcpu compiler flag
Hi Eugeniy, A couple of minor notes below. > -Original Message- > From: Eugeniy Paltsev > Sent: Thursday, June 4, 2020 8:39 PM > To: linux-snps-arc@lists.infradead.org; Vineet Gupta > Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; > Eugeniy Paltsev > > Subject: [PATCH v2 1/4] ARC: allow to override default mcpu compiler flag > > Kernel builds set their own default -mcpu for a given ISA build. We used to use a default "-mcpu" per ARC ISA version (one for ARCompact and one for ARCv2). > But that gets in the way of "custom" -mcpu flags from propagating > into kernel build. But with more versions of CPUs & SoCs becoming available we want to be able to fine-tune generated code more precise. > This will also be used in next patches for HSDK-4xD board support which > uses a different -mcpu to effect dual issue scheduling. "...for utilization of the new CPU's dual-issue capabilities"? > +++ b/arch/arc/Makefile > @@ -10,8 +10,25 @@ CROSS_COMPILE := $(call cc-cross-prefix, arc-linux- > arceb-linux-) > endif > > cflags-y += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__ > -cflags-$(CONFIG_ISA_ARCOMPACT) += -mA7 > -cflags-$(CONFIG_ISA_ARCV2) += -mcpu=hs38 > + > +tune-mcpu-def-$(CONFIG_ISA_ARCOMPACT):= -mA7 I'd suggest to either swap "-mA7" which is being obsoleted with "-mcpu=arc700" right here or as a separate change, otherwise we may soon get ATC700 builds broken with newer compilers. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [RFC] ARC: initial ftrace support
Hi Claus, > -Original Message- > From: linux-snps-arc On Behalf > Of Claudiu Zissulescu > Ianculescu > Sent: Thursday, April 2, 2020 11:10 AM > To: Vineet Gupta > Cc: Alexey Brodkin ; linux-ker...@vger.kernel.org; > Steven Rostedt > ; Ingo Molnar ; > linux-snps-arc@lists.infradead.org; Eugeniy > Paltsev > Subject: Re: [RFC] ARC: initial ftrace support > > Hi, > > ARC-gcc has two modes to call the mcount routines. When using elf32 > configuration, the toolchain is set to use newlib mcount. When > configured for linux, gcc toolchain is using a library call to _mcall > (single underscore) having blink as input argument. > So, using the proper linux toolchain, your patch should work. Is there a chance to switch to Linux-style mcount in Elf32 toolchain with a command-line option? Otherwise I guess we'll need to implement some warning which explicitly says why Elf32 toolchain is not usable for building the Linux kernel... at least in case with ftrace enabled. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER
Hi Claus, > -Original Message- > From: linux-snps-arc On Behalf > Of Claudiu Zissulescu > Ianculescu > Sent: Tuesday, March 31, 2020 1:07 PM > To: Vineet Gupta > Cc: linux-snps-arc@lists.infradead.org; gcc-patc...@gcc.gnu.org; Claudiu > Zissulescu > > Subject: Re: [PATCH] [ARC] Allow more ABIs in GLIBC_DYNAMIC_LINKER > > Pushed. Is this one eligible for being back-ported to older GCCs? At least GCC 9.x would be really good. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: Build regressions/improvements in v5.6
Hi Andy, Geert, > -Original Message- > From: Andy Shevchenko > Sent: Monday, March 30, 2020 4:28 PM > To: Geert Uytterhoeven ; Alexey Brodkin > > Cc: Linux Kernel Mailing List > Subject: Re: Build regressions/improvements in v5.6 > > On Mon, Mar 30, 2020 at 4:26 PM Geert Uytterhoeven > wrote: > > > > Hi Andy, > > > > On Mon, Mar 30, 2020 at 3:08 PM Andy Shevchenko > > wrote: > > > On Mon, Mar 30, 2020 at 12:00 PM Geert Uytterhoeven > > > wrote: > > > > Below is the list of build error/warning regressions/improvements in > > > > v5.6[1] compared to v5.5[2]. > > > > > > > + /kisskb/src/include/linux/dev_printk.h: warning: format '%zu' > > > > expects argument of type > 'size_t', but argument 8 has type 'unsigned int' [-Wformat=]: => 232:23 > > > > > > This is interesting... I checked all dev_WARN_ONCE() and didn't find an > > > issue. > > > > arcv2/axs103_smp_defconfig > > > > It's probably due to a broken configuration for the arc toolchain. > > Alexey, do have any insight? I think I do have some but first I'd like to get it reproduced myself. I just built v5.6 with help of both GCC 8.3.1- & 9.3.1-based toolchains and didn't see a single warning. So I guess I was doing something wrong. FWIW 1. My GCC 8.3.1 toolchain was exactly this: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2019.09-release/arc_gnu_2019.09_prebuilt_uclibc_le_archs_linux_install.tar.gz 2. Linux kernel is vanilla v5.6.0 3. Configured and built as simple as: make axs103_smp_defconfig && make -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Helmut, > > 2. libgpg-error has ARC support since v1.33, see: > > > > https://urldefense.proofpoint.com/v2/url?u=http-3A__git.gnupg.org_cgi-2Dbin_gitweb.cgi-3Fp- > 3Dlibgpg-2Derror.git-3Ba-3Dcommit-3Bh- > 3D48c8f8ddfc80&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=_zJyx > Gdx_-O_dKHjFp6S-2ZXebEcmuHfmUsgpc4uEXA&s=myC306ViTlaxOV8nbOJR8pC74k2lsKmmB1hCGQR0PrE&e= > > This is only the native-support. For rebootstrap, we also need cross > build support, i.e. recording the generated lock-obj header (once glibc > is done). > > > And only for "libatomic-ops" & "guile" nothing has been done yet so if > > there's something > > that really needs to be done please let us know. > > I suggest that you focus on libatomic-ops then. And on glibc of course. > I guess that the other issues are easily solvable when they arise. Sorry for this stupid question but I'm not very familiar with use-cases for libatomic-ops so would like to get some more clarification on what's needed here. I know that GCC has quite a few built-ins for atomic ops and we do implement them. I'm adding our GCC maintainer (Claudiu) in the Cc so he may jump in if needed. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: ARC rebootstrap prereq (was Re: switching ARC to 64-bit time_t )
Hi Helmut, > On Wed, Mar 25, 2020 at 05:25:58PM -0700, Vineet Gupta wrote: > > ARC glibc is still in works, but assuming that will happen in near future > > what > > other upstream prerequisites are needed. The obvious ones would be Linux > > kernel, > > gcc, binutils: all 3 of which are supported for ARC. From a quick glance at > > debian > > wiki pages, I presume *bootstrap is mostly done native, so needs qemu ? > > (full/user > > emulation ? And does qemu need to be upstream too ? > > Given that I ran into the glibc issue, I can tell that at least > rudimentary arc support support is already available in Debian unstable > for binutils, linux and gcc. (Otherwise, I would not have come as far as > glibc.) Once glibc is in place, work can proceed on the Debian side. > guile, libatomic-ops, libffi, libgpg-error and nspr ususally need a > little upstream support. dpkg, gmp, openssl, and perl usually need > Debian-specific changes. I'd recommend looking into libatomic-ops and > libffi early. The other packages are usually simple. I guess almost all of the packages you mentioned already have needed improvements for ARC. 1. libffi has ARC support since v3.1, see: https://github.com/libffi/libffi/commit/b082e15091961373c03d10ed0251f619ebb6ed76 2. libgpg-error has ARC support since v1.33, see: http://git.gnupg.org/cgi-bin/gitweb.cgi?p=libgpg-error.git;a=commit;h=48c8f8ddfc80 3. nspr has ARC support since v4.1, see: https://hg.mozilla.org/projects/nspr/rev/cc73b6c7dab2e8053533e1f2c0c23dc721e10b76 And only for "libatomic-ops" & "guile" nothing has been done yet so if there's something that really needs to be done please let us know. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] ARC: [plat-axs10x]: PGU: remove unused encoder-slave property
Hi Eugeniy, > -Original Message- > From: Eugeniy Paltsev > Sent: Wednesday, March 11, 2020 10:37 PM > To: linux-snps-arc@lists.infradead.org; Vineet Gupta > Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; > Eugeniy Paltsev > > Subject: [PATCH] ARC: [plat-axs10x]: PGU: remove unused encoder-slave property > > ARC PGU is looking for encoder via endpoint mechanism and doesn't > use "encoder-slave" property for a long time. Let's drop unused > "encoder-slave" property from ARC PGU node in axs10x. > > Signed-off-by: Eugeniy Paltsev Acked-by: Alexey Brodkin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[GIT PULL] drm/arc: Filter out interlaced mode
Hi David, Daniel! The following changes since commit e3c3b6e66da1caeb39a504b03ddcdd3693e45254: Merge tag 'exynos-drm-fixes-for-v5.6-rc5-v2' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-fixes (2020-03-12 11:02:52 +1000) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2020.03.12 for you to fetch changes up to 1e8928584e8f29c31c8db1a50b5bdb1769047434: DRM: ARC: PGU: interlaced mode not supported (2020-03-12 07:59:06 +0300) There's just one tiny fix this time around with explicit filtering of interlaced modes as they are not supported by ARC PGU hardware. Eugeniy Paltsev (1): DRM: ARC: PGU: interlaced mode not supported drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++ 1 file changed, 3 insertions(+) Note this is based on the current drm/drm-fixes contents. Thanks, Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] DRM: ARC: PGU: interlaced mode not supported
Hi Greg, > -Original Message- > From: Greg KH > Sent: Wednesday, March 11, 2020 8:22 PM > To: Eugeniy Paltsev > Cc: dri-de...@lists.freedesktop.org; Alexey Brodkin ; > linux-snps- > a...@lists.infradead.org; linux-ker...@vger.kernel.org; David Airlie > ; Daniel Vetter > ; sta...@vger.kernel.org > Subject: Re: [PATCH] DRM: ARC: PGU: interlaced mode not supported > > On Wed, Mar 11, 2020 at 04:13:10PM +0300, Eugeniy Paltsev wrote: > > Filter out interlaced modes as they are not supported by ARC PGU > > hardware. > > > > Signed-off-by: Eugeniy Paltsev > > --- > > drivers/gpu/drm/arc/arcpgu_crtc.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c > > b/drivers/gpu/drm/arc/arcpgu_crtc.c > > index 8ae1e1f97a73..c854066d4c75 100644 > > --- a/drivers/gpu/drm/arc/arcpgu_crtc.c > > +++ b/drivers/gpu/drm/arc/arcpgu_crtc.c > > @@ -67,6 +67,9 @@ static enum drm_mode_status > > arc_pgu_crtc_mode_valid(struct drm_crtc *crtc, > > long rate, clk_rate = mode->clock * 1000; > > long diff = clk_rate / 200; /* +-0.5% allowed by HDMI spec */ > > > > + if (mode->flags & DRM_MODE_FLAG_INTERLACE) > > + return MODE_NO_INTERLACE; > > + > > rate = clk_round_rate(arcpgu->clk, clk_rate); > > if ((max(rate, clk_rate) - min(rate, clk_rate) < diff) && (rate > 0)) > > return MODE_OK; > > -- > > 2.21.1 > > > > > > This is not the correct way to submit patches for inclusion in the > stable kernel tree. Please read: > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.kernel.org_doc_html_latest_process_stable-2Dkernel- > 2Drules.html&d=DwIBAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=oXPD1Sz > FBs-0-4u24Ah1rK1Y65Fma8tJZix0Jih-yqY&s=WTVW1dC7E2oD0muPxtNd9KAHzwIZwEU9jGuCHWx1iQk&e= > for how to do this properly. > > Thanks for the comment. I'll add "Cc: sta...@vger.kernel.org" tag to the patch on committing it to my maintainer tree so one the patch makes its way up to the Linus' tree you'll get notified as usual. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 2/3 v2] ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking
We don't have yet any brc700 or big-enadian platforms with networking support to run this particular configuration. Whenever QEMU for ARC supports arc700 or big-endian targets we may revisit this one. Signed-off-by: Alexey Brodkin --- No changes v1 -> v2. configs/nsim_700_defconfig| 1 + configs/nsim_700be_defconfig | 1 + configs/nsim_hs38be_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig index 2d4a58b178..6a38e2c246 100644 --- a/configs/nsim_700_defconfig +++ b/configs/nsim_700_defconfig @@ -14,6 +14,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig index 61eea91449..d3ed84a415 100644 --- a/configs/nsim_700be_defconfig +++ b/configs/nsim_700be_defconfig @@ -15,6 +15,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig index 5d2ea59d52..b074b4ca98 100644 --- a/configs/nsim_hs38be_defconfig +++ b/configs/nsim_hs38be_defconfig @@ -16,6 +16,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 1/3 v2] ARC: nSIM: switch from ARC UART to DW UART
Since v2019.06 DesingWare nSIM supports DesignWare UART simulation and so we may switch from pretty unusual ARC UART to much more standard DesignWare UART (which in case of U-Boot is just an ordinary 16650 UART). This among other things makes built dinaries compatible with our other platforms to name a few: FPGA-based HAPS boards, QEMU and even ZeBU. Signed-off-by: Alexey Brodkin --- Changes v1 -> v2: * Copyright year bumped to 2020. arch/arc/dts/nsim.dts | 12 +++- configs/nsim_700_defconfig| 8 configs/nsim_700be_defconfig | 8 configs/nsim_hs38_defconfig | 8 configs/nsim_hs38be_defconfig | 8 5 files changed, 23 insertions(+), 21 deletions(-) diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts index 243ecb178e..43f281dfec 100644 --- a/arch/arc/dts/nsim.dts +++ b/arch/arc/dts/nsim.dts @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com) + * Copyright (C) 2015-2016, 2020 Synopsys, Inc. (www.synopsys.com) */ /dts-v1/; @@ -10,7 +10,7 @@ model = "snps,nsim"; aliases { - console = &arcuart0; + console = &uart0; }; cpu_card { @@ -22,9 +22,11 @@ }; }; - arcuart0: serial@0xc0fc1000 { - compatible = "snps,arc-uart"; - reg = <0xc0fc1000 0x100>; + uart0: serial@f000 { + compatible = "snps,dw-apb-uart"; + reg = <0xf000 0x1000>; + reg-shift = <2>; + reg-io-width = <4>; clock-frequency = <7000>; }; diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig index 5633113b09..2d4a58b178 100644 --- a/configs/nsim_700_defconfig +++ b/configs/nsim_700_defconfig @@ -1,13 +1,13 @@ CONFIG_ARC=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyARC0,115200n8" +CONFIG_BOOTARGS="console=ttyS0,115200n8" CONFIG_SYS_PROMPT="nsim# " # CONFIG_CMD_SETEXPR is not set CONFIG_OF_CONTROL=y @@ -16,6 +16,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_DM_SERIAL=y -CONFIG_DEBUG_ARC_SERIAL=y -CONFIG_ARC_SERIAL=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig index 40f7ec7e1f..61eea91449 100644 --- a/configs/nsim_700be_defconfig +++ b/configs/nsim_700be_defconfig @@ -2,13 +2,13 @@ CONFIG_ARC=y CONFIG_CPU_BIG_ENDIAN=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyARC0,115200n8" +CONFIG_BOOTARGS="console=ttyS0,115200n8" CONFIG_SYS_PROMPT="nsim# " # CONFIG_CMD_SETEXPR is not set CONFIG_OF_CONTROL=y @@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_DM_SERIAL=y -CONFIG_DEBUG_ARC_SERIAL=y -CONFIG_ARC_SERIAL=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig index 2820a6fca3..ce68de3251 100644 --- a/configs/nsim_hs38_defconfig +++ b/configs/nsim_hs38_defconfig @@ -2,13 +2,13 @@ CONFIG_ARC=y CONFIG_ISA_ARCV2=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyARC0,115200n8" +CONFIG_BOOTARGS="console=ttyS0,115200n8" CONFIG_SYS_PROMPT="nsim# " # CONFIG_CMD_SETEXPR is not set CONFIG_OF_CONTROL=y @@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_DM_SERIAL=y -CONFIG_DEBUG_ARC_SERIAL=y -CONFIG_ARC_SERIAL=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig index e533fae2b1..5d2ea59d52 100644 --- a/configs/nsim_hs38be_defconfig +++ b/configs/nsim_hs38be_defconfig @@ -3,13 +3,13 @@ CONFIG_ISA_ARCV2=y CONFIG_CPU_BIG_ENDIAN=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=
[PATCH 3/3 v2] ARC: nsim_hs38: Add support of Virtio NET & BLK
Given now nsim_hs38 configuration is usable on QEMU and in QEMU we have Virtio working perfectly fine the next logical step is to add support of supported & known to work net & bkl to this config. Signed-off-by: Alexey Brodkin --- Changes v1 -> v2: * Instead of adding IRQ parent it might be much cleaner solution to just get rid of "interrupt" properties in Virtio nodes. Again that's all OK for now since we don't really sync Linux .dts and U-Boot's ones. It's not that it's super good though but that's what we have today :) arch/arc/Kconfig | 4 ++-- arch/arc/dts/nsim.dts | 24 board/synopsys/{ => nsim}/Kconfig | 3 +++ board/synopsys/nsim/MAINTAINERS | 6 ++ board/synopsys/nsim/Makefile | 7 +++ board/synopsys/nsim/nsim.c| 26 ++ configs/nsim_hs38_defconfig | 9 + 7 files changed, 77 insertions(+), 2 deletions(-) rename board/synopsys/{ => nsim}/Kconfig (74%) create mode 100644 board/synopsys/nsim/MAINTAINERS create mode 100644 board/synopsys/nsim/Makefile create mode 100644 board/synopsys/nsim/nsim.c diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 0cb97207db..545fc3e243 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -160,7 +160,7 @@ config TARGET_TB100 bool "Support tb100" config TARGET_NSIM - bool "Support standalone nSIM & Free nSIM" + bool "Support ARC simulation & prototyping platforms" config TARGET_AXS101 bool "Support Synopsys Designware SDP board AXS101" @@ -184,10 +184,10 @@ config TARGET_IOT_DEVKIT endchoice source "board/abilis/tb100/Kconfig" -source "board/synopsys/Kconfig" source "board/synopsys/axs10x/Kconfig" source "board/synopsys/emsdp/Kconfig" source "board/synopsys/hsdk/Kconfig" source "board/synopsys/iot_devkit/Kconfig" +source "board/synopsys/nsim/Kconfig" endmenu diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts index 43f281dfec..c2899ef2ea 100644 --- a/arch/arc/dts/nsim.dts +++ b/arch/arc/dts/nsim.dts @@ -30,4 +30,28 @@ clock-frequency = <7000>; }; + virtio0: virtio@f010 { + compatible = "virtio,mmio"; + reg = <0xf010 0x2000>; + }; + + virtio1: virtio@f0102000 { + compatible = "virtio,mmio"; + reg = <0xf0102000 0x2000>; + }; + + virtio2: virtio@f0104000 { + compatible = "virtio,mmio"; + reg = <0xf0104000 0x2000>; + }; + + virtio3: virtio@f0106000 { + compatible = "virtio,mmio"; + reg = <0xf0106000 0x2000>; + }; + + virtio4: virtio@f0108000 { + compatible = "virtio,mmio"; + reg = <0xf0108000 0x2000>; + }; }; diff --git a/board/synopsys/Kconfig b/board/synopsys/nsim/Kconfig similarity index 74% rename from board/synopsys/Kconfig rename to board/synopsys/nsim/Kconfig index 27e5509b26..22287032bf 100644 --- a/board/synopsys/Kconfig +++ b/board/synopsys/nsim/Kconfig @@ -1,5 +1,8 @@ if TARGET_NSIM +config SYS_BOARD + default "nsim" + config SYS_VENDOR default "synopsys" diff --git a/board/synopsys/nsim/MAINTAINERS b/board/synopsys/nsim/MAINTAINERS new file mode 100644 index 00..ad23c8338e --- /dev/null +++ b/board/synopsys/nsim/MAINTAINERS @@ -0,0 +1,6 @@ +ARC SIMULATION & PROTOTYPING PLATFORMS +M: Alexey Brodkin +S: Maintained +F: arch/arc/dts/nsim.dts +F: board/synopsys/nsim/ +F: configs/nsim_*_defconfig diff --git a/board/synopsys/nsim/Makefile b/board/synopsys/nsim/Makefile new file mode 100644 index 00..6aaa73 --- /dev/null +++ b/board/synopsys/nsim/Makefile @@ -0,0 +1,7 @@ +# +# Copyright (C) 2020 Synopsys, Inc. All rights reserved. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y += nsim.o diff --git a/board/synopsys/nsim/nsim.c b/board/synopsys/nsim/nsim.c new file mode 100644 index 00..f384f707f6 --- /dev/null +++ b/board/synopsys/nsim/nsim.c @@ -0,0 +1,26 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2020 Synopsys, Inc. All rights reserved. + */ + +#include +#include +#include +#include + +int board_early_init_r(void) +{ + /* +* Make sure virtio bus is enumerated so that peripherals +* on the virtio bus can be discovered by their drivers +*/ + virtio_init(); + + return 0; +} + +int checkboard(void) +{ + printf("Board: ARC virtual or prototyping platform\n"); + return 0; +}; diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig index ce68de3251..6cd01a505b 100644 --
[RFC 1/2] include: Import non-atomic.h from Linux
This header contains implementations of some common bit ops: * __set_bit()/__clear_bit()/__change_bit()/test_bit() * __test_and_set_bit()/__test_and_clear_bit()/__test_and_change_bit() No point in copy-pasting that again & again. Signed-off-by: Alexey Brodkin --- include/asm-generic/bitops/non-atomic.h | 109 1 file changed, 109 insertions(+) create mode 100644 include/asm-generic/bitops/non-atomic.h diff --git a/include/asm-generic/bitops/non-atomic.h b/include/asm-generic/bitops/non-atomic.h new file mode 100644 index 00..9b3be37fff --- /dev/null +++ b/include/asm-generic/bitops/non-atomic.h @@ -0,0 +1,109 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +#ifndef _ASM_GENERIC_BITOPS_NON_ATOMIC_H_ +#define _ASM_GENERIC_BITOPS_NON_ATOMIC_H_ + +#include + +/** + * __set_bit - Set a bit in memory + * @nr: the bit to set + * @addr: the address to start counting from + * + * Unlike set_bit(), this function is non-atomic and may be reordered. + * If it's called on the same region of memory simultaneously, the effect + * may be that only one operation succeeds. + */ +static inline void __set_bit(int nr, volatile unsigned long *addr) +{ + unsigned long mask = BIT_MASK(nr); + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr); + + *p |= mask; +} + +static inline void __clear_bit(int nr, volatile unsigned long *addr) +{ + unsigned long mask = BIT_MASK(nr); + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr); + + *p &= ~mask; +} + +/** + * __change_bit - Toggle a bit in memory + * @nr: the bit to change + * @addr: the address to start counting from + * + * Unlike change_bit(), this function is non-atomic and may be reordered. + * If it's called on the same region of memory simultaneously, the effect + * may be that only one operation succeeds. + */ +static inline void __change_bit(int nr, volatile unsigned long *addr) +{ + unsigned long mask = BIT_MASK(nr); + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr); + + *p ^= mask; +} + +/** + * __test_and_set_bit - Set a bit and return its old value + * @nr: Bit to set + * @addr: Address to count from + * + * This operation is non-atomic and can be reordered. + * If two examples of this operation race, one can appear to succeed + * but actually fail. You must protect multiple accesses with a lock. + */ +static inline int __test_and_set_bit(int nr, volatile unsigned long *addr) +{ + unsigned long mask = BIT_MASK(nr); + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr); + unsigned long old = *p; + + *p = old | mask; + return (old & mask) != 0; +} + +/** + * __test_and_clear_bit - Clear a bit and return its old value + * @nr: Bit to clear + * @addr: Address to count from + * + * This operation is non-atomic and can be reordered. + * If two examples of this operation race, one can appear to succeed + * but actually fail. You must protect multiple accesses with a lock. + */ +static inline int __test_and_clear_bit(int nr, volatile unsigned long *addr) +{ + unsigned long mask = BIT_MASK(nr); + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr); + unsigned long old = *p; + + *p = old & ~mask; + return (old & mask) != 0; +} + +/* WARNING: non atomic and it can be reordered! */ +static inline int __test_and_change_bit(int nr, + volatile unsigned long *addr) +{ + unsigned long mask = BIT_MASK(nr); + unsigned long *p = ((unsigned long *)addr) + BIT_WORD(nr); + unsigned long old = *p; + + *p = old ^ mask; + return (old & mask) != 0; +} + +/** + * test_bit - Determine whether a bit is set + * @nr: bit number to test + * @addr: Address to start counting from + */ +static inline int test_bit(int nr, const volatile unsigned long *addr) +{ + return 1UL & (addr[BIT_WORD(nr)] >> (nr & (BITS_PER_LONG - 1))); +} + +#endif /* _ASM_GENERIC_BITOPS_NON_ATOMIC_H_ */ -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[RFC 2/2] ARC: Add support of bitops via generic implementation
This allows building more things. In particular with CONFIG_PKCS7_MESSAGE_PARSER=y we saw this: >8-- lib/crypto/pkcs7_parser.c: In function 'pkcs7_sig_note_authenticated_attr': lib/crypto/pkcs7_parser.c:489:7: warning: implicit declaration of function '__test_and_set_bit' [-Wimplicit-function-declaration] 489 | if (__test_and_set_bit(sinfo_has_content_type, &sinfo->aa_set)) | ^~ CC lib/crc32.o CC lib/ctype.o DTB test/overlay/test-fdt-overlay-stacked.dtb.S CC lib/div64.o lib/crypto/pkcs7_parser.c: In function 'pkcs7_sig_note_set_of_authattrs': lib/crypto/pkcs7_parser.c:572:7: warning: implicit declaration of function 'test_bit' [-Wimplicit-function-declaration] 572 | if (!test_bit(sinfo_has_content_type, &sinfo->aa_set) || ... LD u-boot arc-elf32-ld.bfd: lib/built-in.o: in function 'pkcs7_sig_note_authenticated_attr': .../lib/crypto/pkcs7_parser.c:489: undefined reference to '__test_and_set_bit' arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:489: undefined reference to '__test_and_set_bit' arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:501: undefined reference to '__test_and_set_bit' arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:501: undefined reference to '__test_and_set_bit' arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:510: undefined reference to '__test_and_set_bit' arc-elf32-ld.bfd: lib/built-in.o:.../lib/crypto/pkcs7_parser.c:510: more undefined references to '__test_and_set_bit' follow arc-elf32-ld.bfd: lib/built-in.o: in function 'pkcs7_sig_note_set_of_authattrs': .../lib/crypto/pkcs7_parser.c:572: undefined reference to `test_bit' arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:572: undefined reference to `test_bit' arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:573: undefined reference to `test_bit' arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:573: undefined reference to `test_bit' arc-elf32-ld.bfd: .../lib/crypto/pkcs7_parser.c:579: undefined reference to `test_bit' arc-elf32-ld.bfd: lib/built-in.o:.../lib/crypto/pkcs7_parser.c:579: more undefined references to 'test_bit' follow >8-- Signed-off-by: Alexey Brodkin --- arch/arc/include/asm/bitops.h | 1 + 1 file changed, 1 insertion(+) diff --git a/arch/arc/include/asm/bitops.h b/arch/arc/include/asm/bitops.h index c6dd28ecef..daa07e80a8 100644 --- a/arch/arc/include/asm/bitops.h +++ b/arch/arc/include/asm/bitops.h @@ -19,5 +19,6 @@ #include #include #include +#include #endif /* __ASM_ARC_BITOPS_H */ -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[RFC 0/2] Import and use non-atomic bit-ops
The following bitops are implemented pretty similarly for many arches and now when we faced a need in them on ARC I guess there's no point in copy-pasting them yet another time but instead it might be better re-use generic version from the Linux kernel. Since we had non of those bitops for ARC inclusion of imported header works perfectly fine. As for other arches I do see they use a bit different implementation but those might be just older versions etc. Sobefore breaking stuff for other arches I'd like to get some feedback from maintainers. Or we may just import proposed header and switch to its usage arch-by-arch whenever people feel kile cleaning-up their bitops. Alexey Brodkin (2): include: Import non-atomic.h from Linux ARC: Add support of bitops via generic implementation arch/arc/include/asm/bitops.h | 1 + include/asm-generic/bitops/non-atomic.h | 109 2 files changed, 110 insertions(+) create mode 100644 include/asm-generic/bitops/non-atomic.h -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 1/3] ARC: nSIM: switch from ARC UART to DW UART
Since v2019.06 DesingWare nSIM supports DesignWare UART simulation and so we may switch from pretty unusual ARC UART to much more standard DesignWare UART (which in case of U-Boot is just an ordinary 16650 UART). This among other things makes built dinaries compatible with our other platforms to name a few: FPGA-based HAPS boards, QEMU and even ZeBU. Signed-off-by: Alexey Brodkin --- arch/arc/dts/nsim.dts | 12 +++- configs/nsim_700_defconfig| 8 configs/nsim_700be_defconfig | 8 configs/nsim_hs38_defconfig | 8 configs/nsim_hs38be_defconfig | 8 5 files changed, 23 insertions(+), 21 deletions(-) diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts index 243ecb178e..a3f3964d35 100644 --- a/arch/arc/dts/nsim.dts +++ b/arch/arc/dts/nsim.dts @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com) + * Copyright (C) 2015-2016, 2019 Synopsys, Inc. (www.synopsys.com) */ /dts-v1/; @@ -10,7 +10,7 @@ model = "snps,nsim"; aliases { - console = &arcuart0; + console = &uart0; }; cpu_card { @@ -22,9 +22,11 @@ }; }; - arcuart0: serial@0xc0fc1000 { - compatible = "snps,arc-uart"; - reg = <0xc0fc1000 0x100>; + uart0: serial@f000 { + compatible = "snps,dw-apb-uart"; + reg = <0xf000 0x1000>; + reg-shift = <2>; + reg-io-width = <4>; clock-frequency = <7000>; }; diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig index 5633113b09..2d4a58b178 100644 --- a/configs/nsim_700_defconfig +++ b/configs/nsim_700_defconfig @@ -1,13 +1,13 @@ CONFIG_ARC=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyARC0,115200n8" +CONFIG_BOOTARGS="console=ttyS0,115200n8" CONFIG_SYS_PROMPT="nsim# " # CONFIG_CMD_SETEXPR is not set CONFIG_OF_CONTROL=y @@ -16,6 +16,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_DM_SERIAL=y -CONFIG_DEBUG_ARC_SERIAL=y -CONFIG_ARC_SERIAL=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig index 40f7ec7e1f..61eea91449 100644 --- a/configs/nsim_700be_defconfig +++ b/configs/nsim_700be_defconfig @@ -2,13 +2,13 @@ CONFIG_ARC=y CONFIG_CPU_BIG_ENDIAN=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyARC0,115200n8" +CONFIG_BOOTARGS="console=ttyS0,115200n8" CONFIG_SYS_PROMPT="nsim# " # CONFIG_CMD_SETEXPR is not set CONFIG_OF_CONTROL=y @@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_DM_SERIAL=y -CONFIG_DEBUG_ARC_SERIAL=y -CONFIG_ARC_SERIAL=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig index 2820a6fca3..ce68de3251 100644 --- a/configs/nsim_hs38_defconfig +++ b/configs/nsim_hs38_defconfig @@ -2,13 +2,13 @@ CONFIG_ARC=y CONFIG_ISA_ARCV2=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyARC0,115200n8" +CONFIG_BOOTARGS="console=ttyS0,115200n8" CONFIG_SYS_PROMPT="nsim# " # CONFIG_CMD_SETEXPR is not set CONFIG_OF_CONTROL=y @@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_DM_SERIAL=y -CONFIG_DEBUG_ARC_SERIAL=y -CONFIG_ARC_SERIAL=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig index e533fae2b1..5d2ea59d52 100644 --- a/configs/nsim_hs38be_defconfig +++ b/configs/nsim_hs38be_defconfig @@ -3,13 +3,13 @@ CONFIG_ISA_ARCV2=y CONFIG_CPU_BIG_ENDIAN=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="c
[PATCH 2/3] ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking
We don't have yet any brc700 or big-enadian platforms with networking support to run this particular configuration. Whenever QEMU for ARC supports arc700 or big-endian targets we may revisit this one. Signed-off-by: Alexey Brodkin --- configs/nsim_700_defconfig| 1 + configs/nsim_700be_defconfig | 1 + configs/nsim_hs38be_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig index 2d4a58b178..6a38e2c246 100644 --- a/configs/nsim_700_defconfig +++ b/configs/nsim_700_defconfig @@ -14,6 +14,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig index 61eea91449..d3ed84a415 100644 --- a/configs/nsim_700be_defconfig +++ b/configs/nsim_700be_defconfig @@ -15,6 +15,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig index 5d2ea59d52..b074b4ca98 100644 --- a/configs/nsim_hs38be_defconfig +++ b/configs/nsim_hs38be_defconfig @@ -16,6 +16,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 3/3] ARC: nsim_hs38: Add support of Virtio NET & BLK
Given now nsim_hs38 configuration is usable on QEMU and in QEMU we have Virtio working perfectly fine the next logical step is to add support of supported & known to work net & bkl to this config. Note so far we don't have device tree descriptions synced from the mainline Linux kernel (which we'll need to do anyway at some point) and as of now we keep U-Boot's device trees as minimalistic as possible in nSIM description we had to add core's interrupt controller node and set it as everyone's interrupt-parent. That's required to make buildman happy. Otherwise it complains like that: >8 w+arch/arc/dts/nsim.dtb: Warning (interrupts_property): /virtio@f010: Missing interrupt-parent >8-------- Signed-off-by: Alexey Brodkin --- arch/arc/Kconfig | 4 ++-- arch/arc/dts/nsim.dts | 36 board/synopsys/{ => nsim}/Kconfig | 3 +++ board/synopsys/nsim/MAINTAINERS | 6 ++ board/synopsys/nsim/Makefile | 7 +++ board/synopsys/nsim/nsim.c| 26 ++ configs/nsim_hs38_defconfig | 9 + 7 files changed, 89 insertions(+), 2 deletions(-) rename board/synopsys/{ => nsim}/Kconfig (74%) create mode 100644 board/synopsys/nsim/MAINTAINERS create mode 100644 board/synopsys/nsim/Makefile create mode 100644 board/synopsys/nsim/nsim.c diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 0cb97207db..545fc3e243 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -160,7 +160,7 @@ config TARGET_TB100 bool "Support tb100" config TARGET_NSIM - bool "Support standalone nSIM & Free nSIM" + bool "Support ARC simulation & prototyping platforms" config TARGET_AXS101 bool "Support Synopsys Designware SDP board AXS101" @@ -184,10 +184,10 @@ config TARGET_IOT_DEVKIT endchoice source "board/abilis/tb100/Kconfig" -source "board/synopsys/Kconfig" source "board/synopsys/axs10x/Kconfig" source "board/synopsys/emsdp/Kconfig" source "board/synopsys/hsdk/Kconfig" source "board/synopsys/iot_devkit/Kconfig" +source "board/synopsys/nsim/Kconfig" endmenu diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts index a3f3964d35..a902c4c4fa 100644 --- a/arch/arc/dts/nsim.dts +++ b/arch/arc/dts/nsim.dts @@ -8,6 +8,7 @@ / { model = "snps,nsim"; + interrupt-parent = <&core_intc>; aliases { console = &uart0; @@ -20,6 +21,12 @@ clock-frequency = <7000>; u-boot,dm-pre-reloc; }; + + core_intc: interrupt-controller { + compatible = "snps,archs-intc"; + interrupt-controller; + #interrupt-cells = <1>; + }; }; uart0: serial@f000 { @@ -30,4 +37,33 @@ clock-frequency = <7000>; }; + virtio0: virtio@f010 { + compatible = "virtio,mmio"; + reg = <0xf010 0x2000>; + interrupts = <31>; + }; + + virtio1: virtio@f0102000 { + compatible = "virtio,mmio"; + reg = <0xf0102000 0x2000>; + interrupts = <32>; + }; + + virtio2: virtio@f0104000 { + compatible = "virtio,mmio"; + reg = <0xf0104000 0x2000>; + interrupts = <33>; + }; + + virtio3: virtio@f0106000 { + compatible = "virtio,mmio"; + reg = <0xf0106000 0x2000>; + interrupts = <34>; + }; + + virtio4: virtio@f0108000 { + compatible = "virtio,mmio"; + reg = <0xf0108000 0x2000>; + interrupts = <35>; + }; }; diff --git a/board/synopsys/Kconfig b/board/synopsys/nsim/Kconfig similarity index 74% rename from board/synopsys/Kconfig rename to board/synopsys/nsim/Kconfig index 27e5509b26..22287032bf 100644 --- a/board/synopsys/Kconfig +++ b/board/synopsys/nsim/Kconfig @@ -1,5 +1,8 @@ if TARGET_NSIM +config SYS_BOARD + default "nsim" + config SYS_VENDOR default "synopsys" diff --git a/board/synopsys/nsim/MAINTAINERS b/board/synopsys/nsim/MAINTAINERS new file mode 100644 index 00..ed4b9a9e78 --- /dev/null +++ b/board/synopsys/nsim/MAINTAINERS @@ -0,0 +1,6 @@ +EM DEVELOPMENT KIT BOARD +M: Alexey Brodkin +S: Maintained +F: arch/arc/dts/nsim.dts +F: board/synopsys/nsim/ +F: configs/nsim_*_defconfig diff --git a/board/synopsys/nsim/Makefile b/board/synopsys/ns
[PATCH 0/3] Improvements for ARC simulation platform
Along with some clean-up we make 2 important changes: 1. Switch to more standard 16550 UART instead of our custom "ARC UART". This paves the way for using this board in QEMU. 2. Now when nSIM virtual board is usable in QEMU we add support of Virtio NIC & block device similarly as we did that in the Linux kernel [1]. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=94b8beb972c524f42078281c9950ed3a946455fa Alexey Brodkin (3): ARC: nSIM: switch from ARC UART to DW UART ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking ARC: nsim_hs38: Add support of Virtio NET & BLK arch/arc/Kconfig | 4 ++-- arch/arc/dts/nsim.dts | 48 +++ board/synopsys/{ => nsim}/Kconfig | 3 +++ board/synopsys/nsim/MAINTAINERS | 6 + board/synopsys/nsim/Makefile | 7 ++ board/synopsys/nsim/nsim.c| 26 + configs/nsim_700_defconfig| 9 configs/nsim_700be_defconfig | 9 configs/nsim_hs38_defconfig | 17 ++ configs/nsim_hs38be_defconfig | 9 10 files changed, 115 insertions(+), 23 deletions(-) rename board/synopsys/{ => nsim}/Kconfig (74%) create mode 100644 board/synopsys/nsim/MAINTAINERS create mode 100644 board/synopsys/nsim/Makefile create mode 100644 board/synopsys/nsim/nsim.c -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: Switch to generic accessors
First of all U-Boot is not that performance oriented as real run-time software like OS or user bare-metal app so we may afford being not super fast as we only being executed once. That in return allows us to be more universal and support wider variety of devices. And looking forward that will significantly reduce maintenance and simplify support of newer architectures. And while at it we add quad-word accessors like readq(), writeq() etc. Signed-off-by: Alexey Brodkin --- arch/arc/include/asm/io.h | 204 +- 1 file changed, 75 insertions(+), 129 deletions(-) diff --git a/arch/arc/include/asm/io.h b/arch/arc/include/asm/io.h index fa844b54f4..70d050590d 100644 --- a/arch/arc/include/asm/io.h +++ b/arch/arc/include/asm/io.h @@ -1,6 +1,6 @@ /* SPDX-License-Identifier: GPL-2.0+ */ /* - * Copyright (C) 2013-2014 Synopsys, Inc. All rights reserved. + * Copyright (C) 2013-2014, 2020 Synopsys, Inc. All rights reserved. */ #ifndef __ASM_ARC_IO_H @@ -54,135 +54,98 @@ static inline void sync(void) /* Not yet implemented */ } -static inline u8 __raw_readb(const volatile void __iomem *addr) -{ - u8 b; +#define __arch_getb(a) (*(unsigned char *)(a)) +#define __arch_getw(a) (*(unsigned short *)(a)) +#define __arch_getl(a) (*(unsigned int *)(a)) +#define __arch_getq(a) (*(unsigned long long *)(a)) - __asm__ __volatile__("ldb%U1%0, %1\n" -: "=r" (b) -: "m" (*(volatile u8 __force *)addr) -: "memory"); - return b; -} +#define __arch_putb(v, a) (*(unsigned char *)(a) = (v)) +#define __arch_putw(v, a) (*(unsigned short *)(a) = (v)) +#define __arch_putl(v, a) (*(unsigned int *)(a) = (v)) +#define __arch_putq(v, a) (*(unsigned long long *)(a) = (v)) -static inline u16 __raw_readw(const volatile void __iomem *addr) -{ - u16 s; +#define __raw_writeb(v, a) __arch_putb(v, a) +#define __raw_writew(v, a) __arch_putw(v, a) +#define __raw_writel(v, a) __arch_putl(v, a) +#define __raw_writeq(v, a) __arch_putq(v, a) - __asm__ __volatile__("ldw%U1%0, %1\n" -: "=r" (s) -: "m" (*(volatile u16 __force *)addr) -: "memory"); - return s; -} +#define __raw_readb(a) __arch_getb(a) +#define __raw_readw(a) __arch_getw(a) +#define __raw_readl(a) __arch_getl(a) +#define __raw_readq(a) __arch_getq(a) -static inline u32 __raw_readl(const volatile void __iomem *addr) +static inline void __raw_writesb(unsigned long addr, const void *data, +int bytelen) { - u32 w; + u8 *buf = (uint8_t *)data; - __asm__ __volatile__("ld%U1 %0, %1\n" -: "=r" (w) -: "m" (*(volatile u32 __force *)addr) -: "memory"); - return w; + while (bytelen--) + __arch_putb(*buf++, addr); } -static inline void __raw_writeb(u8 b, volatile void __iomem *addr) +static inline void __raw_writesw(unsigned long addr, const void *data, +int wordlen) { - __asm__ __volatile__("stb%U1%0, %1\n" -: -: "r" (b), "m" (*(volatile u8 __force *)addr) -: "memory"); -} + u16 *buf = (uint16_t *)data; -static inline void __raw_writew(u16 s, volatile void __iomem *addr) -{ - __asm__ __volatile__("stw%U1%0, %1\n" -: -: "r" (s), "m" (*(volatile u16 __force *)addr) -: "memory"); + while (wordlen--) + __arch_putw(*buf++, addr); } -static inline void __raw_writel(u32 w, volatile void __iomem *addr) +static inline void __raw_writesl(unsigned long addr, const void *data, +int longlen) { - __asm__ __volatile__("st%U1 %0, %1\n" -: -: "r" (w), "m" (*(volatile u32 __force *)addr) -: "memory"); -} + u32 *buf = (uint32_t *)data; -static inline int __raw_readsb(unsigned int addr, void *data, int bytelen) -{ - __asm__ __volatile__ ("1:ld.di r8, [r0]\n" - "sub.fr2, r2, 1\n" - "bnz.d1b\n" - "stb.ab r8, [r1, 1]\n" - : - : "r" (addr), "r" (data), &qu
[PATCH] ARC: Don't mess with endianess settings
There seem to be not that much sense in explicitly setting endianess flags for the tools as we assume the tool with required endianess is used. I.e. we use LE tools for building for LE targets and BE tools for BE targets. Signed-off-by: Alexey Brodkin --- arch/arc/config.mk | 10 -- 1 file changed, 10 deletions(-) diff --git a/arch/arc/config.mk b/arch/arc/config.mk index 18005d9993..4b8a0870eb 100644 --- a/arch/arc/config.mk +++ b/arch/arc/config.mk @@ -8,16 +8,6 @@ else CONFIG_SYS_BIG_ENDIAN = 1 endif -ifdef CONFIG_SYS_LITTLE_ENDIAN -PLATFORM_LDFLAGS += -EL -PLATFORM_CPPFLAGS += -mlittle-endian -endif - -ifdef CONFIG_SYS_BIG_ENDIAN -PLATFORM_LDFLAGS += -EB -PLATFORM_CPPFLAGS += -mbig-endian -endif - ifdef CONFIG_ARC_MMU_VER CONFIG_MMU = 1 endif -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH net 4/4] ARC: [plat-axs10x]: Add missing multicast filter number to GMAC node
Hi Jose, > -Original Message- > From: Jose Abreu > Sent: Tuesday, January 14, 2020 7:09 PM > To: net...@vger.kernel.org > Cc: Joao Pinto ; Jose Abreu ; > Alexey Brodkin > ; Rob Herring ; Mark Rutland > ; Vineet > Gupta ; devicet...@vger.kernel.org; > linux-snps-arc@lists.infradead.org; linux- > ker...@vger.kernel.org > Subject: [PATCH net 4/4] ARC: [plat-axs10x]: Add missing multicast filter > number to GMAC node > > Add a missing property to GMAC node so that multicast filtering works > correctly. > > Fixes: 556cc1c5f528 ("ARC: [axs101] Add support for AXS101 SDP (software > development platform)") > Signed-off-by: Jose Abreu Acked-by: Alexey Brodkin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH v2 5/9] arc: Constify ioreadX() iomem argument (as in generic implementation)
Hi Krzysztof, > The ioreadX() helpers have inconsistent interface. On some architectures > void *__iomem address argument is a pointer to const, on some not. > > Implementations of ioreadX() do not modify the memory under the > address so they can be converted to a "const" version for const-safety > and consistency among architectures. Thanks for this clean-up. Looks good to me, so ... Acked-by: Alexey Brodkin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 3/3] ARC: nsim_hs38: Add support of Virtio NET & BLK
Given now nsim_hs38 configuration is usable on QEMU and in QEMU we have Virtio working perfectly fine the next logical step is to add support of supported & known to work net & bkl to this config. Signed-off-by: Alexey Brodkin --- arch/arc/Kconfig | 4 ++-- arch/arc/dts/nsim.dts | 29 + board/synopsys/{ => nsim}/Kconfig | 3 +++ board/synopsys/nsim/MAINTAINERS | 6 ++ board/synopsys/nsim/Makefile | 7 +++ board/synopsys/nsim/nsim.c| 26 ++ configs/nsim_hs38_defconfig | 9 + 7 files changed, 82 insertions(+), 2 deletions(-) rename board/synopsys/{ => nsim}/Kconfig (74%) create mode 100644 board/synopsys/nsim/MAINTAINERS create mode 100644 board/synopsys/nsim/Makefile create mode 100644 board/synopsys/nsim/nsim.c diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 0cb97207db..545fc3e243 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -160,7 +160,7 @@ config TARGET_TB100 bool "Support tb100" config TARGET_NSIM - bool "Support standalone nSIM & Free nSIM" + bool "Support ARC simulation & prototyping platforms" config TARGET_AXS101 bool "Support Synopsys Designware SDP board AXS101" @@ -184,10 +184,10 @@ config TARGET_IOT_DEVKIT endchoice source "board/abilis/tb100/Kconfig" -source "board/synopsys/Kconfig" source "board/synopsys/axs10x/Kconfig" source "board/synopsys/emsdp/Kconfig" source "board/synopsys/hsdk/Kconfig" source "board/synopsys/iot_devkit/Kconfig" +source "board/synopsys/nsim/Kconfig" endmenu diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts index a3f3964d35..376a776a78 100644 --- a/arch/arc/dts/nsim.dts +++ b/arch/arc/dts/nsim.dts @@ -30,4 +30,33 @@ clock-frequency = <7000>; }; + virtio0: virtio@f010 { + compatible = "virtio,mmio"; + reg = <0xf010 0x2000>; + interrupts = <31>; + }; + + virtio1: virtio@f0102000 { + compatible = "virtio,mmio"; + reg = <0xf0102000 0x2000>; + interrupts = <32>; + }; + + virtio2: virtio@f0104000 { + compatible = "virtio,mmio"; + reg = <0xf0104000 0x2000>; + interrupts = <33>; + }; + + virtio3: virtio@f0106000 { + compatible = "virtio,mmio"; + reg = <0xf0106000 0x2000>; + interrupts = <34>; + }; + + virtio4: virtio@f0108000 { + compatible = "virtio,mmio"; + reg = <0xf0108000 0x2000>; + interrupts = <35>; + }; }; diff --git a/board/synopsys/Kconfig b/board/synopsys/nsim/Kconfig similarity index 74% rename from board/synopsys/Kconfig rename to board/synopsys/nsim/Kconfig index 27e5509b26..22287032bf 100644 --- a/board/synopsys/Kconfig +++ b/board/synopsys/nsim/Kconfig @@ -1,5 +1,8 @@ if TARGET_NSIM +config SYS_BOARD + default "nsim" + config SYS_VENDOR default "synopsys" diff --git a/board/synopsys/nsim/MAINTAINERS b/board/synopsys/nsim/MAINTAINERS new file mode 100644 index 00..ed4b9a9e78 --- /dev/null +++ b/board/synopsys/nsim/MAINTAINERS @@ -0,0 +1,6 @@ +EM DEVELOPMENT KIT BOARD +M: Alexey Brodkin +S: Maintained +F: arch/arc/dts/nsim.dts +F: board/synopsys/nsim/ +F: configs/nsim_*_defconfig diff --git a/board/synopsys/nsim/Makefile b/board/synopsys/nsim/Makefile new file mode 100644 index 00..f4bc65d213 --- /dev/null +++ b/board/synopsys/nsim/Makefile @@ -0,0 +1,7 @@ +# +# Copyright (C) 2019 Synopsys, Inc. All rights reserved. +# +# SPDX-License-Identifier: GPL-2.0+ +# + +obj-y += nsim.o diff --git a/board/synopsys/nsim/nsim.c b/board/synopsys/nsim/nsim.c new file mode 100644 index 00..988ceabf30 --- /dev/null +++ b/board/synopsys/nsim/nsim.c @@ -0,0 +1,26 @@ +// SPDX-License-Identifier: GPL-2.0+ +/* + * Copyright (C) 2019 Synopsys, Inc. All rights reserved. + */ + +#include +#include +#include +#include + +int board_early_init_r(void) +{ + /* +* Make sure virtio bus is enumerated so that peripherals +* on the virtio bus can be discovered by their drivers +*/ + virtio_init(); + + return 0; +} + +int checkboard(void) +{ + printf("Board: ARC virtual or prototyping platform\n"); + return 0; +}; diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig index ce68de3251..6cd01a505b 100644 --- a/configs/nsim_hs38_defconfig +++ b/configs/nsim_hs38_defconfig @@ -9,14 +9,23 @@ CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y CONFIG_BOOTARGS="
[PATCH 0/3] ARC nSIM (AKA virtual & prototyping platform) updates
In this small series we refubrish olde good nSIM configs & platform so that it no uses standard 16650 (in fact DesignWare) UART and little-endian HS version also gets Virtio support (Net & BLK) for use with QEMU. Alexey Brodkin (3): ARC: nSIM: switch from ARC UART to DW UART ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking ARC: nsim_hs38: Add support of Virtio NET & BLK arch/arc/Kconfig | 4 ++-- arch/arc/dts/nsim.dts | 41 ++- board/synopsys/{ => nsim}/Kconfig | 3 +++ board/synopsys/nsim/MAINTAINERS | 6 ++ board/synopsys/nsim/Makefile | 7 +++ board/synopsys/nsim/nsim.c| 26 + configs/nsim_700_defconfig| 9 + configs/nsim_700be_defconfig | 9 + configs/nsim_hs38_defconfig | 17 configs/nsim_hs38be_defconfig | 9 + 10 files changed, 108 insertions(+), 23 deletions(-) rename board/synopsys/{ => nsim}/Kconfig (74%) create mode 100644 board/synopsys/nsim/MAINTAINERS create mode 100644 board/synopsys/nsim/Makefile create mode 100644 board/synopsys/nsim/nsim.c -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH 1/3] ARC: nSIM: switch from ARC UART to DW UART
Since v2019.06 DesingWare nSIM supports DesignWare UART simulation and so we may switch from pretty unusual ARC UART to much more standard DesignWare UART (which in case of U-Boot is just an ordinary 16650 UART). This among other things makes built dinaries compatible with our other platforms to name a few: FPGA-based HAPS boards, QEMU and even ZeBU. Signed-off-by: Alexey Brodkin --- arch/arc/dts/nsim.dts | 12 +++- configs/nsim_700_defconfig| 8 configs/nsim_700be_defconfig | 8 configs/nsim_hs38_defconfig | 8 configs/nsim_hs38be_defconfig | 8 5 files changed, 23 insertions(+), 21 deletions(-) diff --git a/arch/arc/dts/nsim.dts b/arch/arc/dts/nsim.dts index 243ecb178e..a3f3964d35 100644 --- a/arch/arc/dts/nsim.dts +++ b/arch/arc/dts/nsim.dts @@ -1,6 +1,6 @@ // SPDX-License-Identifier: GPL-2.0+ /* - * Copyright (C) 2015-2016 Synopsys, Inc. (www.synopsys.com) + * Copyright (C) 2015-2016, 2019 Synopsys, Inc. (www.synopsys.com) */ /dts-v1/; @@ -10,7 +10,7 @@ model = "snps,nsim"; aliases { - console = &arcuart0; + console = &uart0; }; cpu_card { @@ -22,9 +22,11 @@ }; }; - arcuart0: serial@0xc0fc1000 { - compatible = "snps,arc-uart"; - reg = <0xc0fc1000 0x100>; + uart0: serial@f000 { + compatible = "snps,dw-apb-uart"; + reg = <0xf000 0x1000>; + reg-shift = <2>; + reg-io-width = <4>; clock-frequency = <7000>; }; diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig index 5633113b09..2d4a58b178 100644 --- a/configs/nsim_700_defconfig +++ b/configs/nsim_700_defconfig @@ -1,13 +1,13 @@ CONFIG_ARC=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyARC0,115200n8" +CONFIG_BOOTARGS="console=ttyS0,115200n8" CONFIG_SYS_PROMPT="nsim# " # CONFIG_CMD_SETEXPR is not set CONFIG_OF_CONTROL=y @@ -16,6 +16,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_DM_SERIAL=y -CONFIG_DEBUG_ARC_SERIAL=y -CONFIG_ARC_SERIAL=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig index 40f7ec7e1f..61eea91449 100644 --- a/configs/nsim_700be_defconfig +++ b/configs/nsim_700be_defconfig @@ -2,13 +2,13 @@ CONFIG_ARC=y CONFIG_CPU_BIG_ENDIAN=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyARC0,115200n8" +CONFIG_BOOTARGS="console=ttyS0,115200n8" CONFIG_SYS_PROMPT="nsim# " # CONFIG_CMD_SETEXPR is not set CONFIG_OF_CONTROL=y @@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_DM_SERIAL=y -CONFIG_DEBUG_ARC_SERIAL=y -CONFIG_ARC_SERIAL=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/configs/nsim_hs38_defconfig b/configs/nsim_hs38_defconfig index 2820a6fca3..ce68de3251 100644 --- a/configs/nsim_hs38_defconfig +++ b/configs/nsim_hs38_defconfig @@ -2,13 +2,13 @@ CONFIG_ARC=y CONFIG_ISA_ARCV2=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="console=ttyARC0,115200n8" +CONFIG_BOOTARGS="console=ttyS0,115200n8" CONFIG_SYS_PROMPT="nsim# " # CONFIG_CMD_SETEXPR is not set CONFIG_OF_CONTROL=y @@ -17,6 +17,6 @@ CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y CONFIG_DM=y CONFIG_DM_SERIAL=y -CONFIG_DEBUG_ARC_SERIAL=y -CONFIG_ARC_SERIAL=y +CONFIG_DEBUG_UART_SHIFT=2 +CONFIG_SYS_NS16550=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig index e533fae2b1..5d2ea59d52 100644 --- a/configs/nsim_hs38be_defconfig +++ b/configs/nsim_hs38be_defconfig @@ -3,13 +3,13 @@ CONFIG_ISA_ARCV2=y CONFIG_CPU_BIG_ENDIAN=y CONFIG_TARGET_NSIM=y CONFIG_SYS_TEXT_BASE=0x8100 -CONFIG_DEBUG_UART_BASE=0xc0fc1000 +CONFIG_DEBUG_UART_BASE=0xf000 CONFIG_DEBUG_UART_CLOCK=7000 CONFIG_SYS_CLK_FREQ=7000 CONFIG_DEBUG_UART=y CONFIG_BOOTDELAY=3 CONFIG_USE_BOOTARGS=y -CONFIG_BOOTARGS="c
[PATCH 2/3] ARC: nsim_{700|700be|hs38be}_defconfigs: Disable networking
We don't have yet any brc700 or big-enadian platforms with networking support to run this particular configuration. Whenever QEMU for ARC supports arc700 or big-endian targets we may revisit this one. Signed-off-by: Alexey Brodkin --- configs/nsim_700_defconfig| 1 + configs/nsim_700be_defconfig | 1 + configs/nsim_hs38be_defconfig | 1 + 3 files changed, 3 insertions(+) diff --git a/configs/nsim_700_defconfig b/configs/nsim_700_defconfig index 2d4a58b178..6a38e2c246 100644 --- a/configs/nsim_700_defconfig +++ b/configs/nsim_700_defconfig @@ -14,6 +14,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 diff --git a/configs/nsim_700be_defconfig b/configs/nsim_700be_defconfig index 61eea91449..d3ed84a415 100644 --- a/configs/nsim_700be_defconfig +++ b/configs/nsim_700be_defconfig @@ -15,6 +15,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 diff --git a/configs/nsim_hs38be_defconfig b/configs/nsim_hs38be_defconfig index 5d2ea59d52..b074b4ca98 100644 --- a/configs/nsim_hs38be_defconfig +++ b/configs/nsim_hs38be_defconfig @@ -16,6 +16,7 @@ CONFIG_OF_CONTROL=y CONFIG_OF_EMBED=y CONFIG_DEFAULT_DEVICE_TREE="nsim" CONFIG_SYS_RELOC_GD_ENV_ADDR=y +# CONFIG_NET is not set CONFIG_DM=y CONFIG_DM_SERIAL=y CONFIG_DEBUG_UART_SHIFT=2 -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()
Hi Peter, > > Well it somehow used to work for quite some time now with the data-buffer > > being allocated with 4 words offset (which is 16 bytes for 32-bit platform > > 3 words, devres_node is 3 words. Correct, but 4th word was implicitly there due to the fact on most of 32-bit arches "long long" is aligned by 2 words. > Which is exactly why we had to change it, the odd alignment caused ARC > to explode. I know that better than anybody else as it was my pain & grief :) > > and 32 for 64-bit which is still much less than mentioned 128 bytes). > > Or we just never managed to identify those rare cases when data corruption > > really happened? > > The races are rather rare methinks, you'd have to get a list-op > concurrently with a DMA. > > If you get the list corrupted, I'm thinking the crash is fairly likely, > albeit really difficuly to debug. So that alone IMHO is a good reason to not allow that thing to happen even in theory. > > > No matter which way round you allocate devres and data, by necessity > > > they're always going to consume the same total amount of memory. > > > > So then the next option I guess is to separate meta-data from data buffers > > completely. Are there any reasons to not do that > > Dunno, should work just fine I think. > > > other than the hack we're > > discussing here (meta-data in the beginning of the buffer) used to work > > OK-ish? > > If meta-data at the beginngin used to work, I don't see why meta-data at > the end wouldn't work equally well. They'd be equally broken. Agree. But if we imagine devm allocations are not used for DMA (which is yet another case of interface usage which was never designed for but alas this happens left and right) then move of the meta-data to the end of the buffers solves [mostly my] problem... but given that DMA case we discuss exists I'm not sure if this move actually worth spending time on. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()
Hi Robin, Peter, all, [snip] > On 2019-12-20 2:06 pm, Peter Zijlstra wrote: > > On Fri, Dec 20, 2019 at 11:19:27AM +0100, Marc Gonzalez wrote: > >> Would anyone else have any suggestions, comments, insights, > >> recommendations, > >> improvements, guidance, or wisdom? :-) > > > > Flip devres upside down! > > Which doesn't really help :( > > > **WARNING, wear protective glasses when reading the below** > > > > > > struct devres { > > struct devres_node node; > > void*data; > > }; > > > > /* > > * We place struct devres at the tail of the memory allocation > > * such that data retains the ARCH_KMALLOC_MINALIGN alignment. > > * struct devres itself is just 4 pointers and should therefore > > * only require trivial alignment. > > */ > > static inline struct devres *data2devres(void *data) > > { > > return (struct devres *)(data + ksize(data) - sizeof(struct devres)); > > } > > > > void *alloc_dr(...) > > { > > struct devres *dr; > > void *data; > > > > data = kmalloc(size + sizeof(struct devres), GFP_KERNEL); > > At this point, you'd still need to special-case devm_kmalloc() to ensure > size is rounded up to the next ARCH_KMALLOC_MINALIGN granule, or you'd > go back to the original problem of the struct devres fields potentially > sharing a cache line with the data buffer. That needs to be avoided, > because if the devres list is modified while the buffer is mapped for > noncoherent DMA (which could legitimately happen as they are nominally > distinct allocations with different owners) there's liable to be data > corruption one way or the other. Well it somehow used to work for quite some time now with the data-buffer being allocated with 4 words offset (which is 16 bytes for 32-bit platform and 32 for 64-bit which is still much less than mentioned 128 bytes). Or we just never managed to identify those rare cases when data corruption really happened? > No matter which way round you allocate devres and data, by necessity > they're always going to consume the same total amount of memory. So then the next option I guess is to separate meta-data from data buffers completely. Are there any reasons to not do that other than the hack we're discussing here (meta-data in the beginning of the buffer) used to work OK-ish? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [RFC PATCH v1] devres: align devres.data strictly only for devm_kmalloc()
Hi Marc, We sort of expected something like that to happen at some point. Funny enough it's been a year since my change was accepted in v4.20 and only now somebody noticed :) Though quite a few questions below. > Commit a66d972465d15 ("devres: Align data[] to ARCH_KMALLOC_MINALIGN") > increased the alignment of devres.data unconditionally. > > Some platforms have very strict alignment requirements for DMA-safe > addresses, e.g. 128 bytes on arm64. There, struct devres amounts to: > 3 pointers + pad_to_128 + data + pad_to_256 > i.e. ~220 bytes of padding. Could you please elaborate a bit on mentioned paddings? I may understand the first one for 128 bytes but where does the second one for 256 bytes come from? > Let's enforce the alignment only for devm_kmalloc(). Ok so for devm_kmalloc() we don't change anything, right? We still add the same padding before real data array. > --- > I had not been aware that dynamic allocation granularity on arm64 was > 128 bytes. This means there's a lot of waste on small allocations. Now probably I'm missing something but when do you expect to save something? If those smaller allocations are done with devm_kmalloc() you aren't saving anything. > I suppose there's no easy solution, though. Right! It took a while till I was able to propose something people [almost silently] agreed with. > --- > drivers/base/devres.c | 23 +-- > 1 file changed, 13 insertions(+), 10 deletions(-) > > diff --git a/drivers/base/devres.c b/drivers/base/devres.c > index 0bbb328bd17f..bf39188613d9 100644 > --- a/drivers/base/devres.c > +++ b/drivers/base/devres.c > @@ -26,14 +26,7 @@ struct devres_node { > > struct devres { > struct devres_node node; > - /* > - * Some archs want to perform DMA into kmalloc caches > - * and need a guaranteed alignment larger than > - * the alignment of a 64-bit integer. > - * Thus we use ARCH_KMALLOC_MINALIGN here and get exactly the same > - * buffer alignment as if it was allocated by plain kmalloc(). > - */ > - u8 __aligned(ARCH_KMALLOC_MINALIGN) data[]; > + u8 data[]; > }; > > struct devres_group { > @@ -789,9 +782,16 @@ static void devm_kmalloc_release(struct device *dev, > void *res) > /* noop */ > } > > +#define DEVM_KMALLOC_PADDING_SIZE \ > + (ARCH_KMALLOC_MINALIGN - sizeof(struct devres) % ARCH_KMALLOC_MINALIGN) Even given your update with: --->8 #define DEVM_KMALLOC_PADDING_SIZE \ ((ARCH_KMALLOC_MINALIGN - sizeof(struct devres)) % ARCH_KMALLOC_MINALIGN) --->8 I don't think I understand why do you need that "% ARCH_KMALLOC_MINALIGN" part? > static int devm_kmalloc_match(struct device *dev, void *res, void *data) > { > - return res == data; > + /* > + * 'res' is dr->data (not DMA-safe) > + * 'data' is the hand-aligned address from devm_kmalloc > + */ > + return res + DEVM_KMALLOC_PADDING_SIZE == data; > } > > /** > @@ -811,6 +811,9 @@ void * devm_kmalloc(struct device *dev, size_t size, > gfp_t gfp) > { > struct devres *dr; > > + /* Add enough padding to provide a DMA-safe address */ > + size += DEVM_KMALLOC_PADDING_SIZE; This implementation gets ugly and potentially will lead to problems later when people will start changing code here. Compared to that initially aligned by the compiler dr->data looks much more foolproof. > /* use raw alloc_dr for kmalloc caller tracing */ > dr = alloc_dr(devm_kmalloc_release, size, gfp, dev_to_node(dev)); > if (unlikely(!dr)) > @@ -822,7 +825,7 @@ void * devm_kmalloc(struct device *dev, size_t size, > gfp_t gfp) >*/ > set_node_dbginfo(&dr->node, "devm_kzalloc_release", size); > devres_add(dev, dr->data); > - return dr->data; > + return dr->data + DEVM_KMALLOC_PADDING_SIZE; Ditto. But first I'd like to understand what are you trying to really do with your change and then we'll see if there could be any better implementation. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[GIT PULL REBASED] drm/arc: Yet another set of minor fixes
Hi David, Daniel! The following changes since commit d1eef1c619749b2a57e514a3fa67d9a516ffa919: Linux 5.5-rc2 (2019-12-15 15:16:08 -0800) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.12.16 for you to fetch changes up to 0ff916e2ef6fb742e4906aac26c470314b59bae8: DRM: ARC: PGU: add ARGB format to supported format list (2019-12-16 13:53:05 +0300) Clean-up and fixes for FourCC handling in ARC PGU. Eugeniy Paltsev (4): DRM: ARC: PGU: fix framebuffer format switching DRM: ARC: PGU: cleanup supported format list code DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 DRM: ARC: PGU: add ARGB format to supported format list drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++-- drivers/gpu/drm/arc/arcpgu_regs.h | 2 +- 2 files changed, 19 insertions(+), 19 deletions(-) Note this is based on the current drm/drm-next contents. Thanks, Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [GIT PULL] drm/arc: Yet another set of minor fixes
Hi Daniel, > -Original Message- > From: Daniel Vetter > Sent: Friday, December 13, 2019 1:22 PM > To: Alexey Brodkin > Cc: Daniel Vetter ; David Airlie ; arcml > a...@lists.infradead.org>; Eugeniy Paltsev ; > dri-de...@lists.freedesktop.org > Subject: Re: [GIT PULL] drm/arc: Yet another set of minor fixes > [snip] > > Not sure if you noticed re-spin of my pull-request in the previous message. > > Do you want me to send it in a separate email? > > Yeah I guess this got lost again. So should I re-send it in another email or you will pick it up from existing thread? If I'm going to re-send it do I need to re-base it on today's drm/drm-next? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [GIT PULL] drm/arc: Yet another set of minor fixes
Hi Daniel, [snip] > > Thanks for the pointers > > > > > Or respin this one, but these small pulls have a habit of occasionally > > > getting lost :-/ > > > > Well I'd better re-spin this, see below. > > > > The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594: > > > > Merge tag 'drm-next-5.5-2019-11-22' of > > git://people.freedesktop.org/~agd5f/linux into drm-next > (2019-11-26 08:40:23 +1000) > > > > are available in the Git repository at: > > > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 > > > > for you to fetch changes up to 9c2acc26c899aa12ad009dff10a5573ef769a7fd: > > > > DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 > > 16:43:39 +0300) > > > > > > Clean-up and fixes for FourCC handling in ARC PGU. > > > > > > Eugeniy Paltsev (4): > > DRM: ARC: PGU: fix framebuffer format switching > > DRM: ARC: PGU: cleanup supported format list code > > DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 > > DRM: ARC: PGU: add ARGB format to supported format list > > > > drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++-- > > drivers/gpu/drm/arc/arcpgu_regs.h | 2 +- > > 2 files changed, 19 insertions(+), 19 deletions(-) Not sure if you noticed re-spin of my pull-request in the previous message. Do you want me to send it in a separate email? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [GIT PULL] drm/arc: Yet another set of minor fixes
Hi Daniel, > -Original Message- > From: Daniel Vetter > Sent: Wednesday, November 27, 2019 1:07 PM > To: Alexey Brodkin > Cc: Daniel Vetter ; David Airlie ; arcml > a...@lists.infradead.org>; Eugeniy Paltsev ; > dri-de...@lists.freedesktop.org > Subject: Re: [GIT PULL] drm/arc: Yet another set of minor fixes > > On Wed, Nov 27, 2019 at 07:48:04AM +, Alexey Brodkin wrote: > > Hi David, Daniel! > > > > The following changes since commit 8082731830a0b95f7f7a63b78de67de446013c80: > > > > drm/vram: remove unused declaration (2019-11-27 07:51:49 +0100) > > > > are available in the Git repository at: > > > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 > > > > for you to fetch changes up to b2c68fb15a4c2e27f80353d3067dce30882a0972: > > > > DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 > > 10:38:24 +0300) > > > > > > Clean-up and fixes for FourCC handling in ARC PGU. > > > > > > Eugeniy Paltsev (4): > > DRM: ARC: PGU: fix framebuffer format switching > > DRM: ARC: PGU: cleanup supported format list code > > DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 > > DRM: ARC: PGU: add ARGB format to supported format list > > Uh, this seems to be based on some random snapshot of drm-misc-next, so > contains a _lot_ more than just these 4 patches (compared to drm-next). Indeed it's based off of today's "drm-misc-next". That's because I still get lost when I have to deal with DRM trees which we have a plenty. I guess there should be a clean explanation of which repo and branch should be used for which purpose, right? May I have a reference to it then? > If you want to move arcpgu to drm-misc (which would make tons of sense imo) Could you please elaborate a bit on this? Given we have a couple a patches if at all for each kernel release I'd prefer to escape a need to use yet another repo, tools etc as this doesn't simplify anything but instead makes simple things much more complex (if done rarely). > then: > - create a MAINTAINER patch to add drm-misc as the git repo for it > - request your account for drm-misc, see > https://www.freedesktop.org/wiki/AccountRequests/ > - and set up the scripts > https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Thanks for the pointers > Or respin this one, but these small pulls have a habit of occasionally > getting lost :-/ Well I'd better re-spin this, see below. The following changes since commit acc61b8929365e63a3e8c8c8913177795aa45594: Merge tag 'drm-next-5.5-2019-11-22' of git://people.freedesktop.org/~agd5f/linux into drm-next (2019-11-26 08:40:23 +1000) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 for you to fetch changes up to 9c2acc26c899aa12ad009dff10a5573ef769a7fd: DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 16:43:39 +0300) Clean-up and fixes for FourCC handling in ARC PGU. Eugeniy Paltsev (4): DRM: ARC: PGU: fix framebuffer format switching DRM: ARC: PGU: cleanup supported format list code DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 DRM: ARC: PGU: add ARGB format to supported format list drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++-- drivers/gpu/drm/arc/arcpgu_regs.h | 2 +- 2 files changed, 19 insertions(+), 19 deletions(-) -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [GIT PULL] drm/arc: Minor improvements
Hi all, As Jose suggested I'm adding "drm-misc" maintainers as that tree might be a better fit for ARC PGU patches. -Alexey > -Original Message- > From: linux-snps-arc On Behalf > Of Alexey Brodkin > Sent: Wednesday, November 27, 2019 10:25 AM > To: Daniel Vetter ; David Airlie > Cc: arcml ; Eugeniy Paltsev > ; dri- > de...@lists.freedesktop.org > Subject: RE: [GIT PULL] drm/arc: Minor improvements > > Hi Daniel, David! > > Any chance for this one to be processed sometime soon? > It's been quite some time since July when I initially sent > this pull-request. > > -Alexey > > > -Original Message- > > From: linux-snps-arc On Behalf > > Of Alexey Brodkin > > Sent: Wednesday, November 13, 2019 2:30 PM > > To: Daniel Vetter ; David Airlie > > Cc: arcml ; Eugeniy Paltsev > > ; dri- > > de...@lists.freedesktop.org > > Subject: RE: [GIT PULL] drm/arc: Minor improvements > > > > Hi Daniel, David, > > > > > -Original Message- > > > From: linux-snps-arc On > > > Behalf Of Alexey Brodkin > > > Sent: Thursday, July 18, 2019 12:09 AM > > > To: Daniel Vetter ; David Airlie > > > Cc: arcml ; > > > dri-de...@lists.freedesktop.org > > > Subject: [GIT PULL] drm/arc: Minor improvements > > > > > > Hi Dave, Daniel, > > > > > > The following changes since commit > > > 7aaddd96d5febcf5b24357a326b3038d49a20532: > > > > > > drm/modes: Don't apply cmdline's rotation if it wasn't specified > > > (2019-07-16 10:34:38 +0200) > > > > > > are available in the Git repository at: > > > > > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18 > > > > > > for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9: > > > > > > drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300) > > > > > > > > > This is a pretty simple improvement that allows to find encoder > > > as the one and only (ARC PGU doesn't support more than one) endpoint > > > instead of using non-standard "encoder-slave" property. > > > > > > > > > Eugeniy Paltsev (1): > > > drm/arcpgu: rework encoder search > > > > > > drivers/gpu/drm/arc/arcpgu_drv.c | 16 +--- > > > 1 file changed, 13 insertions(+), 3 deletions(-) > > > > Any chance for this one to get pulled into your tree(s) sometime soon? > > > > -Alexey > > > > ___ > > linux-snps-arc mailing list > > linux-snps-arc@lists.infradead.org > > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux- > 2Dsnps- > > > 2Darc&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=f3bFSjs3gZI9vC > > LJW5sa6Kxu43yXUsCXhaUNhtEymmk&s=eFO6mnw8IJyfrQZYrMEbJ-bryplfw9LvcYBSCEyj5XA&e= > > ___ > linux-snps-arc mailing list > linux-snps-arc@lists.infradead.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps- > 2Darc&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=c8DhCL8_- > 0iY2tS35o8kpDyvbHZ_Cu762s4qtn2hDVg&s=sGFaDT7yPIbVcjW49E_rjb6ND82Nrq0kplYjbztlh3A&e= ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [GIT PULL] drm/arc: Minor improvements
Hi Daniel, David! Any chance for this one to be processed sometime soon? It's been quite some time since July when I initially sent this pull-request. -Alexey > -Original Message- > From: linux-snps-arc On Behalf > Of Alexey Brodkin > Sent: Wednesday, November 13, 2019 2:30 PM > To: Daniel Vetter ; David Airlie > Cc: arcml ; Eugeniy Paltsev > ; dri- > de...@lists.freedesktop.org > Subject: RE: [GIT PULL] drm/arc: Minor improvements > > Hi Daniel, David, > > > -Original Message----- > > From: linux-snps-arc On Behalf > > Of Alexey Brodkin > > Sent: Thursday, July 18, 2019 12:09 AM > > To: Daniel Vetter ; David Airlie > > Cc: arcml ; > > dri-de...@lists.freedesktop.org > > Subject: [GIT PULL] drm/arc: Minor improvements > > > > Hi Dave, Daniel, > > > > The following changes since commit 7aaddd96d5febcf5b24357a326b3038d49a20532: > > > > drm/modes: Don't apply cmdline's rotation if it wasn't specified > > (2019-07-16 10:34:38 +0200) > > > > are available in the Git repository at: > > > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18 > > > > for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9: > > > > drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300) > > > > > > This is a pretty simple improvement that allows to find encoder > > as the one and only (ARC PGU doesn't support more than one) endpoint > > instead of using non-standard "encoder-slave" property. > > > > > > Eugeniy Paltsev (1): > > drm/arcpgu: rework encoder search > > > > drivers/gpu/drm/arc/arcpgu_drv.c | 16 +--- > > 1 file changed, 13 insertions(+), 3 deletions(-) > > Any chance for this one to get pulled into your tree(s) sometime soon? > > -Alexey > > ___ > linux-snps-arc mailing list > linux-snps-arc@lists.infradead.org > https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.infradead.org_mailman_listinfo_linux-2Dsnps- > 2Darc&d=DwICAg&c=DPL6_X_6JkXFx7AXWqB0tg&r=lqdeeSSEes0GFDDl656eViXO7breS55ytWkhpk5R81I&m=f3bFSjs3gZI9vC > LJW5sa6Kxu43yXUsCXhaUNhtEymmk&s=eFO6mnw8IJyfrQZYrMEbJ-bryplfw9LvcYBSCEyj5XA&e= ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] ARC: perf: Accommodate big-endian CPU
Hi Greg, > -Original Message- > From: linux-snps-arc On Behalf > Of Greg Kroah-Hartman > Sent: Thursday, November 21, 2019 11:40 PM > To: Alexey Brodkin > Cc: Sasha Levin ; linux-snps-arc@lists.infradead.org; > linux-ker...@vger.kernel.org; > sta...@vger.kernel.org > Subject: Re: [PATCH] ARC: perf: Accommodate big-endian CPU > > On Tue, Nov 05, 2019 at 07:52:16PM +, Alexey Brodkin wrote: > > Hi Sasha, Greg, > > > > > -Original Message- > > > From: Sasha Levin > > > Sent: Saturday, October 26, 2019 4:11 PM > > > To: Sasha Levin ; Alexey Brodkin > > > ; linux-snps- > > > a...@lists.infradead.org > > > Cc: linux-ker...@vger.kernel.org; sta...@vger.kernel.org; > > > sta...@vger.kernel.org > > > Subject: Re: [PATCH] ARC: perf: Accommodate big-endian CPU > > > > > > Hi, > > > > > > [This is an automated email] > > > > > > This commit has been processed because it contains a -stable tag. > > > The stable tag indicates that it's relevant for the following trees: all > > > > > > The bot has tested the following trees: v5.3.7, v4.19.80, v4.14.150, > > > v4.9.197, v4.4.197. > > > > > > v5.3.7: Build OK! > > > v4.19.80: Failed to apply! Possible dependencies: > > > 0e956150fe09f ("ARC: perf: introduce Kernel PMU events support") > > > 14f81a91ad29a ("ARC: perf: trivial code cleanup") > > > baf9cc85ba01f ("ARC: perf: move HW events mapping to separate > > > function") > > > v4.14.150: Failed to apply! Possible dependencies: > > > v4.9.197: Failed to apply! Possible dependencies: > > > v4.4.197: Failed to apply! Possible dependencies: > > > > Indeed the clash is due to > > commit baf9cc85ba01f ("ARC: perf: move HW events mapping to separate > > function") as tmp variable "j" > was changed on "i". So that's a fixed hunk: > > >8-- > > diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c > > index 8aec462d90fb..30f66b123541 100644 > > --- a/arch/arc/kernel/perf_event.c > > +++ b/arch/arc/kernel/perf_event.c > > @@ -490,8 +490,8 @@ static int arc_pmu_device_probe(struct platform_device > > *pdev) > > /* loop thru all available h/w condition indexes */ > > for (j = 0; j < cc_bcr.c; j++) { > > write_aux_reg(ARC_REG_CC_INDEX, j); > > - cc_name.indiv.word0 = read_aux_reg(ARC_REG_CC_NAME0); > > - cc_name.indiv.word1 = read_aux_reg(ARC_REG_CC_NAME1); > > + cc_name.indiv.word0 = > > le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME0)); > > + cc_name.indiv.word1 = > > le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME1)); > > > > /* See if it has been mapped to a perf event_id */ > > for (i = 0; i < ARRAY_SIZE(arc_pmu_ev_hw_map); i++) { > > >8-- > > > > Should I send a formal patch with it or it's OK for now? > > We need a "formal" patch that we can apply if you want it applied. Done, see https://patchwork.ozlabs.org/patch/1201398/ and your inbox. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: perf: Accommodate big-endian CPU
8-letter strings representing ARC perf events are stores in two 32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc. And the same order of bytes in the word is used regardless CPU endianness. Which means in case of big-endian CPU core we need to swap bytes to get the same order as if it was on little-endian CPU. Otherwise we're seeing the following error message on boot: ->8-- ARC perf: 8 counters (32 bits), 40 conditions, [overflow IRQ support] sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 sysfs_warn_dup+0x46/0x58 sysfs_add_file_mode_ns+0xb2/0x168 create_files+0x70/0x2a0 [ cut here ] WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 perf_event_sysfs_init+0x70/0xa0 Failed to register pmu: arc_pct, reason -17 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 __warn+0x9c/0xd4 warn_slowpath_fmt+0x22/0x2c perf_event_sysfs_init+0x70/0xa0 ---[ end trace a75fb9a9837bd1ec ]--- ->8-- What happens here we're trying to register more than one raw perf event with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters and encoded into two 32-bit words. In this particular case we deal with 2 events: * "IJMP" which counts all jump & branch instructions * "IJMPC___" which counts only conditional jumps & branches Those strings are split in two 32-bit words this way "IJMP" + "" & "IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core being big-endian then we read "PMJI" + "" & "PMJI" + "___C". And since we interpret read array of ASCII letters as a null-terminated string on big-endian CPU we end up with 2 events of the same name "PMJI". Signed-off-by: Alexey Brodkin Cc: sta...@vger.kernel.org --- Greg, Sasha, this is the same patch as commit 5effc09c4907 ("ARC: perf: Accommodate big-endian CPU") but fine-tuned to be applicable to kernels 4.19 and older. arch/arc/kernel/perf_event.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c index 8aec462d90fb..30f66b123541 100644 --- a/arch/arc/kernel/perf_event.c +++ b/arch/arc/kernel/perf_event.c @@ -490,8 +490,8 @@ static int arc_pmu_device_probe(struct platform_device *pdev) /* loop thru all available h/w condition indexes */ for (j = 0; j < cc_bcr.c; j++) { write_aux_reg(ARC_REG_CC_INDEX, j); - cc_name.indiv.word0 = read_aux_reg(ARC_REG_CC_NAME0); - cc_name.indiv.word1 = read_aux_reg(ARC_REG_CC_NAME1); + cc_name.indiv.word0 = le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME0)); + cc_name.indiv.word1 = le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME1)); /* See if it has been mapped to a perf event_id */ for (i = 0; i < ARRAY_SIZE(arc_pmu_ev_hw_map); i++) { -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[GIT PULL] drm/arc: Yet another set of minor fixes
Hi David, Daniel! The following changes since commit 8082731830a0b95f7f7a63b78de67de446013c80: drm/vram: remove unused declaration (2019-11-27 07:51:49 +0100) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.11.27 for you to fetch changes up to b2c68fb15a4c2e27f80353d3067dce30882a0972: DRM: ARC: PGU: add ARGB format to supported format list (2019-11-27 10:38:24 +0300) Clean-up and fixes for FourCC handling in ARC PGU. Eugeniy Paltsev (4): DRM: ARC: PGU: fix framebuffer format switching DRM: ARC: PGU: cleanup supported format list code DRM: ARC: PGU: replace unsupported by HW RGB888 format by XRGB888 DRM: ARC: PGU: add ARGB format to supported format list drivers/gpu/drm/arc/arcpgu_crtc.c | 36 ++-- drivers/gpu/drm/arc/arcpgu_regs.h | 2 +- 2 files changed, 19 insertions(+), 19 deletions(-) Thanks, Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [GIT PULL] drm/arc: Minor improvements
Hi Daniel, David, > -Original Message- > From: linux-snps-arc On Behalf > Of Alexey Brodkin > Sent: Thursday, July 18, 2019 12:09 AM > To: Daniel Vetter ; David Airlie > Cc: arcml ; > dri-de...@lists.freedesktop.org > Subject: [GIT PULL] drm/arc: Minor improvements > > Hi Dave, Daniel, > > The following changes since commit 7aaddd96d5febcf5b24357a326b3038d49a20532: > > drm/modes: Don't apply cmdline's rotation if it wasn't specified > (2019-07-16 10:34:38 +0200) > > are available in the Git repository at: > > g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18 > > for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9: > > drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300) > > > This is a pretty simple improvement that allows to find encoder > as the one and only (ARC PGU doesn't support more than one) endpoint > instead of using non-standard "encoder-slave" property. > > > Eugeniy Paltsev (1): > drm/arcpgu: rework encoder search > > drivers/gpu/drm/arc/arcpgu_drv.c | 16 +--- > 1 file changed, 13 insertions(+), 3 deletions(-) Any chance for this one to get pulled into your tree(s) sometime soon? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] ARC: perf: Accommodate big-endian CPU
Hi Sasha, Greg, > -Original Message- > From: Sasha Levin > Sent: Saturday, October 26, 2019 4:11 PM > To: Sasha Levin ; Alexey Brodkin ; > linux-snps- > a...@lists.infradead.org > Cc: linux-ker...@vger.kernel.org; sta...@vger.kernel.org; > sta...@vger.kernel.org > Subject: Re: [PATCH] ARC: perf: Accommodate big-endian CPU > > Hi, > > [This is an automated email] > > This commit has been processed because it contains a -stable tag. > The stable tag indicates that it's relevant for the following trees: all > > The bot has tested the following trees: v5.3.7, v4.19.80, v4.14.150, > v4.9.197, v4.4.197. > > v5.3.7: Build OK! > v4.19.80: Failed to apply! Possible dependencies: > 0e956150fe09f ("ARC: perf: introduce Kernel PMU events support") > 14f81a91ad29a ("ARC: perf: trivial code cleanup") > baf9cc85ba01f ("ARC: perf: move HW events mapping to separate function") > v4.14.150: Failed to apply! Possible dependencies: > v4.9.197: Failed to apply! Possible dependencies: > v4.4.197: Failed to apply! Possible dependencies: Indeed the clash is due to commit baf9cc85ba01f ("ARC: perf: move HW events mapping to separate function") as tmp variable "j" was changed on "i". So that's a fixed hunk: >8-- diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c index 8aec462d90fb..30f66b123541 100644 --- a/arch/arc/kernel/perf_event.c +++ b/arch/arc/kernel/perf_event.c @@ -490,8 +490,8 @@ static int arc_pmu_device_probe(struct platform_device *pdev) /* loop thru all available h/w condition indexes */ for (j = 0; j < cc_bcr.c; j++) { write_aux_reg(ARC_REG_CC_INDEX, j); - cc_name.indiv.word0 = read_aux_reg(ARC_REG_CC_NAME0); - cc_name.indiv.word1 = read_aux_reg(ARC_REG_CC_NAME1); + cc_name.indiv.word0 = le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME0)); + cc_name.indiv.word1 = le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME1)); /* See if it has been mapped to a perf event_id */ for (i = 0; i < ARRAY_SIZE(arc_pmu_ev_hw_map); i++) { >8-- Should I send a formal patch with it or it's OK for now? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] toolchain,glibc: Allow ARC big endian glibc builds
Hi Vineet, > -Original Message- > From: Vineet Gupta > Sent: Friday, November 1, 2019 10:04 PM > To: buildr...@busybox.net > Cc: linux-snps-arc@lists.infradead.org; Alexey Brodkin > ; Evgeniy Didin > ; Vineet Gupta > Subject: [PATCH] toolchain,glibc: Allow ARC big endian glibc builds > > Apparently big endian glibc builds just work, if we let the endian > header allow that (which prev was #error). > > So this patch bumps glibc to version which fixes the header (this > hopefully will become arc-2019.09-release) and then enables arceb > in glibc toolchain builds > > Signed-off-by: Vineet Gupta > --- > package/glibc/glibc.mk | 2 +- > toolchain/toolchain-buildroot/Config.in | 3 ++- > 2 files changed, 3 insertions(+), 2 deletions(-) > > diff --git a/package/glibc/glibc.mk b/package/glibc/glibc.mk > index d46063c5d111..754408881397 100644 > --- a/package/glibc/glibc.mk > +++ b/package/glibc/glibc.mk > @@ -5,7 +5,7 @@ > > > > ifeq ($(BR2_arc),y) > -GLIBC_VERSION = arc-2019.03-release > +GLIBC_VERSION = ec681dddfa99894513c85da7d5d257b60d04f915 > GLIBC_SITE = $(call > github,foss-for-synopsys-dwc-arc-processors,glibc,$(GLIBC_VERSION)) > else ifeq ($(BR2_RISCV_32),y) > GLIBC_VERSION = 06983fe52cfe8e4779035c27e8cc5d2caab31531 > diff --git a/toolchain/toolchain-buildroot/Config.in > b/toolchain/toolchain-buildroot/Config.in > index c0612bf04176..587e097a9c92 100644 > --- a/toolchain/toolchain-buildroot/Config.in > +++ b/toolchain/toolchain-buildroot/Config.in > @@ -48,7 +48,8 @@ config BR2_TOOLCHAIN_BUILDROOT_GLIBC > BR2_powerpc || BR2_powerpc64 || BR2_powerpc64le || \ > BR2_riscv || BR2_sh || BR2_sparc64 || \ > BR2_x86_64 || BR2_microblaze || BR2_nios2 || \ > -(BR2_arcle && BR2_ARC_ATOMIC_EXT) || BR2_csky > +((BR2_arcle || BR2_arceb) && BR2_ARC_ATOMIC_EXT) || \ > +BR2_csky I guess here we may just use "BR2_arc" which is set for both BR2_arcle && BR2_arceb, see https://git.buildroot.org/buildroot/tree/arch/Config.in.arc#n54 -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: perf: Accommodate big-endian CPU
8-letter strings representing ARC perf events are stores in two 32-bit registers as ASCII characters like that: "IJMP", "IALL", "IJMPTAK" etc. And the same order of bytes in the word is used regardless CPU endianness. Which means in case of big-endian CPU core we need to swap bytes to get the same order as if it was on little-endian CPU. Otherwise we're seeing the following error message on boot: ->8-- ARC perf: 8 counters (32 bits), 40 conditions, [overflow IRQ support] sysfs: cannot create duplicate filename '/devices/arc_pct/events/pmji' CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 sysfs_warn_dup+0x46/0x58 sysfs_add_file_mode_ns+0xb2/0x168 create_files+0x70/0x2a0 [ cut here ] WARNING: CPU: 0 PID: 1 at kernel/events/core.c:12144 perf_event_sysfs_init+0x70/0xa0 Failed to register pmu: arc_pct, reason -17 Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.2.18 #3 Stack Trace: arc_unwind_core+0xd4/0xfc dump_stack+0x64/0x80 __warn+0x9c/0xd4 warn_slowpath_fmt+0x22/0x2c perf_event_sysfs_init+0x70/0xa0 ---[ end trace a75fb9a9837bd1ec ]--- ->8-- What happens here we're trying to register more than one raw perf event with the same name "PMJI". Why? Because ARC perf events are 4 to 8 letters and encoded into two 32-bit words. In this particular case we deal with 2 events: * "IJMP" which counts all jump & branch instructions * "IJMPC___" which counts only conditional jumps & branches Those strings are split in two 32-bit words this way "IJMP" + "" & "IJMP" + "C___" correspondingly. Now if we read them swapped due to CPU core being big-endian then we read "PMJI" + "" & "PMJI" + "___C". And since we interpret read array of ASCII letters as a null-terminated string on big-endian CPU we end up with 2 events of the same name "PMJI". Signed-off-by: Alexey Brodkin Cc: sta...@vger.kernel.org --- arch/arc/kernel/perf_event.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/arch/arc/kernel/perf_event.c b/arch/arc/kernel/perf_event.c index 861a8aea51f9..661fd842ea97 100644 --- a/arch/arc/kernel/perf_event.c +++ b/arch/arc/kernel/perf_event.c @@ -614,8 +614,8 @@ static int arc_pmu_device_probe(struct platform_device *pdev) /* loop thru all available h/w condition indexes */ for (i = 0; i < cc_bcr.c; i++) { write_aux_reg(ARC_REG_CC_INDEX, i); - cc_name.indiv.word0 = read_aux_reg(ARC_REG_CC_NAME0); - cc_name.indiv.word1 = read_aux_reg(ARC_REG_CC_NAME1); + cc_name.indiv.word0 = le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME0)); + cc_name.indiv.word1 = le32_to_cpu(read_aux_reg(ARC_REG_CC_NAME1)); arc_pmu_map_hw_event(i, cc_name.str); arc_pmu_add_raw_event_attr(i, cc_name.str); -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH 0/2] ARC: [plat-hsdk]: enable on-board SPI peripherals
Hi Eugeniy, > -Original Message- > From: Eugeniy Paltsev > Sent: Friday, October 18, 2019 2:11 PM > To: linux-snps-arc@lists.infradead.org; Vineet Gupta > Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; Rob > Herring > ; devicet...@vger.kernel.org; Eugeniy Paltsev > > Subject: [PATCH 0/2] ARC: [plat-hsdk]: enable on-board SPI peripherals > > HSDK board has SPI flash IC and SPI ADC IC. As all SPI-related > blocking changes/fixes are finally applied we can enable them. > > Eugeniy Paltsev (2): > ARC: [plat-hsdk]: Enable on-board SPI NOR flash IC > ARC: [plat-hsdk]: Enable on-boardi SPI ADC IC For both patches in the series Acked-by: Alexey Brodkin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v3] arc: emsdp/iotdk: Switch to DM_MMC
Somehow EMSDP & IoT DK boards were skipped on ARC boads conversion to DM MMC. So doing it now. Signed-off-by: Alexey Brodkin --- Changes v2 -> v3: * Fixed SDIO bus interface unit clock (BIU) According to the documentation SDIO BIU clock is just "apb_clk" which is 50 MHz by default while SDIO CIU clock is "sdio_ref_clk" and by default is 100 MHz. Changes v1 -> v2: * FIFO size on IoTDK is 128 bytes as compared to 256 on EM SDP. That gave us timeouts on data read with some cards. Fixed now. arch/arc/dts/emsdp.dts | 23 ++ arch/arc/dts/iot_devkit.dts| 22 ++ board/synopsys/emsdp/emsdp.c | 29 --- board/synopsys/iot_devkit/iot_devkit.c | 32 -- configs/emsdp_defconfig| 2 ++ configs/iot_devkit_defconfig | 2 ++ 6 files changed, 49 insertions(+), 61 deletions(-) diff --git a/arch/arc/dts/emsdp.dts b/arch/arc/dts/emsdp.dts index d307b95d8e..dbebdb4e76 100644 --- a/arch/arc/dts/emsdp.dts +++ b/arch/arc/dts/emsdp.dts @@ -32,4 +32,27 @@ reg-shift = <2>; reg-io-width = <4>; }; + + mmcclk_biu: mmcclk-biu { + compatible = "fixed-clock"; + clock-frequency = <5000>; + #clock-cells = <0>; + }; + + mmcclk_ciu: mmcclk-ciu { + compatible = "fixed-clock"; + clock-frequency = <1>; + #clock-cells = <0>; + }; + + mmc: mmc0@f001 { + compatible = "snps,dw-mshc"; + reg = <0xf001 0x400>; + bus-width = <4>; + fifo-depth = <256>; + clocks = <&mmcclk_biu>, <&mmcclk_ciu>; + clock-names = "biu", "ciu"; + max-frequency = <2500>; + }; + }; diff --git a/arch/arc/dts/iot_devkit.dts b/arch/arc/dts/iot_devkit.dts index ebf5a950f0..c0173fa5ab 100644 --- a/arch/arc/dts/iot_devkit.dts +++ b/arch/arc/dts/iot_devkit.dts @@ -42,4 +42,26 @@ compatible = "nop-phy"; #phy-cells = <0>; }; + + mmcclk_biu: mmcclk-biu { + compatible = "fixed-clock"; + clock-frequency = <5000>; + #clock-cells = <0>; + }; + + mmcclk_ciu: mmcclk-ciu { + compatible = "fixed-clock"; + clock-frequency = <5000>; + #clock-cells = <0>; + }; + + mmc: mmc0@f000b000 { + compatible = "snps,dw-mshc"; + reg = <0xf000b000 0x400>; + bus-width = <4>; + fifo-depth = <128>; + clocks = <&mmcclk_biu>, <&mmcclk_ciu>; + clock-names = "biu", "ciu"; + max-frequency = <2500>; + }; }; diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c index 7a3fd5b7f2..5ba9f862e1 100644 --- a/board/synopsys/emsdp/emsdp.c +++ b/board/synopsys/emsdp/emsdp.c @@ -85,35 +85,6 @@ int board_early_init_r(void) return 0; } -int board_mmc_init(bd_t *bis) -{ - struct dwmci_host *host = NULL; - - host = malloc(sizeof(struct dwmci_host)); - if (!host) { - printf("dwmci_host malloc fail!\n"); - return 1; - } - - memset(host, 0, sizeof(struct dwmci_host)); - host->name = "Synopsys Mobile storage"; - host->ioaddr = SDIO_BASE; - host->buswidth = 4; - host->dev_index = 0; - host->bus_hz = 5000; - - add_dwmci(host, host->bus_hz / 2, 40); - - return 0; -} - -int board_mmc_getcd(struct mmc *mmc) -{ - struct dwmci_host *host = mmc->priv; - - return !(dwmci_readl(host, DWMCI_CDETECT) & 1); -} - #define CREG_BASE 0xF0001000 #define CREG_BOOT (void *)(CREG_BASE + 0x0FF0) #define CREG_IP_SW_RESET (void *)(CREG_BASE + 0x0FF0) diff --git a/board/synopsys/iot_devkit/iot_devkit.c b/board/synopsys/iot_devkit/iot_devkit.c index 8424e09bd3..9dbdc128f8 100644 --- a/board/synopsys/iot_devkit/iot_devkit.c +++ b/board/synopsys/iot_devkit/iot_devkit.c @@ -145,38 +145,6 @@ int mach_cpu_init(void) return set_cpu_freq(gd->cpu_clk); } -#define ARC_PERIPHERAL_BASE0xF000 -#define SDIO_BASE (ARC_PERIPHERAL_BASE + 0xB000) - -int board_mmc_init(bd_t *bis) -{ - struct dwmci_host *host = NULL; - - host = malloc(sizeof(struct dwmci_host)); - if (!host) { - printf("dwmci_host malloc fail!\n"); - return -ENOMEM; - } - - memset(host, 0, sizeof
[PATCH] arc: emsdp: docs: Prefer Degilent over Opella-XD
Back in the day on early board samples built-in Digilent JTAG probe was not functional so we used externally attached Ashling Opella-XD probe. But now with production units everything works as expected and so we anybody may enjoy readily avaialble built-in JTAG probe so we specify Digilent oprion on MDB's command line example. Signed-off-by: Alexey Brodkin --- board/synopsys/emsdp/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/board/synopsys/emsdp/README b/board/synopsys/emsdp/README index 034062e397..036554c4d5 100644 --- a/board/synopsys/emsdp/README +++ b/board/synopsys/emsdp/README @@ -79,5 +79,5 @@ ARC EM Software Development Platform (AKA EMSDP) 2.1. In case of proprietary MetaWare debugger run: ->8-- - mdb -dll=opxdarc.so -OK -preloadexec="eval *(int*)0xf0001000=0" u-boot + mdb -digilent -OK -preloadexec="eval *(int*)0xf0001000=0" u-boot ->8-- -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH v2] arc: emsdp/iotdk: Switch to DM_MMC
Somehow EMSDP & IoT DK boards were skipped on ARC boads conversion to DM MMC. So doing it now. Signed-off-by: Alexey Brodkin --- Changes v1 -> v2: * FIFO size on IoTDK is 128 bytes as compared to 256 on EM SDP. That gave us timeouts on data read with some cards. Fixed now. arch/arc/dts/emsdp.dts | 23 ++ arch/arc/dts/iot_devkit.dts| 22 ++ board/synopsys/emsdp/emsdp.c | 29 --- board/synopsys/iot_devkit/iot_devkit.c | 32 -- configs/emsdp_defconfig| 2 ++ configs/iot_devkit_defconfig | 2 ++ 6 files changed, 49 insertions(+), 61 deletions(-) diff --git a/arch/arc/dts/emsdp.dts b/arch/arc/dts/emsdp.dts index d307b95d8e..77362354d5 100644 --- a/arch/arc/dts/emsdp.dts +++ b/arch/arc/dts/emsdp.dts @@ -32,4 +32,27 @@ reg-shift = <2>; reg-io-width = <4>; }; + + mmcclk_biu: mmcclk-biu { + compatible = "fixed-clock"; + clock-frequency = <1>; + #clock-cells = <0>; + }; + + mmcclk_ciu: mmcclk-ciu { + compatible = "fixed-clock"; + clock-frequency = <1>; + #clock-cells = <0>; + }; + + mmc: mmc0@f001 { + compatible = "snps,dw-mshc"; + reg = <0xf001 0x400>; + bus-width = <4>; + fifo-depth = <256>; + clocks = <&mmcclk_biu>, <&mmcclk_ciu>; + clock-names = "biu", "ciu"; + max-frequency = <2500>; + }; + }; diff --git a/arch/arc/dts/iot_devkit.dts b/arch/arc/dts/iot_devkit.dts index ebf5a950f0..c0173fa5ab 100644 --- a/arch/arc/dts/iot_devkit.dts +++ b/arch/arc/dts/iot_devkit.dts @@ -42,4 +42,26 @@ compatible = "nop-phy"; #phy-cells = <0>; }; + + mmcclk_biu: mmcclk-biu { + compatible = "fixed-clock"; + clock-frequency = <5000>; + #clock-cells = <0>; + }; + + mmcclk_ciu: mmcclk-ciu { + compatible = "fixed-clock"; + clock-frequency = <5000>; + #clock-cells = <0>; + }; + + mmc: mmc0@f000b000 { + compatible = "snps,dw-mshc"; + reg = <0xf000b000 0x400>; + bus-width = <4>; + fifo-depth = <128>; + clocks = <&mmcclk_biu>, <&mmcclk_ciu>; + clock-names = "biu", "ciu"; + max-frequency = <2500>; + }; }; diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c index 7a3fd5b7f2..5ba9f862e1 100644 --- a/board/synopsys/emsdp/emsdp.c +++ b/board/synopsys/emsdp/emsdp.c @@ -85,35 +85,6 @@ int board_early_init_r(void) return 0; } -int board_mmc_init(bd_t *bis) -{ - struct dwmci_host *host = NULL; - - host = malloc(sizeof(struct dwmci_host)); - if (!host) { - printf("dwmci_host malloc fail!\n"); - return 1; - } - - memset(host, 0, sizeof(struct dwmci_host)); - host->name = "Synopsys Mobile storage"; - host->ioaddr = SDIO_BASE; - host->buswidth = 4; - host->dev_index = 0; - host->bus_hz = 5000; - - add_dwmci(host, host->bus_hz / 2, 40); - - return 0; -} - -int board_mmc_getcd(struct mmc *mmc) -{ - struct dwmci_host *host = mmc->priv; - - return !(dwmci_readl(host, DWMCI_CDETECT) & 1); -} - #define CREG_BASE 0xF0001000 #define CREG_BOOT (void *)(CREG_BASE + 0x0FF0) #define CREG_IP_SW_RESET (void *)(CREG_BASE + 0x0FF0) diff --git a/board/synopsys/iot_devkit/iot_devkit.c b/board/synopsys/iot_devkit/iot_devkit.c index 8424e09bd3..9dbdc128f8 100644 --- a/board/synopsys/iot_devkit/iot_devkit.c +++ b/board/synopsys/iot_devkit/iot_devkit.c @@ -145,38 +145,6 @@ int mach_cpu_init(void) return set_cpu_freq(gd->cpu_clk); } -#define ARC_PERIPHERAL_BASE0xF000 -#define SDIO_BASE (ARC_PERIPHERAL_BASE + 0xB000) - -int board_mmc_init(bd_t *bis) -{ - struct dwmci_host *host = NULL; - - host = malloc(sizeof(struct dwmci_host)); - if (!host) { - printf("dwmci_host malloc fail!\n"); - return -ENOMEM; - } - - memset(host, 0, sizeof(struct dwmci_host)); - host->name = "Synopsys Mobile storage"; - host->ioaddr = (void *)SDIO_BASE; - host->buswidth = 4; - host->dev_index = 0; - host->bus_hz = 5000; - - add_dwmci(ho
[PATCH] arc: emsdp/iotdk: Switch to DM_MMC
Somehow EMSDP & IoT DK boards were skipped on ARC boads conversion to DM MMC. So doing it now. Signed-off-by: Alexey Brodkin --- arch/arc/dts/emsdp.dts | 23 ++ arch/arc/dts/iot_devkit.dts| 22 ++ board/synopsys/emsdp/emsdp.c | 29 --- board/synopsys/iot_devkit/iot_devkit.c | 32 -- configs/emsdp_defconfig| 2 ++ configs/iot_devkit_defconfig | 2 ++ 6 files changed, 49 insertions(+), 61 deletions(-) diff --git a/arch/arc/dts/emsdp.dts b/arch/arc/dts/emsdp.dts index d307b95d8e..77362354d5 100644 --- a/arch/arc/dts/emsdp.dts +++ b/arch/arc/dts/emsdp.dts @@ -32,4 +32,27 @@ reg-shift = <2>; reg-io-width = <4>; }; + + mmcclk_biu: mmcclk-biu { + compatible = "fixed-clock"; + clock-frequency = <1>; + #clock-cells = <0>; + }; + + mmcclk_ciu: mmcclk-ciu { + compatible = "fixed-clock"; + clock-frequency = <1>; + #clock-cells = <0>; + }; + + mmc: mmc0@f001 { + compatible = "snps,dw-mshc"; + reg = <0xf001 0x400>; + bus-width = <4>; + fifo-depth = <256>; + clocks = <&mmcclk_biu>, <&mmcclk_ciu>; + clock-names = "biu", "ciu"; + max-frequency = <2500>; + }; + }; diff --git a/arch/arc/dts/iot_devkit.dts b/arch/arc/dts/iot_devkit.dts index ebf5a950f0..e2cb602cae 100644 --- a/arch/arc/dts/iot_devkit.dts +++ b/arch/arc/dts/iot_devkit.dts @@ -42,4 +42,26 @@ compatible = "nop-phy"; #phy-cells = <0>; }; + + mmcclk_biu: mmcclk-biu { + compatible = "fixed-clock"; + clock-frequency = <5000>; + #clock-cells = <0>; + }; + + mmcclk_ciu: mmcclk-ciu { + compatible = "fixed-clock"; + clock-frequency = <5000>; + #clock-cells = <0>; + }; + + mmc: mmc0@f000b000 { + compatible = "snps,dw-mshc"; + reg = <0xf000b000 0x400>; + bus-width = <4>; + fifo-depth = <256>; + clocks = <&mmcclk_biu>, <&mmcclk_ciu>; + clock-names = "biu", "ciu"; + max-frequency = <2500>; + }; }; diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c index 7a3fd5b7f2..5ba9f862e1 100644 --- a/board/synopsys/emsdp/emsdp.c +++ b/board/synopsys/emsdp/emsdp.c @@ -85,35 +85,6 @@ int board_early_init_r(void) return 0; } -int board_mmc_init(bd_t *bis) -{ - struct dwmci_host *host = NULL; - - host = malloc(sizeof(struct dwmci_host)); - if (!host) { - printf("dwmci_host malloc fail!\n"); - return 1; - } - - memset(host, 0, sizeof(struct dwmci_host)); - host->name = "Synopsys Mobile storage"; - host->ioaddr = SDIO_BASE; - host->buswidth = 4; - host->dev_index = 0; - host->bus_hz = 5000; - - add_dwmci(host, host->bus_hz / 2, 40); - - return 0; -} - -int board_mmc_getcd(struct mmc *mmc) -{ - struct dwmci_host *host = mmc->priv; - - return !(dwmci_readl(host, DWMCI_CDETECT) & 1); -} - #define CREG_BASE 0xF0001000 #define CREG_BOOT (void *)(CREG_BASE + 0x0FF0) #define CREG_IP_SW_RESET (void *)(CREG_BASE + 0x0FF0) diff --git a/board/synopsys/iot_devkit/iot_devkit.c b/board/synopsys/iot_devkit/iot_devkit.c index 8424e09bd3..9dbdc128f8 100644 --- a/board/synopsys/iot_devkit/iot_devkit.c +++ b/board/synopsys/iot_devkit/iot_devkit.c @@ -145,38 +145,6 @@ int mach_cpu_init(void) return set_cpu_freq(gd->cpu_clk); } -#define ARC_PERIPHERAL_BASE0xF000 -#define SDIO_BASE (ARC_PERIPHERAL_BASE + 0xB000) - -int board_mmc_init(bd_t *bis) -{ - struct dwmci_host *host = NULL; - - host = malloc(sizeof(struct dwmci_host)); - if (!host) { - printf("dwmci_host malloc fail!\n"); - return -ENOMEM; - } - - memset(host, 0, sizeof(struct dwmci_host)); - host->name = "Synopsys Mobile storage"; - host->ioaddr = (void *)SDIO_BASE; - host->buswidth = 4; - host->dev_index = 0; - host->bus_hz = 5000; - - add_dwmci(host, host->bus_hz / 2, 40); - - return 0; -} - -int board_mmc_getcd(struct mmc *mmc) -{ - struct dwmci_host *host = mmc->priv;
[PATCH] arc: emsdp: Increase max FAT cluster size
Some especially large SD-cards come from stock formatted with larger FAT cluster size so to accommodate those we just increase what we expect to have here in U-Boot given we have a plenty of space on EM SDP (16 MiB). Signed-off-by: Alexey Brodkin --- configs/emsdp_defconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig index 42415ea713..09fe388e58 100644 --- a/configs/emsdp_defconfig +++ b/configs/emsdp_defconfig @@ -29,6 +29,6 @@ CONFIG_MMC_DW=y CONFIG_MMC_DW_SNPS=y CONFIG_DM_SERIAL=y CONFIG_SYS_NS16550=y -CONFIG_FS_FAT_MAX_CLUSTSIZE=4096 +CONFIG_FS_FAT_MAX_CLUSTSIZE=32768 CONFIG_USE_PRIVATE_LIBGCC=y CONFIG_PANIC_HANG=y -- 2.17.1 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH 3/6] ARC: mm: TLB Miss optim: avoid re-reading ECR
Hi Vineet, > -Original Message- > From: Vineet Gupta > Sent: Monday, September 16, 2019 2:32 PM > To: linux-snps-arc@lists.infradead.org > Cc: Alexey Brodkin ; Vineet Gupta > Subject: [PATCH 3/6] ARC: mm: TLB Miss optim: avoid re-reading ECR > > For setting PTE Dirty bit, reuse the prior test for ST miss. > > No need to reload ECR and test for ST cause code as the prev > condition code is still valid (uncloberred) > > Signed-off-by: Vineet Gupta > --- > arch/arc/mm/tlbex.S | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/arch/arc/mm/tlbex.S b/arch/arc/mm/tlbex.S > index 110c72536e8b..4c88148d4cd1 100644 > --- a/arch/arc/mm/tlbex.S > +++ b/arch/arc/mm/tlbex.S > @@ -380,9 +380,7 @@ ENTRY(EV_TLBMissD) > > ; > ; UPDATE_PTE: Let Linux VM know that page was accessed/dirty I'd suggest to put a BOLD comment here saying that we rely on previously set condition flag so that whoever reads or (even worse) modifies that or previous code keeps in mind that we shouldn't clobber a particular flag. > - lr r3, [ecr] > or r0, r0, _PAGE_ACCESSED; Accessed bit always > - btst_s r3, ECR_C_BIT_DTLB_ST_MISS ; See if it was a Write Access ? > or.nz r0, r0, _PAGE_DIRTY ; if Write, set Dirty bit as well > st_sr0, [r1] ; Write back PTE -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [U-Boot] [RFC PATCH] net: designware: drop compatible altr, socfpga-stmmac
Hi Joe, > -Original Message- > From: Joe Hershberger > Sent: Wednesday, September 4, 2019 1:10 AM > To: Alexey Brodkin > Cc: Ralph Siemsen ; Joseph Hershberger > ; u- > b...@lists.denx.de; linux-snps-arc@lists.infradead.org; Eugeniy Paltsev > > Subject: Re: [U-Boot] [RFC PATCH] net: designware: drop compatible altr, > socfpga-stmmac > > On Tue, Aug 20, 2019 at 3:07 AM Alexey Brodkin > wrote: > > > > Hi Ralph, > > > > > -Original Message- > > > From: Ralph Siemsen > > > Sent: Monday, August 19, 2019 9:43 PM > > > To: u-b...@lists.denx.de; Joe Hershberger ; > > > Alexey Brodkin > > > ; Vlad Zakharov > > > Cc: Ralph Siemsen > > > Subject: [RFC PATCH] net: designware: drop compatible altr,socfpga-stmmac > > > > > > The same compatible = "altr,socfpga-stmmac" appears in both > > > drivers/net/designware.c and drivers/net/dwmac_socfgpa.c, > > > creating ambiguity in which driver will be bound. > > > > > > For Intel/Altera SoC devices, dwmac_socfpga.c is the correct driver. > > > So drop the compatible string from designware.c. > > > > > > Signed-off-by: Ralph Siemsen > > > --- > > > This compatible string also appears in: axs10x_mb.dtsi and hsdk.dts. > > > Maintainers of those boards have been copied, kindly review. > > > > Thanks for this clean-up. > > > > Speaking about AXS10x board where we do have DW GMAC > > I cannot recall the reason I chose to use "altr,socfpga-stmmac" > > for the board here [1] 3 years ago. > > > > But given we don't have any special quirks implemented whatever > > is the most generic DW GMAC compatible string is should be good for us. > > > > Joe, could you please suggest if we need to use just "st,stm32-dwmac" > > or add our own compatible as the ASIC is not from ST obviously but > > an FPGA with Synopsys ARC SoC? > > I think we should only be using what Linux does, so I'm afraid I have > to defer to what exists in the DTs there. In the Linux kernel we use "snps,dwmac", see [1]. But maybe we need to switch to "snps,dwmac-3.70a" even as what we really have is 3.73a. While in U-Boot we don't have either one, the most generic is "st,stm32-dwmac", see [2]. So maybe we want to add at least "snps,dwmac". @Jose Abreu could you please confirm if "snps,dwmac-3.70a" is OK for GMAC IP v3.73a? [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/arc/boot/dts/axs10x_mb.dtsi#n74 [2] https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/net/designware.c#L855 -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] mmc: dw_mmc: fix timeout calculate method
H Tom, [snip] > > > This is the patch with problem, and here is the link on patchwork: > > > https://patchwork.ozlabs.org/patch/1146845/ > > > > Please find my fixes here: > > https://patchwork.ozlabs.org/patch/1156541/ > > https://patchwork.ozlabs.org/patch/1156617/ > > > > Tom do we want https://patchwork.ozlabs.org/patch/1146845/ and fixes for it > > (see 2 items above) to become a part of upcoming v2019.10 release or > > it will be slated for the next one? > > I think we should aim to get all the fixes in for this release. Done, see https://lists.denx.de/pipermail/u-boot/2019-September/382628.html -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] mmc: dw_mmc: fix timeout calculate method
Hi Kever, > -Original Message- > From: Kever Yang > Sent: Monday, September 2, 2019 11:05 AM > To: Alexey Brodkin > Cc: tr...@konsulko.com; eugeniy.palt...@synopsys.com; Simon Glass > ; Peng Fan > ; u-b...@lists.denx.de > Subject: Re: [PATCH] mmc: dw_mmc: fix timeout calculate method > > Hi Alexey, > > On 2019/8/30 下午9:28, Alexey Brodkin wrote: > > Hi Kever, > > > > [snip] > > > >> I think this tree does not including this patch, Peng drop it because of > >> this issue, > >> so you need to apply this patch in your branch to reproduce the problem. > >> I have send out V2 patch for this fix with only using 32bit variable > > Could you please refer me to the problematic patch so I may try it? > > This is the patch with problem, and here is the link on patchwork: > https://patchwork.ozlabs.org/patch/1146845/ Please find my fixes here: https://patchwork.ozlabs.org/patch/1156541/ https://patchwork.ozlabs.org/patch/1156617/ Tom do we want https://patchwork.ozlabs.org/patch/1146845/ and fixes for it (see 2 items above) to become a part of upcoming v2019.10 release or it will be slated for the next one? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] arc: emsdp: Add more platform-specific compiler options
Even though EM SDP is FPGA-based board and different FPGA images (known as .bit-files) are awailable for the board still there's a common subset of options we may rely on for all configs. These are: * Normalizer * Swap instructions * Simple multiplier * Barrel-shifter * Floating-point unit * Shorter instructions (code density) This among other improvements allows to compile code with 64-bit divisions, see [1]. [1] https://patchwork.ozlabs.org/patch/1156541/ Signed-off-by: Alexey Brodkin Cc: Kever Yang --- board/synopsys/emsdp/config.mk | 2 ++ 1 file changed, 2 insertions(+) create mode 100644 board/synopsys/emsdp/config.mk diff --git a/board/synopsys/emsdp/config.mk b/board/synopsys/emsdp/config.mk new file mode 100644 index 00..67fd7bf82a --- /dev/null +++ b/board/synopsys/emsdp/config.mk @@ -0,0 +1,2 @@ +PLATFORM_CPPFLAGS += -mlittle-endian -mnorm -mswap -mmpy-option=3 \ + -mbarrel-shifter -mfpu=fpuda_all -mcode-density -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] arc: libgcc: Import __udivdi3 & __udivmoddi4 to allow 64-bit division
Hi, > -Original Message- > From: Alexey Brodkin > Sent: Monday, September 2, 2019 12:43 PM > To: u-b...@lists.denx.de > Cc: uboot-snps-...@synopsys.com; linux-snps-arc@lists.infradead.org; Alexey > Brodkin > ; Kever Yang > Subject: [PATCH] arc: libgcc: Import __udivdi3 & __udivmoddi4 to allow 64-bit > division > > As reported by Kever here [1] we were unable to compile 64-bit division > code due to missing definition of __udivdi3(). > > Import its implementation and __udivmoddi4() as its direct dependency > from today's libgcc [2]. > > [1] https://patchwork.ozlabs.org/patch/1146845/ > [2] > https://github.com/gcc-mirror/gcc/commit/5d8723600bc0eed41226b5a6785bc02a053b45d5 > > Signed-off-by: Alexey Brodkin > Cc: Kever Yang For the record for EM SDP (emsdp_defconfig) building still fails this way: ->8- arc-linux-ld.bfd: arch/arc/lib/lib.a(libgcc2.o): in function `__udivmoddi4': .../arch/arc/lib/libgcc2.c:195: undefined reference to `__clzdi2' arc-linux-ld.bfd: .../arch/arc/lib/libgcc2.c:195: undefined reference to `__clzdi2' arc-linux-ld.bfd: .../arch/arc/lib/libgcc2.c:196: undefined reference to `__clzdi2' arc-linux-ld.bfd: .../arch/arc/lib/libgcc2.c:196: undefined reference to `__clzdi2' ->8- That happens because we use a very simple -mcpu=arcem which doesn't use HW normalizer unit. I'm preparing a patch that will improve EM SDP's compiler options. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] arc: libgcc: Import __udivdi3 & __udivmoddi4 to allow 64-bit division
As reported by Kever here [1] we were unable to compile 64-bit division code due to missing definition of __udivdi3(). Import its implementation and __udivmoddi4() as its direct dependency from today's libgcc [2]. [1] https://patchwork.ozlabs.org/patch/1146845/ [2] https://github.com/gcc-mirror/gcc/commit/5d8723600bc0eed41226b5a6785bc02a053b45d5 Signed-off-by: Alexey Brodkin Cc: Kever Yang --- arch/arc/lib/libgcc2.c | 75 ++ 1 file changed, 75 insertions(+) diff --git a/arch/arc/lib/libgcc2.c b/arch/arc/lib/libgcc2.c index b92a841a37..ab1dbe1c13 100644 --- a/arch/arc/lib/libgcc2.c +++ b/arch/arc/lib/libgcc2.c @@ -158,3 +158,78 @@ __umodsi3(long a, long b) { return udivmodsi4(a, b, 1); } + +UDWtype +__udivmoddi4(UDWtype n, UDWtype d, UDWtype *rp) +{ + UDWtype q = 0, r = n, y = d; + UWtype lz1, lz2, i, k; + + /* +* Implements align divisor shift dividend method. This algorithm +* aligns the divisor under the dividend and then perform number of +* test-subtract iterations which shift the dividend left. Number of +* iterations is k + 1 where k is the number of bit positions the +* divisor must be shifted left to align it under the dividend. +* quotient bits can be saved in the rightmost positions of the +* dividend as it shifts left on each test-subtract iteration. +*/ + + if (y <= r) { + lz1 = __builtin_clzll(d); + lz2 = __builtin_clzll(n); + + k = lz1 - lz2; + y = (y << k); + + /* +* Dividend can exceed 2 ^ (width - 1) - 1 but still be less +* than the aligned divisor. Normal iteration can drops the +* high order bit of the dividend. Therefore, first +* test-subtract iteration is a special case, saving its +* quotient bit in a separate location and not shifting +* the dividend. +*/ + + if (r >= y) { + r = r - y; + q = (1ULL << k); + } + + if (k > 0) { + y = y >> 1; + + /* +* k additional iterations where k regular test +* subtract shift dividend iterations are done. +*/ + i = k; + do { + if (r >= y) + r = ((r - y) << 1) + 1; + else + r = (r << 1); + i = i - 1; + } while (i != 0); + + /* +* First quotient bit is combined with the quotient +* bits resulting from the k regular iterations. +*/ + q = q + r; + r = r >> k; + q = q - (r << k); + } + } + + if (rp) + *rp = r; + + return q; +} + +UDWtype +__udivdi3(UDWtype n, UDWtype d) +{ + return __udivmoddi4(n, d, (UDWtype *)0); +} -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] arc: emsdp: Add initialization of PSRAM
If the "Page Mode" is not enabled on the device, read operations from PSRAM may result in incorrect data. Signed-off-by: Alexey Brodkin --- board/synopsys/emsdp/emsdp.c | 37 + configs/emsdp_defconfig | 1 + 2 files changed, 38 insertions(+) diff --git a/board/synopsys/emsdp/emsdp.c b/board/synopsys/emsdp/emsdp.c index c0770b58c1..3bf4a1879b 100644 --- a/board/synopsys/emsdp/emsdp.c +++ b/board/synopsys/emsdp/emsdp.c @@ -48,6 +48,43 @@ int mach_cpu_init(void) return 0; } +int board_early_init_r(void) +{ +#define EMSDP_PSRAM_BASE 0xf2001000 +#define PSRAM_FLASH_CONFIG_REG_0 (void *)(EMSDP_PSRAM_BASE + 0x10) +#define PSRAM_FLASH_CONFIG_REG_1 (void *)(EMSDP_PSRAM_BASE + 0x14) +#define CRE_ENABLE BIT(31) +#define CRE_DRIVE_CMD BIT(6) + +#define PSRAM_RCR_DPD BIT(4) +#define PSRAM_RCR_PAGE_MODEBIT(7) + +/* + * PSRAM_FLASH_CONFIG_REG_x[30:15] to the address lines[16:1] of flash, + * thus "<< 1". + */ +#define PSRAM_RCR_SETUP((PSRAM_RCR_DPD | PSRAM_RCR_PAGE_MODE) << 1) + + // Switch PSRAM controller to command mode + writel(CRE_ENABLE | CRE_DRIVE_CMD, PSRAM_FLASH_CONFIG_REG_0); + // Program Refresh Configuration Register (RCR) for BANK0 + writew(0, (void *)(0x1000 + PSRAM_RCR_SETUP)); + // Switch PSRAM controller back to memory mode + writel(0, PSRAM_FLASH_CONFIG_REG_0); + + + // Switch PSRAM controller to command mode + writel(CRE_ENABLE | CRE_DRIVE_CMD, PSRAM_FLASH_CONFIG_REG_1); + // Program Refresh Configuration Register (RCR) for BANK1 + writew(0, (void *)(0x1080 + PSRAM_RCR_SETUP)); + // Switch PSRAM controller back to memory mode + writel(0, PSRAM_FLASH_CONFIG_REG_1); + + printf("PSRAM initialized.\n"); + + return 0; +} + int board_mmc_init(bd_t *bis) { struct dwmci_host *host = NULL; diff --git a/configs/emsdp_defconfig b/configs/emsdp_defconfig index 64281d0529..5e55e3e2b2 100644 --- a/configs/emsdp_defconfig +++ b/configs/emsdp_defconfig @@ -7,6 +7,7 @@ CONFIG_ENV_SIZE=0x1000 CONFIG_SYS_CLK_FREQ=4000 # CONFIG_ARCH_FIXUP_FDT_MEMORY is not set CONFIG_VERSION_VARIABLE=y +CONFIG_BOARD_EARLY_INIT_R=y CONFIG_HUSH_PARSER=y CONFIG_SYS_PROMPT="emsdp# " # CONFIG_CMD_BOOTD is not set -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [RFC PATCH] net: designware: drop compatible altr,socfpga-stmmac
Hi Ralph, > -Original Message- > From: Ralph Siemsen > Sent: Monday, August 19, 2019 9:43 PM > To: u-b...@lists.denx.de; Joe Hershberger ; Alexey > Brodkin > ; Vlad Zakharov > Cc: Ralph Siemsen > Subject: [RFC PATCH] net: designware: drop compatible altr,socfpga-stmmac > > The same compatible = "altr,socfpga-stmmac" appears in both > drivers/net/designware.c and drivers/net/dwmac_socfgpa.c, > creating ambiguity in which driver will be bound. > > For Intel/Altera SoC devices, dwmac_socfpga.c is the correct driver. > So drop the compatible string from designware.c. > > Signed-off-by: Ralph Siemsen > --- > This compatible string also appears in: axs10x_mb.dtsi and hsdk.dts. > Maintainers of those boards have been copied, kindly review. Thanks for this clean-up. Speaking about AXS10x board where we do have DW GMAC I cannot recall the reason I chose to use "altr,socfpga-stmmac" for the board here [1] 3 years ago. But given we don't have any special quirks implemented whatever is the most generic DW GMAC compatible string is should be good for us. Joe, could you please suggest if we need to use just "st,stm32-dwmac" or add our own compatible as the ASIC is not from ST obviously but an FPGA with Synopsys ARC SoC? [1] https://gitlab.denx.de/u-boot/u-boot/commit/fb2dea60e8f355ae00d427db09112a90839c96ec -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH v2 2/2] ARC: enable uboot support unconditionally
Hi Greg, > > May we have this one back-ported to linux-4.19.y? > > > > It was initially applied to Linus' tree during 5.0 development > > cycle [1] but was never back-ported. > > > > Now w/o that patch in KernelCI we see boot failure on ARC HSDK > > board [2] as opposed to normally working later kernel versions. > > > > [1] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=493a2f812446e92bcb1e69a77381b4d39808d730 > > [2] > > https://storage.kernelci.org/stable/linux-4.19.y/v4.19.59/arc/hsdk_defconfig/gcc-8/lab-baylibre/boot-hsdk.txt > > > > Below is that same patch but rebased on linux-4.19 as in its pristine > > form it won't apply due to offset of one of hunks. > > Why is this patch ok for stable kernel trees? Are you not removing > existing support in 4.19 for a feature that people might be using there? > What bug is this fixing that requires this removal? This patch removes a Kconfig option in a trade for properly working detection of arguments passed from U-Boot. Back in the day [3] we had to add that option to get kernel reliably working in use-cases w/o U-Boot (those were typically loading kernel image via JTAG). But with a couple of fixes applied to linux-4.19.y already we no longer need that explicit toggle as we may rely on data passed via dedicated registers and thus automatically know if there was U-Boot which passed some info to the kernel or there was no U-Boot and we don't need to mess with garbage in those registers. Main reason is to make vanilla 4.19.y kernels usable on HSDK board in KernelCI environment. Now they don't boot, see [2] as in HSDK's defconfig ARC_UBOOT_SUPPORT is not set. So we have 2 solutions: 1. Add ARC_UBOOT_SUPPORT to arch/arc/configs/hsdk_defconfig But we cannot do it for vanilla kernel because we simply cannot even submit that change to the Linus' tree as that Kconfig option was removed. Which means we cannot back-port it, right :) 2. Back-port proposed patch which already exists in the Linus'tree and thus is perfectly back-portable. Makes sense? -Alexey [2] https://storage.kernelci.org/stable/linux-4.19.y/v4.19.59/arc/hsdk_defconfig/gcc-8/lab-baylibre/boot-hsdk.txt [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=036b2c5664281e7da5a89c9f742491f30966485f ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH 2/2] dt-bindings: IDU-intc: Add support for edge-triggered interrupts
Hi Mischa, > -Original Message- > From: Mischa Jonker > Sent: Tuesday, July 23, 2019 1:26 PM > To: Vineet Gupta ; Alexey Brodkin > ; > kstew...@linuxfoundation.org; t...@linutronix.de; robh...@kernel.org; > linux-snps- > a...@lists.infradead.org; linux-ker...@vger.kernel.org; > devicet...@vger.kernel.org > Cc: Mischa Jonker > Subject: [PATCH 2/2] dt-bindings: IDU-intc: Add support for edge-triggered > interrupts > > This updates the documentation for supporting a optional extra interrupt > cell to specify edge vs level triggered. LGTM as well. But maybe split pure clean-up changes from addition of the new property description so that info about addition of new property is clearly seen? Otherwise it gets a bit lost among nice and useful generic fixes. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH 1/2] ARCv2: IDU-intc: Add support for edge-triggered interrupts
Hi Mischa, > -Original Message- > From: Mischa Jonker > Sent: Tuesday, July 23, 2019 1:26 PM > To: Vineet Gupta ; Alexey Brodkin > ; > kstew...@linuxfoundation.org; t...@linutronix.de; robh...@kernel.org; > linux-snps- > a...@lists.infradead.org; linux-ker...@vger.kernel.org; > devicet...@vger.kernel.org > Cc: Mischa Jonker > Subject: [PATCH 1/2] ARCv2: IDU-intc: Add support for edge-triggered > interrupts > > This adds support for an optional extra interrupt cell to specify edge > vs level triggered. It is backward compatible with dts files with only > one cell, and will default to level-triggered in such a case. In general LGTM. Still a couple of comments. It might be useful to explain changes made to idu_irq_set_affinity() as it's not immediately clear what affinity has to do with IRQ modes (in theory it should be orthogonal). But what happens we're actually fixing previously implemented short-cut when instead of a separately set IRQ mode we were doing it together with setup of distribution since it's done with the same one command (anyways we relied on the one and only IRQ type being supported). And now we have a proper implementation with separated setup of IRQ mode and affinity. > static int > idu_irq_set_affinity(struct irq_data *data, const struct cpumask *cpumask, >bool force) > @@ -263,13 +285,32 @@ idu_irq_set_affinity(struct irq_data *data, const > struct cpumask *cpumask, > else > distribution_mode = IDU_M_DISTRI_RR; > > - idu_set_mode(data->hwirq, IDU_M_TRIG_LEVEL, distribution_mode); > + idu_set_mode(data->hwirq, false, 0, true, distribution_mode); > > raw_spin_unlock_irqrestore(&mcip_lock, flags); > > return IRQ_SET_MASK_OK; > } > > +static int idu_irq_set_type(struct irq_data *data, u32 type) > +{ > + unsigned long flags; > + > + if (type & ~(IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH)) > + return -EINVAL; Maybe add an explanation why only these types are supported? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH v2] ARC: [plat-hsdk]: allow to switch between AXI DMAC port configurations
Hi Eugeniy, > -Original Message- > From: Eugeniy Paltsev > Sent: Monday, July 22, 2019 12:32 PM > To: linux-snps-arc@lists.infradead.org; Vineet Gupta > Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; > Eugeniy Paltsev > > Subject: [PATCH v2] ARC: [plat-hsdk]: allow to switch between AXI DMAC port > configurations > > We want to use DW AXI DMAC on HSDK board in our automated verification > to test cache & dma kernel code changes. This is perfect candidate > as we don't depend on any external peripherals like MMC card / USB > storage / etc. > To increase test coverage we want to test both options: > * DW AXI DMAC is connected through IOC port & dma direct ops used > * DW AXI DMAC is connected to DDR port & dma noncoherent ops used > > Introduce 'arc_hsdk_axi_dmac_coherent' global variable which can be > modified by debugger (same way as we patch 'ioc_enable') to switch > between these options without recompiling the kernel. > Depend on this value we tweak memory bridge configuration and > "dma-coherent" DTS property of DW AXI DMAC. Looks good to me. Acked-by: Alexey Brodkin -Thanks ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH v2 2/2] ARC: enable uboot support unconditionally
Hi Greg, > -Original Message- > From: Eugeniy Paltsev > Sent: Thursday, February 14, 2019 6:08 PM > To: linux-snps-arc@lists.infradead.org; Vineet Gupta > Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; > Corentin Labbe > ; khil...@baylibre.com; Eugeniy Paltsev > > Subject: [PATCH v2 2/2] ARC: enable uboot support unconditionally > > After reworking U-boot args handling code and adding paranoid > arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and > enable uboot support unconditionally. > > For JTAG case we can assume that core registers will come up > reset value of 0 or in worst case we rely on user passing > '-on=clear_regs' to Metaware debugger. > > Signed-off-by: Eugeniy Paltsev May we have this one back-ported to linux-4.19.y? It was initially applied to Linus' tree during 5.0 development cycle [1] but was never back-ported. Now w/o that patch in KernelCI we see boot failure on ARC HSDK board [2] as opposed to normally working later kernel versions. [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=493a2f812446e92bcb1e69a77381b4d39808d730 [2] https://storage.kernelci.org/stable/linux-4.19.y/v4.19.59/arc/hsdk_defconfig/gcc-8/lab-baylibre/boot-hsdk.txt Below is that same patch but rebased on linux-4.19 as in its pristine form it won't apply due to offset of one of hunks. -Alexey >8 >From 3e565355f6a2d1a82bc9ecd47a46d1fa3c0cd2c1 Mon Sep 17 00:00:00 2001 From: Eugeniy Paltsev Date: Thu, 14 Feb 2019 18:07:45 +0300 Subject: [PATCH] ARC: enable uboot support unconditionally After reworking U-boot args handling code and adding paranoid arguments check we can eliminate CONFIG_ARC_UBOOT_SUPPORT and enable uboot support unconditionally. For JTAG case we can assume that core registers will come up reset value of 0 or in worst case we rely on user passing '-on=clear_regs' to Metaware debugger. Cc: sta...@vger.kernel.org Tested-by: Corentin LABBE Signed-off-by: Eugeniy Paltsev Signed-off-by: Vineet Gupta --- arch/arc/Kconfig| 13 - arch/arc/configs/nps_defconfig | 1 - arch/arc/configs/vdk_hs38_defconfig | 1 - arch/arc/configs/vdk_hs38_smp_defconfig | 2 -- arch/arc/kernel/head.S | 2 -- arch/arc/kernel/setup.c | 2 -- 6 files changed, 21 deletions(-) diff --git a/arch/arc/Kconfig b/arch/arc/Kconfig index 85eb7fc2e241..97b45fe8f0c2 100644 --- a/arch/arc/Kconfig +++ b/arch/arc/Kconfig @@ -199,7 +199,6 @@ config NR_CPUS config ARC_SMP_HALT_ON_RESET bool "Enable Halt-on-reset boot mode" - default y if ARC_UBOOT_SUPPORT help In SMP configuration cores can be configured as Halt-on-reset or they could all start at same time. For Halt-on-reset, non @@ -538,18 +537,6 @@ config ARC_DBG_TLB_PARANOIA endif -config ARC_UBOOT_SUPPORT - bool "Support uboot arg Handling" - default n - help - ARC Linux by default checks for uboot provided args as pointers to - external cmdline or DTB. This however breaks in absence of uboot, - when booting from Metaware debugger directly, as the registers are - not zeroed out on reset by mdb and/or ARCv2 based cores. The bogus - registers look like uboot args to kernel which then chokes. - So only enable the uboot arg checking/processing if users are sure - of uboot being in play. - config ARC_BUILTIN_DTB_NAME string "Built in DTB" help diff --git a/arch/arc/configs/nps_defconfig b/arch/arc/configs/nps_defconfig index 6e84060e7c90..621f59407d76 100644 --- a/arch/arc/configs/nps_defconfig +++ b/arch/arc/configs/nps_defconfig @@ -31,7 +31,6 @@ CONFIG_ARC_CACHE_LINE_SHIFT=5 # CONFIG_ARC_HAS_LLSC is not set CONFIG_ARC_KVADDR_SIZE=402 CONFIG_ARC_EMUL_UNALIGNED=y -CONFIG_ARC_UBOOT_SUPPORT=y CONFIG_PREEMPT=y CONFIG_NET=y CONFIG_UNIX=y diff --git a/arch/arc/configs/vdk_hs38_defconfig b/arch/arc/configs/vdk_hs38_defconfig index 1e59a2e9c602..e447ace6fa1c 100644 --- a/arch/arc/configs/vdk_hs38_defconfig +++ b/arch/arc/configs/vdk_hs38_defconfig @@ -13,7 +13,6 @@ CONFIG_PARTITION_ADVANCED=y CONFIG_ARC_PLAT_AXS10X=y CONFIG_AXS103=y CONFIG_ISA_ARCV2=y -CONFIG_ARC_UBOOT_SUPPORT=y CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38" CONFIG_PREEMPT=y CONFIG_NET=y diff --git a/arch/arc/configs/vdk_hs38_smp_defconfig b/arch/arc/configs/vdk_hs38_smp_defconfig index b5c3f6c54b03..c82cdb10aaf4 100644 --- a/arch/arc/configs/vdk_hs38_smp_defconfig +++ b/arch/arc/configs/vdk_hs38_smp_defconfig @@ -15,8 +15,6 @@ CONFIG_AXS103=y CONFIG_ISA_ARCV2=y CONFIG_SMP=y # CONFIG_ARC_TIMERS_64BIT is not set -# CONFIG_ARC_SMP_HALT_ON_RESET is not set -CONFIG_ARC_UBOOT_SUPPORT=y CONFIG_ARC_BUILTIN_DTB_NAME="vdk_hs38_smp&q
[GIT PULL] drm/arc: Minor improvements
Hi Dave, Daniel, The following changes since commit 7aaddd96d5febcf5b24357a326b3038d49a20532: drm/modes: Don't apply cmdline's rotation if it wasn't specified (2019-07-16 10:34:38 +0200) are available in the Git repository at: g...@github.com:abrodkin/linux.git tags/arcpgu-updates-2019.07.18 for you to fetch changes up to cee17a71656e9e1b5ffc01767844026550d5f4a9: drm/arcpgu: rework encoder search (2019-07-17 23:36:56 +0300) This is a pretty simple improvement that allows to find encoder as the one and only (ARC PGU doesn't support more than one) endpoint instead of using non-standard "encoder-slave" property. Eugeniy Paltsev (1): drm/arcpgu: rework encoder search drivers/gpu/drm/arc/arcpgu_drv.c | 16 +--- 1 file changed, 13 insertions(+), 3 deletions(-) Regards, Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARCv2: Don't pretend we may set U & DE bits in STATUS32 with kflag
As per PRM "kflag" instruction doesn't change state of DE-flag ("Delayed branch is pending") and U-flag ("User mode") in STATUS32 register so let's not act as if we can affect those bits. Signed-off-by: Alexey Brodkin --- arch/arc/include/asm/entry-arcv2.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/arc/include/asm/entry-arcv2.h b/arch/arc/include/asm/entry-arcv2.h index 225e7df2d8ed..6558e2edb583 100644 --- a/arch/arc/include/asm/entry-arcv2.h +++ b/arch/arc/include/asm/entry-arcv2.h @@ -237,7 +237,7 @@ .macro FAKE_RET_FROM_EXCPN lr r9, [status32] - bic r9, r9, (STATUS_U_MASK|STATUS_DE_MASK|STATUS_AE_MASK) + bic r9, r9, STATUS_AE_MASK or r9, r9, STATUS_IE_MASK kflag r9 .endm -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: [haps] Add Virtio support
As a preparation for QEMU usage for ARC let's add basic Virtio-MMIO peripherals support for the platform we're going to use. For now we add 5 Virtio slots in .dts and enable block and network devices via Virtio-MMIO. Note even though typically Virtio register set fits in 0x200 bytes we "allocate" here 0x2000 so that it matches ARC's default 8KiB page size and so remapping of that area is done clearly. We also enable DEVTMPFS automount for more convenient use of external root file-stystem. Before that we used to use built-in Initramfs which didn't automount DEVTMPFS anyways so we didn't need that option, while now it starts making sense. Signed-off-by: Alexey Brodkin Cc: Rob Herring --- arch/arc/boot/dts/haps_hs.dts | 30 ++ arch/arc/configs/haps_hs_defconfig | 5 - 2 files changed, 34 insertions(+), 1 deletion(-) diff --git a/arch/arc/boot/dts/haps_hs.dts b/arch/arc/boot/dts/haps_hs.dts index 1ebfa046492b..44bc522fdec8 100644 --- a/arch/arc/boot/dts/haps_hs.dts +++ b/arch/arc/boot/dts/haps_hs.dts @@ -62,5 +62,35 @@ #interrupt-cells = <1>; interrupts = <20>; }; + + virtio0: virtio@f010 { + compatible = "virtio,mmio"; + reg = <0xf010 0x2000>; + interrupts = <31>; + }; + + virtio1: virtio@f0102000 { + compatible = "virtio,mmio"; + reg = <0xf0102000 0x2000>; + interrupts = <32>; + }; + + virtio2: virtio@f0104000 { + compatible = "virtio,mmio"; + reg = <0xf0104000 0x2000>; + interrupts = <33>; + }; + + virtio3: virtio@f0106000 { + compatible = "virtio,mmio"; + reg = <0xf0106000 0x2000>; + interrupts = <34>; + }; + + virtio4: virtio@f0108000 { + compatible = "virtio,mmio"; + reg = <0xf0108000 0x2000>; + interrupts = <35>; + }; }; }; diff --git a/arch/arc/configs/haps_hs_defconfig b/arch/arc/configs/haps_hs_defconfig index b117e6c16d41..436f2135bdc1 100644 --- a/arch/arc/configs/haps_hs_defconfig +++ b/arch/arc/configs/haps_hs_defconfig @@ -35,10 +35,12 @@ CONFIG_INET=y # CONFIG_IPV6 is not set # CONFIG_WIRELESS is not set CONFIG_DEVTMPFS=y +CONFIG_DEVTMPFS_MOUNT=y # CONFIG_STANDALONE is not set # CONFIG_PREVENT_FIRMWARE_BUILD is not set -# CONFIG_BLK_DEV is not set +CONFIG_VIRTIO_BLK=y CONFIG_NETDEVICES=y +CONFIG_VIRTIO_NET=y # CONFIG_NET_VENDOR_ARC is not set # CONFIG_NET_VENDOR_BROADCOM is not set # CONFIG_NET_VENDOR_INTEL is not set @@ -68,6 +70,7 @@ CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_LOGO=y # CONFIG_HID is not set # CONFIG_USB_SUPPORT is not set +CONFIG_VIRTIO_MMIO=y # CONFIG_IOMMU_SUPPORT is not set CONFIG_EXT2_FS=y CONFIG_EXT2_FS_XATTR=y -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [uclibc-ng-devel] state of uClibc ARC soft-float support
Hi Waldemar, > -Original Message- > From: Waldemar Brodkorb > Sent: Friday, June 21, 2019 1:26 PM > To: Vineet Gupta > Cc: de...@uclibc-ng.org; arcml ; Alexey > Brodkin > > Subject: Re: [uclibc-ng-devel] state of uClibc ARC soft-float support > > Hi Vineet, > > I tried to sync the libm tests from glibc to uClibc-ng, but I think > I broke it. May be we should revert the commit? > 3384c45e66ddf18f235654b67ae34ac7dcb07534 There seems to be no commit with such hash: https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=3384c45e66ddf18f235654b67ae34ac7dcb07534 Did you mean something else? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] ARC: ARCv2: jump label: implement jump label patching
Hi Vineet, > -Original Message- > From: linux-snps-arc On Behalf > Of Vineet Gupta > Sent: Thursday, June 20, 2019 11:50 PM > To: Peter Zijlstra > Cc: linux-a...@vger.kernel.org; Ard Biesheuvel ; > Alexey Brodkin > ; linux-ker...@vger.kernel.org; Jason Baron > ; Paolo Bonzini > ; linux-snps-arc@lists.infradead.org; Eugeniy Paltsev > > Subject: Re: [PATCH] ARC: ARCv2: jump label: implement jump label patching [snip] > Insn encoding is always middl eendina - irrespective of endianness. Apparently only in little-endian mode instructions are encoded as middle-endian, see: -->8- # cat endian.S .global myfunc myfunc: mov r0, r1 -->8- Little-endian: -->8- # arc-linux-gcc -c -mcpu=archs endian.S -EL # arc-linux-objdump -d endian.o endian.o: file format elf32-littlearc Disassembly of section .text: : 0: 200a 0040 mov r0,r1 # arc-linux-readelf -x .text endian.o Hex dump of section '.text': 0x 0a204000. @. -->8- Big-endian: -->8- # arc-linux-gcc -c -mcpu=archs endian.S -EB # arc-linux-objdump -d endian.o endian.o: file format elf32-bigarc Disassembly of section .text: : 0: 200a 0040 mov r0,r1 # arc-linux-readelf -x .text endian.o Hex dump of section '.text': 0x 200a0040 ..@ -->8- -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] ARC: [plat-hsdk]: enable DW SPI controller
Hi Eugeniy, > -Original Message- > From: Eugeniy Paltsev > Sent: Friday, June 7, 2019 5:48 PM > To: linux-snps-arc@lists.infradead.org; Vineet Gupta > Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; > Eugeniy Paltsev > > Subject: [PATCH] ARC: [plat-hsdk]: enable DW SPI controller > > HSDK SoC has DW SPI controller. Enable it in preparation of > enabling on-board SPI peripherals. > > Signed-off-by: Eugeniy Paltsev Adding Rob and... Acked-by: Alexey Brodkin > arch/arc/boot/dts/hsdk.dts | 14 ++ > arch/arc/configs/hsdk_defconfig | 3 +++ > 2 files changed, 17 insertions(+) > > diff --git a/arch/arc/boot/dts/hsdk.dts b/arch/arc/boot/dts/hsdk.dts > index e57b24dd02e7..42e1c961ba48 100644 > --- a/arch/arc/boot/dts/hsdk.dts > +++ b/arch/arc/boot/dts/hsdk.dts > @@ -11,6 +11,7 @@ > */ > /dts-v1/; > > +#include > #include > > / { > @@ -233,6 +234,19 @@ > dma-coherent; > }; > > + spi0: spi@2 { > + compatible = "snps,dw-apb-ssi"; > + reg = <0x2 0x100>; > + #address-cells = <1>; > + #size-cells = <0>; > + interrupts = <16>; > + num-cs = <2>; > + reg-io-width = <4>; > + clocks = <&input_clk>; > + cs-gpios = <&creg_gpio 0 GPIO_ACTIVE_LOW>, > +<&creg_gpio 1 GPIO_ACTIVE_LOW>; > + }; > + > creg_gpio: gpio@14b0 { > compatible = "snps,creg-gpio-hsdk"; > reg = <0x14b0 0x4>; > diff --git a/arch/arc/configs/hsdk_defconfig b/arch/arc/configs/hsdk_defconfig > index 0c4411f50948..ccfa744fe755 100644 > --- a/arch/arc/configs/hsdk_defconfig > +++ b/arch/arc/configs/hsdk_defconfig > @@ -46,6 +46,9 @@ CONFIG_SERIAL_8250_CONSOLE=y > CONFIG_SERIAL_8250_DW=y > CONFIG_SERIAL_OF_PLATFORM=y > # CONFIG_HW_RANDOM is not set > +CONFIG_SPI=y > +CONFIG_SPI_DESIGNWARE=y > +CONFIG_SPI_DW_MMIO=y > CONFIG_GPIOLIB=y > CONFIG_GPIO_SYSFS=y > CONFIG_GPIO_DWAPB=y > -- > 2.21.0 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR
Hi Joseph, > -Original Message- > From: Joseph Myers > Sent: Monday, June 3, 2019 6:41 PM > To: Alexey Brodkin > Cc: Andreas Schwab ; libc-al...@sourceware.org; > linux-snps-arc@lists.infradead.org > Subject: Re: Pass config-time variable to LIBC_SLIBDIR_RTLDDIR > > On Fri, 31 May 2019, Alexey Brodkin wrote: > > > Hi Andreas, > > > > I'm trying to implement multilib support for ARC port of Glibc > > and for that we seem to need to have unique slibdir/rtlddir pair per > > each machine flavor. In our case these are at least: > > - ARC700 (legacy ARCompact architecture) > > - ARC HS38 (new gen ARCv2 architecture) > > - ARC HS38 with hardware floating-point > > - ARC HS48 (binary-compatible with HS38 but with different pipeline so > > compiler schedules instructions differently) > > If two processors are binary-compatible, in general you wouldn't have > different library directories. (The HWCAP mechanism can be used to have a > single dynamic linker search different directories for optimized libraries > depending on the processor; put the relevant HWCAP bits in > HWCAP_IMPORTANT. And of course you can just install different library > builds depending on the processor you'll be running the resulting OS on.) > > Different library directories are intended for the case where binaries for > different ABIs can be executed on the same system (e.g. 32-bit and 64-bit; > https://sourceware.org/ml/libc-alpha/2018-01/msg8.html gives more > details of the various places that need updating to support such a > configuration in glibc). For other cases of different ABIs, there should > be different dynamic linker names, to support multiarch configurations > that might run different-architecture binaries under emulation, but > different library directories are not required. Well I'm trying to solve a little bit different problem - to build a universal multilib cross-toolchain which will be usable for building binaries optimized for different ARC cores. Different I mean: - Binary-incompatible architecture generations: ARCv1/ARCv2 (both still 32-bit) - Hard/soft floating-point - etc. GCC itself handles multilib perfectly fine as long as C library components are installed in proper locations. And bare-metal toolchain with Newlib as well as uClibc Linux toolchain are known to work as expected: C libraries get installed to a subfolder referenced by "arc-linux-gcc -print-multi-lib". As for Glibc at least in Crosstool-NG (the one and only toolchain builder that supports multilib toolchains) Glibc's smarts are used for libs installation in sysroot. I think it used to be done similarly to Newlib & uClibc but then was converted to a current state by this commit: https://github.com/crosstool-ng/crosstool-ng/commit/43c303c946c61469181d633cd5620cb92e44c329 That said since I'm not yet interested in multiple libs on target maybe I'm just looking at a wrong place and instead CT-NG should be improved. Alexey Neyman (in CC) might have more to add here. > > Given we have in GCC a dedicated "-mcpu" value for each of items above > > my first thought was to "automatically" setup slibdir/rtlddir > > based on "-mcpu" value passed in CC during configuration. > > Checking -mcpu in CC is a bad idea, given that the compiler might have > been configured with a default CPU rather than passing it on the command > line. Well this case (no "-mcpu" in CC) is handled - then we just installed libs in default non-multilib location, i.e. simple "/lib". > Rather, you should test how the compiler behaves: either run $CC $CFLAGS > $CPPFLAGS -E -dM -xc /dev/null and extract and examine predefined macros, > or use AC_EGREP_CPP or AC_COMPILE_IFELSE for the same purpose. (If you > don't have predefined macros that make all the required ABI distinctions, > obviously you need to add them.) There are various examples of this in > existing configure / preconfigure fragments. Right I did see a lot of those. > Since there should be a finite list of known ABIs (which would be listed > on https://sourceware.org/glibc/wiki/ABIList for a port included in > glibc), you can then have a finite number of LIBC_SLIBDIR_RTLDDIR calls in > a case statement. Agree, but again this is more for run-time libs on target where having many flavors of libs is quite an overkill. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix
Hi Vineet, > -Original Message- > From: Vineet Gupta > Sent: Monday, June 3, 2019 7:25 PM > To: Alexey Brodkin ; linux-snps-arc@lists.infradead.org > Cc: linux-ker...@vger.kernel.org; Masahiro Yamada > > Subject: Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with > cc-cross-prefix > > On 6/2/19 11:31 PM, Alexey Brodkin wrote: > > For a long time we used to hard-code CROSS_COMPILE prefix > > for ARC until it started to cause problems, so we decided to > > solely rely on CROSS_COMPILE externally set by a user: > > commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's > > Makefile"). > > > > While it works perfectly fine for build-systems where the prefix > > gets defined anyways for us human beings it's quite an annoying > > requirement especially given most of time the same one prefix > > "arc-linux-" is all what we need. > > > > It looks like finally we're getting the best of both worlds: > > 1. W/o cross-toolchain we still may install headers, build .dtb etc > > 2. W/ cross-toolchain get the kerne built with only ARCH=arc > > > > Inspired by [1] & [2]. > > > > [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html > > [2] > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17 > > > > A side note: even though "cc-cross-prefix" does its job it pollutes > > console with output of "which" for all the prefixes it didn't manage to find > > a matching cross-compiler for like that: > > | # ARCH=arc make defconfig > > | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin) > > | *** Default configuration is based on 'nsim_hs_defconfig' > > > > Signed-off-by: Alexey Brodkin > > Cc: Masahiro Yamada > > Cc: Vineet Gupta > > Not a big deal but I'd propose we add "Suggested-by: vgupta" since that is > where > it came from. Ooops, indeed that should have been added, but instead I just mentioned your earlier email in the mailing list. Care to add yourself on patch application? -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix
Hi Masahiro-san, > -Original Message- > From: linux-snps-arc On Behalf > Of Masahiro Yamada > Sent: Monday, June 3, 2019 1:49 PM > To: linux-kbu...@vger.kernel.org > Cc: Michal Marek ; Vineet Gupta > ; Alexey Brodkin > ; linux-ker...@vger.kernel.org; linux-stable > ; Masahiro > Yamada ; linux-snps-arc@lists.infradead.org > Subject: [PATCH] kbuild: use more portable 'command -v' for cc-cross-prefix [snip] > Fixes: bd55f96fa9fc ("kbuild: refactor cc-cross-prefix implementation") > Cc: linux-stable # 5.1 > Reported-by: Alexey Brodkin > Signed-off-by: Masahiro Yamada > --- Thanks for the prompt fix - it does the trick, now no junk in the console! Tested-by: Alexey Brodkin ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix
Hi Masahiro-san, > -Original Message- > From: Masahiro Yamada > Sent: Monday, June 3, 2019 11:18 AM > To: Alexey Brodkin > Cc: arcml ; Linux Kernel Mailing List > ker...@vger.kernel.org>; Vineet Gupta > Subject: Re: [PATCH] ARC: build: Try to guess CROSS_COMPILE with > cc-cross-prefix > > Hi Alexey, > > On Mon, Jun 3, 2019 at 3:42 PM Alexey Brodkin > wrote: [snip] > > A side note: even though "cc-cross-prefix" does its job it pollutes > > console with output of "which" for all the prefixes it didn't manage to find > > a matching cross-compiler for like that: > > | # ARCH=arc make defconfig > > | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin) > > | *** Default configuration is based on 'nsim_hs_defconfig' > > > Oh really? > > masahiro@pug:~$ which arc-linux-gcc > /home/masahiro/tools/arc/bin/arc-linux-gcc > masahiro@pug:~$ which dummy-linux-gcc > masahiro@pug:~$ echo $? > 1 > > > When 'which' cannot find the given command, > it does not print anything to stderr. > > Does it work differently on your machine? Well on Ubuntu 18.04 indeed which doesn't show anything but on my build-server with CentOS 7 I'm getting mentioned verbose output: | # cat /etc/redhat-release | CentOS Linux release 7.3.1611 (Core) | # /usr/bin/which -v | GNU which v2.20, Copyright (C) 1999 - 2008 Carlo Wood. | GNU which comes with ABSOLUTELY NO WARRANTY; | This program is free software; your freedom to use, change | and distribute this program is protected by the GPL. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
[PATCH] ARC: build: Try to guess CROSS_COMPILE with cc-cross-prefix
For a long time we used to hard-code CROSS_COMPILE prefix for ARC until it started to cause problems, so we decided to solely rely on CROSS_COMPILE externally set by a user: commit 40660f1fcee8 ("ARC: build: Don't set CROSS_COMPILE in arch's Makefile"). While it works perfectly fine for build-systems where the prefix gets defined anyways for us human beings it's quite an annoying requirement especially given most of time the same one prefix "arc-linux-" is all what we need. It looks like finally we're getting the best of both worlds: 1. W/o cross-toolchain we still may install headers, build .dtb etc 2. W/ cross-toolchain get the kerne built with only ARCH=arc Inspired by [1] & [2]. [1] http://lists.infradead.org/pipermail/linux-snps-arc/2019-May/005788.html [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fc2b47b55f17 A side note: even though "cc-cross-prefix" does its job it pollutes console with output of "which" for all the prefixes it didn't manage to find a matching cross-compiler for like that: | # ARCH=arc make defconfig | which: no arceb-linux-gcc in (~/.local/bin:~/bin:/usr/bin:/usr/sbin) | *** Default configuration is based on 'nsim_hs_defconfig' Signed-off-by: Alexey Brodkin Cc: Masahiro Yamada Cc: Vineet Gupta --- arch/arc/Makefile | 4 1 file changed, 4 insertions(+) diff --git a/arch/arc/Makefile b/arch/arc/Makefile index e2b991f75bc5..9cfd2ba7a12d 100644 --- a/arch/arc/Makefile +++ b/arch/arc/Makefile @@ -8,6 +8,10 @@ KBUILD_DEFCONFIG := nsim_hs_defconfig +ifeq ($(CROSS_COMPILE),) +CROSS_COMPILE := $(call cc-cross-prefix, arc-linux- arceb-linux-) +endif + cflags-y += -fno-common -pipe -fno-builtin -mmedium-calls -D__linux__ cflags-$(CONFIG_ISA_ARCOMPACT) += -mA7 cflags-$(CONFIG_ISA_ARCV2) += -mcpu=hs38 -- 2.16.2 ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Pass config-time variable to LIBC_SLIBDIR_RTLDDIR
Hi Andreas, I'm trying to implement multilib support for ARC port of Glibc and for that we seem to need to have unique slibdir/rtlddir pair per each machine flavor. In our case these are at least: - ARC700 (legacy ARCompact architecture) - ARC HS38 (new gen ARCv2 architecture) - ARC HS38 with hardware floating-point - ARC HS48 (binary-compatible with HS38 but with different pipeline so compiler schedules instructions differently) - eventually there'll be newer generations like ARCv3/v4 etc Given we have in GCC a dedicated "-mcpu" value for each of items above my first thought was to "automatically" setup slibdir/rtlddir based on "-mcpu" value passed in CC during configuration. Something like that: -->8 +++ b/sysdeps/unix/sysv/linux/arc/configure.ac @@ -2,3 +2,10 @@ GLIBC_PROVIDES dnl See aclocal.m4 in the top level source directory. # Local configure fragment for sysdeps/unix/sysv/linux/arc. arch_minimum_kernel=3.9.0 + +# Extract "-mcpu=xxx" value from CC to install libs in a separate folder +arc_mcpu=[`echo $CC | grep -Po '\-mcpu=\K[^ ]+'`] + +if test "$arc_mcpu" != "" ; then + LIBC_SLIBDIR_RTLDDIR([lib/${arc_mcpu}], [lib/${arc_mcpu}]) +fi -->8 But apparently that doesn't work due to your change [1] in commit 128c43a2d630 ("LIBC_SLIBDIR_RTLDDIR: substitute arguments in single quotes"). I guess mentioned change is not supposed to be reverted but then how do you think it's possible [if at all] to implement that kind of "automatic" setup of slibdir/rtlddir? [1] https://sourceware.org/git/?p=glibc.git;a=commit;h=128c43a2d630 -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
RE: [PATCH] ARC: [plat-hsdk]: enable creg-gpio controller
Hi Eugeniy, > -Original Message- > From: Eugeniy Paltsev > Sent: Tuesday, May 28, 2019 12:41 PM > To: linux-snps-arc@lists.infradead.org; Vineet Gupta > Cc: linux-ker...@vger.kernel.org; Alexey Brodkin ; > Eugeniy Paltsev > > Subject: [PATCH] ARC: [plat-hsdk]: enable creg-gpio controller > > HSDK SOC has CREG GPIO controller which can be used to control SoC > SPI chip select lines. > Enable it in preparation of enabling SPI peripherals. Acked-by: Alexey Brodkin Adding Rob to the Cc list. -Alexey ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc