summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeLines
* fastboot: implement KconfigSteve Rae2016-08-20-0/+67
| | | | | | implement Kconfig for the 'fastboot' feature set Signed-off-by: Steve Rae <steve.rae@raedomain.com>
* cmd: efi_loader: Return CMD_RET_USAGE in case of not enough argumentsBin Meng2016-08-20-1/+1
| | | | | | | | When typing 'bootefi' from U-Boot shell, nothing outputs. Like other commands, return CMD_RET_USAGE so that it can print help message. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Alexander Graf <agraf@suse.de>
* Kconfig: DISTRO_DEFAULTS: Only enable CMD_BOOTZ for ARMTom Rini2016-08-20-1/+1
| | | | | | | | | The 'bootz' command is really only for ARM32 Linux Kernel 'zImage' files but has also been adapted for testing with sandbox. Given that sandbox is a test platform, don't add that logic under DISTRO_DEFAULTS. Cc: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Tom Rini <trini@konsulko.com>
* cmd: booti: move CONFIG_CMD_BOOTI to KconfigMasahiro Yamada2016-08-20-6/+8
| | | | | | | | | | This command is used to boot ARM64 Linux. I made DISTRO_DEFAULTS select this option for ARM64 to respect include/config_distro_defaults.h. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Tom Rini <trini@konsulko.com>
* cmd: Split 'bootz' and 'booti' out from 'bootm'Tom Rini2016-08-20-251/+276
| | | | | | | | | | | | The bootz and booti commands rely on common functionality that is found in common/bootm.c and common/bootm_os.c. They do not however rely on the rest of cmd/bootm.c to be implemented so split them into their own files. Have various Makefiles include the required infrastructure for CONFIG_CMD_BOOT[IZ] as well as CONFIG_CMD_BOOTM. Move the declaration of 'images' over to common/bootm.c. Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Tom Rini <trini@konsulko.com>
* tests: Introduce DT overlay testsMaxime Ripard2016-08-20-49/+698
| | | | | | | | | | | | This adds a bunch of unit tests for the "fdt apply" command. They've all been run successfully in the sandbox. However, as you still require an out-of-tree dtc with overlay support, this is disabled by default. Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* cmd: fdt: add fdt overlay application subcommandMaxime Ripard2016-08-20-7/+31
| | | | | | | | | | | | | | | | | | | | | | | The device tree overlays are a good way to deal with user-modifyable boards or boards with some kind of an expansion mechanism where we can easily plug new board in (like the BBB or the raspberry pi). However, so far, the usual mechanism to deal with it was to have in Linux some driver detecting the expansion boards plugged in and then request these overlays using the firmware interface. That works in most cases, but in some cases, you might want to have the overlays applied before the userspace comes in. Either because the new board requires some kind of an early initialization, or because your root filesystem is accessed through that expansion board. The easiest solution in such a case is to simply have the component before Linux applying that overlay, removing all these drawbacks. Reviewed-by: Stefan Agner <stefan@agner.ch> Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Acked-by: Simon Glass <sjg@chromium.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* libfdt: Add overlay application functionMaxime Ripard2016-08-20-0/+442
| | | | | | | | | | The device tree overlays are a good way to deal with user-modifyable boards or boards with some kind of an expansion mechanism where we can easily plug new board in (like the BBB, the Raspberry Pi or the CHIP). Add a new function to merge overlays with a base device tree. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* libfdt: Add fdt_setprop_inplace_namelen_partialMaxime Ripard2016-08-20-4/+46
| | | | | | | | | | Add a function to modify inplace only a portion of a property.. This is especially useful when the property is an array of values, and you want to update one of them without changing the DT size. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Simon Glass <sjg@chromium.org>
* libfdt: Add fdt_getprop_namelen_wMaxime Ripard2016-08-20-0/+7
| | | | | | | Add a function to retrieve a writeable property only by the first characters of its name. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* libfdt: Add fdt_path_offset_namelenMaxime Ripard2016-08-20-9/+25
| | | | | | | | Add a namelen variant of fdt_path_offset to retrieve the node offset using only a fixed number of characters. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* libfdt: Fix separator spellingMaxime Ripard2016-08-20-4/+4
| | | | | | The function fdt_path_next_seperator had an obvious mispell. Fix it. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* libfdt: Add max phandle retrieval functionMaxime Ripard2016-08-20-0/+39
| | | | | | | | Add a function to retrieve the highest phandle in a given device tree. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Reviewed-by: Stefan Agner <stefan@agner.ch> Acked-by: Simon Glass <sjg@chromium.org>
* libfdt: Add iterator over propertiesMaxime Ripard2016-08-20-0/+24
| | | | | | | | | Implement a macro based on fdt_first_property_offset and fdt_next_property_offset that provides a convenience to iterate over all the properties of a given node. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Simon Glass <sjg@chromium.org>
* libfdt: Add new headers and definesMaxime Ripard2016-08-20-0/+6
| | | | | | | | | | The libfdt overlay support introduces a bunch of new includes and functions. Make sure we are able to build it by adding the needed glue. Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com> Acked-by: Simon Glass <sjg@chromium.org>
* vsprintf: Include stdarg for va_listMaxime Ripard2016-08-20-0/+2
| | | | | | | | | | | | vsprintf.h doesn't include the stdarg.h file, which means that it relies on the files that include vsprintf.h to include stdarg.h as well. Add an explicit include to avoid build errors when simply including that file. Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* scripts: Makefile.lib: Sanitize DTB namesMaxime Ripard2016-08-20-4/+4
| | | | | | | | | | | | | | | Having dashes as a separator in the DTB name is a quite common practice. However, the current code to generate objects from DTBs assumes the separator is an underscore, leading to a compilation error when building a device tree with dashes. Replace all the dashes in the DTB name to generate the symbols name, which should solve this issue. Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* cmd: fdt: Narrow the check for fdt addrMaxime Ripard2016-08-20-1/+1
| | | | | | | | | | | The current code only checks if the fdt subcommand is fdt addr by checking whether it starts with 'a'. Since this is a pretty widely used letter, narrow down that check a bit. Acked-by: Simon Glass <sjg@chromium.org> Acked-by: Pantelis Antoniou <pantelis.antoniou@konsulko.com> Signed-off-by: Maxime Ripard <maxime.ripard@free-electrons.com>
* Merge branch 'master' of git://git.denx.de/u-boot-x86Tom Rini2016-08-16-89/+1275
|\
| * x86: Add theadorable-x86-dfi-bt700 board supportStefan Roese2016-08-16-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for the BayTrail based theadorable-x86-dfi-bt700 board which uses the DFI BT700 BayTrail Qseven SoM on a custom baseboard. The main difference to the DFI baseboard is, that it isn't equipped with a Super IO chip and uses the internal HS SIO UART (memory mapped PCI based) as the console UART. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Add DFI BT700 BayTrail board supportStefan Roese2016-08-16-0/+611
| | | | | | | | | | | | | | | | | | | | This patch adds support for the DFI BayTrail BT700 QSeven SoM installed on the DFI Q7X-151 baseboard. The baseboard is equipped with the Nuvoton NCT6102D Super IO chip providing the UART as console. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: conga-qeval20-qa3: Add SMBus support and SMSC2513 config codeStefan Roese2016-08-16-12/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch includes the following changes: - Remove Designware I2C support from dts as its not used - Configure SMBus PADs in dts - Enable I2C commands and I2C support - Configure SMSC2513 USB hub via SMBus upon startup - Move environment location to match Minnowmax example - Enhancement of the default environment Signed-off-by: Stefan Roese <sr@denx.de> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * i2c: intel_i2c: SMBus driver PCI addition (e.g. BayTrail)Stefan Roese2016-08-16-47/+269
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for the SMBus block read/write functionality. Other protocols like the SMBus quick command need to get added if this is needed. This patch also removed the SMBus related defines from the Ivybridge pch.h header. As they are integrated in this driver and should be used from here. This change is added in this patch to avoid compile breakage to keep the source git bisectable. Tested on a congatec BayTrail board to configure the SMSC2513 USB hub. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Cc: Heiko Schocher <hs@denx.de> Cc: George McCollister <george.mccollister@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * cbfs: Fix incorrect CBFS file header size being usedYaroslav K2016-08-16-4/+4
| | | | | | | | | | | | | | | | | | This fixes incorrect filenames in cbfsls output. Signed-off-by: Yaroslav K. <yar444@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> [clean up checkpatch errors and warnings] Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: bdinfo: Drop meaningless valuesSimon Glass2016-08-16-10/+0
| | | | | | | | | | | | | | These are not useful on x86 so do not print them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * bdinfo: Don't print out empty DRAM banksSimon Glass2016-08-16-3/+5
| | | | | | | | | | | | | | | | | | There is no sense in printing out DRAM banks of size 0 since this means they are empty. Skip them. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: bayleybay: Add PS/2 keyboard and mouse to ASL fileBin Meng2016-08-16-0/+38
| | | | | | | | | | | | | | | | | | Without PS/2 keyboard and mouse in the ASL file, Windows does not see them. No problem for Linux as it probes keyboard and mouse via the legacy 8042 I/O port. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * x86: som-db5800-som-6867: fix SERIRQ on resetGeorge McCollister2016-08-16-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Explicitly enable ILB_SERIRQ function 1 in cfio_regs_pad_ilb_serirq_PCONF0. Pad configuration for SERIRQ is not set to enable the SERIRQ function after a reset though strangely, it is on initial boot. Rebooting from Linux, reset command in u-boot and even pushing the reset button on the development board all lead to the SERIRQ function being disabled (address 0xfed0c560 with value of 0x2003cc80). Signed-off-by: George McCollister <george.mccollister@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * misc: Add simple driver for some Nuvoton NCT6102D devicesStefan Roese2016-08-16-0/+99
| | | | | | | | | | | | | | | | | | | | | | This simple driver provides some functions to control some of the integrated devices. The watchdog is enabled per default. This driver adds a function to disable the watchdog. Also the internal legacy UART (io address 0x3f8/0x2f8) is enabled per default. Signed-off-by: Stefan Roese <sr@denx.de> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org>
| * x86: baytrail: Add SIO HS-UART clock setupStefan Roese2016-08-16-0/+48
| | | | | | | | | | | | | | | | | | | | To support the BayTrail internal SIO HS UART, the internal UART clock needs to get configured. This patch adds support for this clock configuration which will be done, if the PCI device(s) are found. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: cache.h: Add default for CONFIG_SYS_CACHELINE_SIZEStefan Roese2016-08-16-4/+4
| | | | | | | | | | | | | | | | | | | | Don't just define ARCH_DMA_MINALIGN but also CONFIG_SYS_CACHELINE_SIZE if it's undefined. This is needed for the xhci driver to compile. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Simon Glass <sjg@chromium.org> Cc: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Mention running U-Boot in 64-bit mode in the READMESimon Glass2016-08-16-0/+18
| | | | | | | | | | | | | | | | This feature is not supported. Document this, and add some details on how it might be implemented. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Add a reference to README.efiSimon Glass2016-08-16-0/+11
| | | | | | | | | | | | | | | | UEFI is commonly used on x86. Add a reference to U-Boot's support for this in the x86 README. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: Mention how to boot a 64-bit kernel from U-BootSimon Glass2016-08-16-9/+9
| | | | | | | | | | | | | | | | The README indicates that this is not supported, but this is no-longer true. Update the text to indicate this and describe the FIT changes required. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: doc: Add note about the debug FSP usage on BayTrailStefan Roese2016-08-16-0/+4
| | | | | | | | | | | | | | | | | | | | | | The debug FSP image is bigger in size than the normal FSP image. This patch adds a small description on how to use this FSP debug version by changing CONFIG_FSP_ADDR. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Bin Meng <bmeng.cn@gmail.com> Cc: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
| * x86: conga-qeval20-qa3: Add missing MAINTERNERS entryStefan Roese2016-08-16-0/+1
| | | | | | | | | | | | | | | | | | | | Add entry for the missing internal UART defconfig to the MAINTAINERS file. Signed-off-by: Stefan Roese <sr@denx.de> Cc: Bin Meng <bmeng.cn@gmail.com> CC: Simon Glass <sjg@chromium.org> Reviewed-by: Bin Meng <bmeng.cn@gmail.com>
* | mmc: mmc_legacy: fix the compiler error with disabled CONFIG_DM_MMC_OPSJaehoon Chung2016-08-16-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | To prevent the compiler error, split the checking condition whether cfg->ops is NULL or not. It's more clearly, because it's not included in mmc_config structure when CONFIG_DM_MMC_OPS is disabled. drivers/mmc/mmc_legacy.c: In function ‘mmc_create’: drivers/mmc/mmc_legacy.c:118:31: error: ‘const struct mmc_config’ has no member named ‘ops’ drivers/mmc/mmc_legacy.c:118:58: error: ‘const struct mmc_config’ has no member named ‘ops’ make[1]: *** [drivers/mmc/mmc_legacy.o] Error 1 Signed-off-by: Jaehoon Chung <jh80.chung@samsung.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* | mmc: send CMD0 before CMD1 for some MMC cardsYangbo Lu2016-08-16-0/+3
| | | | | | | | | | | | | | | | | | | | When the MMC framework was added in u-boot, the mmc_go_idle was added before mmc_send_op_cond_iter in function mmc_send_op_cond annotating that some cards seemed to need this. Actually, we still need to do this in function mmc_complete_op_cond for those cards. This has been verified on Micron MTFC4GACAECN eMMC chip. Signed-off-by: Yangbo Lu <yangbo.lu@nxp.com>
* | defconfig: k2g_evm_defconfig: Enable mmc driver modelSekhar Nori2016-08-16-0/+1
| | | | | | | | | | | | | | | | | | | | | | K2G can benefit from driver model support in the MMC/SD driver it uses: omap_hsmmc Enable driver model MMC support for K2G. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* | ARM: dts: k2g-evm: enable mmc/sd suppportSekhar Nori2016-08-16-0/+8
| | | | | | | | | | | | | | | | | | | | | | The K2G EVM from TI has an SD card slot as well as onboard eMMC for data storage. Enable support for these. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* | ARM: dts: K2G: Add support for MMC controllerSekhar Nori2016-08-16-0/+23
| | | | | | | | | | | | | | | | | | K2G SoC from TI has two MMC/SD controllers. Add device tree data for these. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* | drivers: mmc: omap_hsmmc: fix build breakageSekhar Nori2016-08-16-0/+2
|/ | | | | | | | | | | | | | | | | | | | | | | structure member 'cd_inverted' of omap_hsmmc_data is available only when OMAP_HSMMC_USE_GPIO is defined. When CONFIG_DM_MMC is defined, but not CONFIG_OMAP_GPIO, this will cause build breakage in omap_hsmmc driver of the sort: CC drivers/mmc/omap_hsmmc.o ../drivers/mmc/omap_hsmmc.c: In function 'omap_hsmmc_ofdata_to_platdata': ../drivers/mmc/omap_hsmmc.c:1763:6: error: 'struct omap_hsmmc_data' has no member named 'cd_inverted' priv->cd_inverted = fdtdec_get_bool(fdt, node, "cd-inverted"); ^ Fix this by accessing cd_inverted only when OMAP_HSMMC_USE_GPIO is defined. Signed-off-by: Sekhar Nori <nsekhar@ti.com> Acked-by: Mugunthan V N <mugunthanvnm@ti.com> Reviewed-by: Tom Rini <trini@konsulko.com>
* common: env_nand: Ensure that we have nand_info[0] prior to useTom Rini2016-08-15-4/+7
| | | | | | | | | | | | | Now that nand_info[] is an array of pointers we need to ensure that it's been populated prior to use. We may for example have ENV in NAND set in configurations that run on boards with and without NAND (where default env is fine enough, such as omap3_beagle and beagleboard (NAND) vs beagle xM (no NAND)). Fixes: b616d9b0a708 ("nand: Embed mtd_info in struct nand_chip") Cc: Scott Wood <oss@buserror.net> Signed-off-by: Tom Rini <trini@konsulko.com> Acked-by: Scott Wood <oss@buserror.net>
* tools/env: ensure environment starts at erase block boundaryAndreas Fenkart2016-08-15-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | 56086921 added support for unaligned environments access. U-boot itself does not support this: - env_nand.c fails when using an unaligned offset. It produces an error in nand_erase_opts{drivers/mtd/nand/nand_util.c} - in env_sf/env_flash the unused space at the end is preserved, but not in the beginning. block alignment is assumed - env_sata/env_mmc aligns offset/length to the block size of the underlying device. data is silently redirected to the beginning of a block There is seems no use case for unaligned environment. If there is some useful data at the beginning of the the block (e.g. end of u-boot) that would be very unsafe. If the redundant environments are hosted by the same erase block then that invalidates the idea of double buffering. It might be that unaligned access was allowed in the past, and that people with legacy u-boot are trapped. But at the time of 56086921 it wasn't supported and due to reasons above I guess it was never introduced. I prefer to remove that (unused) feature in favor of simplicity Signed-off-by: Andreas Fenkart <andreas.fenkart@digitalstrom.com> Acked-by: Stefan Agner <stefan.agner@toradex.com>
* xtensa: add support for the 'xtfpga' evaluation boardChris Zankel2016-08-15-0/+884
| | | | | | | | | | | | | | | | | | | The 'xtfpga' board is actually a set of FPGA evaluation boards that can be configured to run an Xtensa processor. - Avnet Xilinx LX60 - Avnet Xilinx LX110 - Avnet Xilinx LX200 - Xilinx ML605 - Xilinx KC705 These boards share the same components (open-ethernet, ns16550 serial, lcd display, flash, etc.). Signed-off-by: Chris Zankel <chris@zankel.net> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* xtensa: add core information for the de212 processorMax Filippov2016-08-15-0/+839
| | | | | | | | | | DE212 is a general purpose xtensa processor without full MMU. Core information files are autogenerated from the processor description and are not meant to be edited. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* xtensa: add core information for the dc233c processorMax Filippov2016-08-15-0/+757
| | | | | | | | | | DC233C is an xtensa processor with full MMUv3 capable of running Linux. Core information files are autogenerated from the processor description and are not meant to be edited. Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* xtensa: add core information for the dc232b processorChris Zankel2016-08-15-0/+674
| | | | | | | | | | | DC232B is an xtensa processor with full MMUv2 capable of running Linux. Core information files are autogenerated from the processor description and are not meant to be edited. Signed-off-by: Chris Zankel <chris@zankel.net> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* xtensa: add support for the xtensa processor architecture [2/2]Chris Zankel2016-08-15-0/+3107
| | | | | | | | | | | | | The Xtensa processor architecture is a configurable, extensible, and synthesizable 32-bit RISC processor core provided by Tensilica, inc. This is the second part of the basic architecture port, adding the 'arch/xtensa' directory and a readme file. Signed-off-by: Chris Zankel <chris@zankel.net> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
* xtensa: add support for the xtensa processor architecture [1/2]Chris Zankel2016-08-15-6/+179
| | | | | | | | | | | | | | The Xtensa processor architecture is a configurable, extensible, and synthesizable 32-bit RISC processor core provided by Cadence. This is the first part of the basic architecture port with changes to common files. The 'arch/xtensa' directory, and boards and additional drivers will be in separate commits. Signed-off-by: Chris Zankel <chris@zankel.net> Signed-off-by: Max Filippov <jcmvbkbc@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Tom Rini <trini@konsulko.com>
generated by cgit v1.1 at 2024-11-02 11:14:30 +0000