summaryrefslogtreecommitdiff
path: root/arch
Commit message (Collapse)AuthorAgeFilesLines
* xilinx: zynqmp: Update descriptions for u-boot.itsMichal Simek2021-08-261-2/+2
| | | | | | | Use TF-A instead of ATF in description. And update generic description with removing ATF because also configurations without it are supported. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* xilinx: common: Enabling generic function for DT reselectionMichal Simek2021-08-261-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | U-Boot support board detection at run time and based on it change DT. This feature is implemented for SOM Kria platforms which contain two eeproms which contain information about SOM module and CC (Carrier card). Full U-Boot starts with minimal DT file defined by CONFIG_DEFAULT_DEVICE_TREE which is available in multi DTB fit image. It is using default setup of board_name variable initializaed to DEVICE_TREE which corresponds to CONFIG_DEFAULT_DEVICE_TREE option. When DTB_RESELECT is enabled board_detection() is called. Keep it your mind that this code is called before relocation. board_detection() is calling xilinx_read_eeprom() which fills board_info (xilinx_board_description) structure which are parsed in board_name_decode(). Based on DT configuration and amount of nvmemX aliases name of the board is composed by concatenating CONFIG_SYS_BOARD "-" <board_name> "-rev" <board_revision> "-" <cc_name> "-rev" <cc_revision>. If CC is not present or more are available it keeps going. When board name is composed and returned from board_name_decode() it is assigned to board_name variable which is used by board_fit_config_name_match() which is called via fdtdec_setup() when it goes over config options in multi dtb FIT image. From practical point of view multi DTB image is key point here which has to contain configs for detected combinations. Unfortunately as of now they have to be full DTBs and DTBOs are not supported. That's why configuration like: config_X { description = "zynqmp-board-cc"; fdt = "board", "cc"; }; needs to be squashed together with: fdtoverlay -o zynqmp-board-cc -i arch/arm/dts/zynqmp-board.dtb \ arch/arm/dts/zynqmp-cc.dtbo and only one dtb is in fit: config_X { description = "zynqmp-board-cc"; fdt = "board-cc"; }; For creating multi DTBs fit image use mkimage -E, e.g.: mkimage -E -f all.its all.dtb When DTB_RESELECT is enabled xilinx_read_eeprom() is called before relocation and it uses calloc for getting a buffer. Because this is dynamic memory it is not relocated that's why xilinx_read_eeprom() is called again as the part of board_init(). This second read with calloc buffer placed in proper position board_late_init_xilinx() can setup u-boot variables as before. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* xilinx: zynqmp: Generate different u-boot.itb for MULTI_DTB_FITMichal Simek2021-08-261-0/+47
| | | | | | | | | | When MULTI_DTB_FIT is enabled fit-dtb.blob fit image is created which contain all DTBs listed by CONFIG_OF_LIST. And with DTB_RELESELECT there is a need to handle it as one file with DTBs in it not as separate DTBs in u-boot.its/itb. That's why extend mkimage_fit_atf.sh to generate u-boot.itb correctly. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* arm64: dts: Make sure that all DTBs are 64bit alignedMichal Simek2021-08-261-1/+1
| | | | | | | Start of DTB should be 64bit aligned that's why also make sure that end is also 64bit aligned. It is not required but it is nice thing to do. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* soc: xilinx: versal: Add soc_xilinx_versal driverT Karthik Reddy2021-08-263-0/+10
| | | | | | | | | | | | | soc_xilinx_versal driver allows identification of family & revision of versal SoC. This driver is selected by CONFIG_SOC_XILINX_VERSAL. Probe this driver using platdata U_BOOT_DEVICE structure which is defined at mach-versal/cpu.c. Add this config to xilinx_versal_virt_defconfig & xilinx_versal_mini_ospi_defconfig file to select this driver. Signed-off-by: T Karthik Reddy <t.karthik.reddy@xilinx.com> Reviewed-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* soc: xilinx: zynqmp: Add soc_xilinx_zynqmp driverT Karthik Reddy2021-08-263-0/+9
| | | | | | | | | | | | 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: T Karthik Reddy <t.karthik.reddy@xilinx.com> Reviewed-by: Ashok Reddy Soma <ashok.reddy.soma@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* ARM: zynq: Enable smcc and nor for zc770-xm012Michal Simek2021-08-261-0/+9
| | | | | | Enable cfi flash on zc770-xm012 configuration. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* ARM: zynq: Wire single qspi on couple of boardsMichal Simek2021-08-264-0/+32
| | | | | | Single configuration is working fine and no issue to enable it. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* ARM: zynq: Replace 'io-standard' with 'power-source' propertySai Krishna Potthuri2021-08-262-20/+20
| | | | | | | | Replace 'io-standard' property with 'power-source' property in all zynq dts files to be in sync with Zynq Pinctrl driver. Signed-off-by: Sai Krishna Potthuri <lakshmi.sai.krishna.potthuri@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* xilinx: Add jedec compatible string for QSPI (Zynq/ZynqMP)Raju Kumar Pothuraju2021-08-264-4/+4
| | | | | | | | | | | | | | 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: Raju Kumar Pothuraju <raju.kumar-pothuraju@xilinx.com> Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* arm64: zynqmp: Update comment style sm-k26Michal Simek2021-08-261-1/+1
| | | | | | Trivial style patch. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* arm64: zynqmp: Fix header alignment on kv260 boardsMichal Simek2021-08-262-8/+8
| | | | | | Fix header alignment. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* arm64: zynqmp: Fix node name for ds35/36 ledsMichal Simek2021-08-261-2/+2
| | | | | | By dt-binding specs led nodes should have -led suffix that's why add it. Signed-off-by: Michal Simek <michal.simek@xilinx.com>
* Merge https://source.denx.de/u-boot/custodians/u-boot-samsungTom Rini2021-08-033-18/+2
|\
| * samsung: exynos: Convert SROMC interface to a driverSimon Glass2021-07-273-18/+2
| | | | | | | | | | | | | | | | | | | | | | Add a bus driver for this and use it to configure the bus parameters for the Ethernet interface. Drop the old pre-driver-model code. Switch over to use driver model for Ethernet. Signed-off-by: Simon Glass <sjg@chromium.org> Reviewed-by: Jaehoon Chung <jh80.chung@samsung.com> Signed-off-by: Minkyu Kang <mk7.kang@samsung.com>
* | Merge https://source.denx.de/u-boot/custodians/u-boot-x86Tom Rini2021-08-0230-89/+101
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Fixed broken ICH SPI driver in software sequencer mode - Added "m25p,fast-read" to SPI flash node for x86 boards - Drop ROM_NEEDS_BLOBS and BUILD_ROM for x86 ROM builds - Define a default TSC timer frequency for all x86 boards - x86 MTRR MSR programming codes bug fixes - x86 "hob" command bug fixes - Don't program MTRR for DRAM for FSP1 - Move INIT_PHASE_END_FIRMWARE to FSP2 - Use external graphics card by default on Intel Crown Bay - tangier: Fix DMA controller IRQ polarity in CSRT
| * | x86: queensbay: Return directly if IGD / SDVO were already disabledBin Meng2021-08-031-11/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Initialize 'igd' and 'sdvo' to NULL so that we just need to test them against NULL later, to be compatible with that case that IGD and SDVO devices were already in disabled state. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | x86: fsp: Only FSP2 has INIT_PHASE_END_FIRMWAREBin Meng2021-08-032-16/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For FSP1, there is no such INIT_PHASE_END_FIRMWARE. Move board_final_cleanup() to fsp2 directory. Fixes: 7c73cea44290 ("x86: Notify the FSP of the 'end firmware' event") Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
| * | x86: fsp: Don't program MTRR for DRAM for FSP1Bin Meng2021-08-031-4/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are several outstanding issues as to why this does not apply to FSP1: * For FSP1, the system memory and reserved memory used by FSP are already programmed in the MTRR by FSP. * The 'mtrr_top' mistakenly includes TSEG memory range that has the same RES_MEM_RESERVED resource type. Its address is programmed and reported by FSP to be near the top of 4 GiB space, which is not what we want for SDRAM. * The call to mtrr_add_request() is not guaranteed to have its size to be exactly the power of 2. This causes reserved bits of the IA32_MTRR_PHYSMASK register to be written which generates #GP. For FSP2, it seems this is necessary as without this, U-Boot boot process on Chromebook Coral goes very slowly. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
| * | x86: mtrr: Abort if requested size is not power of 2Bin Meng2021-08-022-3/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The size parameter of mtrr_add_request() and mtrr_set_next_var() shall be power of 2, otherwise the logic creates a mask that does not meet the requirement of IA32_MTRR_PHYSMASK register. Programming such a mask value to IA32_MTRR_PHYSMASK generates #GP. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
| * | x86: mtrr: Skip MSRs that were already programmed in mtrr_commit()Bin Meng2021-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present mtrr_commit() programs the MTRR MSRs starting from index 0, which may overwrite MSRs that were already programmed by previous boot stage or FSP. Switch to call mtrr_set_next_var() instead. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
| * | x86: mtrr: Do not clear the unused ones in mtrr_commit()Bin Meng2021-08-021-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Current mtrr_commit() logic assumes that MTRR MSRs are programmed consecutively from index 0 to its maximum number, and whenever it detects an unused one, it clears all other MTRRs starting from that one. However this may not always be the case. In fact, the clear is not much helpful because these MTRRs come out of reset as disabled already. Drop the clear codes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org> Tested on chromebook_coral, chromebook_samus, chromebook_link, minnowmax Tested-by: Simon Glass <sjg@chromium.org>
| * | x86: dts: Define a default TSC timer frequencyBin Meng2021-08-0220-43/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If for some reason, TSC timer frequency cannot be determined from hardware, nor is it specified in the device tree, U-Boot will panic resulting in endless reset during boot. Let's define a default TSC timer frequency using the Kconfig value CONFIG_X86_TSC_TIMER_FREQ (note: #include must be used instead of /include/ otherwise the macro is not pre-processed). Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | x86: tsc: Rename X86_TSC_TIMER_EARLY_FREQ to X86_TSC_TIMER_FREQBin Meng2021-08-022-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently there are two places to specify the x86 TSC timer frequency with one in Kconfig used for early timer and the other one in device tree used when the frequency cannot be determined from hardware. This may potentially create an inconsistent config where the 2 values do not match. Let's use the one specified in Kconfig in the device tree as well. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | x86: kconfig: Drop ROM_NEEDS_BLOBS and BUILD_ROMBin Meng2021-08-022-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | These 2 options are no longer needed as now binman is used to build u-boot.rom. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | x86: tangier: Fix DMA controller IRQ polarity in CSRTAndy Shevchenko2021-08-021-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | IRQ polarity in CSRT has the same definition as by ACPI specification chapter 19.6.64 "Interrupt (Interrupt Resource Descriptor Macro)", i.e. ActiveHigh is 0, and ActiveLow is 1. On Intel Tangier the DMA controller IRQ polarity is ActiveHigh. Note, in DSDT (see southcluster.asl) it's described correctly. Fixes: 5e99fde34a77 ("x86: tangier: Populate CSRT for shared DMA controller") Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Reviewed-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | x86: dts: Add "m25p,fast-read" to SPI flash nodeBin Meng2021-08-0211-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | Except ICH7 SPI, all SPI flashes connected to ICH9 / Fast SPI should have "m25p,fast-read" property present in their DT nodes. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
* | | global: Convert simple_strtoul() with decimal to dectoul()Simon Glass2021-08-0210-15/+15
| | | | | | | | | | | | | | | | | | | | | 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: Simon Glass <sjg@chromium.org>
* | | global: Convert simple_strtoul() with hex to hextoul()Simon Glass2021-08-0225-84/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Simon Glass <sjg@chromium.org>
* | | dtoc: Support widening a bool valueSimon Glass2021-08-011-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | At present if we see 'ranges' property (with no value) we assume it is a boolean, as per the devicetree spec. But another node may define 'ranges' with a value, forcing us to widen it to an int array. At present this is not supported and causes an error. Fix this and add some test cases. Signed-off-by: Simon Glass <sjg@chromium.org> Reported-by: Tom Rini <trini@konsulko.com>
* | | sandbox: Reduce keyed autoboot delaySimon Glass2021-08-013-0/+28
|/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The autoboot tests are a recent addition to U-Boot, providing much-needed coverage in this area. A side effect of the keyed autoboot test is that this feature is enabled in sandbox always. This changes the autoboot prompt and confuses the pytests. Some tests become slower, for example the vboot tests take about 27s now instead of 3s. We don't actually need this feature enabled to be able to run the tests. Add a switch to allow sandbox to turn it on and off as needed. Use this in the one test that needs it. Add a command-line flag in case this is desired in normal use. Signed-off-by: Simon Glass <sjg@chromium.org> Fixes: 25c8b9f298e ("test: add first autoboot unit tests") Reviewed-by: Steffen Jaeckel <jaeckel-floss@eyet-services.de>
* | Merge https://source.denx.de/u-boot/custodians/u-boot-sunxiTom Rini2021-07-312-2/+13
|\ \ | | | | | | | | | | | | | | | | | | - Move the PSCI runtime code for H3/A23/A33 into SRAM - Pick the environment from the actual MMC boot device (SD card vs. eMMC) - Plus a small improvement from Icenowy, just for good measure.
| * | sunxi: decide the inclusion of SCP by SCP_ADDR existenceIcenowy Zheng2021-08-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Icenowy Zheng <icenowy@sipeed.com> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
| * | sunxi: A23/A33/H3: Move sun8i secure monitor to SRAM A2Samuel Holland2021-08-011-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> [Andre: amend commit message, fix R40 and V3s build] Signed-off-by: Andre Przywara <andre.przywara@arm.com>
* | | arm: mvebu: Load U-Boot proper binary in SPL code based on kwbimage headerPali Rohár2021-07-312-22/+205
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de>
* | | arm: mvebu: Use U-Boot's SPL BootROM framework for booting from NAND/UARTPali Rohár2021-07-311-23/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Chris Packham <judge.packham@gmail.com> Tested-by: Chris Packham <judge.packham@gmail.com>
* | | arm: mvebu: Implement return_to_bootrom() via U-Boot's SPL frameworkPali Rohár2021-07-312-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Chris Packham <judge.packham@gmail.com> Tested-by: Chris Packham <judge.packham@gmail.com>
* | | arm: mvebu: Mark return_to_bootrom() as a noreturn functionPali Rohár2021-07-311-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This function does not return, so add the appropriate compiler flag. Signed-off-by: Pali Rohár <pali@kernel.org> Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Chris Packham <judge.packham@gmail.com> Tested-by: Chris Packham <judge.packham@gmail.com>
* | | arm: mvebu: Fix return_to_bootrom()Pali Rohár2021-07-311-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Pali Rohár <pali@kernel.org> Fixes: 944c7a317675 ("arm: mvebu: Add option to use UART xmodem protocol via kwboot") Reviewed-by: Marek Behún <marek.behun@nic.cz> Reviewed-by: Stefan Roese <sr@denx.de> Reviewed-by: Chris Packham <judge.packham@gmail.com> Tested-by: Chris Packham <judge.packham@gmail.com>
* | | Merge branch '2021-07-28-assorted-fixes'Tom Rini2021-07-293-11/+26
|\ \ \ | | | | | | | | | | | | - Assorted bugfixes
| * | | arm64: Update memcpy_{from, to}io() helpersPatrice Chotard2021-07-282-10/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Patrice Chotard <patrice.chotard@foss.st.com> Reviewed-by: Patrick Delaunay <patrick.delaunay@foss.st.com> Cc: mark.kettenis@xs4all.nl Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
| * | | arm: use the correct prototype for reset_cpu functionPatrick Delaunay2021-07-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Patrick Delaunay <patrick.delaunay@foss.st.com>
* | | | Merge tag 'ti-v2021.10-rc2' of ↵Tom Rini2021-07-2920-276/+727
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | https://source.denx.de/u-boot/custodians/u-boot-ti - Add MMC High speed modes for AM64 and J7200 - Add Sierra/Torrent SERDES driver - Minor clean-ups for R5F boot from SPL
| * | | arm: dts: k3-j721e-r5: Remove MAIN R5FSS0 cluster from SPLSuman Anna2021-07-272-16/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 2984b82b3b76 ("arm: dts: k3-j721e-r5: Enable r5fss0 cluster in SPL"). Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-5-s-anna@ti.com
| * | | arm: mach-k3: Cleanup common start_non_linux_remote_cores()Suman Anna2021-07-272-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-4-s-anna@ti.com
| * | | arm: mach-k3: j721e: Cleanup MAIN R5 boot code from R5 SPLSuman Anna2021-07-271-40/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-3-s-anna@ti.com
| * | | arm: mach-k3: j721e: Move booting of Main R5FSS Core0 to A72 U-BootSuman Anna2021-07-271-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726211311.5977-2-s-anna@ti.com
| * | | arm: dts: k3-am65: Fix up MCU R5FSS cluster mode back to Split-modeSuman Anna2021-07-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 468ec2f3ef8f ("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 e49787634312 ("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: e49787634312 ("arm: dts: k3-am65: Sync Linux v5.11-rc6 dts into U-Boot") Signed-off-by: Suman Anna <s-anna@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726162213.28719-1-s-anna@ti.com
| * | | arch: dts: am642-sk-u-boot: Disable main_sdhci0 DT node and define alias ↵Aswath Govindraju2021-07-271-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | index 1 for main_sdhci1 node A Wilink wireless device is connected to MMCSD0 subsystem and is not supported in U-Boot. Therefore, disable main_sdhci0 device tree node in U-Boot. If main_sdhci0 device tree node is disabled then the the index of main_sdhci1 node becomes 0 which leads to break in boot flow. Therefore, add an alias to fix the index to 1. Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726152807.22991-3-a-govindraju@ti.com
| * | | arch: arm: mach-k3: am642_init: Correct the function name spl_boot_mode() to ↵Aswath Govindraju2021-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | spl_mmc_boot_mode() Function spl_boot_mode() is called in common/spl/spl_mmc.c, to find the boot mode for a given boot device. This function was renamed to spl_mmc_boot_mode() by commit e97590654aea4c964f49bd915543a417d0c76996. Therefore, rename spl_boot_mode to spl_mmc_boot_mode. Fixes: 57dba04afbb7 ("arm: mach-k3: am642: Add support for boot device detection") Signed-off-by: Aswath Govindraju <a-govindraju@ti.com> Signed-off-by: Lokesh Vutla <lokeshvutla@ti.com> Link: https://lore.kernel.org/r/20210726152807.22991-2-a-govindraju@ti.com
View Lorry Controller Status