30017e78bc
Recovery and fastbootd hardening. With GKI we find in certain situations the timing of the drivers loading is delayed as compared to a monolithic kernel. This exasperates an existing race where during second stage init, the graphics driver might not have completely instantiated by the time fastboot or recovery menu ui is being set up. To address this, we call gr_init() every 10ms until either 5 seconds timeout or success. If we timeout, there will be no TUI (minui), but this is better than if we just tried once and dropped the TUI and was effectively running headless. 5 seconds timeout is arbitrary, based on the default in init for wait for file; but makes sense as any longer will impact flashstation and fastboot flashall enough to be a cause for consternation. It should be noted that both recovery and fastbootd can still service adb or fastboot gadgets headless. For instance if the device tree is misconfigured as a permanent issue that would head for the timeout. Prefering to give up after a timeout so that device can be flashed by fastbootd, or rebooted by recovery adbd, over the protocol is advantageous for tool stability. Architectural Concern: The graphics driver, if not well written, may panic the kernel if we try to access it too soon while it is probing. On such devices it will be necessary to hold off in 'on init' or 'on early-init' phases until the graphics drivers have completely probed. Or better yet, fix the driver. This problem would happen in any case occasionally even without this adjustments, but could conceivably be amplified by the loop trying to open the graphics device. Signed-off-by: Mark Salyzyn <salyzyn@google.com> Bug: 151950334 Test: make sure user space fastbootd comes up reliably for a GKI kernel Change-Id: I1ce31a01544a58cdf7b9d657c1146bee77894e46 |
||
---|---|---|
.. | ||
include/recovery_ui | ||
Android.bp | ||
default_device.cpp | ||
device.cpp | ||
screen_ui.cpp | ||
stub_ui.cpp | ||
ui.cpp | ||
vr_device.cpp | ||
vr_ui.cpp | ||
wear_device.cpp | ||
wear_ui.cpp |