Skip to content
Snippets Groups Projects
  1. Sep 03, 2024
    • HONG Yifan's avatar
      kleaf: Clarify when vendor-bootconfig.img is added to default kernel_images.boot_image_outs. · b5592984
      HONG Yifan authored
      If kernel_images.boot_image_outs is set, it assumes a list of defaults.
      Clarify that vendor-bootconfig.img is always added on build_vendor_boot,
      because it doesn't know if VENDOR_BOOTCONFIG is actually set or not.
      
      Bug: 361735034
      Change-Id: I51588b63bec52c8da7f62ee44d203ce6e7eded49
      b5592984
    • HONG Yifan's avatar
      kleaf: Pass RAMDISK_COMPRESS/RAMDISK_EXT to build_boot_images. · a3d1b920
      HONG Yifan authored
      It was previously incorrectly missed. If the build config
      does NOT specify RAMDISK_COMPRESS/RAMDISK_EXT, building boot images
      may break.
      
      This is hit when
      - kernel_images(build_initramfs = True)
      - INITRAMFS_VENDOR_RAMDISK_FRAGMENT_NAME is empty
      in which case build_boot_images will try to build
      ramdisk.{ramdisk_compress}; but it may be unable to do so when
      RAMDISK_COMPRESS/RAMDISK_DECOMPRESS/RAMDISK_EXT is not set in the build
      config but only in BUILD files.
      
      Bug: 361733833
      Change-Id: If1fd54a9197404b2e4112e0b2d8a169caf2742af
      a3d1b920
  2. Feb 22, 2024
  3. Feb 08, 2024
  4. Dec 07, 2023
    • Isaac Manjarres's avatar
      kleaf: Add support for specifying modules for recovery/charger · 14a840e8
      Isaac Manjarres authored
      
      Currently, the same modules.load file is used for normal boot,
      recovery/fastbootd and charger modes during first-stage init. This
      means that during normal boot, the modules that are needed for
      recovery and charger modes are loaded during first-stage init, which
      is not required.
      
      Add support for specifying a list of modules that are required for
      booting into recovery or charger mode. This introduces two new
      attributes to the kernel_images() macro called: modules_recovery_list
      and modules_charger_list. Each attribute points to a list of modules
      that are needed to boot into each mode respectively. This list can
      be generated dynamically by concatenating the list of vendor_boot or
      vendor_kernel_boot modules required for first stage init, along with
      the list of modules needed to boot into each mode.
      
      Defining these attributes also produces a file named
      modules.load.[recovery/charger] in the initramfs, which init uses
      instead of modules.load when booting into recovery or charger mode
      respectively to load the first-stage init and recovery and charger
      modules. In case of normal boot, init will use the modules.load
      file, which will only contain the modules needed for first
      stage init, and the recovery and charger modules will be loaded
      from the vendor_dlkm partition during second-stage init.
      
      Bug: 266752750
      Change-Id: I11503b11683ef64cf0933b8641959ea5acd63ab1
      Signed-off-by: default avatarIsaac J. Manjarres <isaacmanjarres@google.com>
      (cherry picked from commit b9ba4b67)
      [isaacmanjarres: Re-wrote some of the commit message/implemented it
      as part of kleaf. Also added tests for the new attributes.]
      (cherry picked from commit d08605f4)
      [isaacmanjarres: Resolved trivial merge conflicts when backporting
      from main.]
      14a840e8
  5. Oct 10, 2023
    • Ramji Jiyani's avatar
      kleaf: system_dlkm: Add flatten images support · a8a858a1
      Ramji Jiyani authored
      
      Generate flatten images if kernel_images have
      build_system_dlkm_flatten is set True. These
      images don't have the `uname -r` in the directory
      structure and all modules are available as
      lib/modules/*.ko with modules.load and modules.dep
      depmod artifacts.
      
      Generates images as follow:
      
      If system_dlkm_fs_type is set:
        system_dlkm.flatten.<system_dlkm_fs_type>.img
      
      If system_dlkm_fs_types is set:
        system_dlkm.flatten.<fs_type>.img for each fs types
      
      By default when no fs type is specified:
        system_dlkm.flatten.ext4.img
      
      Bug: 301178664
      Test: Manual image verification with different options
      Test: TH
      Change-Id: I4b7815d131d3d26adaa35c4550e76db71aa33936
      Signed-off-by: default avatarRamji Jiyani <ramjiyani@google.com>
      a8a858a1
  6. Sep 29, 2023
    • Ramji Jiyani's avatar
      kleaf: system_dlkm build images for list of fs · 96cb38ae
      Ramji Jiyani authored
      
      Introduces system_dlkm_fs_types list attribute for the
      kernel_images rule to build the system_dlkm partition
      images for all filesystem provided in the list.
      
      Deprecates the system_dlkm_fs_type but gives it priority
      for backward compitability resons.
      
      Behavior based on values of system_dlkm_fs_type &
      system_dlkm_fs_types:
      
          Both specified: Fail with deprecation message
          Both not specified: system_dlkm.img with ext4
      	This is same as current default behavior when
      	system_dlkm_fs_type is not specified.
          system_dlkm_fs_type="fs": system_dlkm.img with given fs
      	This is same as current behavior.
          system_dlkm_fs_types=[list_of_filesystems]: system_dlkm.fs.img
      	for each file system type in list_of_filesystems
      
      Bug: 297407875
      Test: TH, Manual with all permutations & combinations
      Change-Id: Ie8ee880dbbc41576603a1ab1b56f0307a6ab2e90
      Signed-off-by: default avatarRamji Jiyani <ramjiyani@google.com>
      (cherry picked from commit b0fedfdc)
  7. Jul 06, 2023
    • Yifan Hong's avatar
      kleaf: Add visibility to kleaf/{impl,artifact_tests}/**/*.bzl. · 346241d8
      Yifan Hong authored
      This ensures that these extensions, which are implementation
      details of Kleaf, doesn't get loaded outside of kleaf.
      
      The public symbols are re-exported in kernel.bzl.
      
      If this breaks a build, one may use
      --nocheck_bzl_visibility to temporarily disable
      the check.
      
      Also fix buildifier warnings.
      
      gki_artifacts.bzl are not included in this change due to an internal usage.
      
      Test: TH
      Bug: 283857454
      Change-Id: If8139982e0e55a72729fbc058ec99965d069195e
      346241d8
  8. Jun 05, 2023
    • William McVicker's avatar
      kleaf: add option to archive the vendor_dlkm modules · 36a1f499
      William McVicker authored and William McVicker's avatar William McVicker committed
      If `vendor_dlkm_archive = True` is set, then the tarball
      `vendor_dlkm_staging_archive.tar.gz` is created. This can be used to
      easily get the vendor_dlkm modules without have to mount the vendor_dlkm
      ext4 image.
      
      Bug: 281621377
      Change-Id: I28023de9c42243f3859078f9e424c84cf7400769
      36a1f499
  9. Mar 17, 2023
    • Yifan Hong's avatar
      kleaf: vendor_dlkm exclude modules from system_dlkm · 6b37bf64
      Yifan Hong authored
      After this change, if dedup_dlkm_modules is set:
      
      - When building vendor_dlkm, the staging directory from
        system_dlkm is extracted to MODULES_STAGING_DIR beforehand,
        so that depmod can find them. This allows modules from
        vendor_dlkm to link to modules from system_dlkm.
      - system_dlkm.modules.load is concatenated to $DIST_DIR/modules.load
        (after modules.load from vendor_boot) so that the list of modules
        from system_dlkm are excluded from vendor_dlkm.modules.load list.
      
      This means that after this change, if dedup_dlkm_modules is set
      for a build, a device effectively enables the feature that allows
      vendor_dlkm modules to depend on system_dlkm modules.
      
      If dedup_dlkm_modules is set, additional changes are required
      on the device so that userspace loads system_dlkm modules before
      loading vendor_dlkm modules.
      
      Note that even with this change, vendor_boot modules and
      system_dlkm modules themselves (the *.ko files) aren't excluded
      from vendor_dlkm.img built from the kernel source tree if
      vendor_dlkm_modules_list specifies .* (all modules). They are only
      excluded from modules.load. However, the images from the kernel
      source tree are for development purposes. It is expected that
      the system_dlkm / vendor_dlkm images are built from the platform
      source tree, excluding modules not in the corresponding modules.load
      file.
      
      A subsequent optimization would be to exclude vendor_boot / system_dlkm
      modules from this "debug" vendor_dlkm image built from the kernel
      source tree. This optimization is not covered by this change.
      
      Bug: 272523944
      Bug: 272525097
      
      Change-Id: I86197ed03bc32563399f69e8f93eaefc585a9464
      6b37bf64
  10. Mar 06, 2023
    • Zheng Pan's avatar
      Support VENDOR_DLKM_ETC_FILES · fb99c515
      Zheng Pan authored
      Enable users to pass in etc files that need to be installed to
      vendor_dlkm.img /etc folder.
      
      Bug: 270603150
      Bug: 271443724
      Test: build kernel and check vendor_dlkm.img and dist folder
      
      Change-Id: I63a2f348ced7681180e26647bfdb3d4c09de735b
      fb99c515
  11. Dec 12, 2022
    • Ramji Jiyani's avatar
      kleaf: ext4/erofs choices for dlkm partition · 234e10e9
      Ramji Jiyani authored
      
      system_dlkm and vendor_dlkm can be ext4 or erofs images
      as these are supported read only filesystem in platform
      builds.
      
      Add an option to choose between ext4/erofs for these
      partitions for the kernel's development only images to
      match patform choices with ext4 as the default if choice
      is not provided.
      
      Choice will be passed as environemental variables to build_utils.sh:
      SYSTEM_DLKM_FS_TYPE=["ext4" | "erofs"] for build_system_dlkm_image
      VENDOR_DLKM_FS_TYPE=["ext4" | "erofs"] for build_vendor_dlkm_image
      
      Bug: 261617174
      Bug: 232430739
      Test: TH
      Change-Id: I4a37e9d0116bb4b2f38fc119011a441d7c73e9f7
      Signed-off-by: default avatarRamji Jiyani <ramjiyani@google.com>
      234e10e9
  12. Dec 03, 2022
  13. Nov 30, 2022
  14. Nov 29, 2022
  15. Nov 15, 2022
  16. Oct 27, 2022
  17. Oct 19, 2022
  18. Oct 03, 2022
    • Yifan Hong's avatar
      kleaf: Add kwargs to kernel_images · 801c00cc
      Yifan Hong authored
      This passes things like visibility and tags to internal targets.
      
      Test: TH
      Bug: 244786402
      
      Change-Id: I28a33f7d1351d031fdc04336f6077a9bf3023529
      801c00cc
  19. Aug 16, 2022
  20. Aug 10, 2022
    • Yifan Hong's avatar
      kleaf: enable building device system_dlkm against GKI system_dlkm_staging_archive · e8a8dd2e
      Yifan Hong authored
      
      system_dlkm_image produces staging_archive and modules.load
      files. Also download them and put them as part of distribution
      when building against downloaded prebuilts.
      
      With system_dlkm_staging_archive.tar.gz from GKI
      piped to the device's system_dlkm rule, instead
      of creating the staging directory, unarchive the archive
      and build system_dlkm from there.
      
      As part of this change, kernel_images now also
      accept these arguments:
      - system_dlkm_modules_list
      - system_dlkm_modules_blocklist
      - system_dlkm_props
      
      ... which corresponds to the upper-case version of the build configs,
      respectively. Their semantics are the same as the build configs.
      Unlike vendor_dlkm_*:
      - system_dlkm_modules_list falls back to modules_list if not set
      - system_dlkm_modules_blocklist falls back to modules_blocklist if not set
      
      Test: build slider_images_system_dlkm_image with build_system_dlkm=True
      Bug: 233401974
      Bug: 238786592
      
      Change-Id: Ie9a2073d571b23eee58764ef9ced0976e5fa9622
      Signed-off-by: default avatarYifan Hong <elsk@google.com>
      e8a8dd2e
  21. Aug 06, 2022
    • Yifan Hong's avatar
      kleaf: modules_options is a file, not a string. · ba9c8287
      Yifan Hong authored
      Unlike MODULES_OPTIONS in build.sh, modules_options in
      Kleaf points to a file that contains the lines.
      
      Fix comments and build rules that previously assume
      it contains strings.
      
      Test: bazel test //common:kernel_aarch64_tests
      Fixes: 241162984
      Change-Id: Ie3ab2544f91cbcec55e5af390fc06eba400add14
      ba9c8287
  22. Aug 05, 2022
  23. Jun 15, 2022
  24. Jun 02, 2022
Loading