- 22 May, 2020 9 commits
-
-
Serge Semin authored
Due to being embedded into the CPU cores MIPS count/compare timer frequency is changed together with the CPU clocks alteration. In case if frequency really changes the kernel clockevent framework must be notified, otherwise the kernel timers won't work correctly. Fix this by calling clockevents_update_freq() for each r4k clockevent handlers registered per available CPUs. Traditionally MIPS r4k-clock are clocked with CPU frequency divided by 2. But this isn't true for some of the platforms. Due to this we have to save the basic CPU frequency, so then use it to scale the initial timer frequency (mips_hpt_frequency) and pass the updated value further to the clockevent framework. Signed-off-by:
Serge Semin <Sergey.Semin@baikalelectronics.ru> Cc: Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Paul Burton <paulburton@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de>
-
Serge Semin authored
Commit 07d69579 ("MIPS: Don't register r4k sched clock when CPUFREQ enabled") disabled the r4k-clock usage for scheduler ticks counting due to the scheduler being non-tolerant for unstable clocks sources. For the same reason the clock should be used in the system clocksource framework with care. As soon as CPU frequency changes the clocksource framework should be notified about this by marking the R4K timer being unstable (which it really is, since the ticks rate has been changed synchronously with the CPU frequency). Signed-off-by:
-
Serge Semin authored
Loops-per-jiffies is a special number which represents a number of noop-loop cycles per CPU-scheduler quantum - jiffies. As you understand aside from CPU-specific implementation it depends on the CPU frequency. So when a platform has the CPU frequency fixed, we have no problem and the current udelay interface will work just fine. But as soon as CPU-freq driver is enabled and the cores frequency changes, we'll end up with distorted udelay's. In order to fix this we have to accordinly adjust the per-CPU udelay_val (the same as the global loops_per_jiffy) number. This can be done in the CPU-freq transition event handler. We subscribe to that event in the MIPS arch time-inititalization method. Co-developed-by:
Alexey Malahov <Alexey.Malahov@baikalelectronics.ru> Signed-off-by:
Jiaxun Yang <jiaxun.yang@flygoat.com> Cc: Thomas Bogendoerfer <tsbogend@alpha.franken.de> Cc: Paul Burton <paulburton@kernel.org> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Arnd Bergmann <arnd@arndb.de> Cc: Rob Herring <robh+dt@kernel.org> Cc: devicetree@vger.kernel.org Signed-off-by:
-
Serge Semin authored
On some platforms IO-memory might require to use a proper load/store instructions (like Baikal-T1 IO-memory). To fix the cps-vec UART debug printout let's add the CONFIG_CPS_NS16550_WIDTH config to determine which instructions lb/sb, lh/sh or lw/sw are required for MMIO operations. Signed-off-by:
-
Serge Semin authored
There are bit fields which persist in the MIPS CONFIG and CONFIG6 registers, but haven't been described in the generic mipsregs.h header so far. In particular, the generic CONFIG bitfields are BE - endian mode, BM - burst mode, SB - SimpleBE, OCP interface mode indicator, UDI - user-defined "CorExtend" instructions, DSP - data scratch pad RAM present, ISP - instruction scratch pad RAM present, etc. The core-specific CONFIG6 bitfields are JRCD - jump register cache prediction disable, R6 - MIPSr6 extensions enable, IFUPerfCtl - IFU performance control, SPCD - sleep state performance counter, DLSB - disable load/store bonding. A new exception code reported in the ExcCode field of the Cause register: 30 - Parity/ECC error exception happened on either fetch, load or cache refill. Lets add them to the mipsregs.h header to be used in future platform code, which have them utilized. Signed-off-by:
-
Serge Semin authored
CP0 config register may indicate whether write-through merging is allowed. Currently there are two types of the merging available: SysAD Valid and Full modes. Whether each of them are supported by the core is implementation dependent. Moreover whether the ability to change the mode also depends on the chip family instance. Taking into account all of this we created a dedicated mm_config() method to detect and enable merging if it's supported. It is called for MIPS-type processors at CPU-probe stage and attempts to detect whether the write merging is available. If it's known to be supported and switchable, then switch on the full mode. Otherwise just perform the CP0.Config.MM field analysis. In addition there are platforms like InterAptiv/ProAptiv, which do have the MM bit field set by default, but having write-through cacheing unsupported makes write-merging also unsupported. In this case we just ignore the MM field value. Co-developed-by:
-
Serge Semin authored
Commit 1aeba347 ("MIPS: Hardcode cpu_has_mips* where target ISA allows") updated the cpu_has_mips* macro to be replaced with a constant expression where it's possible. By mistake it wasn't done correctly for cpu_has_mips64r1/cpu_has_mips64r2 macro. They are defined to be replaced with conditional expression __isa_range_or_flag(), which means either ISA revision being within the range or the corresponding CPU options flag was set at the probe stage or both being true at the same time. But the ISA level value doesn't indicate whether the ISA is MIPS32 or MIPS64. Due to this if we select MIPS32r1 - MIPS32r5 architectures the __isa_range() macro will activate the cpu_has_mips64rX flags, which is incorrect. In order to fix the problem we make sure the 64bits CPU support is enabled by means of checking the flag cpu_has_64bits aside with proper ISA range and specific Revision flag being set. Fixes: 1aeba347 ("MIPS: Hardcode cpu_has_mips* where target ISA allows") Signed-off-by:
-
Serge Semin authored
This is a MIPS32 Release 5 based IP core with XPA, EVA, dual/quad issue exec pipes, MMU with two-levels TLB, UCA, MSA, MDU core level features and system level features like up to six P5600 calculation cores, CM2 with L2 cache, IOCU/IOMMU (though might be unused depending on the system-specific IP core configuration), GIC, CPC, virtualisation module, eJTAG and PDtrace. As being MIPS32 Release 5 based core it provides all the features available by the CPU_MIPS32_R5 config, while adding a few more like UCA attribute support, availability of CPU-freq (by means of L2/CM clock ratio setting), EI/VI GIC modes detection at runtime. In addition to this if P5600 architecture is enabled modern GNU GCC provides a specific tuning for P5600 processors with respect to the classic MIPS32 Release 5. First of all branch-likely avoidance is activated only when the code is compiled with the speed optimization (avoidance is always enabled for the pure MIPS32 Release 5 architecture). Secondly the madd/msub avoidance is enabled since madd/msub utilization isn't profitable due to overhead of getting the result out of the HI/LO registers. Multiply-accumulate instructions are activated and utilized together with the necessary code reorder when multiply-add/multiply-subtract statements are met. Finally load/store bonding is activated by default. All of these optimizations may make the code relatively faster than if just MIP32 release 5 architecture was requested. Co-developed-by:
-
Serge Semin authored
There are five MIPS32/64 architecture releases currently available: from 1 to 6 except fourth one, which was intentionally skipped. Three of them can be called as major: 1st, 2nd and 6th, that not only have some system level alterations, but also introduced significant core/ISA level updates. The rest of the MIPS architecture releases are minor. Even though they don't have as much ISA/system/core level changes as the major ones with respect to the previous releases, they still provide a set of updates (I'd say they were intended to be the intermediate releases before a major one) that might be useful for the kernel and user-level code, when activated by the kernel or compiler. In particular the following features were introduced or ended up being available at/after MIPS32/64 Release 5 architecture: + the last release of the misaligned memory access instructions, + virtualisation - VZ ASE - is optional component of the arch, + SIMD - MSA ASE - is optional component of the arch, + DSP ASE is optional component of the arch, + CP0.Status.FR=1 for CP1.FIR.F64=1 (pure 64-bit FPU general registers) must be available if FPU is implemented, + CP1.FIR.Has2008 support is required so CP1.FCSR.{ABS2008,NAN2008} bits are available. + UFR/UNFR aliases to access CP0.Status.FR from user-space by means of ctc1/cfc1 instructions (enabled by CP0.Config5.UFR), + CP0.COnfig5.LLB=1 and eretnc instruction are implemented to without accidentally clearing LL-bit when returning from an interrupt, exception, or error trap, + XPA feature together with extended versions of CPx registers is introduced, which needs to have mfhc0/mthc0 instructions available. So due to these changes GNU GCC provides an extended instructions set support for MIPS32/64 Release 5 by default like eretnc/mfhc0/mthc0. Even though the architecture alteration isn't that big, it still worth to be taken into account by the kernel software. Finally we can't deny that some optimization/limitations might be found in future and implemented on some level in kernel or compiler. In this case having even intermediate MIPS architecture releases support would be more than useful. So the most of the changes provided by this commit can be split into either compile- or runtime configs related. The compile-time related changes are caused by adding the new CONFIG_CPU_MIPS32_R5/CONFIG_CPU_MIPSR5 configs and concern the code activating MIPSR2 or MIPSR6 already implemented features (like eretnc/LLbit, mthc0/mfhc0). In addition CPU_HAS_MSA can be now freely enabled for MIPS32/64 release 5 based platforms as this is done for CPU_MIPS32_R6 CPUs. The runtime changes concerns the features which are handled with respect to the MIPS ISA revision detected at run-time by means of CP0.Config.{AT,AR} bits. Alas these fields can be used to detect either r1 or r2 or r6 releases. But since we know which CPUs in fact support the R5 arch, we can manually set MIPS_CPU_ISA_M32R5/MIPS_CPU_ISA_M64R5 bit of c->isa_level and then use cpu_has_mips32r5/cpu_has_mips64r5 where it's appropriate. Since XPA/EVA provide too complex alterationss and to have them used with MIPS32 Release 2 charged kernels (for compatibility with current platform configs) they are left to be setup as a separate kernel configs. Co-developed-by:
-
- 21 May, 2020 2 commits
-
-
Serge Semin authored
Indeed according to the MIPS32 Privileged Resource Architecgture the MAAR pair register address field either takes [12:31] bits for non-XPA systems and [12:55] otherwise. In any case the current address mask is just wrong for 64-bit and 32-bits XPA chips. So lets extend it to 59-bits of physical address value. This shall cover the 64-bits architecture and systems with XPA enabled, and won't cause any problem for non-XPA 32-bit systems, since address values exceeding the architecture specific MAAR mask will be just truncated with setting zeros in the unsupported upper bits. Co-developed-by:
-
Tiezhu Yang authored
After commit f5ff0a28 ("[MIPS] Use generic NTP code for all MIPS platforms"), TICK_SIZE is not used in ip27-timer.c for many years, remove it. Signed-off-by:
Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by:
-
- 20 May, 2020 2 commits
-
-
Paul Cercueil authored
Add missing include which adds the prototype to plat_time_init(). Fixes: f932449c ("MIPS: ingenic: Drop obsolete code, merge the rest in setup.c") Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
-
Tiezhu Yang authored
After commit 0ce5ebd2 ("mfd: ioc3: Add driver for SGI IOC3 chip"), the related includes and comment about ioc3 are not used any more in ip27-timer.c, remove them. Signed-off-by:
-
- 19 May, 2020 3 commits
-
-
Serge Semin authored
When XPA mode is enabled the normally 32-bits MAAR pair registers are extended to be of 64-bits width as in pure 64-bits MIPS architecture. In this case the MAAR registers can enable the speculative loads/stores for addresses of up to 39-bits width. But in this case the process of the MAAR initialization changes a bit. The upper 32-bits of the registers are supposed to be accessed by mean of the dedicated instructions mfhc0/mthc0 and there is a CP0.MAAR.VH bit which should be set together with CP0.MAAR.VL as indication of the boundary validity. All of these peculiarities were taken into account in this commit so the speculative loads/stores would work when XPA mode is enabled. Co-developed-by:
-
Zhi Li authored
The parameter "cmdline_p" is useless in bootcmdline_init()，remove it. Signed-off-by:
Zhi Li <lizhi01@loongson.cn> Signed-off-by:
-
Tiezhu Yang authored
After commit 9d0aaf98 ("MIPS: SGI-IP27: Move all shared IP27 declarations to ip27-common.h"), ip27-common.h is included more than once in ip27-timer.c, remove it. Signed-off-by:
-
- 18 May, 2020 2 commits
-
-
Joshua Kinard authored
Remove an old macro that no longer exists anywhere else in the tree that snuck in when IP30 support was added Signed-off-by:
Joshua Kinard <kumba@gentoo.org> Signed-off-by:
-
Tiezhu Yang authored
After commit 87fcfa7b ("MIPS: Loongson64: Add generic dts"), there already exists the node and property of Loongson CPU UART0 in loongson3-package.dtsi: cpu_uart0: serial@1fe001e0 { compatible = "ns16550a"; reg = <0 0x1fe001e0 0x8>; clock-frequency = <33000000>; interrupt-parent = <&liointc>; interrupts = <10 IRQ_TYPE_LEVEL_HIGH>; no-loopback-test; }; In order to support for serial console on the Loongson platform, add CONFIG_SERIAL_OF_PLATFORM=y to loongson3_defconfig. With this patch, we can see the following boot messages: [ 1.877745] printk: console [ttyS0] disabled [ 1.881979] 1fe001e0.serial: ttyS0 at MMIO 0x1fe001e0 (irq = 16, base_baud = 2062500) is a 16550A [ 1.890838] printk: console [ttyS0] enabled And also, we can login normally from the serial console. Signed-off-by:
-
- 17 May, 2020 6 commits
-
-
Guoyun Sun authored
User space checkpoint and restart tool (CRIU) needs the page's change to be soft tracked. This allows to do a pre checkpoint and then dump only touched pages. Signed-off-by:
Guoyun Sun <sunguoyun@loongson.cn> Signed-off-by:
-
WANG Xuerui authored
These are exposed to userland alternatively via the new CPUCFG instruction on Loongson-3A R4 and above. Add definitions for readback on older cores. Signed-off-by:
WANG Xuerui <git@xen0n.name> Cc: Huacai Chen <chenhc@lemote.com> Cc: Jiaxun Yang <jiaxun.yang@flygoat.com> Signed-off-by:
-
WANG Xuerui authored
Add the constants for easier and maintainable composition of CPUCFG values. Signed-off-by:
-
WANG Xuerui authored
Fix some symbol names to align with Loongson's User Manual wording. Also correct the comment in csr_readq() suggesting the wrong instruction in use. Fixes: 6a6f9b7d ("MIPS: Loongson: Add CFUCFG&CSR support") Signed-off-by:
-
Tiezhu Yang authored
When CONFIG_HAVE_STD_PC_SERIAL_PORT is set, there exists build errors of 8250-platform.c due to linux/module.h is not included. CONFIG_HAVE_STD_PC_SERIAL_PORT is not used in arch/mips for many years, 8250-platform.c is also not built and used, so it is not necessary to fix the build errors, just remove the not used file 8250-platform.c and the related code in Kconfig and Makefile. Signed-off-by:
-
Tiezhu Yang authored
When ATI Radeon GPU driver has been compiled directly into the kernel instead of as a module, we should make sure the firmware for the model (check available ones in /lib/firmware/radeon) is built-in to the kernel as well, otherwise there exists the following fatal error during GPU init, change CONFIG_DRM_RADEON=y to CONFIG_DRM_RADEON=m to fix it. [ 1.900997] [drm] Loading RS780 Microcode [ 1.905077] radeon 0000:01:05.0: Direct firmware load for radeon/RS780_pfp.bin failed with error -2 [ 1.914140] r600_cp: Failed to load firmware "radeon/RS780_pfp.bin" [ 1.920405] [drm:r600_init] *ERROR* Failed to load firmware! [ 1.926069] radeon 0000:01:05.0: Fatal error during GPU init [ 1.931729] [drm] radeon: finishing device. Fixes: 024e6a8b ("MIPS: Loongson: Add a Loongson-3 default config file") Signed-off-by:
-
- 15 May, 2020 5 commits
-
-
Oleksij Rempel authored
schema violation was detected by the dtbs_check Signed-off-by:
Oleksij Rempel <o.rempel@pengutronix.de> Signed-off-by:
-
Oleksij Rempel authored
Fit led nodes to the latest naming schema. Signed-off-by:
-
Joshua Kinard authored
The attached patch wraps several of the macros in IP27's spaces.h header file with the _AC() macro. This matches most of the other spaces.h files in the MIPS tree. Signed-off-by:
-
Thomas Bogendoerfer authored
With the change of platform file inclusion object were included via platform-y and core-y. Remove the core-y part to fix it. Fixes: 26bff9eb ("MIPS: Only include the platformfile needed") Signed-off-by:
-
Thomas Bogendoerfer authored
Changing inclusion of Platform files, broke VR41xx platforms. Add Makefile to vr41xx directory and traverse subdirs from it. Fixes: 26bff9eb ("MIPS: Only include the platformfile needed") Signed-off-by:
-
- 13 May, 2020 7 commits
-
-
Zou Wei authored
Fixes coccicheck warnings: arch/mips/kvm/emulate.c:1793:3-4: Unneeded semicolon arch/mips/kvm/emulate.c:1968:3-4: Unneeded semicolon Reported-by:
Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zou Wei <zou_wei@huawei.com> Reviewed-by:
Huacai Chen <chenhc@lemote.com> Signed-off-by:
-
Zou Wei authored
Fixes coccicheck warnings: arch/mips/kvm/vz.c:1186:4-5: Unneeded semicolon arch/mips/kvm/vz.c:1195:3-4: Unneeded semicolon arch/mips/kvm/vz.c:1949:3-4: Unneeded semicolon arch/mips/kvm/vz.c:1121:2-3: Unneeded semicolon arch/mips/kvm/vz.c:2188:3-4: Unneeded semicolon Reported-by:
-
Jason Yan authored
Fix the following coccicheck warning: arch/mips/kvm/tlb.c:472:2-3: Unneeded semicolon arch/mips/kvm/tlb.c:489:2-3: Unneeded semicolon Signed-off-by:
Jason Yan <yanaijie@huawei.com> Signed-off-by:
-
Jason Yan authored
Fix the following coccicheck warning: arch/mips/kvm/mips.c:82:1-28: WARNING: Assignment of 0/1 to bool variable arch/mips/kvm/mips.c:88:1-28: WARNING: Assignment of 0/1 to bool variable Signed-off-by:
-
Lars Povlsen authored
This is an add-on patch to the main SoC Sparx5 series (Message-ID: <20200513125532.24585-1-lars.povlsen@microchip.com>). This changes the miim pinctrl function name from "miim1" to "miim" due to refactoring in the driver, obsoleting the instance number. The change in the driver was to better fit new platforms, as the instance number is redundant information. Specifically, support for the Microchip Sparx5 SoC is being submitted, where this change became necessary. Reviewed-by:
Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by:
Lars Povlsen <lars.povlsen@microchip.com> Acked-by:
-
Huacai Chen authored
Commit 26bff9eb ("MIPS: Only include the platformfile needed") moves platform-(CONFIG_XYZ) from arch/mips/xyz/Platform to arch/mips/ Kbuild.platforms. This change causes an error when "make clean": ./scripts/Makefile.clean:15: arch/mips/vr41xx/Makefile: No such file or directory make[3]: *** No rule to make target `arch/mips/vr41xx/Makefile'. Stop. make[2]: *** [arch/mips/vr41xx] Error 2 make[1]: *** [_clean_arch/mips] Error 2 make: *** [sub-make] Error 2 Clean-files are defined in arch/mips/Kbuild: obj- := $(platform-) Due to the movement of platform-(CONFIG_XYZ), "make clean" will enter arch/mips/vr41xx/ whether CONFIG_MACH_VR41XX is defined or not. Because there is no Makefile in arch/mips/vr41xx/, "make clean" fails. I don't know what is the best way to fix it, but it seems like we can avoid this error by changing the obj- definition: obj- := $(platform-y) Fixes: 26bff9eb ("MIPS: Only include the platformfile needed") Signed-off-by:
-
Huacai Chen authored
Commit 26bff9eb ("MIPS: Only include the platform file needed") misspelled "txx9" to "tx99", so fix it. Fixes: 26bff9eb ("MIPS: Only include the platform file needed") Signed-off-by:
-
- 12 May, 2020 4 commits
-
-
Thomas Bogendoerfer authored
Instead of including all Platform files, we simply include the needed one and avoid clashes with makefile variables. Signed-off-by: -
Nathan Chancellor authored
Currently, when linking with ld.lld, this warning pops up: arch/mips/vdso/Makefile:70: MIPS VDSO requires binutils >= 2.25 CONFIG_LD_VERSION is set with scripts/ld-version.sh, which is specific to GNU ld. It returns 0 for ld.lld so CONFIG_MIPS_LD_CAN_LINK_VDSO does not set. ld.lld has a completely different versioning scheme (as it follows LLVM's versioning) and it does not have the issue mentioned in the comment block so it should be allowed to link the VDSO. With this patch, the VDSO successfully links and shows P_MIPS_PC32 in vgettimeofday.o. $ llvm-objdump -Dr arch/mips/vdso/vgettimeofday.o | grep R_MIPS_PC32 00000024: R_MIPS_PC32 _start 000000b0: R_MIPS_PC32 _start 000002bc: R_MIPS_PC32 _start 0000036c: R_MIPS_PC32 _start 00000468: R_MIPS_PC32 _start Reported-by:Dmitry Golovin <dima@golovin.in> Signed-off-by:
Nathan Chancellor <natechancellor@gmail.com> Link: https://github.com/ClangBuiltLinux/linux/issues/785 Link: https://github.com/llvm/llvm-project/commit/e364e2e9ce50c12eb2bf093560e1a1a8544d455aSigned-off-by:
-
Nathan Chancellor authored
Currently, the VDSO is being linked through $(CC). This does not match how the rest of the kernel links objects, which is through the $(LD) variable. When clang is built in a default configuration, it first attempts to use the target triple's default linker then the system's default linker, unless told otherwise through -fuse-ld=... We do not use -fuse-ld= because it can be brittle and we have support for invoking $(LD) directly. See commit fe00e50b ("ARM: 8858/1: vdso: use $(LD) instead of $(CC) to link VDSO") and commit 691efbed ("arm64: vdso: use $(LD) instead of $(CC) to link VDSO") for examples of doing this in the VDSO. Do the same thing here. Replace the custom linking logic with $(cmd_ld) and ldflags-y so that $(LD) is respected. We need to explicitly add two flags to the linker that were implicitly passed by the compiler: -G 0 (which comes from ccflags-vdso) and --eh-frame-hdr. Before this patch (generated by adding '-v' to VDSO_LDFLAGS): <gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/collect2 \ -plugin <gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/liblto_plugin.so \ -plugin-opt=<gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/lto-wrapper \ -plugin-opt=-fresolution=/tmp/ccGEi5Ka.res \ --eh-frame-hdr \ -G 0 \ -EB \ -mips64r2 \ -shared \ -melf64btsmip \ -o arch/mips/vdso/vdso.so.dbg.raw \ -L<gcc_prefix>/lib/gcc/mips64-linux/9.3.0/64 \ -L<gcc_prefix>/lib/gcc/mips64-linux/9.3.0 \ -L<gcc_prefix>/lib/gcc/mips64-linux/9.3.0/../../../../mips64-linux/lib \ -Bsymbolic \ --no-undefined \ -soname=linux-vdso.so.1 \ -EB \ --hash-style=sysv \ --build-id \ -T arch/mips/vdso/vdso.lds \ arch/mips/vdso/elf.o \ arch/mips/vdso/vgettimeofday.o \ arch/mips/vdso/sigreturn.o After this patch: <gcc_prefix>/bin/mips64-linux-ld \ -m elf64btsmip \ -Bsymbolic \ --no-undefined \ -soname=linux-vdso.so.1 \ -EB \ -nostdlib \ -shared \ -G 0 \ --eh-frame-hdr \ --hash-style=sysv \ --build-id \ -T arch/mips/vdso/vdso.lds \ arch/mips/vdso/elf.o \ arch/mips/vdso/vgettimeofday.o arch/mips/vdso/sigreturn.o \ -o arch/mips/vdso/vdso.so.dbg.raw Note that we leave behind -mips64r2. Turns out that ld ignores it (see get_emulation in ld/ldmain.c). This is true of current trunk and 2.23, which is the minimum supported version for the kernel: https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldmain.c;hb=aa4209e7b679afd74a3860ce25659e71cc4847d5#l593 https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=ld/ldmain.c;hb=a55e30b51bc6227d8d41f707654d0a5620978dcf#l641 Before this patch, LD=ld.lld did nothing: $ llvm-readelf -p.comment arch/mips/vdso/vdso.so.dbg | sed 's/(.*//' String dump of section '.comment': [ 0] ClangBuiltLinux clang version 11.0.0 After this patch, it does: $ llvm-readelf -p.comment arch/mips/vdso/vdso.so.dbg | sed 's/(.*//' String dump of section '.comment': [ 0] Linker: LLD 11.0.0 [ 62] ClangBuiltLinux clang version 11.0.0 Link: https://github.com/ClangBuiltLinux/linux/issues/785Signed-off-by:
-
Nathan Chancellor authored
This was all done to work around a GCC bug that has been fixed after 4.2. The kernel requires GCC 4.6 or newer so remove all of these hacks and just use the traditional flags. $ mips64-linux-gcc --version | head -n1 mips64-linux-gcc (GCC) 4.6.3 $ mips64-linux-gcc -EB -dM -E -C -x c /dev/null | grep MIPSE #define MIPSEB 1 #define __MIPSEB__ 1 #define _MIPSEB 1 #define __MIPSEB 1 $ mips64-linux-gcc -EL -dM -E -C -x c /dev/null | grep MIPSE #define __MIPSEL__ 1 #define MIPSEL 1 #define _MIPSEL 1 #define __MIPSEL 1 This is necessary when converting the MIPS VDSO to use $(LD) instead of $(CC) to link because the OUTPUT_FORMAT is defaulted to little endian and only flips to big endian when '-EB' is set on the command line. There is no issue currently because the compiler explicitly passes '-EB' or '-EL' to the linker regardless of whether or not it was provided by the user. Passing '-v' to VDSO_LDFLAGS shows: <gcc_prefix>/libexec/gcc/mips64-linux/9.3.0/collect2 ... -EB ... even though '-EB' is nowhere to be found in KBUILD_CFLAGS. The VDSO Makefile already supports getting '-EB' or '-EL' from KBUILD_CFLAGS through a filter directive but '-EB' or '-EL' is not always present. If we do not do this, we will see the following error when compiling for big endian: $ make -j$(nproc) ARCH=mips CROSS_COMPILE=mips64-linux- \ 64r2el_defconfig arch/mips/vdso/ ... mips64-linux-ld: arch/mips/vdso/elf.o: compiled for a big endian system and target is little endian mips64-linux-ld: arch/mips/vdso/elf.o: endianness incompatible with that of the selected emulation mips64-linux-ld: failed to merge target specific data of file arch/mips/vdso/elf.o ... Remove this legacy hack and just use '-EB' and '-EL' unconditionally. Reported-by:
-
