- Oct 04, 2016
-
-
Since the mx6ull adds the AIPS3, so enable its initialization. Signed-off-by:
Peng Fan <peng.fan@nxp.com> Signed-off-by:
Ye Li <ye.li@nxp.com> Cc: Stefano Babic <sbabic@denx.de>
-
Update memory map address for mx6ull. Signed-off-by:
-
Update Clock settings and CCM register map for i.MX6ULL. Signed-off-by:
-
Adjust POR_B settings on i.MX6ULL according to IC design team's suggestion: 2'b00 : always PUP100K 2'b01 : PUP100K when PMIC_ON_REQ || SOC_NOT_FAIL 2'b10 : always disable PUP100K 2'b11 : PDN100K when SOC_FAIL, PUP100K when SOC_NOT_FAIL -- recommended setting Signed-off-by:
Anson Huang <Anson.Huang@nxp.com> Cc: Stefano Babic <sbabic@denx.de>
-
Update misc SOC related settings for i.MX6ULL, such as FEC mac address, cpu speed grading and mmdc channel mask clearing. Also update s_init to skip pfd reset. Signed-off-by: -
Since MX6ULL select MX6UL, we can not use IS_ENABLED(CONFIG_MX6UL) here, because this piece code is only for i.MX6UL. Signed-off-by:
Stefano Babic <sbabic@denx.de>
-
Rom already initialized clock at 396M and 132M for arm core and ahb, so skip setting them again in U-Boot. Signed-off-by:
-
The i.MX6ULL's GPT supportting taking OSC as clock source. Add i.MX6ULL support. Signed-off-by:
-
Introduce is_mx6ull macro. Signed-off-by: -
i.MX6ULL is derivative from i.MX6UL, so select MX6UL for MX6ULL. If need to differenate MX6ULL from MX6UL, use CONFIG_MX6ULL Signed-off-by:
-
Add i.MX6ULL major cpu type. Signed-off-by:
-
Add iomux header file for i.MX6ULL. Signed-off-by:
-
The CPU detection macro is_mx6dq returns 0 on an i.MX6DQP, so we need to check for it explicitly in order to correctly initialize the pads when CONFIG_MX6QDL is defined. Signed-off-by:Filip Brozovic <fbrozovic@gmail.com>
-
- Oct 02, 2016
-
-
Andrew F. Davis authored
Like OMAP54xx and AM43xx family SoCs, AM33xx based SoCs have high security enabled models. Allow AM33xx devices to be built with HS Device Type Support. Signed-off-by:
Andrew F. Davis <afd@ti.com> Reviewed-by:
Tom Rini <trini@konsulko.com> Acked-by:
Lokesh Vutla <lokeshvutla@ti.com>
-
Andrew F. Davis authored
The option SPL_SPI_SUPPORT is used to enable support in SPL for loading images from SPI flash, it should not be used to determine the build type of the SPL image itself. The ability to read images from SPI flash does not imply the SPL will be booted from SPI flash. Unconditionally build SPI flash compatible SPL images. Signed-off-by:
-
Andrew F. Davis authored
Depending on the boot media, different images are needed for secure devices. The build generates u-boot*_HS_* files as appropriate for the different boot modes. For AM33xx devices additional image types are needed for various SPL boot modes as the ROM checks for the name of the boot mode in the file it loads. Signed-off-by:
-
Andrew F. Davis authored
The config option AM33XX is used in several boards and should be defined as a stand-alone option for this SOC. We break this out from target boards that use this SoC and common headers then enable AM33XX on in all the boards that used these targets to eliminate any functional change with this patch. This is similar to what has already been done in 9de852642cae ("arm: Kconfig: Add support for AM43xx SoC specific Kconfig") and is done for the same reasons. Signed-off-by: -
Daniel Allred authored
Adds a secure dram reservation fixup for secure devices, when a region in the emif has been set aside for secure world use. The size is defined by the CONFIG_TI_SECURE_EMIF_TOTAL_REGION_SIZE config option. Signed-off-by:
Daniel Allred <d-allred@ti.com> Reviewed-by:
-
Daniel Allred authored
After EMIF DRAM is configured, but before it is used, calls are made on secure devices to reserve any configured memory region needed by the secure world and then to lock the EMIF firewall configuration. If any other firewall configuration needs to be applied, it must happen before the lock call. Signed-off-by: -
Daniel Allred authored
Create a few public APIs which rely on secure world ROM/HAL APIs for their implementation. These are intended to be used to reserve a portion of the EMIF memory and configure hardware firewalls around that region to prevent public code from manipulating or interfering with that memory. Signed-off-by:
-
Daniel Allred authored
Adds start address and size config options for setting aside a portion of the EMIF memory space for usage by security software (like a secure OS/TEE). There are two sizes, a total size and a protected size. The region is divided into protected (secure) and unprotected (public) regions, that are contiguous and start at the start address given. If the start address is zero, the intention is that the region will be automatically placed at the end of the available external DRAM space. Signed-off-by: -
Jacob Chen authored
rockchip platform have a protocol to pass the the kernel reboot mode to bootloader by some special registers when system reboot. In bootloader we should read it and take action. We can only setup boot_mode in board_late_init becasue "setenv" need env setuped. So add CONFIG_BOARD_LATE_INIT to common header and use a entry "rk_board_late_init" to replace "board_late_init" in board file. Signed-off-by:
Jacob Chen <jacob2.chen@rock-chips.com> Acked-by:
Simon Glass <sjg@chromium.org>
-
Jacob Chen authored
To keep it same with 3288 Signed-off-by:
-
Jacob Chen authored
Signed-off-by:
-
Xu Ziyuan authored
The latest rk3288-miniarm board doesn't have eMMC device, so remove it. Signed-off-by:
Ziyuan Xu <xzy.xu@rock-chips.com> Acked-by:
-
Kever Yang authored
Add a regulator-init-microvolt for vdd_center regulator so that we can get a init value for driver probe. Not like pmic regulator, the PWM regulator do not have a known default output value, so we would like to init the regulator when driver probe. Signed-off-by:
Kever Yang <kever.yang@rock-chips.com> Acked-by:
-
Kever Yang authored
Enable DM_PWM and DM_REGULATOR on rockchip SoCs. Signed-off-by:
-
Kever Yang authored
Reference to kernel source code, rockchip pwm has three type, we are using v2 for rk3288 and rk3399, so let's update the register to sync with pwm_data_v2 in kernel. Signed-off-by:
-
Kever Yang authored
Update PPLL to 676MHz and PMU_PCLK to 48MHz, because: 1. 48MHz can make sure the pwm can get exact 50% duty ratio, but 99MHz can not, 2. We think 48MHz is fast enough for pmu pclk and it is lower power cost than 99MHz, 3. PPLL 676 MHz and PMU_PCLK 48MHz are the clock rate we are using internally for kernel,it suppose not to change the bus clock like pmu_pclk in kernel, so we want to change it in uboot. Signed-off-by:
-
Sandy Patterson authored
Default SPL_MMC_SUPPORT to false when ROCKCHIP_SPL_BACK_TO_BROM is enabled. Acked-by:
Sandy Patterson <apatterson@sightlogix.com> Acked-by:
-
Sandy Patterson authored
Move back_to_bootrom() call later in SPL init so that the console is initialized and printouts happen. Currently when ROCKCHIP_SPL_BACK_TO_BROM is enabled there is no console output from the SPL init stages. I wasn't sure exactly where this should happen, so if we are set to do run spl_board_init, then go back to bootrom there after preloader_console_init(). Otherwise fall back to old behavior of doing it in board_init_f. Signed-off-by:
-
Xu Ziyuan authored
The all current Rockchip SoCs supporting 4GB of ram have problems accessing the memory region 0xfe000000~0xff000000. Actually, some IP controller can't address to, so let's limit the available range. This patch fixes a bug which found in miniarm-rk3288-4GB board. The U-Boot was relocated to 0xfef72000, and .bss variants was also relocated, such as do_fat_read_at_block. Once eMMC controller transfer data to do_fat_read_at_block via DMA, DMAC can't access more than 0xfe000000. So that DMAC didn't work sane. Signed-off-by:
-
Lokesh Vutla authored
Given that boot monitor image is being generated to a specific target location depending on the SoC and U-boot relies on addr_mon env variable to be aligned with boot monitor target location. When ever the target address gets updated in boot monitor, it is difficult to sync between u-boot and boot monitor and also there is no way to update user that boot monitor image is updated. To avoid this problem, boot monitor image is being generated with mkimage header. Adding support in mon_install command for parsing this header. Signed-off-by:
Suman Anna <s-anna@ti.com> Signed-off-by:
-
Lokesh Vutla authored
Enable ECC byte lane for k2g-evm Signed-off-by:
-
- Sep 27, 2016
-
-
Sanchayan Maity authored
Enable USB device tree node for Toradex Colibri Vybrid module. Signed-off-by:Sanchayan Maity <maitysanchayan@gmail.com>
-
Sanchayan Maity authored
Add device tree node for USB peripheral on Vybrid. Signed-off-by: -
B, Ravi authored
This patch enables the DFU boot mode support for dra7x platform. Signed-off-by:
Ravi Babu <ravibabu@ti.com> Reviewed-by:
-
Stephen Warren authored
On Tegra186, it is necessary to perform an SMC to fully flush all caches; flushing/cleaning by set/way is not enough. Implement the required hook to make this happen. Signed-off-by:
Stephen Warren <swarren@nvidia.com> Reviewed-by:
Tom Warren <twarren@nvidia.com>
-
Stephen Warren authored
Commit ce02a71c "tegra: dts: Sync tegra20 device tree files with Linux" enabled the ULPI USB port on Ventana, but made no attempt to ensure that U-Boot code could handle this. In practice, various code is missing, and various configuration options are not enabled, which causes U-Boot to hang when attempting to initialize this USB port. This patch enables ULPI PHY support on Ventana, and adds the required pinmux setup for the port to operate. Note that Ventana is so similar to Seaboard that this change is made in the Seaboard board file, which is shared with Ventana. Seaboard also has the ULPI USB port wired up in hardware, although to an internal port that often doesn't have anything attached to it. However, the DT nodes for the USB controller and PHY had different status property values, so the port was not initialized by U-Boot. Fix this inconsistency, and enable the ULPI port, just like in the Linux kernel DT. This likewise requires enabling ULPI support in the Seaboard defconfig. Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by:
-
Stephen Warren authored
Some boards have a different set of USB controllers enabled in DT than the set referenced by /alias entries. This patch fixes that. For example, this avoids the following message while booting on Ventana, which is caused by the fact that the USB0 controller had no alias, and defaulted to wanting a sequence number of 0, which was later explicitly requested by the alias for USB controller 2. USB2: Device 'usb@c5008000': seq 0 is in use by 'usb@c5000000' This didn't affect USB operation in any way though. Related, there's no need for the USB controller aliases to have an order that's different from the HW order, so re-order any aliases to match the HW ordering. This has the benefit that since USB controller 0 is the only one that supports device-mode in HW, and U-Boot only supports enabling device move on controller 0, there's now good synergy in the ordering! For Tegra20, that's not relevant at present since USB device mode doesn't work correctly on that SoC, but it will save some head-scratching later. This patch doesn't fix the colibri_t20 board, even though it has the same issue, since Marcel already sent a patch for that. Cc: Marcel Ziswiler <marcel.ziswiler@toradex.com> Signed-off-by:
Marcel Ziswiler <marcel.ziswiler@toradex.com> Tested-on: Harmony and Ventana
-
