- Feb 18, 2021
-
-
Add nodes for Cadence CSI2RX, DPHY, and TI's CSI2RX wrapper. Also add nodes for OV5640 which is the camera the drivers have been tested with. Signed-off-by:
Pratyush Yadav <p.yadav@ti.com> Signed-off-by:
Vignesh Raghavendra <vigneshr@ti.com>
-
Vignesh Raghavendra authored
ADC pins are not brought out on SK EVM. So keep it disabled. Signed-off-by: -
Vignesh Raghavendra authored
ADC is used by software running on R5 by default. Therefore mark the node as reserved in Linux DT. Signed-off-by:
-
- Feb 17, 2021
-
-
Enable PCIe and SERDES, since multi-link support is added in u-boot and the changes adapted in both kernel and ethernet firmware. Signed-off-by:
Kishon Vijay Abraham I <kishon@ti.com> Signed-off-by:
-
- Feb 11, 2021
-
-
Vignesh Raghavendra authored
AM642 SK has S28HS512T flash connected OSPI controller. Add DT entries for the same. Signed-off-by:
-
Vignesh Raghavendra authored
AM642 SK board has 2 CPSW ports. Add DT entries for the same. Also add timesync_router DT node. Signed-off-by: -
Enable USB Super-Speed HOST port. Signed-off-by:
-
WL1837 module is connected to SDHCI0 in AM642 SK. Enable it here. Signed-off-by:
-
- Feb 10, 2021
-
-
Suman Anna authored
The property 'ti,sci-rm-range-girq' is obsolete and was replaced with the equivalent property 'ti,interrupt-ranges'. This property was erroneously added in the Wkup GPIO Interrupt Router node. Drop this. Fixes: 86eb634b ("arm64: dts: ti: k3-j7200: Add GPIO interrupt routers") Signed-off-by:
Suman Anna <s-anna@ti.com>
-
Suman Anna authored
The property 'ti,sci-rm-range-girq' is obsolete and was replaced with the equivalent property 'ti,interrupt-ranges' in commit 05d9d8fb ("arm64: dts: k3-j721e: ti-sci-inta/intr: Update to latest bindings"). This property should have been deleted but was missed out in the Wkup GPIO Interrupt Router node. Fix this now. Signed-off-by:
-
- Feb 08, 2021
-
-
Suman Anna authored
Reserve some portions of the MAIN domain on-chip SRAM for use by various R5F cores on AM642 SK board. A bank (256 KB) each is reserved from the on-chip SRAM for each R5F core. This is done through specific child SRAM nodes in the board dts file. The memory regions are also assigned to each R5F remoteproc node using the sram property. The reserved SRAM banks are as follows for each core: Main R5FSS0 Core0 : OCSRAM1 Main R5FSS0 Core1 : OCSRAM2 Main R5FSS1 Core0 : OCSRAM3 Main R5FSS1 Core1 : OCSRAM4 The addresses chosen are the same as the respective processors on the AM64x EVM board to maintain firmware compatibility between the two boards. Please also see commit d4175486 ("arm64: dts: ti: k3-am642-evm: Reserve some on-chip SRAM for R5Fs"). Tested-by:
Lokesh Vutla <lokeshvutla@ti.com> Signed-off-by:
-
Suman Anna authored
Add a reserved memory node to reserve a portion of the DDR memory to be used for performing inter-processor communication between all the remote processors running RTOS or baremetal on the TI K3 AM642 SK board. 8 MB of memory is reserved for this purpose, and this accounts for all the vrings and vring buffers between all the possible pairs of remote processors. The reserved memory set aside is the same as the respective carveout on the AM64x EVM board to maintain firmware compatibility between the two boards. Please see commit bfe19680 ("arm64: dts: ti: k3-am642-evm: Reserve memory for IPC between RTOS cores"). Tested-by:
-
Suman Anna authored
Two carveout reserved memory nodes each have been added for each of the R5F remote processor devices within the MAIN domain on the TI AM642 SK board. These nodes are assigned to the respective rproc device nodes as well. The first region will be used as the DMA pool for the rproc devices, and the second region will furnish the static carveout regions for the firmware memory. The current carveout addresses and sizes are defined statically for each device. The R5F processors do not have an MMU, and as such require the exact memory used by the firmwares to be set-aside. The firmware images do not require any RSC_CARVEOUT entries in their resource tables to allocate the memory for firmware memory segments. The addresses chosen are the same as the respective processors on the AM64x EVM board to maintain firmware compatibility between the two boards. Note that the R5F1 carveouts are needed only if the R5F cluster is running in Split (non Single-CPU) mode. The reserved memory nodes can be disabled later on if there is no use-case defined to use the corresponding remote processor. Tested-by:
-
Suman Anna authored
Add the required 'mboxes' property to all the R5F processors on the TI AM642 SK board. The mailboxes and some shared memory are required for running the Remote Processor Messaging (RPMsg) stack between the host processor and each of the R5Fs. The chosen sub-mailboxes match the values used in the current firmware images. This can be changed, if needed, as per the system integration needs after making appropriate changes on the firmware side as well. Note that any R5F Core1 resources are needed and used only when that R5F cluster is configured for Split-mode. Tested-by:
-
Suman Anna authored
Add the sub-mailbox nodes that are used to communicate between MPU and various remote processors present in the AM64x SoCs for the AM642 SK board. These include the R5F remote processors in the two dual-R5F clusters (MAIN_R5FSS0 & MAIN_R5FSS1) in the MAIN domain; and a M4 processor in the MCU safety island. These sub-mailbox nodes utilize the System Mailbox clusters 2, 4 and 6. The remaining clusters 3, 5 and 7 are currently not used, and so are disabled. Clusters 0 and 1 were never added to the dts file as they do not support interrupts towards the A53 core. The sub-mailbox nodes added match the hard-coded mailbox configuration used within the TI RTOS IPC software packages. The R5F processor sub-systems are assumed to be running in Split mode, so a sub-mailbox node is used by each of the R5F cores. Only the sub-mailbox node for the first R5F core in each cluster is used in case of a Single-CPU mode for that R5F cluster. The nodes are all identical to those added on the AM64x EVM board to maintain firmware compatibility between the two boards. NOTE: The cluster nodes only have the Mailbox IP interrupt outputs that are routed to the GIC_SPI. The sub-mailbox nodes' irq-id are indexing into the listed interrupts, with the usr-id using the actual interrupt output line number from the Mailbox IP. Tested-by:
-
- Feb 07, 2021
-
-
arm64: dts: ti: k3-j7200-main: Remove sdhci-caps-mask to add support for SDR104 mode in MMCSD1 subsystem Remove sdhci-caps-mask property as SDR104 speed mode is now supported in MMCSD1 subsystem of J7200 SoC[1]. [1] - https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf Signed-off-by:
Aswath Govindraju <a-govindraju@ti.com> Signed-off-by:
-
HS200 and HS400 modes at 1.8 V card voltage, are now supported in MMCSD0 subsystem of J7200 SoC[1]. Set respective tags to indicate it. [1] - https://www.ti.com/lit/ug/spruiu1a/spruiu1a.pdf Signed-off-by:
-
- Feb 05, 2021
-
-
Lokesh Vutla authored
AM642 StarterKit (SK) board is a low cost, small form factor board designed for TI’s AM642 SoC. It supports the following interfaces: * 2 GB LPDDR4 RAM * x2 Gigabit Ethernet interfaces capable of working in switch and MAC mode * x1 USB 3.0 Type-A port * x1 UHS-1 capable µSD card slot * 2.4/5 GHz WLAN + Bluetooth 4.2 through WL1837 * 512 Mbit OSPI flash * x2 UART through UART-USB bridge * XDS110 for onboard JTAG debug using USB * Temperature sensors, user push buttons and LEDs * 40-pin Raspberry Pi compatible GPIO header * 24-pin header for peripherals in MCU island (I2C, UART, SPI, IO) * 54-pin header for Programmable Realtime Unit (PRU) IO pins * Interface for remote automation. Includes: * power measurement and reset control * boot mode change Add basic support for AM642 SK. Signed-off-by:
Sekhar Nori <nsekhar@ti.com>
-
- Jan 27, 2021
-
-
Necip Fazil Yildiran authored
commit f477a538 upstream. When G2_DMA is enabled and SH_DMA is disabled, it results in the following Kbuild warning: WARNING: unmet direct dependencies detected for SH_DMA_API Depends on [n]: SH_DMA [=n] Selected by [y]: - G2_DMA [=y] && SH_DREAMCAST [=y] The reason is that G2_DMA selects SH_DMA_API without depending on or selecting SH_DMA while SH_DMA_API depends on SH_DMA. When G2_DMA was first introduced with commit 40f49e7e ("sh: dma: Make G2 DMA configurable."), this wasn't an issue since SH_DMA_API didn't have such dependency, and this way was the only way to enable it since SH_DMA_API was non-visible. However, later SH_DMA_API was made visible and dependent on SH_DMA with commit d8902adc ("dmaengine: sh: Add Support SuperH DMA Engine driver"). Let G2_DMA depend on SH_DMA_API instead to avoid Kbuild issues. Fixes: d8902adc ("dmaengine: sh: Add Support SuperH DMA Engine driver") Signed-off-by:
Necip Fazil Yildiran <fazilyildiran@gmail.com> Signed-off-by:
Rich Felker <dalias@libc.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Yazen Ghannam authored
commit 76e2fc63 upstream. Set the maximum DIE per package variable on AMD using the NodesPerProcessor topology value. This will be used by RAPL, among others, to determine the maximum number of DIEs on the system in order to do per-DIE manipulations. [ bp: Productize into a proper patch. ] Fixes: 028c221e ("x86/CPU/AMD: Save AMD NodeId as cpu_die_id") Reported-by:
Johnathan Smithinovic <johnathan.smithinovic@gmx.at> Reported-by:
Rafael Kitover <rkitover@gmail.com> Signed-off-by:
Yazen Ghannam <Yazen.Ghannam@amd.com> Signed-off-by:
Borislav Petkov <bp@suse.de> Tested-by:
-
Andy Lutomirski authored
commit 67de8dca upstream. The default kernel_fpu_begin() doesn't work on systems that support XMM but haven't yet enabled CR4.OSFXSR. This causes crashes when _mmx_memcpy() is called too early because LDMXCSR generates #UD when the aforementioned bit is clear. Fix it by using kernel_fpu_begin_mask(KFPU_387) explicitly. Fixes: 7ad81676 ("x86/fpu: Reset MXCSR to default in kernel_fpu_begin()") Reported-by:
Krzysztof Mazur <krzysiek@podlesie.net> Signed-off-by:
Andy Lutomirski <luto@kernel.org> Signed-off-by:
Krzysztof Piotr Olędzki <ole@ans.pl> Tested-by:
-
Borislav Petkov authored
commit 1eb8f690 upstream. Move it outside of CONFIG_SMP in order to avoid ifdeffery at the usage sites. Fixes: 76e2fc63 ("x86/cpu/amd: Set __max_die_per_package on AMD") Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Reported-by:
kernel test robot <lkp@intel.com> Signed-off-by:
-
Andy Lutomirski authored
commit e4512289 upstream. Currently, requesting kernel FPU access doesn't distinguish which parts of the extended ("FPU") state are needed. This is nice for simplicity, but there are a few cases in which it's suboptimal: - The vast majority of in-kernel FPU users want XMM/YMM/ZMM state but do not use legacy 387 state. These users want MXCSR initialized but don't care about the FPU control word. Skipping FNINIT would save time. (Empirically, FNINIT is several times slower than LDMXCSR.) - Code that wants MMX doesn't want or need MXCSR initialized. _mmx_memcpy(), for example, can run before CR4.OSFXSR gets set, and initializing MXCSR will fail because LDMXCSR generates an #UD when the aforementioned CR4 bit is not set. - Any future in-kernel users of XFD (eXtended Feature Disable)-capable dynamic states will need special handling. Add a more specific API that allows callers to specify exactly what they want. Signed-off-by:
-
Ariel Marcovitch authored
[ Upstream commit 2225a8dd ] This is a bug that causes early crashes in builds with an .exit.text section smaller than a page and an .init.text section that ends in the beginning of a physical page (this is kinda random, which might explain why this wasn't really encountered before). The init sections are ordered like this: .init.text .exit.text .init.data Currently, these sections aren't page aligned. Because the init code might become read-only at runtime and because the .init.text section can potentially reside on the same physical page as .init.data, the beginning of .init.data might be mapped read-only along with .init.text. Then when the kernel tries to modify a variable in .init.data (like kthreadd_done, used in kernel_init()) the kernel panics. To avoid this, make _einittext page aligned and also align .exit.text to make sure .init.data is always seperated from the text segments. Fixes: 060ef9d8 ("powerpc32: PAGE_EXEC required for inittext") Signed-off-by:
Ariel Marcovitch <ariel.marcovitch@gmail.com> Reviewed-by:
Christophe Leroy <christophe.leroy@csgroup.eu> Signed-off-by:
Michael Ellerman <mpe@ellerman.id.au> Link: https://lore.kernel.org/r/20210102201156.10805-1-ariel.marcovitch@gmail.com Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
Youling Tang authored
[ Upstream commit fdcfeaba ] Use the common INIT_DATA_SECTION rule for the linker script in an effort to regularize the linker script. Signed-off-by:
Youling Tang <tangyouling@loongson.cn> Signed-off-by:
-
Sagar Shrikant Kadam authored
[ Upstream commit 0983834a ] Ethernet phy VSC8541-01 on HiFive Unleashed has its reset line connected to a gpio, so enable GPIO driver's required to reset the phy. Signed-off-by:
Sagar Shrikant Kadam <sagar.kadam@sifive.com> Signed-off-by:
Palmer Dabbelt <palmerdabbelt@google.com> Signed-off-by:
-
Sagar Shrikant Kadam authored
[ Upstream commit be969b7c ] HiFive unleashed A00 board has VSC8541-01 ethernet phy, this device is identified as a Revision B device as described in device identification registers. In order to use this phy in the unmanaged mode, it requires a specific reset sequence of logical 0-1-0-1 transition on the NRESET pin as documented here [1]. Currently, the bootloader (fsbl or u-boot-spl) takes care of the phy reset. If due to some reason the phy device hasn't received the reset by the prior stages before the linux macb driver comes into the picture, the MACB mii bus gets probed but the mdio scan fails and is not even able to read the phy ID registers. It gives an error message: "libphy: MACB_mii_bus: probed mdio_bus 10090000.ethernet-ffffffff: MDIO device at address 0 is missing." Thus adding the device OUI (Organizationally Unique Identifier) to the phy device node helps to probe the phy device. [1]: VSC8541-01 datasheet: https://www.mouser.com/ds/2/523/Microsemi_VSC8541-01_Datasheet_10496_V40-1148034.pdf Signed-off-by:
-
David Woodhouse authored
[ Upstream commit b36b0fe9 ] It's useful to be able to test non-vector event channel delivery, to make sure Linux will work properly on older Xen which doesn't have it. It's also useful for those working on Xen and Xen-compatible hypervisors, because there are guest kernels still in active use which use PCI INTX even when vector delivery is available. Signed-off-by:
David Woodhouse <dwmw@amazon.co.uk> Reviewed-by:
Boris Ostrovsky <boris.ostrovsky@oracle.com> Link: https://lore.kernel.org/r/20210106153958.584169-4-dwmw2@infradead.org Signed-off-by:
Juergen Gross <jgross@suse.com> Signed-off-by:
-
David Woodhouse authored
[ Upstream commit 3499ba81 ] For a while, event channel notification via the PCI platform device has been broken, because we attempt to communicate with xenstore before we even have notifications working, with the xs_reset_watches() call in xs_init(). We tend to get away with this on Xen versions below 4.0 because we avoid calling xs_reset_watches() anyway, because xenstore might not cope with reading a non-existent key. And newer Xen *does* have the vector callback support, so we rarely fall back to INTX/GSI delivery. To fix it, clean up a bit of the mess of xs_init() and xenbus_probe() startup. Call xs_init() directly from xenbus_init() only in the !XS_HVM case, deferring it to be called from xenbus_probe() in the XS_HVM case instead. Then fix up the invocation of xenbus_probe() to happen either from its device_initcall if the callback is available early enough, or when the callback is finally set up. This means that the hack of calling xenbus_probe() from a workqueue after the first interrupt, or directly from the PCI platform device setup, is no longer needed. Signed-off-by:
-
Arnd Bergmann authored
[ Upstream commit c35a824c ] With UBSAN enabled and building with clang, there are occasionally warnings like WARNING: modpost: vmlinux.o(.text+0xc533ec): Section mismatch in reference from the function arch_atomic64_or() to the variable .init.data:numa_nodes_parsed The function arch_atomic64_or() references the variable __initdata numa_nodes_parsed. This is often because arch_atomic64_or lacks a __initdata annotation or the annotation of numa_nodes_parsed is wrong. for functions that end up not being inlined as intended but operating on __initdata variables. Mark these as __always_inline, along with the corresponding asm-generic wrappers. Signed-off-by:
Arnd Bergmann <arnd@arndb.de> Acked-by:
Will Deacon <will@kernel.org> Link: https://lore.kernel.org/r/20210108092024.4034860-1-arnd@kernel.org Signed-off-by:
Catalin Marinas <catalin.marinas@arm.com> Signed-off-by:
-
Damien Le Moal authored
[ Upstream commit 11f4c2e9 ] If of_clk_init() is not called in time_init(), clock providers defined in the system device tree are not initialized, resulting in failures for other devices to initialize due to missing clocks. Similarly to other architectures and to the default kernel time_init() implementation, call of_clk_init() before executing timer_probe() in time_init(). Signed-off-by:
Damien Le Moal <damien.lemoal@wdc.com> Acked-by:
Stephen Boyd <sboyd@kernel.org> Reviewed-by:
-
- Jan 19, 2021
-
-
Arnd Bergmann authored
[ Upstream commit bac71717 ] dtc points out that the interrupts for some devices are not parsable: picoxcell-pc3x2.dtsi:45.19-49.5: Warning (interrupts_property): /paxi/gem@30000: Missing interrupt-parent picoxcell-pc3x2.dtsi:51.21-55.5: Warning (interrupts_property): /paxi/dmac@40000: Missing interrupt-parent picoxcell-pc3x2.dtsi:57.21-61.5: Warning (interrupts_property): /paxi/dmac@50000: Missing interrupt-parent picoxcell-pc3x2.dtsi:233.21-237.5: Warning (interrupts_property): /rwid-axi/axi2pico@c0000000: Missing interrupt-parent There are two VIC instances, so it's not clear which one needs to be used. I found the BSP sources that reference VIC0, so use that: https://github.com/r1mikey/meta-picoxcell/blob/master/recipes-kernel/linux/linux-picochip-3.0/0001-picoxcell-support-for-Picochip-picoXcell-SoC.patch Acked-by:
Jamie Iles <jamie@jamieiles.com> Link: https://lore.kernel.org/r/20201230152010.3914962-1-arnd@kernel.org ' Signed-off-by:
-
Randy Dunlap authored
[ Upstream commit 8a48c0a3 ] fs/dax.c uses copy_user_page() but ARC does not provide that interface, resulting in a build error. Provide copy_user_page() in <asm/page.h>. ../fs/dax.c: In function 'copy_cow_page_dax': ../fs/dax.c:702:2: error: implicit declaration of function 'copy_user_page'; did you mean 'copy_to_user_page'? [-Werror=implicit-function-declaration] Reported-by:
Randy Dunlap <rdunlap@infradead.org> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: linux-snps-arc@lists.infradead.org Cc: Dan Williams <dan.j.williams@intel.com> #Acked-by: Vineet Gupta <vgupta@synopsys.com> # v1 Cc: Andrew Morton <akpm@linux-foundation.org> Cc: Matthew Wilcox <willy@infradead.org> Cc: Jan Kara <jack@suse.cz> Cc: linux-fsdevel@vger.kernel.org Cc: linux-nvdimm@lists.01.org #Reviewed-by: Ira Weiny <ira.weiny@intel.com> # v2 Signed-off-by:
Vineet Gupta <vgupta@synopsys.com> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit c5e6ae56 ] If you run 'make uImage uImage.gz' with the parallel option, uImage.gz will be created by two threads simultaneously. This is because arch/arc/Makefile does not specify the dependency between uImage and uImage.gz. Hence, GNU Make assumes they can be built in parallel. One thread descends into arch/arc/boot/ to create uImage, and another to create uImage.gz. Please notice the same log is displayed twice in the following steps: $ export CROSS_COMPILE=<your-arc-compiler-prefix> $ make -s ARCH=arc defconfig $ make -j$(nproc) ARCH=arc uImage uImage.gz [ snip ] LD vmlinux SORTTAB vmlinux SYSMAP System.map OBJCOPY arch/arc/boot/vmlinux.bin OBJCOPY arch/arc/boot/vmlinux.bin GZIP arch/arc/boot/vmlinux.bin.gz GZIP arch/arc/boot/vmlinux.bin.gz UIMAGE arch/arc/boot/uImage.gz UIMAGE arch/arc/boot/uImage.gz Image Name: Linux-5.10.0-rc4-00003-g62f23044 Created: Sun Nov 22 02:52:26 2020 Image Type: ARC Linux Kernel Image (gzip compressed) Data Size: 2109376 Bytes = 2059.94 KiB = 2.01 MiB Load Address: 80000000 Entry Point: 80004000 Image arch/arc/boot/uImage is ready Image Name: Linux-5.10.0-rc4-00003-g62f23044 Created: Sun Nov 22 02:52:26 2020 Image Type: ARC Linux Kernel Image (gzip compressed) Data Size: 2815455 Bytes = 2749.47 KiB = 2.69 MiB Load Address: 80000000 Entry Point: 80004000 This is a race between the two threads trying to write to the same file arch/arc/boot/uImage.gz. This is a potential problem that can generate a broken file. I fixed a similar problem for ARM by commit 3939f334 ("ARM: 8418/1: add boot image dependencies to not generate invalid images"). I highly recommend to avoid such build rules that cause a race condition. Move the uImage rule to arch/arc/Makefile. Another strangeness is that arch/arc/boot/Makefile compares the timestamps between $(obj)/uImage and $(obj)/uImage.*: $(obj)/uImage: $(obj)/uImage.$(suffix-y) @ln -sf $(notdir $<) $@ @echo ' Image $@ is ready' This does not work as expected since $(obj)/uImage is a symlink. The symlink should be created in a phony target rule. I used $(kecho) instead of echo to suppress the message 'Image arch/arc/boot/uImage is ready' when the -s option is given. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 0cfccb3c ] The top-level boot_targets (uImage and uImage.*) should be phony targets. They just let Kbuild descend into arch/arc/boot/ and create files there. If a file exists in the top directory with the same name, the boot image will not be created. You can confirm it by the following steps: $ export CROSS_COMPILE=<your-arc-compiler-prefix> $ make -s ARCH=arc defconfig all # vmlinux will be built $ touch uImage.gz $ make ARCH=arc uImage.gz CALL scripts/atomic/check-atomics.sh CALL scripts/checksyscalls.sh CHK include/generated/compile.h # arch/arc/boot/uImage.gz is not created Specify the targets as PHONY to fix this. Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit f2712ec7 ] arch/arc/boot/Makefile supports uImage.lzma, but you cannot do 'make uImage.lzma' because the corresponding target is missing in arch/arc/Makefile. Add it. I also changed the assignment operator '+=' to ':=' since this is the only place where we expect this variable to be set. Signed-off-by:
-
Masahiro Yamada authored
[ Upstream commit 98367209 ] The deb-pkg builds for ARCH=arc fail. $ export CROSS_COMPILE=<your-arc-compiler-prefix> $ make -s ARCH=arc defconfig $ make ARCH=arc bindeb-pkg SORTTAB vmlinux SYSMAP System.map MODPOST Module.symvers make KERNELRELEASE=5.10.0-rc4 ARCH=arc KBUILD_BUILD_VERSION=2 -f ./Makefile intdeb-pkg sh ./scripts/package/builddeb cp: cannot stat 'arch/arc/boot/bootpImage': No such file or directory make[4]: *** [scripts/Makefile.package:87: intdeb-pkg] Error 1 make[3]: *** [Makefile:1527: intdeb-pkg] Error 2 make[2]: *** [debian/rules:13: binary-arch] Error 2 dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2 make[1]: *** [scripts/Makefile.package:83: bindeb-pkg] Error 2 make: *** [Makefile:1527: bindeb-pkg] Error 2 The reason is obvious; arch/arc/Makefile sets $(boot)/bootpImage as the default image, but there is no rule to build it. Remove the meaningless KBUILD_IMAGE assignment so it will fallback to the default vmlinux. With this change, you can build the deb package. I removed the 'bootpImage' target as well. At best, it provides 'make bootpImage' as an alias of 'make vmlinux', but I do not see much sense in doing so. Signed-off-by:
-
Alexander Lobakin authored
commit 69e97683 upstream. LLVM-built Linux triggered a boot hangup with KASLR enabled. arch/mips/kernel/relocate.c:get_random_boot() uses linux_banner, which is a string constant, as a random seed, but accesses it as an array of unsigned long (in rotate_xor()). When the address of linux_banner is not aligned to sizeof(long), such access emits unaligned access exception and hangs the kernel. Use PTR_ALIGN() to align input address to sizeof(long) and also align down the input length to prevent possible access-beyond-end. Fixes: 405bc8fd ("MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE") Cc: stable@vger.kernel.org # 4.7+ Signed-off-by:
Alexander Lobakin <alobakin@pm.me> Tested-by:
Nathan Chancellor <natechancellor@gmail.com> Reviewed-by:
Kees Cook <keescook@chromium.org> Signed-off-by:
Thomas Bogendoerfer <tsbogend@alpha.franken.de> Signed-off-by:
-
Paul Cercueil authored
commit 4d4f9c1a upstream. The compressed payload is not necesarily 4-byte aligned, at least when compiling with Clang. In that case, the 4-byte value appended to the compressed payload that corresponds to the uncompressed kernel image size must be read using get_unaligned_le32(). This fixes Clang-built kernels not booting on MIPS (tested on a Ingenic JZ4770 board). Fixes: b8f54f2c ("MIPS: ZBOOT: copy appended dtb to the end of the kernel") Cc: <stable@vger.kernel.org> # v4.7 Signed-off-by:
Paul Cercueil <paul@crapouillou.net> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Reviewed-by:
Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by:
-
Anders Roxell authored
commit 5b058973 upstream. When building mips tinyconfig with clang the following warning show up: arch/mips/lib/uncached.c:45:6: warning: variable 'sp' is uninitialized when used here [-Wuninitialized] if (sp >= (long)CKSEG0 && sp < (long)CKSEG2) ^~ arch/mips/lib/uncached.c:40:18: note: initialize the variable 'sp' to silence this warning register long sp __asm__("$sp"); ^ = 0 1 warning generated. Rework to make an explicit inline move, instead of the non-standard use of specifying registers for local variables. This is what's written from the gcc-10 manual [1] about specifying registers for local variables: "6.47.5.2 Specifying Registers for Local Variables ................................................. [...] "The only supported use for this feature is to specify registers for input and output operands when calling Extended 'asm' (*note Extended Asm::). [...]". [1] https://docs.w3cub.com/gcc~10/local-register-variables Signed-off-by:
Anders Roxell <anders.roxell@linaro.org> Reported-by:
Naresh Kamboju <naresh.kamboju@linaro.org> Reviewed-by:
-
