Refactor the build support for kernel modules. This refactoring is
leveraged to add support for directories of kernel modules in each
partition. To add a directory of kernel modules, define
BOARD_KERNEL_MODULE_DIRS to include the directory name, for example:
BOARD_KERNEL_MODULE_DIRS := 5.4
The build will then check all the usual kernel module related macros
with an extension of _5.4, for example you can define
BOARD_VENDOR_KERNEL_MODULES_5.4 := <modules to copy>
BOARD_VENDOR_KERNEL_MODULES_ARCHIVE_5.4 = <path to archive file>
BOARD_VENDOR_KERNEL_MODULES_LOAD_5.4 := <modules for load list>
Bug: 157645635
Change-Id: I1687d0ec85c1dcf21350350623b4689aba3f6717
Merged-In: I1687d0ec85c1dcf21350350623b4689aba3f6717
Moving this makes each of the partition's kernel module Makefile
generation more similar, enabling a forthcoming cleanup/refactoring.
If recovery-is-boot and there are kernel modules defined in
BOARD_GENERIC_RAMDISK_KERNEL_MODULES, those kernel modules will
now be included in the default assignment to
BOARD_RECOVERY_KERNEL_MODULES_LOAD. If this is not desired then
BOARD_RECOVERY_KERNEL_MODULES_LOAD may simply be set to
BOARD_RECOVERY_KERNEL_MODULES (or a custom list of recovery kernel
modules to load).
Bug: 157645635
Change-Id: Ia1392b7d20d07cee75420edd95dcee1dc825516e
Merged-In: Ia1392b7d20d07cee75420edd95dcee1dc825516e
Currently the two special-case calls to create just a module load list
(as opposed to copying a set of modules and creating a module load list)
are inside checks that the related board macro for the module set is not
empty.
While it would be incorrect to create a non-empty module load list with
an empty set of modules, this error would quickly surface at runtime.
More importantly, moving these out will permit refactoring this code to
clean it up.
Bug: 157645635
Change-Id: I199788d49072d4c59737b3ef2c75546852cf3e36
Merged-In: I199788d49072d4c59737b3ef2c75546852cf3e36
This check is meant to initialize BOARD_ODM_KERNEL_MODULES_LOAD to
BOARD_ODM_KERNEL_MODULES if BOARD_ODM_KERNEL_MODULES_LOAD is empty.
Bug: 157645635
Change-Id: I9c8ac0e64bb002e926d15b446a63801d7cfa9911
Merged-In: I9c8ac0e64bb002e926d15b446a63801d7cfa9911
Ramdisks are currently compressed using gzip, which is generally
smaller, but slower to decompress than lz4. Provide an option for an
lz4 scheme to reduce the time taken to unpack initramfs during boot.
Bug: 156129966
Signed-off-by: J. Avila <elavila@google.com>
Merged-In: Iac9538e6ee6ec51e6b487de2101f53bb5d9c54c8
Change-Id: Iac9538e6ee6ec51e6b487de2101f53bb5d9c54c8
When we do 64-32 migration, we want compare mode to be present only for
non-c++ actions as it would impact performance on 32-core machines
otherwise.
Bug: b/157414300
Test: Ran a build with "RBE_CXX_LINKS="true" RBE_CXX_LINKS_EXEC_STRATEGY="remote" RBE_CXX_COMPARE="false" RBE_compare="true" use_rbe mmma bionic"
and observed that local-executions happened only for link actions and
not for C++ actions.
Change-Id: Ia972c74d804085196a7b6ec755af63042c6b3909
Merged-In: Ia972c74d804085196a7b6ec755af63042c6b3909
The oem partition allows system build.prop to import properties from it
by "import /oem/oem.prop xxxx". An _ImportParser() error was raised on
this case.
BUG: 154171021
Test: 1) "atest --host releasetools_test releasetools_py3_test -c"
2) On a device who has oem partition, "make dist" and sign its
target zip file.
Change-Id: I47875bf7a698390e11690150e6516a3064550ca0
Merged-In: I47875bf7a698390e11690150e6516a3064550ca0
* changes:
Add an option to input the boot variables for OTA package generation
Reland "Calculate the runtime fingerprint prefixes from build prop"
Reland "Add a wrapper class PartitionBuildProp""
The values of the ro.boot* variables are not part of the image files
and are provided (e.g. by bootloaders) at runtime. Meanwhile, their
values may affect some of the device build properties, as a different
build.prop file can be imported by init during runtime.
This cl adds an option to accepts a list of possible values for some
boot variables. The OTA generation script later use these values to
calculate the alternative runtime fingerprints of the device; and
list the device names and fingerprints in the OTA package's metadata.
The OTA metadata is verified by the OTA server or recovery to ensure
the correct OTA package is used for update. We haven't made any
restrictions on what ro.boot* variables can be used for fingerprint
override. One possible candidate can be the skus listed in
ODM_MANIFEST_SKUS.
Bug: 152167826
Test: unittests pass, generate an OTA file with the new option
Change-Id: I637dea3472354236d2fd1ef0a3306712b3283c29
Merged-In: I637dea3472354236d2fd1ef0a3306712b3283c29
This reverts commit b21e48b499.
In practice, some partners use the 'import' statement to override
the device fingerprint at runtime. The runtime fingerprint will
later add to the metadata of OTA package, so that the OTA server
can deliver the package to corresponding devices correctly.
This CL supports parsing a subset of import statement that the init
process recognizes. And we loose the restriction based on how the
dynamic fingerprint is used in practice. Right now, we only searches
for the override of brand, name and device. And the placeholder
format should be ${placeholder}, with its value supplied by the
script caller.
As part of the implementation, we generate all the possible
combinations of the input boot variables. And recalculate the
fingerprint for each of the combination. Though we load the
build.prop multiple times, the logic is easier to follow. Also,
it's more convenient to enhance the logic if we only want to
allow some of the boot variables combination later.
Bug: 152167826
Change-Id: I4a9fa35c7ac037ff1cf4f9a4bdff602beac3894b
Merged-In: I4a9fa35c7ac037ff1cf4f9a4bdff602beac3894b
Test: unittests pass
This reverts commit 6022545272.
The build prop for a partition used to be a simple key:value
dictionary. But we need more fields to hold the alternative build
props overriden by the 'import' statement. Therefore, add a new
class as a wrapper for these props first.
Bug: 152167826
Change-Id: I5c952cd2a976ba1a09ddc66d56c2b8b55a61986b
Merged-In: I5c952cd2a976ba1a09ddc66d56c2b8b55a61986b
Test: unittests pass
include stub cellbroadcat app for data preservation by dafault.
Bug: 155844209
Change-Id: I34d1978ce89f4d4edbf327a3b61f7fb87262aae0
Merged-in: I34d1978ce89f4d4edbf327a3b61f7fb87262aae0
If the BoardConfig defined BOARD_VENDOR_RAMDISK_MODULES_LOAD and
BOARD_VENDOR_RAMDISK_RECOVERY_KERNEL_MODULES_LOAD, generate both a
modules.load and modules.load.recovery respectively on the vendor
ramdisk. BOARD_VENDOR_RAMDISK_MODULES must be the set, or super set,
of all the modules represented in both of *_LOAD BOARD variables.
Signed-off-by: Mark Salyzyn <salyzyn@google.com>
Bug: 151950334
Test: build, confirm, fastboot flashall, boot with split.
Merged-In: Ib2925aec6ea7a2a01a554c808d6697d8c85f9fc0
Change-Id: Ib2925aec6ea7a2a01a554c808d6697d8c85f9fc0
