- 21 1月, 2018 1 次提交
-
-
由 Mathieu Malaterre 提交于
Improve the DTS files by removing all the leading "0x" and zeros to fix the following dtc warnings: Warning (unit_address_format): Node /XXX unit name should not have leading "0x" and: Warning (unit_address_format): Node /XXX unit name should not have leading 0s Converted using the following command: find . -type f \( -iname *.dts -o -iname *.dtsi \) -exec sed -E -i -e "s/@0x([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" -e "s/@0+([0-9a-fA-F\.]+)\s?\{/@\L\1 \{/g" {} + For simplicity, two sed expressions were used to solve each warnings separately. To make the regex expression more robust a few other issues were resolved, namely setting unit-address to lower case, and adding a whitespace before the the opening curly brace: https://elinux.org/Device_Tree_Linux#Linux_conventions This is a follow up to commit 4c9847b7 ("dt-bindings: Remove leading 0x from bindings notation") Reported-by: NDavid Daney <ddaney@caviumnetworks.com> Suggested-by: NRob Herring <robh@kernel.org> Signed-off-by: NMathieu Malaterre <malat@debian.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 11 12月, 2017 3 次提交
-
-
由 Michael Ellerman 提交于
As far as I can tell CONFIG_CPM is the right symbol to use to conditionally compile the cpm-serial.c code. Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Michael Ellerman 提交于
Only build the OPAL console code in when necessary. This looks like it should use CONFIG_PPC_POWERNV, but because the opal-call.S code is 64-bit only, we must only build it when we're building the boot wrapper 64-bit. Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Michael Ellerman 提交于
The serial code in uartlite.c only matches if we find one of two Xilinx (xlnx) nodes in the device tree, there's no need to build or link the code on other platforms. As far as I can tell CONFIG_XILINX_VIRTEX is the appropriate symbol to use to conditionally compile the code. Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 01 12月, 2017 1 次提交
-
-
由 Pankaj Bansal 提交于
The flexcan driver assumed that flexcan controller is big endian for powerpc architecture and little endian for other architectures. But this is not universally true. flexcan controller can be little or big endian on any architecture. Therefore the flexcan driver has been modified to check for "big-endian" device tree property for controllers that are big endian. consequently add the property to freescale P1010 SOC device tree. Signed-off-by: NPankaj Bansal <pankaj.bansal@nxp.com> Reviewed-by: NPoonam Aggrwal <poonam.aggrwal@nxp.com> Signed-off-by: NMarc Kleine-Budde <mkl@pengutronix.de>
-
- 09 11月, 2017 2 次提交
-
-
由 Masahiro Yamada 提交于
We need to add "clean-files" in Makfiles to clean up DT blobs, but we often miss to do so. Since there are no source files that end with .dtb or .dtb.S, so we can clean-up those files from the top-level Makefile. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NRob Herring <robh@kernel.org>
-
由 Masahiro Yamada 提交于
Most of DT files are compiled under arch/*/boot/dts/, but we have some other directories, like drivers/of/unittest-data/. We often miss to add gitignore patterns per directory. Since there are no source files that end with .dtb or .dtb.S, we can ignore the patterns globally. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NRob Herring <robh@kernel.org>
-
- 02 11月, 2017 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
Many source files in the tree are missing licensing information, which makes it harder for compliance tools to determine the correct license. By default all files without license information are under the default license of the kernel, which is GPL version 2. Update the files which contain no license information with the 'GPL-2.0' SPDX license identifier. The SPDX identifier is a legally binding shorthand, which can be used instead of the full boiler plate text. This patch is based on work done by Thomas Gleixner and Kate Stewart and Philippe Ombredanne. How this work was done: Patches were generated and checked against linux-4.14-rc6 for a subset of the use cases: - file had no licensing information it it. - file was a */uapi/* one with no licensing information in it, - file was a */uapi/* one with existing licensing information, Further patches will be generated in subsequent months to fix up cases where non-standard license headers were used, and references to license had to be inferred by heuristics based on keywords. The analysis to determine which SPDX License Identifier to be applied to a file was done in a spreadsheet of side by side results from of the output of two independent scanners (ScanCode & Windriver) producing SPDX tag:value files created by Philippe Ombredanne. Philippe prepared the base worksheet, and did an initial spot review of a few 1000 files. The 4.13 kernel was the starting point of the analysis with 60,537 files assessed. Kate Stewart did a file by file comparison of the scanner results in the spreadsheet to determine which SPDX license identifier(s) to be applied to the file. She confirmed any determination that was not immediately clear with lawyers working with the Linux Foundation. Criteria used to select files for SPDX license identifier tagging was: - Files considered eligible had to be source code files. - Make and config files were included as candidates if they contained >5 lines of source - File already had some variant of a license header in it (even if <5 lines). All documentation files were explicitly excluded. The following heuristics were used to determine which SPDX license identifiers to apply. - when both scanners couldn't find any license traces, file was considered to have no license information in it, and the top level COPYING file license applied. For non */uapi/* files that summary was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 11139 and resulted in the first patch in this series. If that file was a */uapi/* path one, it was "GPL-2.0 WITH Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was: SPDX license identifier # files ---------------------------------------------------|------- GPL-2.0 WITH Linux-syscall-note 930 and resulted in the second patch in this series. - if a file had some form of licensing information in it, and was one of the */uapi/* ones, it was denoted with the Linux-syscall-note if any GPL family license was found in the file or had no licensing in it (per prior point). Results summary: SPDX license identifier # files ---------------------------------------------------|------ GPL-2.0 WITH Linux-syscall-note 270 GPL-2.0+ WITH Linux-syscall-note 169 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21 ((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17 LGPL-2.1+ WITH Linux-syscall-note 15 GPL-1.0+ WITH Linux-syscall-note 14 ((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5 LGPL-2.0+ WITH Linux-syscall-note 4 LGPL-2.1 WITH Linux-syscall-note 3 ((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3 ((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1 and that resulted in the third patch in this series. - when the two scanners agreed on the detected license(s), that became the concluded license(s). - when there was disagreement between the two scanners (one detected a license but the other didn't, or they both detected different licenses) a manual inspection of the file occurred. - In most cases a manual inspection of the information in the file resulted in a clear resolution of the license that should apply (and which scanner probably needed to revisit its heuristics). - When it was not immediately clear, the license identifier was confirmed with lawyers working with the Linux Foundation. - If there was any question as to the appropriate license identifier, the file was flagged for further research and to be revisited later in time. In total, over 70 hours of logged manual review was done on the spreadsheet to determine the SPDX license identifiers to apply to the source files by Kate, Philippe, Thomas and, in some cases, confirmation by lawyers working with the Linux Foundation. Kate also obtained a third independent scan of the 4.13 code base from FOSSology, and compared selected files where the other two scanners disagreed against that SPDX file, to see if there was new insights. The Windriver scanner is based on an older version of FOSSology in part, so they are related. Thomas did random spot checks in about 500 files from the spreadsheets for the uapi headers and agreed with SPDX license identifier in the files he inspected. For the non-uapi files Thomas did random spot checks in about 15000 files. In initial set of patches against 4.14-rc6, 3 files were found to have copy/paste license identifier errors, and have been fixed to reflect the correct identifier. Additionally Philippe spent 10 hours this week doing a detailed manual inspection and review of the 12,461 patched files from the initial patch version early this week with: - a full scancode scan run, collecting the matched texts, detected license ids and scores - reviewing anything where there was a license detected (about 500+ files) to ensure that the applied SPDX license was correct - reviewing anything where there was no detection but the patch license was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied SPDX license was correct This produced a worksheet with 20 files needing minor correction. This worksheet was then exported into 3 different .csv files for the different types of files to be modified. These .csv files were then reviewed by Greg. Thomas wrote a script to parse the csv files and add the proper SPDX tag to the file, in the format that the file expected. This script was further refined by Greg based on the output to detect more types of files automatically and to distinguish between header and source .c files (which need different comment types.) Finally Greg ran the script using the .csv files to generate the patches. Reviewed-by: NKate Stewart <kstewart@linuxfoundation.org> Reviewed-by: NPhilippe Ombredanne <pombredanne@nexb.com> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Signed-off-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 22 10月, 2017 1 次提交
-
-
由 Geert Uytterhoeven 提交于
Signed-off-by: NGeert Uytterhoeven <geert+renesas@glider.be> Acked-by: NRob Herring <robh@kernel.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 31 8月, 2017 3 次提交
-
-
由 Hannes Reinecke 提交于
mpsc.c and mpc52xx-psc.c are platform-specific serial drivers, and should be compiled for the respective platforms only. Signed-off-by: NHannes Reinecke <hare@suse.com> Reviewed-by: NTorsten Duwe <duwe@suse.de> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Tobin C. Harding 提交于
.llong is an undocumented PPC specific directive. The generic equivalent is .quad, but even better (because it's self describing) is .8byte. Convert all .llong directives to .8byte. Signed-off-by: NTobin C. Harding <me@tobin.cc> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Dan Carpenter 提交于
My static checker complains that 0x00001800 >> 13 is zero. Looking at the context, it seems like a copy and paste bug from the line below and probably 0x3 << 13 or 0x00006000 was intended. Fixes: 2af59f7d ("[POWERPC] 4xx: Add 405GPr and 405EP support in boot wrapper") Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com> Acked-by: NBenjamin Herrenschmidt <benh@kernel.crashing.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 10 8月, 2017 3 次提交
-
-
由 Christophe Leroy 提交于
Two config options exist to define powerpc MPC8xx: * CONFIG_PPC_8xx * CONFIG_8xx arch/powerpc/platforms/Kconfig.cputype has contained the following comment about CONFIG_8xx item for some years: "# this is temp to handle compat with arch=ppc" arch/powerpc is now the only place with remaining use of CONFIG_8xx: get rid of them. Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Christophe Leroy 提交于
The 8xx cannot access the TBL and TBU registers using mfspr/mtspr It must be accessed using mftb/mftbu Due to this, there is a number of places with #ifdef CONFIG_8xx This patch defines new macros MFTBL(x) and MFTBU(x) on the same model as MFTB(x) and tries to make use of them as much as possible. In arch/powerpc/include/asm/timex.h, we also remove the ifdef for the asm() operands as the compiler doesn't mind unused operands Signed-off-by: NChristophe Leroy <christophe.leroy@c-s.fr> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Ivan Mikhaylov 提交于
Add mmc0 changes for enabling arasan emmc and change defconfig appropriately. Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 28 7月, 2017 1 次提交
-
-
由 Michael Ellerman 提交于
Historically the boot wrapper was always built 32-bit big endian, even for 64-bit kernels. That was because old firmwares didn't necessarily support booting a 64-bit image. Because of that arch/powerpc/boot/Makefile uses CROSS32CC for compilation. However when we added 64-bit little endian support, we also added support for building the boot wrapper 64-bit. However we kept using CROSS32CC, because in most cases it is just CC and everything works. However if the user doesn't specify CROSS32_COMPILE (which no one ever does AFAIK), and CC is *not* biarch (32/64-bit capable), then CROSS32CC becomes just "gcc". On native systems that is probably OK, but if we're cross building it definitely isn't, leading to eg: gcc ... -m64 -mlittle-endian -mabi=elfv2 ... arch/powerpc/boot/cpm-serial.c gcc: error: unrecognized argument in option ‘-mabi=elfv2’ gcc: error: unrecognized command line option ‘-mlittle-endian’ make: *** [zImage] Error 2 To fix it, stop using CROSS32CC, because we may or may not be building 32-bit. Instead setup a BOOTCC, which defaults to CC, and only use CROSS32_COMPILE if it's set and we're building for 32-bit. Fixes: 147c0516 ("powerpc/boot: Add support for 64bit little endian wrapper") Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au> Reviewed-by: NCyril Bur <cyrilbur@gmail.com>
-
- 03 7月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
Most of DT files in PowerPC use #include "..." to make pre-processor include DT in the same directory, but we have 3 exceptional files that use #include <...> for that. Fix them to remove -I$(srctree)/arch/$(SRCARCH)/boot/dts path from dtc_cpp_flags. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 28 6月, 2017 5 次提交
-
-
由 Javier Martinez Canillas 提交于
The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken into account so the driver defines only a set of compatible strings using the "atmel" vendor as a generic fallback for compatible I2C devices. So add this generic fallback to the device node compatible string to make the device to match the driver using the OF device ID table. Signed-off-by: NJavier Martinez Canillas <javier@dowhile0.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Javier Martinez Canillas 提交于
The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken into account so the driver defines only a set of compatible strings using the "atmel" vendor as a generic fallback for compatible I2C devices. So add this generic fallback to the device node compatible string to make the device to match the driver using the OF device ID table. Signed-off-by: NJavier Martinez Canillas <javier@dowhile0.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Javier Martinez Canillas 提交于
The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken into account so the driver defines only a set of compatible strings using the "atmel" vendor as a generic fallback for compatible I2C devices. So add this generic fallback to the device node compatible string to make the device to match the driver using the OF device ID table. Signed-off-by: NJavier Martinez Canillas <javier@dowhile0.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Javier Martinez Canillas 提交于
The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken into account so the driver defines only a set of compatible strings using the "atmel" vendor as a generic fallback for compatible I2C devices. So add this generic fallback to the device node compatible string to make the device to match the driver using the OF device ID table. Signed-off-by: NJavier Martinez Canillas <javier@dowhile0.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Javier Martinez Canillas 提交于
The at24 driver allows to register I2C EEPROM chips using different vendor and devices, but the I2C subsystem does not take the vendor into account when matching using the I2C table since it only has device entries. But when matching using an OF table, both the vendor and device has to be taken into account so the driver defines only a set of compatible strings using the "atmel" vendor as a generic fallback for compatible I2C devices. So add this generic fallback to the device node compatible string to make the device to match the driver using the OF device ID table. Signed-off-by: NJavier Martinez Canillas <javier@dowhile0.org> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 30 5月, 2017 4 次提交
-
-
由 Nicholas Piggin 提交于
crtsaveres.S is empty with 64-bit builds already, so just don't build and link it to match the vmlinux build. Signed-off-by: NNicholas Piggin <npiggin@gmail.com> [mpe: Use CONFIG_PPC64_BOOT_WRAPPER not CONFIG_PPC32 to fix BE build] Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Ivan Mikhaylov 提交于
Add a device tree for FSP2 board (476 based). Signed-off-by: NIvan Mikhaylov <ivan@de.ibm.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Pavel Machek 提交于
Currently the DTS defines two partitions at the same addresses, if you use one, you will corrupt information on the other one. Fix it by shifting the second partition. Signed-off-by: NPavel Machek <pavel@denx.de> [mpe: Reconstruct change log from email thread] Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
由 Nicholas Piggin 提交于
FIXUP_ENDIAN uses SRR[01] with MSR_RI=1, which gets corrupted if there is an interleaving system reset or machine check interrupt. Set MSR_RI=0 before setting SRRs. The rfid will restore MSR. Signed-off-by: NNicholas Piggin <npiggin@gmail.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 19 5月, 2017 1 次提交
-
-
由 Olof Johansson 提交于
We use a directory under arch/$ARCH/boot/dts as an include path that has links outside of the subtree to find dt-bindings from under include/dt-bindings. That's been working well, but new DT architectures haven't been adding them by default. Recently there's been a desire to share some of the DT material between arm and arm64, which originally caused developers to create symlinks or relative includes between the subtrees. This isn't ideal -- it breaks if the DT files aren't stored in the exact same hierarchy as the kernel tree, and generally it's just icky. As a somewhat cleaner solution we decided to add a $ARCH/ prefix link once, and allow DTS files to reference dtsi (and dts) files in other architectures that way. Original approach was to create these links under each architecture, but it lead to the problem of recursive symlinks. As a remedy, move the include link directories out of the architecture trees into a common location. At the same time, they can now share one directory and one dt-bindings/ link as well. Fixes: 4027494a ('ARM: dts: add arm/arm64 include symlinks') Reported-by: NRussell King <linux@armlinux.org.uk> Reported-by: NOmar Sandoval <osandov@osandov.com> Reviewed-by: NHeiko Stuebner <heiko@sntech.de> Reviewed-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NHeiko Stuebner <heiko@sntech.de> Acked-by: NRob Herring <robh@kernel.org> Cc: Heiko Stuebner <heiko@sntech.de> Cc: Mark Rutland <mark.rutland@arm.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Will Deacon <will.deacon@arm.com> Cc: Mikael Starvik <starvik@axis.com> Cc: Jesper Nilsson <jesper.nilsson@axis.com> Cc: James Hogan <james.hogan@imgtec.com> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Frank Rowand <frowand.list@gmail.com> Cc: linux-arch <linux-arch@vger.kernel.org> Signed-off-by: NOlof Johansson <olof@lixom.net>
-
- 18 5月, 2017 1 次提交
-
-
由 Holger Brunck 提交于
Signed-off-by: NHolger Brunck <holger.brunck@keymile.com> Signed-off-by: NDavid S. Miller <davem@davemloft.net>
-
- 08 3月, 2017 1 次提交
-
-
由 Michael Ellerman 提交于
Recent toolchains force the TOC to be 256 byte aligned. We need to enforce this alignment in the zImage linker script, otherwise pointers to our TOC variables (__toc_start) could be incorrect. If the actual start of the TOC and __toc_start don't have the same value we crash early in the zImage wrapper. Cc: stable@vger.kernel.org Suggested-by: NAlan Modra <amodra@gmail.com> Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 28 2月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
Fix typos and add the following to the scripts/spelling.txt: partiton||partition Link: http://lkml.kernel.org/r/1481573103-11329-7-git-send-email-yamada.masahiro@socionext.comSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 22 2月, 2017 2 次提交
-
-
由 Hongtao Jia 提交于
Update #thermal-sensor-cells from 0 to 1 according to the new binding. The sensor specifier added is the monitoring site ID, and represents the "n" in TRITSRn and TRATSRn. Signed-off-by: NJia Hongtao <hongtao.jia@nxp.com> Acked-by: NScott Wood <scottwood@freescale.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
由 Hongtao Jia 提交于
Update #thermal-sensor-cells from 0 to 1 according to the new binding. The sensor specifier added is the monitoring site ID, and represents the "n" in TRITSRn and TRATSRn. Signed-off-by: NJia Hongtao <hongtao.jia@nxp.com> Acked-by: NScott Wood <scottwood@freescale.com> Signed-off-by: NZhang Rui <rui.zhang@intel.com>
-
- 03 2月, 2017 1 次提交
-
-
由 Chris Packham 提交于
The L2 cache controller on the T2080 SoC has similar capabilities to the others already supported by the mpc85xx_edac driver. Add it to the list of compatible devices. Signed-off-by: NChris Packham <chris.packham@alliedtelesis.co.nz> Acked-by: NJohannes Thumshirn <jth@kernel.org> Acked-by: NMichael Ellerman <mpe@ellerman.id.au> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: devicetree@vger.kernel.org Cc: linux-edac <linux-edac@vger.kernel.org> Cc: linuxppc-dev@lists.ozlabs.org Link: http://lkml.kernel.org/r/20170201231624.28843-1-chris.packham@alliedtelesis.co.nzSigned-off-by: NBorislav Petkov <bp@suse.de>
-
- 02 2月, 2017 1 次提交
-
-
由 Michael Ellerman 提交于
Add a few things that have been missed from .gitignore over the years. Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
-
- 25 1月, 2017 2 次提交
-
-
由 Valentin Longchamp 提交于
This board is built around Freescale's T1040 SoC. The peripherals used by this design are: - DDR3 RAM with SPD support - parallel NOR Flash as boot medium - 1 PCIe bus (PCIe1 x1) - 3 FMAN Ethernet devices (FMAN1 DTSEC1/2/5) - 4 IFC bus devices: - NOR flash - NAND flash - QRIO reset/power mgmt CPLD - BFTIC chassis management CPLD - 2 I2C buses - 1 SPI bus - HDLC bus with the QE's UCC1 - last but not least, the mandatory serial port The board can be used with the corenet32_smp_defconfig. Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by: NScott Wood <oss@buserror.net>
-
由 Valentin Longchamp 提交于
It is not implemented on the kmcoge4 hardware and if not disabled it leads to error messages with the corenet32_smp_defconfig. Signed-off-by: NValentin Longchamp <valentin.longchamp@keymile.com> Signed-off-by: NScott Wood <oss@buserror.net>
-
- 10 12月, 2016 4 次提交
-
-
由 Madalin Bucur 提交于
Signed-off-by: NMadalin Bucur <madalin.bucur@nxp.com> Signed-off-by: NScott Wood <oss@buserror.net>
-
由 Madalin Bucur 提交于
The alias is used by the boot loader to perform a device tree fixup. Signed-off-by: NMadalin Bucur <madalin.bucur@nxp.com> Signed-off-by: NScott Wood <oss@buserror.net>
-
由 Madalin Bucur 提交于
Signed-off-by: NMadalin Bucur <madalin.bucur@nxp.com> Signed-off-by: NScott Wood <oss@buserror.net>
-
由 Madalin Bucur 提交于
Signed-off-by: NMadalin Bucur <madalin.bucur@nxp.com> Signed-off-by: NScott Wood <oss@buserror.net>
-