- 26 8月, 2021 8 次提交
-
-
由 T Karthik Reddy 提交于
soc_xilinx_zynqmp driver allows identification of family & revision of zynqmp SoC. This driver is selected by CONFIG_SOC_XILINX_ZYNQMP. Add this config to xilinx_zynqmp_virt_defconfig file. Probe this driver using platdata U_BOOT_DEVICE structure which is specified in mach-zynqmp/cpu.c. Signed-off-by: NT Karthik Reddy <t.karthik.reddy@xilinx.com> Reviewed-by: NAshok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
-
由 Michal Simek 提交于
Enable cfi flash on zc770-xm012 configuration. Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
-
由 Michal Simek 提交于
Single configuration is working fine and no issue to enable it. Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
-
由 Sai Krishna Potthuri 提交于
Replace 'io-standard' property with 'power-source' property in all zynq dts files to be in sync with Zynq Pinctrl driver. Signed-off-by: NSai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com> Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
-
由 Raju Kumar Pothuraju 提交于
Add missing "jedec, spi-nor" compatible string for QSPI flash node. Spi-nor framework uses this compatibility string to probe & initialize flash. With missing compatibility string we are observing below error: Zynq> sf probe 0 0 0 jedec_spi_nor spi_flash@0:0: unrecognized JEDEC id bytes: 00, 00, 00 Failed to initialize SPI flash at 0:0 (error -2) Signed-off-by: NRaju Kumar Pothuraju <raju.kumar-pothuraju@xilinx.com> Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
-
由 Michal Simek 提交于
Trivial style patch. Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
-
由 Michal Simek 提交于
Fix header alignment. Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
-
由 Michal Simek 提交于
By dt-binding specs led nodes should have -led suffix that's why add it. Signed-off-by: NMichal Simek <michal.simek@xilinx.com>
-
- 03 8月, 2021 2 次提交
-
-
由 Simon Glass 提交于
It is a pain to have to specify the value 10 in each call. Add a new dectoul() function and update the code to use it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
It is a pain to have to specify the value 16 in each call. Add a new hextoul() function and update the code to use it. Add a proper comment to simple_strtoul() while we are here. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
- 01 8月, 2021 2 次提交
-
-
由 Icenowy Zheng 提交于
There are more Allwinner SoCs that do not have a SCP now. When there's no SCP_ADDR macro defined, we can assume there's no SCP available. Drop the scp part of FIT description when SCP_ADDR does not exist. Signed-off-by: NIcenowy Zheng <icenowy@sipeed.com> Reviewed-by: NAndre Przywara <andre.przywara@arm.com> Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
-
由 Samuel Holland 提交于
So far for the H3, A23, and A33 SoCs, we use DRAM to hold the secure monitor code (providing PSCI runtime services). And while those SoCs do not have the secure SRAM B like older SoCs, there is enough (secure) SRAM A2 to put the monitor code and data in there instead. Follow the design of 64-bit SoCs and use the first part for the monitor, and the last 16 KiB for the SCP firmware. With this change, the monitor no longer needs to reserve a region in DRAM. Signed-off-by: NSamuel Holland <samuel@sholland.org> Reviewed-by: NAndre Przywara <andre.przywara@arm.com> [Andre: amend commit message, fix R40 and V3s build] Signed-off-by: NAndre Przywara <andre.przywara@arm.com>
-
- 31 7月, 2021 5 次提交
-
-
由 Pali Rohár 提交于
Now that proper load and execution addresses are set in v1 kwbimage we can use it for loading and booting U-Boot proper. Use the new spl_parse_board_header() function to implement parsing the kwbimage v1 header. Use information from this header to locate offset and size of the U-Boot proper binary, instead of using the legacy U-Boot header which is prepended to the U-Boot proper binary stored at fixed offset. This has the advantage that we do not need to relay on legacy U-Boot header anymore and therefore U-Boot proper binary can be stored at any offset, as is the case when loading & booting U-Boot proper by BootROM. The CONFIG_SYS_U_BOOT_OFFS option is therefore not used by SPL code anymore. Also allow to compile U-Boot SPL without CONFIG_SPL_SPI_FLASH_SUPPORT, CONFIG_SPL_MMC_SUPPORT or CONFIG_SPL_SATA_SUPPORT set. In this case BootROM is used for loading and executing U-Boot proper. This reduces the size of U-Boot's SPL image. By default these config options are enabled and so BootROM loading is not used. In some cases BootROM reads from SPI NOR at lower speed than U-Boot SPL. So people can decide whether they want to have smaller SPL binary at the cost of slower boot. Therefore dependency on CONFIG_SPL_DM_SPI, CONFIG_SPL_SPI_FLASH_SUPPORT, CONFIG_SPL_SPI_LOAD, CONFIG_SPL_SPI_SUPPORT, CONFIG_SPL_DM_GPIO, CONFIG_SPL_DM_MMC, CONFIG_SPL_GPIO_SUPPORT, CONFIG_SPL_LIBDISK_SUPPORT, CONFIG_SPL_MMC_SUPPORT, CONFIG_SPL_SATA_SUPPORT and CONFIG_SPL_LIBDISK_SUPPORT is changed from strict to related "imply" (which can be selectivelly turned off and causes booting via BootROM). Options CONFIG_SYS_SPI_U_BOOT_OFFS, CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_SECTOR and CONFIG_SYS_MMCSD_RAW_MODE_U_BOOT_DATA_PART_OFFSET have to to be set to zero as they define the location where kwbimage header starts. It is the location where BootROM expects start of the kwbimage from which it reads, parses and executes SPL part. The same applies to option CONFIG_SPL_SATA_RAW_U_BOOT_SECTOR, which has to be set to one. Update all config files to set correct values of these options and set CONFIG_SYS_U_BOOT_OFFS to the correct value - the offset where U-Boot proper starts. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de>
-
由 Pali Rohár 提交于
Current code uses hack in board_init_f() which calls return_to_bootrom() to skip U-Boot SPL code and return back to BootROM to load U-Boot via UART or from NAND. This change migrates that hack from the board_init_f() function and changes it to return BOOT_DEVICE_BOOTROM instead of returning to BootROM directly, so that U-Boot's SPL framework is used for returning to BootROM. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de> Reviewed-by: NChris Packham <judge.packham@gmail.com> Tested-by: NChris Packham <judge.packham@gmail.com>
-
由 Pali Rohár 提交于
U-Boot's SPL framework already has an API for loading U-Boot via BootROM. Implement the function board_return_to_bootrom() for mvebu SPL code. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de> Reviewed-by: NChris Packham <judge.packham@gmail.com> Tested-by: NChris Packham <judge.packham@gmail.com>
-
由 Pali Rohár 提交于
This function does not return, so add the appropriate compiler flag. Signed-off-by: NPali Rohár <pali@kernel.org> Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de> Reviewed-by: NChris Packham <judge.packham@gmail.com> Tested-by: NChris Packham <judge.packham@gmail.com>
-
由 Pali Rohár 提交于
Register r0 should be set to return value 0x0 - NO_ERR. Set r0 with return value after all registers are restored from the stack, so that the return value is always correct. Signed-off-by: NPali Rohár <pali@kernel.org> Fixes: 944c7a31 ("arm: mvebu: Add option to use UART xmodem protocol via kwboot") Reviewed-by: NMarek Behún <marek.behun@nic.cz> Reviewed-by: NStefan Roese <sr@denx.de> Reviewed-by: NChris Packham <judge.packham@gmail.com> Tested-by: NChris Packham <judge.packham@gmail.com>
-
- 29 7月, 2021 11 次提交
-
-
由 Patrice Chotard 提交于
At early U-Boot stage, before relocation, MMU is not yet configured and disabled. DDR may not be configured with the correct memory attributes (can be configured in MT_DEVICE instead of MT_MEMORY). In this case, usage of memcpy_{from, to}io() may leads to synchronous abort in AARCH64 in case the normal memory address is not 64Bits aligned. To avoid such situation, forbid usage of normal memory cast to (u64 *) in case MMU is not enabled. Signed-off-by: NPatrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: NPatrick Delaunay <patrick.delaunay@foss.st.com> Cc: mark.kettenis@xs4all.nl Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
-
由 Patrick Delaunay 提交于
Align reset_cpu function with the next prototypes in sysreset.h or in cpu_func.h to solve compilation issue: void reset_cpu(void); This patch solves the prototype conflict when cpu_func.h is included. Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
-
由 Simon Glass 提交于
Rename these options so that CONFIG_IS_ENABLED can be used with them. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NHeiko Schocher <hs@denx.de>
-
由 Simon Glass 提交于
It is quite confusing that CONFIG_SYS_I2C selects the legacy I2C and CONFIG_DM_I2C selects the current I2C. The deadline to migrate I2C is less than a year away. Also we want to have a CONFIG_I2C for U-Boot proper just like we have CONFIG_SPL_I2C for SPL, so we can simplify the Makefile rules. Rename this symbol so it is clear it is going away. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NHeiko Schocher <hs@denx.de>
-
由 Simon Glass 提交于
Rename these options so that CONFIG_IS_ENABLED can be used with them. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Rename these options so that CONFIG_IS_ENABLED can be used with them. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Rename this option so that CONFIG_IS_ENABLED can be used with it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Rename this option so that CONFIG_IS_ENABLED can be used with it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Rename this option so that CONFIG_IS_ENABLED can be used with it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Rename this option so that CONFIG_IS_ENABLED can be used with it. Signed-off-by: NSimon Glass <sjg@chromium.org>
-
由 Simon Glass 提交于
Rename this option so that CONFIG_IS_ENABLED can be used with it. Signed-off-by: NSimon Glass <sjg@chromium.org> Reviewed-by: NJaehoon Chung <jh80.chung@samsung.com>
-
- 27 7月, 2021 12 次提交
-
-
由 Artem Lapkin 提交于
Khadas vim series: Use devicetree for SMBIOS settings Add settings and enable the default sysinfo driver so that these can come from the device tree. Reviewed-by: NNeil Armstrong <narmstrong@baylibre.com> Signed-off-by: NArtem Lapkin <art@khadas.com> Signed-off-by: NNeil Armstrong <narmstrong@baylibre.com>
-
由 Alexandru Gagniuc 提交于
Add the "/reserved-memory/optee" node to the SPL devicetree. The purpose is to allow configuring TZC regions when booting OP-TEE. Signed-off-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: NSimon Glass <sjg@chromium.org>
-
由 Alexandru Gagniuc 提交于
OP-TEE is very particular about how the TZC should be configured. When booting an OP-TEE payload, an incorrect TZC configuration will result in a panic. Most information can be derived from the SPL devicetree. The only information we don't have is the split between TZDRAM and shared memory. This has to be hardcoded. The rest of the configuration is fairly easy, and only requires 3 TZC regions. Configure them. Signed-off-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com>
-
由 Alexandru Gagniuc 提交于
The purpose of this change is to allow configuring TrustZone (TZC) memory permissions. For example, OP-TEE expects TZC regions to be configured in a very particular way. The API presented here is intended to allow exactly that. UCLASS support is not implemented, because it would not be too useful. Changing TZC permissions needs to be done with care, so as not to cut off access to memory we are currently using. One place where we can use this is at the end of SPL, right before jumping to OP-TEE. Signed-off-by: NAlexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
-
由 Marek Vasut 提交于
Commit 500327e2 ("ARM: dts: stm32mp1: DT alignment with Linux kernel v5.8-rc1") renamed sdmmc2_d47_pins_b phandle to sdmmc2_d47_pins_c, but without updating the AV96 DT which uses that phandle. Linux missed similar update as well and it was only added in commit 1ad6e36ec266 ("ARM: dts: stm32: Fix sdmmc2 pins on AV96") . Update the AV96 DT pinmux phandle, otherwise eMMC 8bit mode does not work and access to eMMC takes a very long time to fall back to 4bit mode. Signed-off-by: NMarek Vasut <marex@denx.de> Cc: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
-
由 Patrick Delaunay 提交于
When a push-button is released and PA13/PA14 are defined as input (high-Z) the LED should not be active as the circuit is open but a small current leak through PCB or push-button close the circuit and allows a small LED bias giving erroneous level voltage. So it is recommended to activate an internal pull-up in order to clearly fix the voltage at PA13/PA14 when button is released and to wait a short delay before to read the GPIO value only when the pull-up is correctly configured. Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: NPatrice Chotard <patrice.chotard@foss.st.com>
-
由 Patrick Delaunay 提交于
When the TAMP register 20 have an invalid value (0x0 for example after TAMPER error) the "boot_device" U-Boot env variable have no value and no error is displayed in U-Boot log. The STM32MP boot command bootcmd_stm32mp failed with strange trace: "Boot over !" and the next command in bootcmd_stm32mp failed with few indication: if test ${boot_device} = serial || test ${boot_device} = usb; then stm32prog ${boot_device} ${boot_instance}; As it is difficult to investigate, the current patch avoids this issue: - change the debug message to error: "unexpected boot mode" is displayed - display trace "Boot over invalid!" in bootcmd_stm32mp - execute "run distro_bootcmd" to try all the possible target Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com> Reviewed-by: NPatrice Chotard <patrice.chotard@foss.st.com>
-
由 Suman Anna 提交于
The MAIN R5FSS0 cluster and corresponding nodes are no longer required to be enabled in R5 SPL after removing the support for booting any core from this cluster on R5 SPL. So, remove these from the relevant dts files. This is essentially a revert of the additions done in commit 2984b82b ("arm: dts: k3-j721e-r5: Enable r5fss0 cluster in SPL"). Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-5-s-anna@ti.com
-
由 Suman Anna 提交于
The mach-k3 common code defined a weak start_non_linux_remote_cores() function so that the proper implementation can be plugged in the SoC-specific source files. This won't be needed anymore, so remove the the common code. Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-4-s-anna@ti.com
-
由 Suman Anna 提交于
The common J7 specific start_non_linux_remote_cores() override function implements the logic to load and boot the Main R5FSS Core0 from R5 SPL. This won't be supported any more for either J721E or J7200 after the R5 SPL rearchitecture for the System Firmware split into TI Foundation Security (TIFS) and Device Management (DM) firmwares. So, cleanup the corresponding code and the related SPL env variables. Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-3-s-anna@ti.com
-
由 Suman Anna 提交于
The Main R5FSS Core0 on J721E SoCs is originally booted from R5 SPL itself to achieve certain product-level early-boot metrics. This is no longer supported after the R5 SPL re-architecture (support merged for v2021.10-rc1). Move the booting of this core altogether from R5 SPL to A72 U-Boot. The env variables are left as is for now, and will be cleaned up in a subsequent patch. Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-2-s-anna@ti.com
-
由 Suman Anna 提交于
The default U-Boot environment variables and design are all set up to have the MCU R5FSS cluster to be in Split-mode. This is the setting in v2021.01 U-Boot and the dt nodes are synched with the kernel binding property names in commit 468ec2f3 ("remoteproc: k3_r5: Sync to upstreamed kernel DT property names") merged in v2021.04-rc2. The mode for the cluster got switched back to LockStep mode by mistake in commit e4978763 ("arm: dts: k3-am65: Sync Linux v5.11-rc6 dts into U-Boot") also in v2021.04-rc2. This throws the following warning messages when early-booting the cores using default env variables, k3_r5f_rproc r5f@41400000: Invalid op: Trying to start secondary core 2 in lockstep mode Load Remote Processor 1 with data@addr=0x82000000 65268 bytes: Failed! Fix this by switching back the cluster to the expected Split-mode. Make this mode change in the u-boot specific dtsi file to avoid such sync overrides in the future until the kernel dts is also switched to Split-mode by default. Fixes: e4978763 ("arm: dts: k3-am65: Sync Linux v5.11-rc6 dts into U-Boot") Signed-off-by: NSuman Anna <s-anna@ti.com> Signed-off-by: NLokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726162213.28719-1-s-anna@ti.com
-