Previously, we rely on mount points to copy files out of
efs partitions. Switch over to dump.f2fs to read directly
from block device without mounting. This allows us to copy
files out of efs partition in both 4K and 16K mode.
Test: Boot dev option enabled ext4 device
Bug: 340965747
Change-Id: I9d3f3d5200adc31f13298488b5be068b0fe7c7f4
This reduces the amount of computation needed on critical
boot path for F2FS devices. Boot time is expected to improve
with this patch.
Bug: 341216848
Test: boot device with ext4 and f2fs
Change-Id: I7311a22a7bf9773d3909656d98cc578a43cb9477
Products using 16KB kernel may wish to boot into 16KB mode
directly. To do this, these targets would need to use ext4
as their default fs type for /data and /metadata . Add
a build time flag which would install ext4 fstabs.
Test: th
Bug: 339337171
Change-Id: I53de1599bbff583b45ca2bf6d3e3efb83957913e
Common fstab entries(everything but /metadata and /data) are
moved to a separate fstab file.
This allows us to create an ext4 variant of the same fstab later.
Test: device boots
Bug: 339337171
Change-Id: I3129551c98b14473c776f2cf3dee1b81fc0c84b3
Since /persisit was previously mounted during eraly-init stage,
this CL delays the /persist mount to post-fs-data stage.
Actions which depends on the /persist partition are also moved.
Bug: 319335586
Change-Id: I6bcc775f16331905c6896f3a2ec5bbea9e20744f
During boot, this CL adds the following sequence of actions:
1. mount original efs partitions(most likely f2fs) on /mnt/vendor/efs
2. copy files in /mnt/vendor/efs to /data/vendor/copied/efs.img
3. fsync all the files in /data/vendor/copied/efs.img
4. rename /data/vendor/copied/efs.img to /data/vendor/copied/efs
5. bind-mount /data/vendor/copied/efs to /mnt/vendor/efs
6. repeat 1-5 for efs_backup and modem_userdata
The original EFS partitions are mounted and only used for file
copying, no destructive action done on original efs partitions.
Test: reformat /data as ext4, boot the device
Bug: 319335586
Change-Id: Ide78be316778acfc5c582c4a7b78853796cf4c1e
Revert submission 26822004
Reason for revert: Potential culprit for b/339099720- verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted changes: /q/submissionid:26822004
Change-Id: Ie9598a3b3b56c8ce26f475079798c44314696f44
Revert submission 26822004
Reason for revert: Potential culprit for b/339099720- verifying through ABTD before revert submission. This is part of the standard investigation process, and does not mean your CL will be reverted.
Reverted changes: /q/submissionid:26822004
Change-Id: I744fccbf1aacd817ca1a0c6f4a121393307c8797
Since /persisit was previously mounted during eraly-init stage,
this CL delays the /persist mount to post-fs-data stage.
Actions which depends on the /persist partition are also moved.
Bug: 319335586
Change-Id: I0e70f672b9a5f4b05b95dd30b0a74bb8f91f399a
During boot, this CL adds the following sequence of actions:
1. mount original efs partitions(most likely f2fs) on /mnt/vendor/efs
2. copy files in /mnt/vendor/efs to /data/vendor/copied/efs.img
3. fsync all the files in /data/vendor/copied/efs.img
4. rename /data/vendor/copied/efs.img to /data/vendor/copied/efs
5. bind-mount /data/vendor/copied/efs to /mnt/vendor/efs
6. repeat 1-5 for efs_backup and modem_userdata
The original EFS partitions are mounted and only used for file
copying, no destructive action done on original efs partitions.
Test: reformat /data as ext4, boot the device
Bug: 319335586
Change-Id: I4c4024b4cad18199226f5644f98254b2230574d6
When a user opts into 16K developer option, we would need to convert the
/data and /metadata partition into ext4. Add necessary fstab entries for
ext4 so that zuma devices can boot on ext4.
This CL does not automatically switch existing devices to ext4, the
newly added fstab entries are intentionally marked as "non-formattable",
so that we don't accidentally format a wiped device as ext4. This CL
merely allows the device to boot if the /data partition is already
formatted as ext4.
Test: adb shell cmd recovery wipe ext4 , make sure device boots
Bug: 293313353
Change-Id: I3a2a2e9d09cdea884f58b509a06c6829938dc369
Next CLs in this stack will make changes to persist/efs mount process
This CL will first move relevant code to a separate file for easier
review.
To support booting under 16K page size, we need to copy files on
persist partition(F2FS, which does not support 16K page size)
to data partition(which will would be EXT4 for dev option enabled
devices).
Bug: 319335586
Change-Id: I2750eb8b53431037cecc972448799409345f5ca3
Compression on apex disables direct IO for loopback, which introduces
double buffering and longer latency.
Bug: 298717358
Change-Id: I3b1de10f17931bec7769947bad62a22637a8a528
Signed-off-by: Jaegeuk Kim <jaegeuk@google.com>
From field data, sometimes kcompactd is
pretty activated and can impact critical
CUJs. Disable it first to mitigate the
impact.
Bug: 332916849
Test: boot
Change-Id: I87cdcf184afb5fe10e873162b94bd3bf54b1acbd
Signed-off-by: Martin Liu <liumartin@google.com>
DisplayPort kernel driver passes error code/status to hardware composer
via the dp_hotplug_error_code sysfs file. When HWC receives/consumes
the error, it will write "0" into that file to reset the error code. So
this file must be readable and writable by the HWC code running with
"system" user/group permissions.
Previously we used to set the ownership to system:system, but in order
to be more consistent with the rest of sysfs files in that directory,
we can use root:graphics instead with permissions 0664. HWC runs
under the "graphics" group, so this should allow HWC write access.
Bug: 324953626
Test: checked permissions of dp_hotplug_error_code sysfs
Change-Id: Idf65acc12d158a78565c41f4e2aea24362e2cdff
After USB enumeration, some SD card readers do not send signals to the
device when the SD card is inserted or removed.
To support SD card hotplugging, this patch enables in-kernel
media-presence polling, which will check the SD card status every 2
seconds after a SD card reader is attached.
Bug: 186479576
Test: SD card insertion/removal and data copy (see b/301566595)
Change-Id: I044aeffd9386c0bee6138402e5130c39e1adbc9f
Signed-off-by: Kuen-Han Tsai <khtsai@google.com>
We have observed more reclaiming activities as upstream
has changed how PCP high is calculated since 5.15 kernel.
Re-align the level back to 5.10 first so we can monitor
how it impacts the MM metrics.
Bug: 309409009
Test: boot
Change-Id: I7ac1eb88a8dae7c823330a2c75aec9547bd5c427
Signed-off-by: Martin Liu <liumartin@google.com>
Set `avb_keys=no_such_key` for dynamic kernel partitions to allow booting
unlocked devices with a custom kernel. This allows a few things:
1) Dogfooders can flash a custom kernel without wiping their device.
This can help developers track down hard-to-reproduce bugs without
rolling out a patch to the whole dogfooder population.
2) Developers can uprev their device's kernel without wiping their
device or packaging the kernel with an Android platform build.
Note: we are using "no_such_key" to ensure an AVB keys file doesn't
accidentally get created.
Test: Flash CI build. Then flash custom kernel on top.
Bug: 274825778
Change-Id: Ibf3cee491404b9efc18c49936edf64c2e3084adf
