- Oct 24, 2024
-
-
The two tools that create android boot images, mkbootimg and the fastboot client, set the kernel address by default to 0x11008000. U-boot always honors this field, and will try to copy the ramdisk to whatever value is set in the header, which won't be mapped to the actual RAM on most platforms, resulting in the kernel obviously not booting. All the targets in U-Boot right now will download the android boot image to CONFIG_SYS_LOAD_ADDR, which means that it will already have been downloaded to some location that is suitable to use the ramdisk in-place for header version 0 to 2. For header version 3 and later, the ramdisk can't be used in-place to use ramdisk_addr_r in this case. Signed-off-by:
Neil Armstrong <neil.armstrong@linaro.org> Reviewed-by:
Mattijs Korpershoek <mkorpershoek@baylibre.com> Tested-by:
Guillaume La Roque <glaroque@baylibre.com> Link: https://lore.kernel.org/r/20241017-topic-fastboot-fixes-mkbootimg-v2-3-c3927102d931@linaro.org Signed-off-by:
-
When trying to boot an android boot image with a compressed kernel, if the kernel is used in-place because it was created with mkbootimg, the space will be too small to properly uncompress. Take in account the compressed state, and if compressed use the kernel_addr_r which should be big enough. Signed-off-by:
-
When booting with platforms having > 4GiB of memory, the kernel physical address can be more than 32bits. Use ulong like all the other addresses, and fix the print to show the > 32bits address numbers. Signed-off-by:
-
To align with the official Android BCB (Bootloader Control Block) specifications, it's important to note that the slot_suffix should start with an underscore symbol. For a comprehensive understanding of the expected slot_suffix format in userspace, please refer to the provided reference [1]. Links: [1] - https://source.android.com/docs/core/architecture/bootloader/updating#slots Based-on: https://android-review.googlesource.com/c/platform/external/u-boot/+/1446439 Reviewed-by:
Simon Glass <sjg@chromium.org> Tested-by:
Dmitry Rokosov <ddrokosov@salutedevices.com> Tested-by: Mattijs Korpershoek <mkorpershoek@baylibre.com> # vim3_android Link: https://lore.kernel.org/r/20241017-android_ab_master-v5-6-43bfcc096d95@salutedevices.com Signed-off-by:
-
It's really helpful to have the ability to dump BCB block for debugging A/B logic on the board supported this partition schema. Command 'bcb ab_dump' prints all fields of bootloader_control struct including slot_metadata for all presented slots. Output example: ===== > board# bcb ab_dump ubi 0#misc > Read 512 bytes from volume misc to 000000000bf07580 > Read 512 bytes from volume misc to 000000000bf42f40 > Bootloader Control: [misc] > Active Slot: _a > Magic Number: 0x42414342 > Version: 1 > Number of Slots: 2 > Recovery Tries Remaining: 0 > CRC: 0x2c8b50bc (Valid) > > Slot[0] Metadata: > - Priority: 15 > - Tries Remaining: 0 > - Successful Boot: 1 > - Verity Corrupted: 0 > > Slot[1] Metadata: > - Priority: 14 > - Tries Remaining: 7 > - Successful Boot: 0 > - Verity Corrupted: 0 ==== The ab_dump command allows you to display ABC data directly on the U-Boot console. During an A/B test execution, this test verifies the accuracy of each field within the ABC data. Signed-off-by:
-
In the entire cmd/bcb.c file, the return value of strcmp() is not directly compared to 0. Therefore, it would be better to maintain this style in the new do_bcb_ab_select() function as well. Reviewed-by:
-
To enhance code organization, it is beneficial to consolidate all A/B BCB management routines into a single super-command. The 'bcb' command is an excellent candidate for this purpose. This patch integrates the separate 'ab_select' command into the 'bcb' group as the 'ab_select' subcommand, maintaining the same parameter list for consistency. Signed-off-by:
-
U_BOOT_LONGHELP and U_BOOT_CMD_WITH_SUBCMDS offer numerous advantages, including: - common argument restrictions checking - automatic subcommand matching - improved usage and help handling By utilizing the U_BOOT_LONGHELP approach, we can reduce the amount of command management code and describe commands more succinctly. Signed-off-by:
-
There are new function documentation requirements in U-Boot, so apply these changes for android_ab. Reviewed-by:
-
Align with cmd_sf, and try to rely on DT for spi speed and mode, and still fallback on spi_flash_probe() if it fails. With the current scheme, spi_flash_probe() will be called with CONFIG_SF_DEFAULT_SPEED and CONFIG_SF_DEFAULT_MODE with are set to 0 by default on DT platforms using DM_SPI_FLASH. Like cmd_sf, keep the option to specify the speed and mode from the dfu_alt_mode string, but rely on DT properties if not specified. Using CONFIG_SF_DEFAULT_SPEED and CONFIG_SF_DEFAULT_MODE makes the SPIFC controller on Amlogic Meson G12B & SM1 hardware fail and is unable to recover until a system reboot. Signed-off-by:
-
To smoothly handle the transition from the legacy SPI FLASH API to the driver model API, add the DM functions as dummy inline functions. Today, client code uses #if/#else conditionals, but it's better to use if(IS_ENABLED()) to make sure all code builds fine and avoid configuration hell, leaving the compiler remove the dead code. An example is cmd/sf, which could make use of those dummy functions to drop the conditional compilation. Signed-off-by:
-
- Oct 23, 2024
-
-
https://source.denx.de/u-boot/custodians/u-boot-watchdogTom Rini authored
CI: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=378&view=results * watchdog: gpio_wdt: add support for stoppable devices (Rasmus) * watchdog: Add DaVinci's watchdog support (Bastien) * cyclic: disentangling cyclic API from schedule() (Rasmus) * watchdog: introduce separate SPL symbol for WDT_GPIO (Rasmus)
-
Currently, enabling WDT_GPIO on a board which uses SPL, but does not have SPL_WDT, SPL_DM_GPIO or SPL_OF_CONTROL enabled, breaks the build. Make it possible to use the WDT_GPIO driver on such boards by introducing a separate symbol controlling whether the driver is built for SPL. Make it default to WDT_GPIO such that boards that already have it enabled and all the SPL prerequisites satisfied will continue to have it in SPL. Signed-off-by:
Rasmus Villemoes <ravi@prevas.dk> Reviewed-by:
Tom Rini <trini@konsulko.com> Reviewed-by:
Stefan Roese <sr@denx.de>
-
Nothing in cyclic.h is needed to define struct global_data, so do not include that header. If any .c file relies on getting cyclic.h through asm/global_data.h, it needs to include it itself. Signed-off-by:
-
This TU currently relies on getting a declaration of schedule() through some nested include. Include the proper header directly. Signed-off-by:
-
These TUs currently rely on getting a declaration of schedule() through some nested include. Include the proper header directly. Signed-off-by:
-
This TU currently relies on getting a declaration of schedule() through some nested include. Include the proper header directly. Signed-off-by:
-
These library routines obviously do not make use of the cyclic_register() etc. API, but do need to call schedule(). Include the proper header. Eventually, their ifdef logic should be updated to avoid talking about CONFIG_WATCHDOG. Signed-off-by:
-
Nobody relies on getting the cyclic API declared by including the watchdog.h header, but for historical reasons, many TUs include watchdog.h to get a declaration of schedule(). Now that we have a dedicated header for just that, include that header instead of cyclic.h. Eventually, all TUs that call schedule() should themselves include u-boot/schedule.h, but this is a step towards getting rid of unnecessary include statements in cyclic.h and global_data.h. Signed-off-by:
-
The only caller left is schedule(); everybody outside cyclic.c now calls or references schedule(). Signed-off-by:
-
This is the last place outside of cyclic.c that references cyclic_run() directly. Replace by schedule(), so that cyclic_run() can be made private. This also better matches what I believe commit 29caf930 ("cyclic: Use schedule() instead of WATCHDOG_RESET()") intended to do. Signed-off-by:
-
Prior to commit 29caf930 ("cyclic: Use schedule() instead of WATCHDOG_RESET()") we had /* Currently only needed for fs/cramfs/uncompress.c */ static inline void watchdog_reset_func(void) { WATCHDOG_RESET(); } and .outcb was set to that watchdog_reset_func(). Said commit changed that .outcb to cyclic_run instead of schedule, which would otherwise match all the other WATCHDOG_RESET replacements done. As the HW_WATCHDOG case is not handled by cyclic_run, this seems to be an oversight. Signed-off-by:
-
Modifying a generic header like watchdog.h, removing not directly used asm/ptrace.h header relies on whoever includes it to already have included something that defines the type ulong. Make the asm/ptrace.h header self-contained by including the proper header. Signed-off-by:
-
This makes use of the cyclic API but relies on implicitly getting the appropriate declarations through some nested include. Include the cyclic.h header directly. Signed-off-by:
-
I noticed an "unnecessary" include of <cyclic.h> in global_data.h, in the sense that nothing in cyclic.h is needed in order to define 'struct global_data'. Well, it's not unnecessary, as it implicitly ensures that everybody gets a declaration of schedule(), and schedule() is (obviously) called all over the tree. Almost none of those places directly include <cyclic.h>, but for historical reasons, many do include <watchdog.h> (most schedule() instances are replacements of WATCHDOG_RESET()). However, very few TUs actually need the declarations of the cyclic_register() and struct cyclic_info, and they also don't really need anything from the watchdog.h header. So introduce a new header which just contains a declaration of schedule(), which can then be included from all the places that do call schedule(). I removed the direct reference to cyclic_run(), because we shouldn't have two public functions for doing roughly the same without being very explicit about when one should call one or the other. Testing of later patches that explicitly include <schedule.h> when schedule() is used revealed a problem with host tool build on win32, which apparently picked up a host <schedule.h>. To avoid that problem, put the new header in include/u-boot/ and hence make the include statements say <u-boot/schedule.h>. Signed-off-by:
-
WATCHDOG_RESET is no more. Replace the reference by schedule(). While here, rearrange the sentence a bit so that "cyclic_run()" becomes the object and "the main function responsible for calling all registered cyclic functions" a parenthetical rather than the other way around, which at least to me makes it more readable. Signed-off-by:
-
Add support for the DaVinci's watchdog timer Signed-off-by:
Bastien Curutchet <bastien.curutchet@bootlin.com> Reviewed-by:
-
Back when I added this driver in commit 2ac84904, I wrote The corresponding linux driver apparently has support for some watchdog circuits which can be disabled by tri-stating the gpio, but I have never actually encountered such a chip in the wild; That has changed now; I have a board with just such a watchdog on my desk currently. Add support for that. - For a hw_algo="toggle" device, the gpio is requested as output if the always-running flag is set, otherwise as input. - The ->start() method is updated to change the direction to output when required (i.e. it is not always-running). - The ->stop() method is implemented, but of course reports failure if always-running. As I still haven't met any hw_algo="level" devices, I'm not entirely sure how they fit in, but I'm borrowing logic from the corresponding linux driver: - In ->probe(), such devices always request the gpio as GPIOD_IS_OUT. - In ->stop(), the linux driver has an "eternal ping" comment and sets the gpio to (logic) high. Stefan: Added necessary changes in test/dm/wdt.c to fix CI build breakage, as suggested by Rasmus. Signed-off-by:
-
- Oct 22, 2024
-
-
https://source.denx.de/u-boot/custodians/u-boot-videoTom Rini authored
CI: https://source.denx.de/u-boot/custodians/u-boot-video/-/pipelines/22907 * VNBYTES() comment fix * add VIDEO dependency for FDT_SIMPLEFB * fdt_simplefb: drop not needed CONFIG_VIDEO check * am62x,evm: preserve splash screen while OS is booting * simplefb: warning fix for CONFIG_FDT_64BIT=n
-
Fix compile warning with !CONFIG_FDT_64BIT by casting the variable in the debug print. Signed-off-by:
Eva Kurchatova <lekkit@at.encryp.ch> Reported-by:
Leo Yu-Chi Liang <ycliang@andestech.com>
-
Update simple-framebuffer device-tree node by enumerating framebuffer related information in existing simple-framebuffer node in Linux device-tree file and enabling it. In case there is no simple-framebuffer stub detected in Linux kernel device-tree and video is still active, then update the device-tree to reserve the framebuffer region for the active splash screen. This helps preserve the splash screen till the display server takes over after OS is booted. Signed-off-by:Devarsh Thakkar <devarsht@ti.com>
-
CONFIG_VIDEO conditional compilation checks are no longer needed since FDT_SIMPLEFB Kconfig now depends on VIDEO Kconfig. Signed-off-by:
-
The fdt_simplefb.c APIs rely on video-uclass APIs and structures to fill/update framebuffer information, so compile it only when VIDEO Kconfig is enabled, as otherwise below warning can be seen if VIDEO Kconfig is disabled: "boot/fdt_simplefb.c:96:12: warning: fdt_simplefb_enable_existing_node defined but not used [-Wunused-function] 96 | static int fdt_simplefb_enable_existing_node(void *blob)" Reported-by:
-
The VNBYTES() macro has been updated to silence possible warnings regarding authorized (but unusual) uses of this macro, but the comment was kept unchanged. A year has passed so let's fix the comment now to avoid confusions. Fixes: cc05d352 ("video: Add parentheses around VNBYTES() macro") Suggested-by:
Miquel Raynal <miquel.raynal@bootlin.com> Reviewed-by:
-
In v2024.10, "make envtools" is broken for at least these defconfigs: am335x_evm_defconfig rpi_3_defconfig rpi_4_defconfig mx7dsabresd_defconfig wandboard_defconfig imx8mp_evk_defconfig The only defconfig we use for which it is not broken is stm32mp13_defconfig. They all work just fine in v2024.07. The symptoms are slightly different, but all related to the fact that some transitively included header uses IS_ENABLED or CONFIG_IS_ENABLED without linux/kconfig.h having already been included. A simple git bisect doesn't produce anything sensible, it ends up at 3a9f642c (crypto: nuvoton: npcm_sha: Support SHA 384/512) which clearly has nothing to do with this. But digging deeper, one eventually finds 0f92fa45 ("env: Remove <common.h> and add needed includes"). So at first I tried adding "#include <linux/kconfig.h>" in include/env_default.h and include/env_flags.h. That fixes it for some, but not all, of the above. For example rpi_3_defconfig still fails, then in log.h complaining about BIT() and u8 not being defined. At least BIT() is should have gotten from bitops.h, except that that's behind ifdef __KERNEL__, so not set for the envtools build. It turns out that the envtools source code in fw_env_private.h already has some hackery to deal with all this, in the form of the __ASSEMBLY__ games it plays before including config.h. It seems that if we just make sure to do that include early enough, so that config.h is indeed parsed with that __ASSEMBLY__ hackery in place, everything builds fine. Fixes: 0f92fa45 ("env: Remove <common.h> and add needed includes") Signed-off-by:
Fabio Estevam <festevam@gmail.com>
-
- Oct 21, 2024
-
-
Tom Rini authored
Chia-Wei Wang <chiawei_wang@aspeedtech.com> says: Aspeed AST2700 SoCs integrates the Caliptra secure IP, where an ECDSA384 signature verification HW interface is exported for SoC crypto needs. This patch series firstly extends the FIT image signing/verify common code to support the ECDSA384 algorithm. For better convenience, the device tree for ECDSA public key storage is also revised by referring to RSA implementations. After the FIT common code revision, the driver is implemented for AST2700 to leverage the Caliptra ECDSA384 signature verification. These are verified by signed FIT images with the algorithm "sha384,ecdsa384". Link: https://lore.kernel.org/r/20241014095620.216936-1-chiawei_wang@aspeedtech.com
-
Aspeed AST27xx SoCs integrate the CPTRA 1.0 secure IP, which export an ECDSA384_SIGNATURE_VERIFY mailbox command service for SoC to use. This patch is verified by the FIT signature verification using the "sha384,ecdsa384" algorithm. Signed-off-by:
Chia-Wei Wang <chiawei_wang@aspeedtech.com> Reviewed-by:
-
The padding algorithm is not mandatory for all signing algorithm. For example, ECDSA does not require a padding method. For RSA requiring PKCS padding, the belonging info->crypto(), assigned with rsa_verify_key(), also has the check on the validity of info->padding(). Thus, remove the info->padding check from the upper, general layer. Signed-off-by:
-
Add ECDSA384 algorithm support for image signing and verification. Signed-off-by:
-
Tom Rini authored
Manorit Chawdhry <m-chawdhry@ti.com> says: This series adds support for Adaptive voltage scaling on J721S2 device [0]. [0]: https://www.ti.com/lit/pdf/spruj28 (Section 5.2.4.1 AVS Support) AVS Test for J721S2: https://gist.github.com/manorit2001/b2fd9f6764a863294d4aa0755c83c84f Boot Test results: https://gist.github.com/manorit2001/d44e035552cb19aadeb0d928d5cb5f26 Link: https://lore.kernel.org/r/20241015-b4-upstream-j721s2-avs-v5-0-5c8087387dc5@ti.com
-
