summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
| * | arm: dts: k3-j721e-main: Update the speed modes supported and their itap ↵Aswath Govindraju2021-04-161-4/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | delay values for MMCSD subsystems According to latest errata of J721e [1], HS400 mode is not supported in MMCSD0 subsystem (i2024) and SDR104 mode is not supported in MMCSD1/2 subsystems (i2090). Therefore, replace mmc-hs400-1_8v with mmc-hs200-1_8v in MMCSD0 subsystem and add a sdhci mask to disable SDR104 speed mode. Also, update the itap delay values for all the MMCSD subsystems according the latest J721e data sheet[2] [1] - https://www.ti.com/lit/er/sprz455/sprz455.pdf [2] - https://www.ti.com/lit/ds/symlink/tda4vm.pdf Fixes: 70e167495ab2 ("arm: dts: k3-j721e: Sync Linux v5.11-rc6 dts into U-Boot") Signed-off-by: Aswath Govindraju <a-govindraju@ti.com>
| * | test: pinmux: add test for 'pinctrl-single' driverDario Binacchi2021-04-125-5/+191
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The test adds two pinmux nodes to the device tree, one to test when a register changes only one pin's mux (pinctrl-single,pins), and the other to test when more than one pin's mux is changed (pinctrl-single,bits). This required replacing the controller's register access functions when the driver is used on sandbox. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | pinctrl: single: add get_pin_muxing operationDario Binacchi2021-04-121-9/+213
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It allows to display the muxing of a given pin. Inspired by more recent versions of the Linux driver, in addition to the address and the value of the configuration register I added the pin function retrieved from the DT. In doing so, the information displayed does not depend on the platform, being a generic type driver, and it can be useful for debug purposes. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | pinctrl: single: add get_pin_name operationDario Binacchi2021-04-121-0/+16
| | | | | | | | | | | | | | | | | | | | | It returns the name of the requested pin. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | pinctrl: single: add get_pins_count operationDario Binacchi2021-04-121-0/+37
| | | | | | | | | | | | | | | | | | | | | It returns the number of selectable pins. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | pinctrl: single: add register access functionsDario Binacchi2021-04-121-25/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | The configuration of pinmux registers was implemented with duplicate code which can be removed by adding two functions for read/write access. Access to 8-bit registers has also been added. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | pinctrl: single: change function mask default valueDario Binacchi2021-04-121-2/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The patch is inspired by more recent versions of the Linux driver. Replacing the default value 0xffffffff of the function mask with 0 is certainly more conservative in case the "pinctrl-single,function-mask" DT property is missing. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | pinctrl: single: check "register-width" DT propertyDario Binacchi2021-04-121-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In more recent versions of the Linux kernel the driver's probe function returns an error if the "pinctrl-single,register-width" DT property is missing. The lack of this information, in fact, does not allow to know whether to access the registers of the controller at 8, 16, ... bits. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | pinctrl: single: get register area size by device APIDario Binacchi2021-04-121-6/+8
| | | | | | | | | | | | | | | | | | | | | Use dev_read_addr_size to get size of the controller's register area. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
| * | pinctrl: single: fix debug messages formattingDario Binacchi2021-04-121-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The dev_dbg(dev, " reg/val 0x%pa/0x%08x\n", &reg, val); prints the 'reg' address preceded by the prefix 0x0x instead of 0x. This because the printf '%pa' format specifier already prepends the prefix '0x' to the address displayed. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
| * | pinctrl: single: fix offset managementDario Binacchi2021-04-121-10/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The pinmux configuration DT node of a peripheral does not define a physical address but an offset. Only by adding it to the base address of the controller it is possible to calculate the physical address of the register to be configured. Printing an offset also requires a different formatting option than a physical address. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
| * | pinctrl: single: fix the loop counter variable typeDario Binacchi2021-04-121-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 'n' variable is used as a loop counter, not as a physical address, and is used in a comparison with an int. So it makes sense to change its type from phys_addr_t to int. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org> Reviewed-by: Pratyush Yadav <p.yadav@ti.com>
| * | pinctrl: single: fix format of structure documentationDario Binacchi2021-04-121-9/+36
| | | | | | | | | | | | | | | | | | | | | U-Boot adopted the kernel-doc annotation style. Signed-off-by: Dario Binacchi <dariobin@libero.it> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | configs: omap35_logic_somlv: Fix MMC bootingAdam Ford2021-04-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A previous patch had removed the GPIO nodes from being built into the SPL Device tree, but CONFIG_SPL_GPIO_SUPPORT remained which makes the MMC card detect fail and the board does not boot. Fix this by disabling CONFIG_SPL_GPIO_SUPPORT. Fixes: 6f1efe81aa84 ("configs: omap3/35_logic and omap3/35_logic_somlv: Reduce SPL size") Signed-off-by: Adam Ford <aford173@gmail.com>
* | | Merge branch '2021-04-16-env-updates'Tom Rini2021-04-1810-70/+149
|\ \ \ | | | | | | | | | | | | | | | | | | | | - SPI Flash ENV improvements / cleanups - Redundant support for FAT - Assorted bugfixes
| * | | env: sf: remove the static env_flash variablePatrick Delaunay2021-04-161-23/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As the the SPI flash is probed and is released in each ENV sf function the env_flash no more need to be static. This patch move this device handle as local variable of each function and simplify the associated code (env_flash is never == NULL when setup_flash_device is called). Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
| * | | env: sf: add missing spi_flash_freePatrick Delaunay2021-04-161-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Free the SPI resources by calling spi_flash_free() in each env sf function to avoid issue for other SPI users. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
| * | | env: sf: add support of command env erasePatrick Delaunay2021-04-161-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support of opts erase for env in SPI flash; this opts is used by command 'env erase'. This command only fills the env offset by 0x0 (bit flip to 0) and the saved environment becomes invalid (with bad CRC). It doesn't erase the sector here to avoid issue when the sector is larger than the env (i.e. embedded when CONFIG_ENV_SECT_SIZE > CONFIG_ENV_SIZE). The needed sector erase will be managed in the next "env save" command, using the opt ".save", before to update the environment in SPI flash. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
| * | | env: sf: update the use of macro ENV_SAVE_PTRPatrick Delaunay2021-04-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove CONFIG_IS_ENABLED(SAVEENV) as it is already tested in the ENV_SAVE_PTR macro. Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
| * | | env: add ENV_ERASE_PTR macroPatrick Delaunay2021-04-163-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add ENV_ERASE_PTR macro to handle erase opts and remove the associated ifdef. This patch is a extension of previous commit 82b2f4135719 ("env_internal.h: add alternative ENV_SAVE_PTR macro"). Signed-off-by: Patrick Delaunay <patrick.delaunay@foss.st.com>
| * | | env: Fix invalid env handling in env_init()Marek Vasut2021-04-161-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes the case where there are multiple environment drivers, one of them is the default environment one, and it is followed by an environment driver which does not implement .init() callback. The default environment driver sets gd->env_valid to ENV_INVALID and returns 0 from its .init() callback implementation, which is valid behavior for default environment. Since the subsequent environment driver does not implement .init(), it also does not modify the $ret variable in the loop. Therefore, the loop is exited with gd->env_valid=ENV_INVALID and ret=0, which means that the code further down in env_init() will not reset the environment to the default one, which is incorrect. This patch sets the $ret variable back to -ENOENT in case the env_valid is set to ENV_INVALID by an environment driver, so that the environment would be correctly reset back to default one, unless a subsequent driver loads a valid environment. Signed-off-by: Marek Vasut <marex@denx.de> Tested-By: Tim Harvey <tharvey@gateworks.com>
| * | | env/fat.c: support redund environmentBrandon Maier2021-04-162-8/+40
| | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com> CC: Joe Hershberger <joe.hershberger@ni.com> CC: Wolfgang Denk <wd@denx.de>
| * | | env: Fix warning when forcing environment without ENV_ACCESS_IGNORE_FORCEMartin Fuzzey2021-04-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since commit 0f036bf4b87e ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set") a warning message is displayed when setenv -f is used WITHOUT CONFIG_ENV_ACCESS_IGNORE_FORCE, but the variable is set anyway, resulting in lots of log pollution. env_flags_validate() returns 0 if the access is accepted, or non zero if it is refused. So the original code #ifndef CONFIG_ENV_ACCESS_IGNORE_FORCE if (flag & H_FORCE) return 0; #endif was correct, it returns 0 (accepts the modification) if forced UNLESS IGNORE_FORCE is set (in which case access checks in the following code are applied). The broken patch just added a printf to the force accepted case. To obtain the intent of the patch we need this: if (flag & H_FORCE) { #ifdef CONFIG_ENV_ACCESS_IGNORE_FORCE printf("## Error: Can't force access to \"%s\"\n", name); #else return 0; #endif } Fixes: 0f036bf4b87e ("env: Warn on force access if ENV_ACCESS_IGNORE_FORCE set") Signed-off-by: Martin Fuzzey <martin.fuzzey@flowbird.group>
| * | | env: increment redund flag on read failBrandon Maier2021-04-163-22/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If one of the reads fails when importing redundant environments (a single read failure), the env_flags wouldn't get initialized in env_import_redund(). If a user then calls saveenv, the new environment will have the wrong flags value. So on the next load the new environment will be ignored. While debugging this, I also noticed that env/sf.c was not correctly handling a single read failure, as it would not check the crc before assigning it to gd->env_addr. Having a special error path for when there is a single read failure seems unnecessary and may lead to future bugs. Instead collapse the 'single read failure' error to be the same as a 'single crc failure'. That way env_check_redund() either passes or fails, and if it passes we are guaranteed to have checked the CRC. Signed-off-by: Brandon Maier <brandon.maier@rockwellcollins.com> CC: Joe Hershberger <joe.hershberger@ni.com> CC: Wolfgang Denk <wd@denx.de> CC: Heiko Schocher <hs@denx.de> Reviewed-by: Tom Rini <trini@konsulko.com>
| * | | env: add CONFIG_ENV_SECT_SIZE_AUTORasmus Villemoes2021-04-162-2/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is roughly the U-Boot side equivalent to commit e282c422e0 (tools: fw_env: use erasesize from MEMGETINFO ioctl). The motivation is the case where one has a board with several revisions, where the SPI flashes have different erase sizes. In our case, we have an 8K environment, and the flashes have erase sizes of 4K (newer boards) and 64K (older boards). Currently, we must set CONFIG_ENV_SECT_SIZE to 64K to make the code work on the older boards, but for the newer ones, that ends up wasting quite a bit of time reading/erasing/restoring the last 56K. At first, I wanted to allow setting CONFIG_ENV_SECT_SIZE to 0 to mean "use the erase size the chip reports", but that config option is used in a number of preprocessor conditionals, and shared between ENV_IS_IN_FLASH and ENV_IS_IN_SPI_FLASH. So instead, introduce a new boolean config option, which for now can only be used with ENV_IS_IN_SPI_FLASH. If left off, there's no change in behaviour. The only slightly annoying detail is that, when selected, the compiler is apparently not smart enough to see that the the saved_size and saved_offset variables are only used under the same "if (sect_size > CONFIG_ENV_SIZE)" condition as where they are computed, so we need to initialize them to 0 to avoid "may be used uninitialized" warnings. On our newer boards with the 4K erase size, saving the environment now takes 0.080 seconds instead of 0.53 seconds, which directly translates to that much faster boot time since our logic always causes the environment to be written during boot. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
| * | | env/sf.c: use a variable to hold the sector sizeRasmus Villemoes2021-04-161-10/+12
|/ / / | | | | | | | | | | | | | | | | | | As preparation for the next patch, use a local variable to represent the sector size. No functional change. Signed-off-by: Rasmus Villemoes <rasmus.villemoes@prevas.dk>
* | | Merge https://gitlab.denx.de/u-boot/custodians/u-boot-sunxiTom Rini2021-04-169-55/+215
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds support for devices with R40 dual rank DRAM, and asymmetric A64 DRAM devices like the Pinephone/3GB. Also we enable automatic gzipped kernel support, and allow scripted DT overlay support. The rest of the patches are cleanups, but also some sunxi-specific preparatory patches for USB3.0 and improved HDMI support. The bulk of those changes will go through other trees, though. Build-tested for all 156 sunxi boards, and boot tested on a A64, A20, R40, H5, H6 and H616 board. USB, SD card, eMMC, HDMI and Ethernet all work there (where applicable), with the exception of Ethernet on the H5. Since this is already broken in v2021.04, I will send a separate fix.
| * | sunxi: video: select dw-hdmi in Kconfig, not MakefileJernej Skrabec2021-04-162-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently sunxi Makefile manually specifies full path to dw-hdmi common code. However, that is not needed because it can be selected in Kconfig instead. Select proper symbol in Kconfig and drop path from Makefile. Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
| * | sunxi: arm64: Add addresses for compressed kernel loadArnaud Ferraris2021-04-161-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "booti" command to load arm64 Linux kernels supports automatic decompression of zipped kernel images, but relies on some environment variables to point to usable buffer RAM. Add those variables and let them point to some default values, that should cover most use-cases. Signed-off-by: Andre Przywara <andre.przywara@arm.com>
| * | sunxi: binman: Do not hardcode U-Boot load addressSamuel Holland2021-04-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The FIT description has access to the configuration variables. Use the appropriate variable instead of hardcoding the address. Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
| * | sunxi: binman: Respect the default FIT configurationSamuel Holland2021-04-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | binman can fill in the default FIT configuration index as selected by the "default-dt" argument, which is set to CONFIG_DEFAULT_DEVICE_TREE. Let's respect the user's configuration by taking advantage of this feature, instead of always defaulting to the first device tree in CONFIG_OF_LIST. Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
| * | clk: sunxi: h6: Add XHCI clocksSamuel Holland2021-04-161-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | The XHCI controller has its own clock and reset. Add them. Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
| * | clk: sunxi: Add a dummy clock driver for the RTCSamuel Holland2021-04-162-0/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The 32kHz clock ("LOSC") on sunxi SoCs is provided by the RTC. It is used, among other things, by the XHCI controller in the H6. To be able to call clk_get_bulk() on the XHCI controller, some device needs to provide all referenced clocks. Since LOSC is a fixed-rate always-on clock, implementation is trivial. Signed-off-by: Samuel Holland <samuel@sholland.org> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
| * | sunxi: enable dual rank memory on R40Icenowy Zheng2021-04-161-6/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we do not have proper dual rank memory detection on R40 (because we omitted PIR_QSGATE, which does not work on R40 with our configuration), and dual rank memory is just simply disabled as early R40 boards available (Banana Pi M2 Ultra and Berry) have single rank memory. As a board with dual rank memory (Forlinx OKA40i-C) is now known to us, we need to have a way to do memory rank detection to support that board. Add some routine to detect memory rank by trying to access the memory in rank 1 and check for error status of the memory controller, and then enable dual rank memory on R40. Similar routine can be used to detect half DQ width (which is also detected by PIR_QSGATE on other SoCs), but it's left unimplemented because there's no known R40 board with half DQ width now. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Andre Przywara <andre.przywara@arm.com> [Andre: Move R40 detect code call into sunxi_dram_init()] Signed-off-by: Andre Przywara <andre.przywara@arm.com>
| * | sunxi: support asymmetric dual rank DRAM on A64/R40Icenowy Zheng2021-04-162-23/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously we have known that R40 has a configuration register for its rank 1, which allows different configuration than rank 0. Reverse engineering of newest libdram of A64 from Allwinner shows that A64 has this register too. It's bit 0 (which enables dual rank in rank 0 configuration register) means a dedicated rank size setup is used for rank 1. Now, Pine64 scheduled to use a 3GiB LPDDR3 DRAM chip (which has 2GiB rank 0 and 1GiB rank 1) on PinePhone, that makes asymmetric dual rank DRAM support necessary. Add this support. The code could support both A64 and R40, but because dual rank detection is broken on R40 now, we cannot really use it on R40 currently. Signed-off-by: Icenowy Zheng <icenowy@aosc.io> Reviewed-by: Andre Przywara <andre.przywara@arm.com> Tested-by: Peter Robinson <pbrobinson@gmail.com> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
| * | sunxi: add fdtoverlay_addr_r environment variableJernej Skrabec2021-04-161-23/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 69076dff2284 ("cmd: pxe: add support for FDT overlays") added support for loading DT overlay files to PXE boot. However, it needs additional environment variable which points to memory location which can be used to temporary store overlay data. Add it and in the process unify alignment using spaces and fix comment. Reviewed-by: Andre Przywara <andre.przywara@arm.com> Signed-off-by: Jernej Skrabec <jernej.skrabec@siol.net> Signed-off-by: Andre Przywara <andre.przywara@arm.com>
* | | Merge branch '2021-04-14-assorted-vboot-improvements'Tom Rini2021-04-1531-266/+955
|\ \ \ | |/ / |/| | | | | | | | | | | - Add ECDSA support to FIT images - Improve FIT image loadables (incl fpga) support - Further FIT improvements with SPL
| * | lib/rsa: Use EVP_PKEY instead of RSAChan, Donald2021-04-141-102/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Most modern OpenSSL engines have methods overridden at the EVP level rather than at RSA level, to make these engines work properly with mkimage, the RSA signing code needs to switch to using EVP_* APIs as much as possible. Signed-off-by: Donald Chan <hoiho@lab126.com> [trini: Rebase on top of keyfile changes] Signed-off-by: Tom Rini <trini@konsulko.com>
| * | image-fit: Accept OP-TEE images when booting a FITAlexandru Gagniuc2021-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | OP-TEE images are normally packaged with type = "tee; os = "tee"; However, fit_image_load() thinks that is somehow invalid. However if they were declared as type = "kernel", os = "linux", fit_image_load() would happily accept them and allow the boot to continue. There is no technical limitation to excluding "tee". Allowing "tee" images is useful in a boot flow where OP-TEE is executed before linux. In fact, I think it's unintuitive for a "load"ing function to also do parsing and contain a bunch ad-hoc heuristics that only its caller might know. But I don't make the rules, I just write fixes. In more polite terms: refactoring the fit_image API is beyond the scope of this change. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | image-fit: Accept IH_TYPE_FIRMWARE in fit_image_load() as validAlexandru Gagniuc2021-04-141-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Consider the following FIT: images { whipple {}; }; configurations { conf-1 { firmware = "whipple"; }; }; Getting the 'firmware' image with fit_image_load() is not possible, as it doesn't understand 'firmware =' properties. Although one could pass IH_TYPE_FIRMWARE for 'image_type', this needs to be converted to a "firmware" string for FDT lookup -- exactly what this change does. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | spl: LOAD_FIT_FULL: Support 'kernel' and 'firmware' propertiesAlexandru Gagniuc2021-04-141-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | The 'firmware' property of a config node takes precedence over the 'kernel' property. 'standalone' is deprecated. However, give users a couple of releases where 'standalone' still works, but warns loudly. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
| * | spl: LOAD_FIT_FULL: Relocate FDT for u-boot payloadsAlexandru Gagniuc2021-04-141-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | U-Boot expects the FDT to be located right after the _end linker symbol (see fdtdec.c: board_fdt_blob_setup()) The "basic" LOAD_FIT path is aware of this limitation, and relocates the FDT at the expected location. Guessing the expected location probably only works reliably on 32-bit arm, and it feels like a hack. One proposal would be to pass the FDT address to u-boot (e.g. using 'r2' on arm platforms). The variable is named "fdt_hack" to remind future contributors that, "hey! we should fix the underlying problem". However, that is beyond the scope of this patch. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
| * | spl: LOAD_FIT_FULL: Do not hard-code os to IH_OS_U_BOOTAlexandru Gagniuc2021-04-141-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The information on the OS should be contained in the FIT, as the self-explanatory "os" property of a node under /images. Hard-coding this to U_BOOT might send us down the wrong path later in the boot process. Reviewed-by: Simon Glass <sjg@chromium.org> Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
| * | spl: LOAD_FIT_FULL: Fix selection of the "fdt" nodeAlexandru Gagniuc2021-04-141-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The correct FDT to use is described by the "fdt" property of the configuration node. When the fit_unamep argument to fit_image_load() is "fdt", we get the "/images/fdt" node. This is incorrect, as it ignores the "fdt" property of the config node, and in most cases, the "/images/fdt" node doesn't exist. Use NULL for the 'fit_unamep' argument. With NULL, fit_image_load() uses the IH_TYPE_FLATDT value to read the config property "fdt", which points to the correct FDT node(s). fit_image_load() should probably be split into a function that reads an image by name, and one that reads an image by config reference. I don't make those decisions, I just point out the craziness. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | common: fit: Add weak board_fit_config_name_matchSean Anderson2021-04-143-19/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Several architectures had a default board_fit_config_name_match already; this provides a generic weak version. We default to rejecting all configs. This will use the FIT's default config, instead of the first config. This may result in boot failures if there are multiple configurations and the first config is *not* the default. Signed-off-by: Sean Anderson <sean.anderson@seco.com>
| * | doc: FIT image: Update FPGA example to make use of "loadables"Alexandru Gagniuc2021-04-141-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new correct way to load an FPGA image is to declare it in the list of "loadables". multi-with-fpga.its used the now deprecated "fpga" property. Since this example most likely intended to use u-boot's generic FPGA loading code, compatible = "u-boot,fpga-legacy" is also appropriate here. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | Kconfig: Document the limitations of the simple SPL_LOAD_FIT pathAlexandru Gagniuc2021-04-141-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "simple" SPL_LOAD_FIT path is the most compliant with the format documented in doc/uImage.FIT/source_file_format.txt. The other two paths to load a FIT are SPL_LOAD_FIT_FULL and the "bootm" command. Since the Kconfig menu is the most likely place for a new user to see these options, it seems like the most logical candidate to document the limitations. This documents the _known_ issues, and is not intended to be a complete list of all follies. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
| * | spl: fit: Support loading FPGA images from list of "loadables"Alexandru Gagniuc2021-04-141-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4afc4f37c70e ("doc: FIT image: Clarify format and simplify syntax") and delegated FPGA images to be added via the list of "loadables" in lieu of the "fpga" property. Now actually implement this in code. Note that the "compatible" property is ignored for the time being, as implementing "compatible" loading is beyond the scope of this change. However, "u-boot,fpga-legacy" is accepted without warning. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
| * | spl: fit: Warn if FIT contains "fpga" property in config nodeAlexandru Gagniuc2021-04-141-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit 4afc4f37c70e ("doc: FIT image: Clarify format and simplify syntax") requires that FPGA images be referenced through the "loadables" in the config node. This means that "fpga" properties in config nodes are deprecated. Given that there are likely FIT images which use "fpga", let's not break those right away. Print a warning message that such use is deprecated, and give users a couple of releases to update their Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
| * | spl: fit: Move FPGA loading code to separate functionsAlexandru Gagniuc2021-04-141-25/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | The FPGA loading code in spl_simple_fit_read() can easily be separated from the rest of the logic. It is split into two functions instead of one because spl_fit_upload_fpga() is used in a subsequent patch. Signed-off-by: Alexandru Gagniuc <mr.nuke.me@gmail.com> Reviewed-by: Simon Glass <sjg@chromium.org>
generated by cgit (git 2.34.1) at 2025-09-29 05:42:14 +0000