Skip to content
Snippets Groups Projects
  1. Feb 24, 2025
    • Tom Rini's avatar
      Prepare v2025.04-rc3 · dc0ee458
      Tom Rini authored
      
      Signed-off-by: default avatarTom Rini <trini@konsulko.com>
      v2025.04-rc3
      dc0ee458
    • Marek Vasut's avatar
      mmc: Fix size calculation for sector addressed MMC version 4 · dbb9e136
      Marek Vasut authored
      
      For eMMC v4 and newer that is smaller than 2 GiB, the JEDEC JESD84-B51
      section 6.2.4 Configure partitions indicates that EXT_CSD SEC_COUNT
      should not be used to determine device size, and instead device size
      should be calculated from C_SIZE and C_SIZE_MULT.
      
      This is not exactly accurate, the 2 GiB limit is not a hard line,
      there are eMMC devices which are smaller than 2 GiB and still
      require device size to be determined from EXT_CSD SEC_COUNT. The
      hard line is instead OCR HCS bit, which indicates whether the device
      is byte or sector addressed, the former applies to most devices
      below 2 GiB, and the later applies mostly to devices above 2 GiB.
      
      However, there are a couple of devices which are smaller than 2 GiB
      and still set the OCR HCS bit to indicate they are sector addressed,
      and therefore the size calculation for those devices should also
      use EXT_CSD SEC_COUNT . Use mmc->high_capacity flag to discern the
      devices instead of arbitrary 2 GiB limit. The mmc->high_capacity flag
      reflects the OCR HCS bit state.
      
      Fixes: 639b7827 ("mmc: fix the condition for MMC version 4")
      Signed-off-by: default avatarMarek Vasut <marex@denx.de>
      dbb9e136
    • Joao Marcos Costa's avatar
      fs/squashfs: fix potential integer overflows · 59fd62d7
      Joao Marcos Costa authored
      
      The length of buffers used to read inode tables, directory tables, and
      reading a file are calculated as: number of blocks * block size, and
      such plain multiplication is prone to overflowing (thus unsafe).
      
      Replace it by __builtin_mul_overflow, i.e. safe math.
      
      Signed-off-by: default avatarJoao Marcos Costa <joaomarcos.costa@bootlin.com>
      59fd62d7
  2. Feb 22, 2025
  3. Feb 20, 2025
  4. Feb 19, 2025
  5. Feb 18, 2025
  6. Feb 17, 2025
  7. Feb 16, 2025
  8. Feb 15, 2025
    • Tom Rini's avatar
      Merge branch 'master' of https://source.denx.de/u-boot/custodians/u-boot-sh · 274dc529
      Tom Rini authored
      Add empty weak assembler function armv8_switch_to_el2_prep() which is
      jumped to just before U-Boot determines which EL it is running in and
      decides which path to take to boot the Linux kernel. Add
      IH_TYPE_TFA_BL31 into supported images type, to allow implementation of
      board specific U_BOOT_FIT_LOADABLE_HANDLER(IH_TYPE_TFA_BL31, ...) TFA
      BL31 loadable handler for fitImages.
      
      This PR contains common hooks which are noop, R-Car Gen4 board specific
      implementation using these hooks is coming in next PR.
      274dc529
    • Marek Vasut's avatar
      image: Add support for starting TFA BL31 as fitImage loadables · 854a5a00
      Marek Vasut authored
      
      Add support for starting TFA from U-Boot running in EL3 as part of
      fitImage boot, so the user can start U-Boot in the highest privilege
      level on the platform, bundle TFA, Linux, DT into a single fitImage
      and boot such a bundle as a whole.
      
      There are two main benefits of this approach. First is the ability
      to run U-Boot in EL3, where it has unrestricted access to the entire
      system and can act as a useful debug tool, as it was always intended
      to be used. Second is the ability to easily and safely update of any
      component in the fitImage, be it TFA, Linux or DT.
      
      The boot process is similar to regular Linux with DT fitImage boot
      process, except the TFA has to be bundled into the fitImage. For the
      bundling instructions, see below. The TFA is started as a 'loadables'
      with custom U_BOOT_FIT_LOADABLE_HANDLER and armv8_switch_to_el2_prep()
      handling implemented in board code, and performing the handoff and
      boot in case the TFA was loaded.
      
      The loadables handler is optional and meant to set up any sort of
      handoff structures used by the TFA BL31 or perform any other setup
      that is needed by the blob. The custom armv8_switch_to_el2_prep()
      has to implement the jump to TFA BL31 with return to U-Boot just
      before booting the Linux kernel.
      
      Example fitImage image and configuration section:
      
      /dts-v1/;
      
      / {
          description = "Linux kernel with FDT blob and TFA BL31";
      
          images {
              kernel-1 { ... };
              fdt-1 { ... };
              atf-1 {                  /* This is the TFA BL31 image */
                  description = "TFA BL31";
                  data = /incbin/("../build/plat/release/bl31.bin");
                  type = "tfa-bl31";
                  arch = "arm64";
                  os = "arm-trusted-firmware";
                  compression = "none";
                  load = <0x46400000>;
                  entry = <0x46400000>;
              };
          };
      
          configurations {
              default = "conf-1";
              conf-1 {
                  description = "Boot Linux";
                  kernel = "kernel-1";
                  fdt = "fdt-1";
                  loadables = "atf-1"; /* This is the TFA BL31 loadable */
              };
          };
      };
      
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      Signed-off-by: default avatarMarek Vasut <marek.vasut+renesas@mailbox.org>
      854a5a00
Loading