This file contained incorrect commented-out conditionals that
were apparently copied and pasted from somewhere. Fix them to
match gs101 configuration.
Bug: 212047904
Test: build master-without-vendor
Change-Id: Ibecd05d6e5cf1ee94be57203b63c6aec3cab8aa6
Moving vendor_dlkm.modules.blocklist to the source repo and picking to
/<DEVICE>-kernel, the development experience can be aligned between
Kernel and Android codebase.
Bug: 214017561
Change-Id: Ia9994121309a8a0e5a664b64c51ffb3ad9110747
intermediates-dir-for relies on several variables that
haven't been set at the time the board configuration
runs. The board configuration got around that by using
deferred expansion, but deferred expansion is something
that starlark doesn't support. Remove intermediates-dir-for
and switch to TARGET_RECOVERY_FSTAB_GENRULE.
Bug: 201700692
Test: m RBC_BOARD_CONFIG=1 nothing on gs201 products
Change-Id: I74bf8700161f6519d29b2b3634a286c4e758d136
Remove option for _64 and default to 64-bit only builds.
Removes the (out of date) manifest_64 files.
Removes OMX since it is not supported for 64-bits.
Bug: 213924541
Test: Build, Boot, YouTube playback, Play store, Camera
Signed-off-by: Pat Tjin <pattjin@google.com>
Change-Id: I1e97903b598a2fff46d912a009b2bc73f1b0f466
Add a file "fstab.gs201-fips" alongside the existing "fstab.gs201" in
order to specify different encryption settings in FIPS mode.
"androidboot.fstab_suffix=gs201-fips" on the kernel command line will be
used to select the FIPS fstab when needed.
As the two fstabs should be otherwise identical, generate them from a
template file so that they will stay in sync.
Note that generating the fstabs requires that they be installed as build
system modules rather than via PRODUCT_COPY_FILES, which results in the
vendor_ramdisk copy of the fstabs being installed to system/etc rather
than /. This shouldn't cause any problem, now that Android has been
updated to look for the fstab in this location too.
(cherry-pick from device/google/gs101)
Test: Boot to home screen with/without fips mode
Bug: 202417706
Signed-off-by: Konstantin Vyshetsky <vkon@google.com>
Change-Id: I8fdc1c9a91399816fa2d4c53f282d63e988ce7d5
Kernel modules on the blocklist are not automatically loaded during
second stage init. Modules are often put on the blocklist if we want
them to get loaded only under certain circumstances.
Bug: 192241728
Change-Id: I05d55f8a2854619b92defcf3fb11cc2b87a8dab6
Previously, we copied all available kernel modules into the vendor_boot
ramdisk except for approx. 14 modules that we explicitly excluded.
Going forward, the kernel build will distribute the two additional files
vendor_boot.modules.load and vendor_dlkm.modules.load which define,
respectively, the lists of modules that should be loaded from
vendor_boot and vendor_dlkm.
The contents of the two *.modules.load files will be copied almost
verbatim into modules.load files in the respective images except for the
fact that the directory names of the .ko files are stripped. So, for
example, kernel/net/core/pktgen.ko becomes just pktgen.ko.
Additionally, we only copy those .ko files into the vendor_boot image
that are listed in vendor_boot.modules.load. On the other hand, the
vendor_dlkm partition image will contain all .ko files regardless of
whether they are listed in vendor_dlkm.modules.load.
Bug: 190652328
Change-Id: I6fc41a0143e7253f193cac509ba30506feb4e2d9
They aren't needed for first-stage boot, and can be loaded from
`/vendor` and `/vendor_dlkm`.
Bug: 189506395
Test: boot to home
Change-Id: Ib4c708c8631586cf25e1535035b8bc81f727ef5f
