summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2024-06-18ARM: dts: stm32: Make PWR regulator driver available on STM32MP13xxMarek Vasut
This patch makes STM32 PWR regulators available on stm32mp13xx. This requires TFA to clear RCC_SECCFGR, is disabled by default on stm32mp13xx and can only be enabled on board config level. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Patrice Chotard <[email protected]>
2024-06-18ARM: dts: stm32: add PWR regulators support on stm32mp131Marek Vasut
This patch adds STM32 PWR regulators DT support on stm32mp131. This requires TFA to clear RCC_SECCFGR, is disabled by default and can only be enabled on board DT level. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Patrice Chotard <[email protected]>
2024-06-18net: dwc_eth_qos: add support for phy-reset-gpios propertyHeesub Shin
This commit adds support for a property 'phy-reset-gpios' to reset PHY chipset. Signed-off-by: Heesub Shin <[email protected]> Reviewed-by: Patrice Chotard <[email protected]>
2024-06-18stm32mp: Reserve OPTEE area in EFI memory mapPatrice Chotard
Since commit 7b78d6438a2b3 ("efi_loader: Reserve unaccessible memory") memory region above ram_top is tagged in EFI memory map as EFI_BOOT_SERVICES_DATA. In case of STM32MP1/STM32MP13 platforms, above ram_top, there is one reserved-memory region tagged "no-map" dedicated to OP-TEE : _ addr=de000000 size=2000000 for stm32mp157x-dkx and stm32mp135f-dk _ addr=fe000000 size=2000000 for stm32mp157c-ev1 Before booting kernel, EFI memory map is first built, the OPTEE region is tagged as EFI_BOOT_SERVICES_DATA and when reserving LMB, the tag LMB_NONE is used. Then after, the LMB are completed by boot_fdt_add_mem_rsv_regions() which try to add again the same OPTEE region (addr=de000000 size=2000000 in case of stm32mp157x-dkx / stm32mp135f-dk or addr=fe000000 size=2000000 in case for stm2mp157c-ev1) but now with LMB_NOMAP tag which produces the following error message : _ for stm32mp157x-dkx / stm32mp135f-dk : "ERROR: reserving fdt memory region failed (addr=de000000 size=2000000 flags=4)" _ for stm32mp157c-ev1 : "ERROR: reserving fdt memory region failed (addr=fe000000 size=2000000 flags=4)" To avoid this, OPTEE area shouldn't be used by EFI, so we need to mark it as reserved. Signed-off-by: Patrice Chotard <[email protected]> Reviewed-by: Patrick Delaunay <[email protected]>
2024-06-17Merge tag 'xilinx-for-v2024.10-rc1' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-microblaze into next AMD/Xilinx changes for v2024.10-rc1 common: - spl: Introduce SoC specific init function xilinx: - Enable FF-A and NVMEM - Rename spl_board_init() to spl_soc_init() zynqmp: - DT alignments - Enable reset from SPL - Enable USB3 for KD240 - Align multiboot register on Kria for proper reboot - Allow multiboot environment write even in saved environment - Move zynqmp commands from board/ to arch/ - Clean up xilinx_zynqmp.h versal: - Do not prioritize boot device if driver is not enabled versal-net: - Setup location for redundant variables in SPI versal2: - Add support for new SOC mmc: - Fix tap delay for SD on Versal NET spi: - Add SPI_NOR_OCTAL_READ flag for mx66uw2g345gx0 flash part gpio: - Cover MODEPIN firmware dependency
2024-06-17Merge tag 'u-boot-nand-20240617' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-nand-flash Pull request for u-boot-nand-20240617 The first patch is by Arseniy Krasnov and adds support for OTP area access on MX30LFxG18AC chip series. The second patch is by John Watts and adds MTD dependency in Kconfig for UBI. The last patch is by Ravi Minnikanti and fixes bitflip return value on page read.
2024-06-17Merge tag 'u-boot-stm32-20240617' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-stm STM32MP1: - Ping IWDG on exit from PSCI suspend code
2024-06-17xilinx: Enable FF-A for all our arm64 SoCsMichal Simek
Enable FFA_TRANSPORT which also enable FFA command. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/5a850b1558fad0f05c61de82110abe4c0e7fd2e4.1718104009.git.michal.simek@amd.com
2024-06-17xilinx: versal-net: Add env redund offsetVenkatesh Yadav Abbarapu
ENV_OFFSET_REDUND config is by default set to 0 for flashes. Saving the env variables is overwriting data at 0 offset, which is wrong. So add default redund env offset ENV_OFFSET_REDUND at 0x7F00000 for Versal NET platform. Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2024-06-17gpio: Add proper dependency on ZYNQMP_FIRMWAREMichal Simek
ZYNQMP_FIRMWARE can be disabled and driver depends on it that's why record this dependency via Kconfig. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/c3ca38fbb2f4e6948a5ef95b369015de96259709.1717685091.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Align #address/size-cells with nodeMichal Simek
zynqmp-mini-nand wasn't aligned with dt binding that's why fix it. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/3916fde2e896b8be8863505305118903e0644ab0.1717684544.git.michal.simek@amd.com
2024-06-17xilinx: zynqmp: Enable reset_cpu() in SPLLukas Funke
This commit enables SPL to reset the CPU via PMU-firmware. The usual reset mechanism requires bl31 to be loaded which may not be the case in SPL. Signed-off-by: Lukas Funke <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2024-06-17arm64: zynqmp: Enable usb3 for k24 somNeal Frager
This patch corrects the mio and pll configuration registers for using usb3 on the kd240 starter kit. Without this patch, the usb3 to sd card bridge does not initialize correctly and u-boot is unable to find the OS located on the kd240 starter kit sd card. In addition, this patch correctly configures mio76 and mio77 as gpio pins which are used as reset gpio pins on the kd240 starter kit. Signed-off-by: Neal Frager <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2024-06-17arm64: zynqmp: Setup multiboot register to 0Michal Simek
On Kria when board starts from Image A or Image B partition multiboot register is already setup to that location. When reset command is called board is issuing soft reset which start SW at already used location (offset of multiboot * 32k). But board should continue to run from multiboot offset 0 (start of QSPI) and call early bootloader every reboot that's why clear multiboot register to 0 by default to go that route all the time. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/edaf714a778bdd7447533a77b3455e4fd623f9da.1717420131.git.michal.simek@amd.com
2024-06-17spi: versal2: Enable spi drivers for Versal Gen 2Michal Simek
Enable and update OSPI/QSPI/GQSPI drivers to support Versal Gen 2 SoCs. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/691782470f56f7d49a3204f6757296f2752d4156.1716994063.git.michal.simek@amd.com
2024-06-17mmc: versal2: Update zynq_sdhci driver to support AMD Versal Gen 2Michal Simek
Enable tap delay programming for new SoC and also enable it via defconfig. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/f07daded9704cbc393657b65a28933c34a8cec25.1716994063.git.michal.simek@amd.com
2024-06-17soc: versal2: Add SoC driver for AMD Versal Gen 2Michal Simek
Communication is happening via firmware interface (SMC) or via direct register reading if firmware driver is not available. Also enable it via defconfig. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/22cf9c765e47ab03dbf2b8363e6626e809113432.1716994063.git.michal.simek@amd.com
2024-06-17arm64: versal2: Add support for AMD Versal Gen 2Michal Simek
Add support for AMD Versal Gen 2. SoC is based on Cortex-a78ae 4 cluster/2 cpu core each. A lot of IPs are shared with previous families. There are couple of new IP blocks where the most interesting from user point of view is UFS. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/bc2b70831ce1031bd0fac32357bff84936e1310f.1716994063.git.michal.simek@amd.com
2024-06-17arm64: zynqmp: Update rproc nodeMichal Simek
remoteproc node should be updated to be aligned with the latest dt-schema. Reviewed-by: Tanmay Shah <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/d8247a46f486a612f85767de9b832ad33fa980fe.1717065556.git.michal.simek@amd.com
2024-06-17xilinx: versal: Do not prioritize boot device if driver is not enabledVenkatesh Yadav Abbarapu
SOC can boot out of the device which is not accessible from APU and running this is detected as a warning, as the device is not accessible.For example getting below warning when the boot mode is OSPI and OSPI is not enabled in device tree. Invalid bus 0 (err=-19) Failed to initialize SPI flash at 0:0 (error -19) Ignoring the prioritization of the boot device which driver is not enabled and continue with the default boot_targets. Recommendation is to use custom boot_targets via environment file as is done for example for Kria via zynqmp_kria.env file. Signed-off-by: Venkatesh Yadav Abbarapu <[email protected]> Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/8b7cca5c7b84cb4854104e0c48f8aa63c4ec5ace.1715322156.git.michal.simek@amd.com
2024-06-17mtd: spi-nor: Add SPI_NOR_OCTAL_READ flag for mx66uw2g345gx0 flash partPrasad Kummari
Added SPI_NOR_OCTAL_READ flag for Macronix mx66uw2g345gx0 2Gb(256MB) NOR Flash memory. Initial testing was conducted on the Versal NET board using SDR mode, which included basic erase, write, and read-back operations. Signed-off-by: Prasad Kummari <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2024-06-17arm64: zynq(mp): Rename spl_board_init() to spl_soc_init()Lukas Funke
Rename spl_board_init() to spl_soc_init(). SoC specific implementation should be separated from board specific implementation in order to be extended by board developers. Signed-off-by: Lukas Funke <[email protected]> Acked-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2024-06-17spl: Introduce SoC specific init functionLukas Funke
Some architectures use spl_board_init() in their SoC specific implementation. Board developers should be able to add board specific implementation via spl_board_init(). Hence, introduce a spl_soc_init() method which is called right before spl_board_init() for SoC specific implementation. Signed-off-by: Lukas Funke <[email protected]> Reviewed-by: Devarsh Thakkar <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2024-06-17xilinx: zynqmp: Allow multiboot environment write even in saved environmentKory Maincent
Once the environment was saved, the current multiboot image information became unreachable. When dealing with firmware updates, this information is necessary alongside the saved environment to know the booted image. Move the multiboot environment set operation before the saved environment check to ensure this information is always available. Signed-off-by: Kory Maincent <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2024-06-17sdhci: zynq: Fix tap delay for SD on Versal NETSimek, Michal
I can't see any way how tap delays are setup on Versal NET platform because xlnx,versal-8.9a compatible string is also used there but driver is not letting to setup tap delays. Not sure if versal_iclk_phases[] is also valid for Versal NET but the patch is made to investigate it. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/e535cfc1a59b5146a5c9a3ab389dc770de80440c.1713427490.git.michal.simek@amd.com
2024-06-17board: zynqmp: Move zynqmp commands from board/ to arch/Charlie Johnston
The zynqmp cmds.c is currently tied to the board but the commands contained within are more closely tied to the architecture. To allow usage of those commands when the architecture is ZynqMP but the board is not, this change moves the cmds into the arch/ tree. The source file is renamed to zynqmp.c to reflect the command name as well. Signed-off-by: Charlie Johnston <[email protected]> Link: https://lore.kernel.org/r/[email protected] Signed-off-by: Michal Simek <[email protected]>
2024-06-17xilinx: Enable NVMEM framework for all platformsMichal Simek
Boards which have for example MAC address in eeprom but not in Xilinx format (legacy or FRU) could reference it via nvmem cells. For example: &gem0 { nvmem-cells = <&mac>; nvmem-cell-names = "mac-address"; }; &eeprom { #address-cells = <1>; #size-cells = <1>; mac: mac-address@f0 { reg = <0xf0 6>; }; }; For getting it work above DT changes are required but also CONFIG_NVMEM should be enabled. That's why enable it by default in generic defconfigs to be able to use it directly by changing DT only. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/9c8ee7a4c7a16367438a92a4c9581bac9d968f84.1712815454.git.michal.simek@amd.com
2024-06-17xilinx: zynqmp: Clean up xilinx_zynqmp.hMichal Simek
Options are moving to Kconfig by running sed and comments are staying in that's why do clean up and remove useless comments. Signed-off-by: Michal Simek <[email protected]> Link: https://lore.kernel.org/r/fa117ac482591d3d5957af54fe99e6acc89972e3.1713167731.git.michal.simek@amd.com
2024-06-17ARM: dts: stm32: Ping IWDG on exit from PSCI suspend codeMarek Vasut
Make sure the OS would not get any spurious IWDG pretimeout IRQ right after the system wakes up. This may happen in case the SoC got woken up by another source than the IWDG pretimeout and the pretimeout IRQ arrived immediately afterward, but too late to be handled by the suspend main loop. In case either of the IWDG is enabled, ping it first and then return to the OS. Signed-off-by: Marek Vasut <[email protected]> Reviewed-by: Patrice Chotard <[email protected]> Reviewed-by: Igor Opaniuk <[email protected]>
2024-06-17mtd: nand: pxa3xx: Incorrect bitflip return on page readRavi Minnikanti
Once a page is read with higher bitflips all subsequent reads are returning the same bitflip value even though they have none. max_bitflip variable is not being reset to 0 across page reads. This is causing problems like incorrectly marking erase blocks bad by UBI and causing read failures. Verified the change with both MTD reads and UBI. This change is inline with other NFC drivers. Sample error log where a block is marked bad incorrectly: ubi0: fixable bit-flip detected at PEB 125 ubi0: run torture test for PEB 125 ubi0: fixable bit-flip detected at PEB 125 ubi0 error: torture_peb: read problems on freshly erased PEB 125, must be bad ubi0 error: erase_worker: failed to erase PEB 125, error -5 ubi0: mark PEB 125 as bad Link: https://lore.kernel.org/all/[email protected] Signed-off-by: rminnikanti <[email protected]> Reviewed-by: Chris Packham <[email protected]> Signed-off-by: rminnikanti <[email protected]> Acked-by: Michael Trimarchi <[email protected]> Signed-off-by: Dario Binacchi <[email protected]>
2024-06-17ubi: Depend on MTDJohn Watts
UBI required MTD to build correctly, add it as a Kconfig dependency. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: John Watts <[email protected]> Reviewed-by: Michael Trimarchi <[email protected]> Reviewed-by: Heiko Schocher <[email protected]> Signed-off-by: Dario Binacchi <[email protected]>
2024-06-17mtd: rawnand: macronix: OTP access for MX30LFxG18ACArseniy Krasnov
Support for OTP area access on MX30LFxG18AC chip series. Link: https://lore.kernel.org/all/[email protected] Signed-off-by: Arseniy Krasnov <[email protected]> Signed-off-by: Dario Binacchi <[email protected]>
2024-06-16Merge tag 'efi-2024-07-rc5-2' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-efi Pull request efi-2024-07-rc5-2 Documentation: * Correct links and board names in PHYTEC board descriptions. * Describe UEFI measured boot. * Fix typos in include/bootmeth.h. * Fix link reference to general verified boot docs. UEFI: * Measure device-tree into PCR1 instead of PCR0
2024-06-16Merge branch 'next' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-watchdog into next - misc cyclic infrastructure improvements (Rasmus) - watchdog_reset cleanup (Rasmus) CI: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=369&view=results
2024-06-16Merge tag 'u-boot-rockchip-next-20240615' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-rockchip into next CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/21113 - New board: Theobroma Systems SOM-RK3588-Q7 Tiger, ArmSoM Sige7 Rk3588; - PX30 dts migrate to OF_UPSTREAM; - Some other update on board or config;
2024-06-16Merge tag 'u-boot-rockchip-20240614' of ↵Tom Rini
https://source.denx.de/u-boot/custodians/u-boot-rockchip CI: https://source.denx.de/u-boot/custodians/u-boot-rockchip/-/pipelines/21111 - pmic fix for rk8xx; - pinctrl fix for rk3188/rv1126/rk3588; - mkimage fix for rockcihp "-l" option;
2024-06-16powerpc: mpc85xx: remove dead watchdog-related codeRasmus Villemoes
Nothing in-tree calls watchdog_reset() anymore (that stopped two years ago with the removal of the WATCHDOG_RESET macro). So that function is dead code. That was the only caller of reset_85xx_watchdog(), so that can obviously also be removed. Finally, init_85xx_watchdog() is/was also not called from anywhere, so that can go away as well, which nicely also removes a bit of arch-specific code from the generic watchdog.h header. Cc: Christophe Leroy <[email protected]> Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-06-16powerpc: mpc83xx: remove unused watchdog_reset() functionRasmus Villemoes
There is no longer any code in tree that calls a watchdog_reset() function. The macro WATCHDOG_RESET, which used to emit a call to watchdog_reset(), got removed two years ago. Cc: Christophe Leroy <[email protected]> Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-06-16sh4: remove watchdog.c fileRasmus Villemoes
The external functions defined here are not called from anywhere. So they, and consequently the whole file, can be dropped. Cc: Nobuhiro Iwamatsu <[email protected]> Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-06-16sh4: move reset_cpu() from watchdog.c to cpu.cRasmus Villemoes
The next patch will remove all the other code from watchdog.c, which would leave just this function in there. It seems just as natural for this function to be defined in cpu.c, allowing us to delete watchdog.c completely. Cc: Nobuhiro Iwamatsu <[email protected]> Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-06-16serial: ns16550: fix comment to mention schedule instead of watchdog_resetRasmus Villemoes
watchdog_reset() is no more. Make the comments match the code and today's reality. Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-06-16wdt-uclass: watchdog_reset cleanupRasmus Villemoes
watchdog_reset() is no longer called from anywhere, so we do not need to define a dummy no-op function. Remove that definition, and update references to say schedule() instead. Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-06-16m68k: remove dead codeRasmus Villemoes
There are no calls of "watchdog_reset()" anymore anywhere in the tree since the WATCHDOG_RESET macro got removed in 942d07df0e79 ("watchdog: Remove WATCHDOG_RESET macro"). The only places the identifiers watchdog_disable and watchdog_init are called are in arch/arm/mach-omap2/, so those can obviously not refer to these instances. Hence these functions are not actually used at all and can be removed. As a bonus, this also removes two leftover references to WATCHDOG_RESET. Cc: Huan Wang <[email protected]> Cc: Angelo Dureghello <[email protected]> Signed-off-by: Rasmus Villemoes <[email protected]> Reviewed-by: Stefan Roese <[email protected]>
2024-06-16cyclic: make clients embed a struct cyclic_info in their own data structureRasmus Villemoes
There are of course not a whole lot of examples in-tree yet, but before they appear, let's make this API change: Instead of separately allocating a 'struct cyclic_info', make the users embed such an instance in their own structure, and make the convention that the callback simply receives the 'struct cyclic_info *', from which the clients can get their own data using the container_of() macro. This has a number of advantages. First, it means cyclic_register() simply cannot fail, simplifying the code. The necessary storage will simply be allocated automatically when the client's own structure is allocated (often via uclass_priv_auto or similar). Second, code for which CONFIG_CYCLIC is just an option can more easily be written without #ifdefs, if we just provide an empty struct cyclic_info {}. For example, the nested CONFIG_IS_ENABLED()s in https://lore.kernel.org/u-boot/[email protected]/ are mostly due to the existence of the 'struct cyclic_info *' member being guarded by #ifdef CONFIG_CYCLIC. And we do probably want to avoid the extra memory overhead of that member when !CONFIG_CYCLIC. But that is automatic if, instead of a 'struct cyclic_info *', one simply embeds a 'struct cyclic_info', which will have size 0 when !CONFIG_CYCLIC. Also, the no-op cyclic_register() function can just unconditionally be called, and the compiler will see that (1) the callback is referenced, so not emit a warning for a maybe-unused function and (2) see that it can actually never be reached, so not emit any code for it. Reviewed-by: Stefan Roese <[email protected]> Signed-off-by: Rasmus Villemoes <[email protected]>
2024-06-16wdt-uclass: prevent multiple cyclic_register callsRasmus Villemoes
Currently, the cyclic_register() done in wdt_start() is not undone in wdt_stop(). Moreover, calling wdt_start multiple times (which is perfectly allowed on an already started device, e.g. to change the timeout value) will result in another struct cyclic_info being registered, referring to the same watchdog device. This can easily be seen on e.g. a wandboard: => cyclic list function: watchdog@20bc000, cpu-time: 22 us, frequency: 1.01 times/s => wdt list watchdog@20bc000 (imx_wdt) => wdt dev watchdog@20bc000 => wdt start 50000 WDT: Started watchdog@20bc000 with servicing every 1000ms (50s timeout) => cyclic list function: watchdog@20bc000, cpu-time: 37 us, frequency: 1.03 times/s function: watchdog@20bc000, cpu-time: 241 us, frequency: 1.01 times/s => wdt start 12345 WDT: Started watchdog@20bc000 with servicing every 1000ms (12s timeout) => cyclic list function: watchdog@20bc000, cpu-time: 36 us, frequency: 1.03 times/s function: watchdog@20bc000, cpu-time: 100 us, frequency: 1.04 times/s function: watchdog@20bc000, cpu-time: 299 us, frequency: 1.00 times/s So properly unregister the watchdog device from the cyclic framework in wdt_stop(). In wdt_start(), we cannot just skip the registration, as the (new) timeout value may mean that we have to ask the cyclic framework to call us more often. So if we're already running, first unregister the old cyclic instance. Reviewed-by: Stefan Roese <[email protected]> Signed-off-by: Rasmus Villemoes <[email protected]>
2024-06-16cyclic: stop strdup'ing name in cyclic_register()Rasmus Villemoes
We are not checking the return value of strdup(), nor freeing the string in cyclic_unregister(). However, all current users either pass a string literal or the dev->name of the client device. So in all cases the name string will live at least as long as the cyclic_info is registered, so just make that a requirement. Reviewed-by: Stefan Roese <[email protected]> Signed-off-by: Rasmus Villemoes <[email protected]>
2024-06-16doc: Fix link reference to general verified boot docsAlexander Dahl
Fixes: ad29e08b79fd ("doc: Bring in FIT signature files") Signed-off-by: Alexander Dahl <[email protected]> Reviewed-by: Simon Glass <[email protected]>
2024-06-16doc: describe UEFI measured bootIlias Apalodimas
We currently only describe the process to enable measured boot using bootm. Describe the UEFI requirements as well which predate bootm. Signed-off-by: Ilias Apalodimas <[email protected]> Reviewed-by: Heinrich Schuchardt <[email protected]>
2024-06-16tpm: measure DTB in PCR1 instead of PCR0Ilias Apalodimas
The PC client spec [0], doesn't describe measurements for DTBs. It does describe what do to for ACPI tables though. There is a description for ACPI in 3.3.4.1 PCR[0] – SRTM, POST BIOS, and Embedded Drivers and they explicitly mention ACPI in there. There's no mention of ACPI in 3.3.4.2 PCR[1] – Host Platform Configuration. However, in Figure 6 -- PCR Mapping of UEFI Components ACPI is shown in PCR1. The general description also mentions PCR0 is for code and PCR1 is for data such as ACPI and SMBIOS. So let's switch over the DTB measurements to PCR1 which seems a better fit. [0] https://trustedcomputinggroup.org/resource/pc-client-specific-platform-firmware-profile-specification Reported-by: Heinrich Schuchardt <[email protected]> Signed-off-by: Ilias Apalodimas <[email protected]> Reviewed-by: Eddie James <[email protected]>
2024-06-16doc: board: phytec: phycore-am64: Fix phyBOARD NameDaniel Schultz
The Carrier-Board for the pyhCORE-AM64x is called phyBOARD-Electra. Signed-off-by: Daniel Schultz <[email protected]>