- 24 1月, 2018 11 次提交
-
-
由 Álvaro Fernández Rojas 提交于
It's a Winbond (w25x32) 4 MB SPI flash. Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Álvaro Fernández Rojas 提交于
This driver manages the low speed SPI controller present on this SoC. Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Álvaro Fernández Rojas 提交于
This driver manages the SPI controller present on this SoC. Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Álvaro Fernández Rojas 提交于
This driver manages the SPI controller present on this SoC. Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Álvaro Fernández Rojas 提交于
This driver manages the SPI controller present on this SoC. Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Álvaro Fernández Rojas 提交于
This driver manages the SPI controller present on this SoC. Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Álvaro Fernández Rojas 提交于
This driver is a simplified version of linux/drivers/spi/spi-bcm63xx.c Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com>
-
由 Álvaro Fernández Rojas 提交于
Command bytes are part of the written bytes and they should be taken into account when sending a spi transfer. Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com>
-
由 Álvaro Fernández Rojas 提交于
For some SPI controllers it's not possible to keep the CS active between transfers and they are limited to a known number of bytes. This splits spi_flash reads into different iterations in order to respect the SPI controller limits. Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com>
-
由 Álvaro Fernández Rojas 提交于
wait_for_bit callers use the 32 bit LE version Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com>
-
由 Álvaro Fernández Rojas 提交于
Add 8/16/32 bits and BE/LE versions of wait_for_bit. This is needed for reading registers that are not aligned to 32 bits, and for Big Endian platforms. Signed-off-by: NÁlvaro Fernández Rojas <noltari@gmail.com> Reviewed-by: NDaniel Schwierzeck <daniel.schwierzeck@gmail.com> Reviewed-by: NJagan Teki <jagan@openedev.com>
-
- 10 1月, 2018 2 次提交
-
-
由 Miquel Raynal 提交于
Linux bindings have been introduced in the code (removing the U-Boot specific ones) without documentation update. Compatible string has changed, as well as the four GPIO properties. Reflect this by updating the soft-spi.txt documentation. Fixes: 102412c4 ("dm: spi: soft_spi: switch to use linux compatible string") Signed-off-by: NMiquel Raynal <miquel.raynal@free-electrons.com> Reviewed-by: NJagan Teki <jagan@amarulasolutions.com>
-
-
- 09 1月, 2018 13 次提交
-
-
-
由 Masahiro Yamada 提交于
I do not see a good reason to do this by a CONFIG option that affects all SoCs. The ram_size can be adjusted by dram_init() at run-time. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
I did not enable SDMA when I added sdhci-cadence support because LD20 boards are equipped with a large amount memory beyond 32 bit address range, but SDMA does not support the 64bit address. U-Boot relocates itself to the end of effectively available RAM. This would make the MMC enumeration fail because the buffer for EXT_CSD allocated in the stack would go too high, then SDMA would fail to transfer data. Recent SDHCI-compatible controllers support ADMA, but unfortunately U-Boot does not support ADMA. In the previous commit, I hided the DRAM area that exceeds the 32 bit address range. Now, I can enable CONFIG_MMC_SDHCI_SDMA. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
LD20 / PXs3 boards are equipped with a large amount of memory beyond the 32 bit address range. U-Boot relocates itself to the end of the available RAM. This is a problem for DMA engines that only support 32 bit physical address, like the SDMA of SDHCI controllers. In fact, U-Boot does not need to run at the very end of RAM. It is rather troublesome for drivers with DMA engines because U-Boot does not have API like dma_set_mask(), so DMA silently fails, making the driver debugging difficult. Hide the memory region that exceeds the 32 bit address range. It can be done by simply carving out gd->ram_size. It would also possible to override get_effective_memsize() or to define CONFIG_MAX_MEM_MAPPED, but dram_init() is a good enough place to do this job. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Elaine Zhang 提交于
Bind rockchip reset to clock-controller with rockchip_reset_bind(). Signed-off-by: NElaine Zhang <zhangqing@rock-chips.com> Signed-off-by: NKever Yang <kever.yang@rock-chips.com> Acked-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
-
由 Elaine Zhang 提交于
Create driver to support the soft reset (i.e. peripheral) of all Rockchip SoCs. Example of usage: i2c driver: ret = reset_get_by_name(dev, "i2c", &reset_ctl); if (ret) { error("reset_get_by_name() failed: %d\n", ret); } reset_assert(&reset_ctl); udelay(50); reset_deassert(&reset_ctl); i2c dts node: resets = <&cru SRST_P_I2C1>, <&cru SRST_I2C1>; reset-names = "p_i2c", "i2c"; Signed-off-by: NElaine Zhang <zhangqing@rock-chips.com> Signed-off-by: NKever Yang <kever.yang@rock-chips.com> Acked-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> [Fixed commit tag:] Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com>
-
由 Tom Rini 提交于
Signed-off-by: NTom Rini <trini@konsulko.com>
-
-
由 Jagan Teki 提交于
It is not much needed to print nand size in SPL during nand boot, and most of nand spl drivers doesn't print the same. Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
-
由 Jagan Teki 提交于
board/icorem6_rqs/ is forgot to remove while moving common board files together in (sha1: 52aaddd6) "i..MX6: engicam: Add imx6q/imx6ul boards for existing boards" Signed-off-by: NJagan Teki <jagan@amarulasolutions.com>
-
由 Stefan Agner 提交于
The i.MX 6UL/ULL feature a Cortex-A7 CPU which suppor the ARM generic timer. This change makes use of the ARM generic timer in U-Boot. This is crucial to make the ARM generic timers usable in Linux since timer_init() initalizes the system counter module, which is necessary to use the generic timers CP15 registers. Signed-off-by: NStefan Agner <stefan.agner@toradex.com> Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
-
由 Stefan Agner 提交于
Introduce a new config symbol to select the i.MX General Purpose Timer (GPT). Signed-off-by: NStefan Agner <stefan.agner@toradex.com> Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
-
由 Stefan Agner 提交于
Signed-off-by: NStefan Agner <stefan.agner@toradex.com> Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
-
- 08 1月, 2018 5 次提交
-
-
-
由 Clemens Gruber 提交于
The blob_encap and blob_decap functions were not flushing the dcache before passing data to CAAM/DMA and not invalidating the dcache when getting data back. Therefore, blob encapsulation and decapsulation failed with errors like the following due to data cache incoherency: "40000006: DECO: desc idx 0: Invalid KEY command" To ensure coherency, we require the key_mod, src and dst buffers to be aligned to the cache line size and flush/invalidate the memory regions. The same requirements apply to the job descriptor. Tested on an i.MX6Q board. Reviewed-by: NSumit Garg <sumit.garg@nxp.com> Signed-off-by: NClemens Gruber <clemens.gruber@pqgruber.com>
-
由 Andy Shevchenko 提交于
As defined on reference board followed by Intel Edison a Bluetooth device is attached to HSU0, i.e. PCI 0000:04.1. Describe it in ACPI accordingly. Note, we use BCM2E95 ID here as one most suitable for such device based on the description in commit message of commit 89ab37b489d1 ("Bluetooth: hci_bcm: Add support for BCM2E95 and BCM2E96") in the Linux kernel source tree. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Andy Shevchenko 提交于
The recent commit 03c4749dd6c7 ("gpio / ACPI: Drop unnecessary ACPI GPIO to Linux GPIO translation") in the Linux kernel reveals the issue we have in ACPI tables here, i.e. we must use hardware numbers for GPIO resources and, taking into consideration that GPIO and pin control are *different* IPs on Intel Tangier, we need to supply numbers properly. Besides that, it improves user experience since the official documentation for Intel Edison board is referring to GPIO hardware numbering scheme. Signed-off-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com> Acked-by: NBin Meng <bmeng.cn@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Tom Rini 提交于
We only need to compile and link these files when building for full U-Boot. Move them to under cmd/x86/ to make sure they aren't linked in and undiscarded due to u_boot_list_2_cmd_* being included). Cc: Bin Meng <bmeng.cn@gmail.com> Signed-off-by: NTom Rini <trini@konsulko.com> Reviewed-by: NBin Meng <bmeng.cn@gmail.com>
-
- 04 1月, 2018 2 次提交
-
-
由 Fabio Estevam 提交于
Since commit 051ba9e0 ("Kconfig: mx6ull: Deselect MX6UL from CONFIG_MX6ULL") CONFIG_MX6ULL does not select CONFIG_MX6UL anymore, so take this into consideration in all the checks for CONFIG_MX6UL. This fixes a boot regression. Reported-by: NStefan Agner <stefan@agner.ch> Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com> Reviewed-by: NStefan Agner <stefan@agner.ch> Tested-by: NBreno Lima <breno.lima@nxp.com> Tested-by: NPeng Fan <peng.fan@nxp.com> Reviewed-by: NStefano Babic <sbabic@denx.de> Tested-by: NJörg Krause <joerg.krause@embedded.rocks>
-
-
- 03 1月, 2018 7 次提交
-
-
由 Christopher Spinrath 提交于
Boot scripts located in the root directory of the first partition of USB, mmc, and SATA drives are executed twice: first by the distro boot command and then by the legacy boot command. This may have weird side effects if those scripts only change or extend the environment (including parts of the boot command itself). Removing the script execution from the legacy boot command has its own caveats. For instance, the distro boot command may execute the boot.scr on the mmc drive, then the boot.scr on the SATA drive, before the legacy boot command actually boots from the mmc drive. However, the current behavior would only execute the boot.scr once more before the actual boot, but it does not prevent the script located on the SATA drive from being executed, and thus, both scripts from being mixed up. Considering that the legacy boot command is only in place to boot old (standard) installations, let's go with the resolution having less custom code and remove the script execution from the legacy boot command. Signed-off-by: NChristopher Spinrath <christopher.spinrath@rwth-aachen.de> Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
-
由 Christopher Spinrath 提交于
The current default environment of the cm_fx6 is not suitable for booting modern distributions. Instead of extending the custom environment, let's use the distro boot command, which has been developed for precisely this use case. If the distro boot command fails, fall back to the old behavior (except for USB drives where the old behaviour is completely covered by the distro boot command). That way it is still possible to create "rescue SD cards" for old installations (e.g. if one messes up the on-flash environment). Signed-off-by: NChristopher Spinrath <christopher.spinrath@rwth-aachen.de> Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
-
由 Christopher Spinrath 提交于
In preparation for supporting the distro boot command, introduce the standard variables for specifying load addresses, which are documented in README and doc/README.distro, and replace the custom variables used so far with them. Since the current address layout disregards an address for an initramfs, also switch to the load addresses used and proven by other imx6 boards (e.g. the wandboard and nitrogen6x), instead of going on with our own way. Signed-off-by: NChristopher Spinrath <christopher.spinrath@rwth-aachen.de> Reviewed-by: NFabio Estevam <fabio.estevam@nxp.com>
-
由 Philipp Tomsich 提交于
The Rockchip-released ATF for the Firefly apparently (i.e. Kever reported this) does not tolerate a FDT being passed as the platform parameter and will run into a hard stop. To work around this limitation in the ATF parameter handling, we enable SPL_ATF_NO_PLATFORM_PARAM (which will force passing NULL for the platform parameters). Note that this only affects this platform, as the ATF releases for the RK3368 and RK3399 have always either ignored the platform parameter (i.e. before the FDT-based parameters were supported) or support receiving a pointer to a FDT. Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Philipp Tomsich 提交于
While we expect to call a pointer to a valid FDT (or NULL) as the platform parameter to an ATF, some ATF versions are not U-Boot aware and have an insufficiently robust (or an overzealour) parameter validation: either way, this may cause a hard-stop with uncooperative ATF versions. This change adds the option to suppress passing a platform parameter and will always pass NULL. Debug output from ATF w/ this option disabled (i.e. default): INFO: plat_param_from_bl2: 0x291450 Debug output from ATF w/ this option enabled: INFO: plat_param_from_bl2: 0 Signed-off-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Tested-by: NPhilipp Tomsich <philipp.tomsich@theobroma-systems.com> Reviewed-by: NKever Yang <kever.yang@rock-chips.com>
-
由 Eran Matityahu 提交于
commit 20f14714 ("imx: spl: Update NAND bootmode detection bit") broke the NAND bootmode detection by checking if BOOT_CFG1[7:4] == 0x8 for NAND boot mode. This commit essentially reverts it, while using the IMX6_BMODE_* macros that were introduced since. Tables 8-7 & 8-10 from IMX6DQRM say the NAND boot mode selection is done when BOOT_CFG1[7] is 1, but BOOT_CFG1[6:4] is not necessarily 0x0 in this case. Actually, NAND boot mode is when 0x8 <= BOOT_CFG1[7:4] <= 0xf, like it was in the code before. Signed-off-by: NEran Matityahu <eran.m@variscite.com> Cc: Stefano Babic <sbabic@denx.de> Cc: Jagan Teki <jagan@openedev.com> Cc: Tim Harvey <tharvey@gateworks.com>
-
由 Eric Nelson 提交于
This is a virtual "board" that uses configuration files and Kconfig to define the memory layout used by a real board during the board bring-up process. It generates an SPL image that can be loaded using imx_usb or SB_LOADER.exe. When run, it will generate a set of calibration constants for use in either or both a DCD configuration file for boards that use u-boot.imx or struct mx6_mmdc_calibration for boards that boot via SPL. In essence, it is a configurable, open-source variant of the Freescale ddr-stress tool. https://community.nxp.com/docs/DOC-105652 File mx6memcal_defconfig configures the board for use with mx6sabresd or mx6qsabreauto. Signed-off-by: NEric Nelson <eric@nelint.com> Signed-off-by: NFabio Estevam <fabio.estevam@nxp.com>
-