- Nov 02, 2022
-
-
It was noticed that while converting CONFIG_SPL_PAD_TO to Kconfig its value for the MIPS MT762x/8x targets got not ported correctly. Its default is not 0x10000 instead of 0x0. This patch fixes this issue. Fixes: ca8a329a ("Convert CONFIG_SPL_PAD_TO et al to Kconfig") Signed-off-by:
Stefan Roese <sr@denx.de> Cc: Ruben Winters <Ruben.Winters@gooiland-elektro.nl> Cc: Weijie Gao <weijie.gao@mediatek.com> Cc: Daniel Schwierzeck <daniel.schwierzeck@gmail.com> Cc: Tom Rini <trini@konsulko.com>
-
Daniel Schwierzeck authoredThis converts the following to Kconfig: CONFIG_SYS_MIPS_TIMER_REQ Signed-off-by:
Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: -
Daniel Schwierzeck authored
CPU_CLOCK_RATE is just used once for CONFIG_SYS_MIPS_TIMER_FREQ which is migrated to Kconfig in the next patch. Signed-off-by:
Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: -
Daniel Schwierzeck authored
Resolve all uses of CONFIG_SYS_MHZ with the currently defined value. Remove code which depends on CONFIG_SYS_MHZ but where no board configs actually use that code. Signed-off-by:
Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: -
Daniel Schwierzeck authored
This board has been removed a long time ago. Signed-off-by:
Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
Reviewed-by: -
https://source.denx.de/u-boot/custodians/u-boot-watchdogTom Rini authored
- cyclic: get rid of (the need for) cyclic_init() (Rasmus)
-
https://source.denx.de/u-boot/custodians/u-boot-spi.gitTom Rini authored
- NPCM PSPI controller (Jim)
-
Currently, we must call cyclic_init() at some point before cyclic_register() becomes possible. That turns out to be somewhat awkward, especially with SPL, and has resulted in a watchdog callback not being registered, thus causing the board to prematurely reset. We already rely on gd->cyclic reliably being set to NULL by the asm code that clears all of gd. Now that the cyclic list is a hlist, and thus an empty list is represented by a NULL head pointer, and struct cyclic_drv has no other members, we can just as well drop a level of indirection and put the hlist_head directly in struct global_data. This doesn't increase the size of struct global_data, gets rid of an early malloc(), and generates slightly smaller code. But primarily, this avoids having to call cyclic_init() early; the cyclic infrastructure is simply ready to register callbacks as soon as we enter C code. We can still end up with schedule() being called from asm very early, so we still need to check that gd itself has been properly initialized [*], but once it has, gd->cyclic_list is perfectly fine to access, and will just be an empty list. As for cyclic_uninit(), it was never really the opposite of cyclic_init() since it didn't free the struct cyclic_drv nor set gd->cyclic to NULL. Rename it to cyclic_unregister_all() and use that in test/, and also insert a call at the end of the board_init_f sequence so that gd->cyclic_list is a fresh empty list before we enter board_init_r(). A small piece of ugliness is that I had to add a cast in cyclic_get_list() to silence a "discards 'volatile' qualifier" warning, but that is completely equivalent to the existing handling of the uclass_root_s list_head member. [*] I'm not really sure where we guarantee that the register used for gd contains 0 until it gets explicitly initialized, but that must be the case, otherwise testing gd for being NULL would not make much sense. Signed-off-by:
Rasmus Villemoes <rasmus.villemoes@prevas.dk> Reviewed-by:
-
A hlist is headed by just a single pointer, so can only be traversed forwards, and insertions can only happen at the head (or before/after an existing list member). But each list node still consists of two pointers, so arbitrary elements can still be removed in O(1). This is precisely what we need for the cyclic_list - we never need to traverse it backwards, and the order the callbacks appear in the list should really not matter. One advantage, and the main reason for doing this switch, is that an empty list is represented by a NULL head pointer, so unlike a list_head, it does not need separate C code to initialize - a memset(,0,) of the containing structure is sufficient. This is mostly mechanical: - The iterators are updated with an h prefix, and the type of the temporary variable changed to struct hlist_node*. - Adding/removing is now just hlist_add_head (and not tail) and hlist_del(). - struct members and function return values updated. Signed-off-by:
-
All the way back in 2013, the linux kernel updated the four hlist_for_each_entry* iterators to require one less auxiliary variable: commit b67bfe0d42cac56c512dd5da4b1b347a23f4b70a Author: Sasha Levin <sasha.levin@oracle.com> Date: Wed Feb 27 17:06:00 2013 -0800 hlist: drop the node parameter from iterators Currently, there is only one "user" of any of these, namely in fs/ubifs/super.c, but that actually uses the "new-style" form, and is (obviously, or it wouldn't have built) inside #ifndef __UBOOT__. Before adding actual users of these, import the version as of linux v6.1-rc1, including the hlist_entry_safe() helper used by the new versions. Signed-off-by: -
We're already relying on gd->cyclic being NULL before cyclic_init() is called - i.e., we're relying on all of gd being zeroed before entering any C code. And when we do populate gd->cyclic, its ->cyclic_ready member is automatically set to true. So we can actually just rely on testing gd->cyclic itself. The only wrinkle is that cyclic_uninit() actually did set ->cyclic_ready to false. However, since it doesn't free gd->cyclic, the cyclic infrastructure is actually still ready (i.e., the list_head is properly initialized as an empty list). Signed-off-by:
-
As a preparation for future patches, use a flag in gd->flags rather than a separate member in (the singleton) struct cyclic_drv to keep track of whether we're already inside cyclic_run(). Signed-off-by:
-
- Nov 01, 2022
-
-
Tom Rini authored
To quote the author: The patchset adds support for the FWU Multi Bank Update[1] feature. Certain aspects of the Dependable Boot[2] specification have also been implemented. The FWU multi bank update feature is used for supporting multiple sets(also called banks) of firmware image(s), allowing the platform to boot from a different bank, in case it fails to boot from the active bank. This functionality is supported by keeping the relevant information in a structure called metadata, which provides information on the images. Among other parameters, the metadata structure contains information on the currect active bank that is being used to boot image(s). Functionality is being added to work with the UEFI capsule driver in u-boot. The metadata is read to gather information on the update bank, which is the bank to which the firmware images would be flashed to. On a successful completion of the update of all components, the active bank field in the metadata is updated, to reflect the bank from which the platform will boot on the subsequent boots. Currently, the feature is being enabled on the STM32MP157C-DK2 and Synquacer boards. The DK2 board boots a FIP image from a uSD card partitioned with the GPT partioning scheme, while the Synquacer board boots a FIP image from a MTD partitioned SPI NOR flash device. This feature also requires changes in a previous stage of bootloader, which parses the metadata and selects the bank to boot the image(s) from. Support has being added in tf-a(BL2 stage) for the STM32MP157C-DK2 board to boot the active bank images. These changes have been merged to the upstream tf-a repository. The patch for adding a python test for the feature has been developed, and was sent in the version 5 of the patches[3]. However, the test script depends on adding support for the feature on MTD SPI NOR devices, and that is being done as part of the Synquacer patches. Hence these set of patches do not have the test script for the feature. That will be added through the patches for adding support for the feauture on Synquacer platform. [1] - https://developer.arm.com/documentation/den0118/a [2] - https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf [3] - https://lists.denx.de/pipermail/u-boot/2022-June/485992.html
-
- Oct 31, 2022
-
-
Add documentation for the FWU Multi Bank Update feature. The document describes the steps needed for setting up the platform for the feature, as well as steps for enabling the feature on the platform. Signed-off-by:
Sughosh Ganu <sughosh.ganu@linaro.org> Acked-by:
Etienne Carriere <etienne.carriere@linaro.org> Acked-by:
Ilias Apalodimas <ilias.apalodimas@linaro.org>
-
Add support for setting OEM flags in the capsule header. As per the UEFI specification, bits 0-15 of the flags member of the capsule header can be defined per capsule GUID. The oemflags will be used for the FWU Multi Bank update feature, as specified by the Dependable Boot specification[1]. Bit 15 of the flags member will be used to determine if the acceptance/rejection of the updated images is to be done by the firmware or an external component like the OS. [1] - https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf Signed-off-by:
-
The Dependable Boot specification[1] describes the structure of the firmware accept and revert capsules. These are empty capsules which are used for signalling the acceptance or rejection of the updated firmware by the OS. Add support for generating these empty capsules. [1] - https://git.codelinaro.org/linaro/dependable-boot/mbfw/uploads/6f7ddfe3be24e18d4319e108a758d02e/mbfw.pdf Signed-off-by:
-
Add test cases for accessing the FWU Metadata on the sandbox platform. The sandbox platform also uses the metadata access driver for GPT partitioned block devices. The FWU feature will be tested on the sandbox64 variant with a raw capsule. Remove the FIT capsule testing from sandbox64 defconfig -- the FIT capsule test will be run on the sandbox_flattree variant. Signed-off-by:
Heinrich Schuchardt <xypron.glpk@gmx.de> Acked-by:
-
Add a command to read the metadata as specified in the FWU specification and print the fields of the metadata. Signed-off-by:
-
The FWU Multi Bank Update feature supports updating firmware images to one of multiple sets(also called banks) of images. The firmware images are clubbed together in banks, with the system booting images from the active bank. Information on the images such as which bank they belong to is stored as part of the metadata structure, which is stored on the same storage media as the firmware images on a dedicated partition. At the time of update, the metadata is read to identify the bank to which the images need to be flashed(update bank). On a successful update, the metadata is modified to set the updated bank as active bank to subsequently boot from. Signed-off-by:
-
The FWU Multi Bank Update specification requires the Update Agent to carry out certain checks at the time of platform boot. The Update Agent is the component which is responsible for updating the firmware components and maintaining and keeping the metadata in sync. The spec requires that the Update Agent perform the following checks at the time of boot * Sanity check of both the metadata copies maintained by the platform. * Get the boot index passed to U-Boot by the prior stage bootloader and use this value for metadata bookkeeping. * Check if the system is booting in Trial State. If the system boots in the Trial State for more than a specified number of boot counts, change the Active Bank to be booting the platform from. Call these checks through the main loop event at the time of platform boot. Signed-off-by:
-
Add an event type EVT_MAIN_LOOP that can be used for registering events that need to be run after the platform has been initialised and before the main_loop function is called. Signed-off-by:
Simon Glass <sjg@chromium.org> Reviewed-by:
-
The FWU Multi Bank Update feature allows the platform to boot the firmware images from one of the partitions(banks). The first stage bootloader(fsbl) passes the value of the boot index, i.e. the bank from which the firmware images were booted from to U-Boot. On the STM32MP157C-DK2 board, this value is passed through one of the SoC's backup register. Add a function to read the boot index value from the backup register. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: -
Add weak functions for getting the update index value and dfu alternate number needed for FWU Multi Bank update functionality. The current implementation for getting the update index value is for platforms with 2 banks. If a platform supports more than 2 banks, it can implement it's own function. The function to get the dfu alternate number has been added for platforms with GPT partitioned storage devices. Platforms with other storage partition scheme need to implement their own function. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: -
Enabling capsule update functionality on the platform requires populating information on the images that are to be updated using the functionality. Do so for the DK2 board. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com>
Reviewed-by: -
The FWU metadata structure is accessed through the driver model interface. On the stm32mp157c dk2 and ev1 boards, the FWU metadata is stored on the uSD card. Add the fwu-mdata node on the u-boot specifc dtsi file for accessing the metadata structure. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: -
In the FWU Multi Bank Update feature, the information about the updatable images is stored as part of the metadata, on a separate partition. Add a driver for reading from and writing to the metadata when the updatable images and the metadata are stored on a block device which is formatted with GPT based partition scheme. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com>
Acked-by: -
In the FWU Multi Bank Update feature, the information about the updatable images is stored as part of the metadata, which is stored on a dedicated partition. Add the metadata structure, and a driver model uclass which provides functions to access the metadata. These are generic API's, and implementations can be added based on parameters like how the metadata partition is accessed and what type of storage device houses the metadata. Signed-off-by:
Patrick Delaunay <patrick.delaunay@foss.st.com> -
Add bindings needed for accessing the FWU metadata partitions. These include the compatible string which point to the access method and the actual device which stores the FWU metadata. The current patch adds basic bindings needed for accessing the metadata structure on GPT partitioned block devices. Signed-off-by:
-
Tom Rini authored
To quote Simon: This series provides an implementation of VBE from TPL through to U-Boot proper, using VBE to load the relevant firmware stages. It buils a single image.bin file containing all the phases: TPL - initial phase, loads VPL using binman symbols VPL - main firmware phase, loads SPL using VBE parameters SPL - loads U-Boot proper using VBE parameters U-Boot - final firmware phase, where OS booting is processed This series does not include the OS-booting phase. That will be the subject of a future series. The implementation is entirely handled by sandbox. It should be possible to enable this on a real board without much effort, but that is also the subject of a future series.
-
Add a test which checks that VBE boots correctly from TPL through to U-Boot proper. Signed-off-by: -
Add a VBE comment which shows the current state. Currently this is just the phases which booted via VBE. Signed-off-by: -
We expect VPL and SPL to load using VBE. Add a record of this so we can check it in U-Boot proper. Signed-off-by: -
Use a manual test for the VBE test, so we can make the pytest and the C unit test work together properly. Signed-off-by: -
Add the required Kconfig option so that signatures can be verified when loading a configuration. Signed-off-by: -
Use binman to build an image which includes all the U-Boot phases so that a full VBE boot can take place with just that image.bin file. Attach the image file to mmc2 so it can be loaded. VBE is used to load images in two phases: - In VPL, VBE decides which SPL image to load - In SPL, VBE decides which U-Boot image to load The latter should really be determined by VPL, since it does the full signature verification on the selected configuration. However, we have separate configurations for SPL and U-Boot proper, so for now we keep it simple and have SPL do its own verification. This will need to be tidied up later. Signed-off-by: -
At present we put the driver in the /chosen node in U-Boot. This is a bit strange, since U-Boot doesn't normally use that node itself. It is better to put it under the bootstd node. To make this work we need to copy create the node under /chosen when fixing up the device tree. Copy over all the properties so that fwupd knows what to do. Update the sandbox device tree accordingly. Signed-off-by: -
Enable the various features needed in VPL, by adding Kconfig options. Update the defconfig for sandbox_vpl so that the build for each phase includes what is needed. Drop LZMA for now and make sure partition support is omitted in SPL, since it is not needed. Signed-off-by: -
We don't need the U-Boot prefix on the version and in fact it is harmful since pytest gets confused seeing the U-Boot banner bring displayed when the version is printed. Drop the prefix from the string. We could produce an entirely new string from the component parts, but this adds to the rodata size and would break the use of version_string as the only thing which holds this information. Signed-off-by: -
Move this into its own file so it can be built only by U-Boot proper. Signed-off-by: -
Add an SPL loader to obtain the next-phase binary from a FIT provided by the VBE driver. Signed-off-by:
-
