'qcom,config-pipe-trust-reg' property doesn't seem to be
used by the qcom, bam_dma driver, so remove the same
from 'ipq6018' dts.
This is a preparatory patch for subsequent patch in
this series which converts the qcom_bam_dma device-tree
binding into YAML format.
Without this change, 'make dtbs_check' leads to the following
error:
$ arch/arm64/boot/dts/qcom/ipq6018-cp01-c1.dt.yaml:
dma-controller@704000: 'qcom,config-pipe-trust-reg' does not match
any of the regexes: 'pinctrl-[0-9]+'
Stephan Gerhold [Mon, 18 Oct 2021 13:36:56 +0000 (15:36 +0200)]
arm64: dts: qcom: Drop unneeded extra device-specific includes
For some reason apq8016-sbc, apq8096-db820c, msm8916-mtp and msm8996-mtp
were added as separate .dts and .dtsi files where the first only contains
the model name and the latter contains most of the actual definitions.
Perhaps this was done with the expectation that there would be other
devices also making use of exactly the same. However, this has not
been the case until now and it also seems unlikely in the future.
Having the extra .dtsi only clutters the file list and provides
little benefit.
Move the contents of the .dtsi into the .dts file to make this consistent
with most other devices that simply define everything in the .dts.
There are no functional changes introduced by this patch:
The compiled ".dtb"s are completely identical.
Stephan Gerhold [Mon, 18 Oct 2021 11:00:09 +0000 (13:00 +0200)]
arm64: dts: qcom: msm8916: Drop standalone smem node
SMEM can now be described directly in the reserved-memory.
This is mainly meant for newer SoCs where there is only one SMEM
region. However, even on older SoCs like MSM8916 there is clearly one
main SMEM region (described by "memory-region") that holds the
smem_header and one special extra region used only for data of the
RPM ("qcom,rpm-msg-ram").
The definition in reserved-memory also looks cleaner for older SoCs,
so make use of that in MSM8916 as well.
Stephan Gerhold [Mon, 18 Oct 2021 11:00:08 +0000 (13:00 +0200)]
arm64: dts: qcom: Fix node name of rpm-msg-ram device nodes
According to the new DT schema for qcom,rpm-msg-ram the node name
should be sram@. memory@ is reserved for definition of physical RAM
(usable by Linux).
This fixes the following dtbs_check error on various device trees:
memory@60000: 'device_type' is a required property
From schema: dtschema/schemas/memory.yaml
arm64: dts: qcom: msm8996: Add device tree entries to support crypto engine
The change adds description of Qualcomm crypto engine controller and
BAM associated with it. The change is inspired by commit 3e482859f1ef
("dts: qcom: sdm845: Add dt entries to support crypto engine.")
While performance of cryptographic algorithms executed on QCE is lower
than e.g. ones tinkered for ARM NEON, the offloaded execution would
make sense:
arm64: dts: qcom: msm8996: move clock-frequency from PN547 NFC to I2C bus
Although the early NXP NCI NFC bindings required the clock-frequency
property, it was never used by the driver and it is actually a property
of I2C bus, not I2C slave.
arm64: dts: qcom: sdm630: Add disabled Venus support
Add support for the Venus video decoder/encoder but leave it disabled
by default; it is expected to eventually get enabled in each machine
specific DT, where required.
This string- and electrical configuration depend on the board and panel,
and should hence not be defined generically for every user of pm660l.
SoMainline will pick this configuration again when enabling WLED on the
Sony Nile platform.
Marijn Suijten [Thu, 7 Oct 2021 21:33:58 +0000 (23:33 +0200)]
arm64: dts: qcom: pmi8994: Remove hardcoded linear WLED enabled-strings
The driver now sets an appropriate default for WLED4 (and WLED5) just
like WLED3 making this linear array from 0-3 redundant. In addition the
driver is now able to parse arrays of variable length solving the "all
four strings *have to* be defined" comment.
Besides the driver will now warn when both properties are specified to
prevent ambiguity: the length of the array is enough to imply a set
number of strings.
Herobrine is a Chrome OS board/platform based on the QCA SC7280.
Add a .dtsi for the platform parts and a .dts for the board
specific bits. Currently the .dtsi has everything except the
compatible strings, things will likely get shuffled around in the
future as we learn more about the differences between boards.
Per QMP PHY bindings schema, 'vdda-phy-supply' and 'vdda-phy-supply' are
required for IPQ8074 QMP USB3 PHY. Since supplies are not added in DTS
for this platform, add a dummy regulator as the supply to QMP USB3 PHY,
so that dtbs_check stops complaining the missing supplies.
IPQ8074 PCIe PHY nodes are broken in the many ways:
- '#address-cells', '#size-cells' and 'ranges' are missing.
- Child phy/lane node is missing, and the child properties like
'#phy-cells' and 'clocks' are mistakenly put into parent node.
- The clocks properties for parent node are missing.
Fix them to get the nodes comply with the bindings schema.
'vdda-phy-supply' and 'vdda-pll-supply' are required properties. Add
them to fix the dtbs_check warnings below.
phy@1da7000: 'vdda-phy-supply' is a required property
arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dt.yaml
arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dt.yaml
arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dt.yaml
phy@1da7000: 'vdda-pll-supply' is a required property
arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dt.yaml
arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dt.yaml
arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dt.yaml
arm64: dts: qcom: Drop reg-names from QMP PHY nodes
The 'reg-names' is not a supported/used property. Drop it from QMP PHY
nodes to fix dtbs_check warnings like below.
phy-wrapper@88e9000: 'reg-names' does not match any of the regexes: '^phy@[0-9a-f]+$', 'pinctrl-[0-9]+'
arch/arm64/boot/dts/qcom/sm8350-hdk.dt.yaml
arch/arm64/boot/dts/qcom/sm8350-mtp.dt.yaml
Many child nodes of QMP PHY are named without following bindings schema
and causing dtbs_check warnings like below.
phy@1c06000: 'lane@1c06800' does not match any of the regexes: '^phy@[0-9a-f]+$'
arch/arm64/boot/dts/qcom/msm8998-asus-novago-tp370ql.dt.yaml
arch/arm64/boot/dts/qcom/msm8998-hp-envy-x2.dt.yaml
arch/arm64/boot/dts/qcom/msm8998-lenovo-miix-630.dt.yaml
arch/arm64/boot/dts/qcom/msm8998-mtp.dt.yaml
arch/arm64/boot/dts/qcom/msm8998-oneplus-cheeseburger.dt.yaml
arch/arm64/boot/dts/qcom/msm8998-oneplus-dumpling.dt.yaml
Douglas Anderson [Wed, 29 Sep 2021 22:38:14 +0000 (15:38 -0700)]
arm64: dts: qcom: pmk8350: Make RTC disabled by default; enable on sc7280-idp
The RTC on the pmk8350 is not useful on all boards. Some boards may
not provide backup power to the PMIC but might have another RTC on the
board that does have backup power. In this case it's better to not use
the RTC on the PMIC.
At the moment, the only boards that includes this PMIC are sc7280-idp
and sc7280-idp2. On sc7280-idp I'm not aware of any other RTCs, but
sc7280-idp2 has a Chrome OS EC on it and this is intended to provide
the RTC for the AP.
Let's do what we normally do for hardware that's not used by all
boards and set it to a default status of "disabled" and then enable it
on the boards that need it.
NOTE: for sc7280-idp it's _possible_ we might also want to add
`allow-set-time;`. That could be the subject of a future patch if it
is indeed true.
Signed-off-by: Douglas Anderson <dianders@chromium.org> Reviewed-by: Satya Priya <skakit@codeaurora.org> Reviewed-by: Stephen Boyd <swboyd@chromium.org> Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
[bjorn: Enable the RTC on the MTP as well] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210929153553.1.Ib44c2ac967833d7a3f51452d44d15b7b8d23c1f0@changeid
Amit Pundir [Thu, 30 Sep 2021 18:57:42 +0000 (00:27 +0530)]
arm64: dts: qcom: qrb5165-rb5: Add msm-id and board-id
Add qcom,msm-id and qcom,board-id for Robotics Board RB5.
This will help us boot the device with newer Android boot
image header versions, which package dtb separately
instead of the default Image.gz-dtb (appended dtb) format.
Amit Pundir [Thu, 30 Sep 2021 18:57:41 +0000 (00:27 +0530)]
arm64: dts: qcom: sdm845-db845c: Add msm-id and board-id
Add qcom,msm-id and qcom,board-id for Dragonboard 845c.
This will help us boot the device with newer Android boot
image header versions, which package dtb separately
instead of the default Image.gz-dtb (appended dtb) format.
Konrad Dybcio [Sat, 2 Oct 2021 00:13:58 +0000 (02:13 +0200)]
arm64: dts: qcom: sdm845: Move gpio.h inclusion to SoC DTSI
Almost any board that boots and has a way to interact with it
(say for the rare cases of just-pstore or let's-rely-on-bootloader-setup)
needs to set some GPIOs, so it makes no sense to include gpio.h separately
each time. Hence move it to SoC DTSI.
Konrad Dybcio [Sat, 2 Oct 2021 00:13:57 +0000 (02:13 +0200)]
arm64: dts: qcom: sdm845: Add size/address-cells to dsi[01]
Add the aforementioned properties in the SoC DTSI so that everybody doesn't
have to copy that into their device DTs, effectively reducing code
duplication.
Konrad Dybcio [Sat, 2 Oct 2021 00:13:55 +0000 (02:13 +0200)]
arm64: dts: qcom: sdm845: Disable Adreno, modem and Venus by default
Components that rely on proprietary (not to mention signed!) firmware should
not be enabled by default, as lack of the aforementioned firmware could cause
various issues, from random errors to straight-up failing to boot.
Re-enable these remote processors on boards that didn't previously explicitly
disable them.
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@somainline.org> Signed-off-by: Konrad Dybcio <konrad.dybcio@somainline.org> Tested-By: Steev Klimaszewski <steev@kali.org>
[bjorn: Added missing changes to db845c and lenovo-yoga-c630 to the patch] Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20211002001358.45920-3-konrad.dybcio@somainline.org
Stephan Gerhold [Mon, 4 Oct 2021 20:49:55 +0000 (22:49 +0200)]
ARM: dts: qcom: msm8916-samsung-serranove: Include dts from arm64
After adding all necessary support for MSM8916 SMP/cpuidle without PSCI
on ARM32, build the Samsung Galaxy S4 Mini VE device tree from the arm64
tree together with the ARM32 include to allow booting this device on ARM32.
The approach to include device tree files from other architectures is
inspired from e.g. the Raspberry Pi (bcm2711-rpi-4-b.dts) where this is
used to build the device tree for both ARM32 and ARM64.
Stephan Gerhold [Mon, 4 Oct 2021 20:49:54 +0000 (22:49 +0200)]
ARM: dts: qcom: msm8916: Add include for SMP without PSCI on ARM32
Add a special device tree include for MSM8916 on ARM32 that sets up
SMP and cpuidle without PSCI. This is meant for devices with signed
firmware that does not support PSCI and only allows booting ARM32 kernels.
Stephan Gerhold [Mon, 4 Oct 2021 20:49:53 +0000 (22:49 +0200)]
arm64: dts: qcom: msm8916: Add CPU ACC and SAW/SPM
Add the device tree nodes necessary for SMP bring-up and cpuidle
without PSCI on ARM32. The hardware is typically controlled by the
PSCI implementation in the TrustZone firmware and is therefore marked
as status = "reserved" by default (from the device tree specification):
"Indicates that the device is operational, but should not be used.
Typically this is used for devices that are controlled by another
software component, such as platform firmware."
Since this is part of the MSM8916 SoC it should be added to msm8916.dtsi
but in practice these nodes should only get enabled via an extra include
on ARM32.
This is necessary for some devices with signed firmware which is missing
both ARM64 and PSCI support and can therefore only boot ARM32 kernels.
Stephan Gerhold [Mon, 4 Oct 2021 20:49:47 +0000 (22:49 +0200)]
ARM: qcom: Add ARCH_MSM8916 for MSM8916 on ARM32
Add a CONFIG_ARCH_MSM8916 option to enable building MSM8916 support
on ARM32. Note that since ARM64 is the main supported architecture
for MSM8916 this is only intended for testing and for devices where
signed firmware does not allow booting ARM64 kernels.
The LTE version of the S4 Mini VE has a NXP PN547, which is supported
by the nxp-nci-i2c driver in mainline. It seems to detect NFC tags
using "nfctool" just fine, although more testing is difficult given
there seem to be very few useful applications making use of the
Linux NFC subsystem. :(
Note that for some reason Samsung decided to connect the I2C pins
to GPIOs where no hardware I2C bus is available, so we need to
fall back to software bit-banging with i2c-gpio.
Like the Samsung Galaxy A3/A5, the S4 Mini VE uses a Richtek RT5033 PMIC
as battery fuel gauge, charger, flash LED and for some regulators.
For now, only add the fuel gauge/battery device to the device tree,
so we can check the remaining battery percentage.
The other RT5033 drivers need some more work first before
they can be used properly.
Add the CORERIVER TC360 touch key together with the two necessary
fixed regulators for it.
Note that for some reason Samsung decided to connect this to GPIOs
where no hardware I2C bus is available, so we need to fall back
to software bit-banging using i2c-gpio.
Stephan Gerhold [Mon, 4 Oct 2021 20:19:07 +0000 (22:19 +0200)]
arm64: dts: qcom: Add device tree for Samsung Galaxy S4 Mini Value Edition
The Samsung Galaxy S4 Mini Value Edition is an updated version of the
original S4 Mini based on MSM8916. It is similar to the other Samsung
devices based on MSM8916 with only a few minor differences.
The device tree contains initial support for the S4 Mini Value Edition with:
- UART
- eMMC/SD card (needs quirk for some reason)
- Buttons
- Vibrator
- WiFi/Bluetooth (WCNSS)
- USB
Unfortunately, the S4 Mini VE was released with outdated 32-bit only
firmware and never received any update from Samsung. Since the 32-bit
TrustZone firmware is signed there seems to be no way currently to
actually boot this device tree on arm64 Linux at the moment. :(
However, it is possible to use this device tree by compiling an ARM32 kernel
instead. The device tree can be easily built on ARM32 with an #include
and it works really well there. To avoid confusion for others it is still
better to add this device tree on arm64. Otherwise it's easy to forget
to update this one when making some changes that affect all MSM8916 devices.
Maybe someone finds a way to boot ARM64 Linux on this device at some point.
In this case I expect that this device tree can be simply used as-is.
Luca Weiss [Thu, 7 Oct 2021 21:24:37 +0000 (23:24 +0200)]
arm64: dts: qcom: Add SM7225 device tree
The Snapdragon 750G (sm7225) is software-wise very similar to Snapdragon
690 (sm6350) with minor differences in clock speeds and as added here,
it uses the Kryo 570 instead of Kryo 560.
Caleb Connolly [Wed, 20 Oct 2021 16:36:59 +0000 (16:36 +0000)]
arm64: dts: qcom: sdm845-oneplus: enable second wifi channel
Like the c630, the OnePlus 6 is also capable of using both antenna
channels for 2.4 and 5ghz wifi, however unlike the c630 only the first
channel is used for bluetooth.
Now that the pmic-mpp is a proper hierarchical IRQ chip, add interrupt
controller properties ('interrupt-controller' and '#interrupt-cells').
The interrupts property is no longer needed so remove it.
Now that the pmic-mpp is a proper hierarchical IRQ chip, add interrupt
controller properties ('interrupt-controller' and '#interrupt-cells').
The interrupts property is no longer needed so remove it.
arm64: dts: qcom: apq8016-sbc: fix mpps state names
The majority of device tree nodes for mpps use xxxx-state as pinctrl
nodes. Change names of mpps pinctrl nodes for the apq8016-sbc board to
follow that pattern.
arm64: dts: qcom: pm8994: fix mpps device tree node
Add missing "qcom,spmi-mpp" to the compatible list as required by the
node description. Also add gpio-ranges property to mpps device tree
node, adding the mapping between pinctrl and GPIO pins.
arm64: dts: qcom: pm8916: fix mpps device tree node
Add missing "qcom,spmi-mpp" to the compatible list as required by the
node description. Also add gpio-ranges property to mpps device tree
node, adding the mapping between pinctrl and GPIO pins.
Arnaud Ferraris [Sat, 16 Oct 2021 10:20:24 +0000 (12:20 +0200)]
arm64: dts: qcom: add 'chassis-type' property
A new 'chassis-type' root node property has recently been approved for
the device-tree specification, in order to provide a simple way for
userspace to detect the device form factor and adjust their behavior
accordingly.
This patch fills in this property for end-user devices (such as laptops,
smartphones and tablets) based on Qualcomm ARM64 processors.
arm64: dts: qcom: sdm845: Drop standalone smem node
Now that the SMEM binding and driver allows the SMEM node to be
described in the reserved-memory region directly, move the compatible
and hwlock properties to the reserved-memory node and drop the
standadlone node.
Stephan Gerhold [Tue, 21 Sep 2021 15:21:19 +0000 (17:21 +0200)]
arm64: dts: qcom: msm8916: Drop underscore in node name
Using underscores in device tree nodes is not very common.
Additionally, the _region suffix in "smem_region@..." is not really
useful since it's obvious that it describes a reserved memory region.
Commit 0f6b380d580c ("arm64: dts: qcom: apq8016-sbc: Update modem and WiFi
firmware path") added "firmware-name"s to the APQ8016 SBC (DB410c) device
tree to separate the (test key)-signed firmware from other devices.
However, the added names are a bit confusing. The "modem" firmware used by
DB410c is actually a simplified version for APQ8016 that lacks most of the
modem functionality (phone calls, SMS etc) that is available on MSM8916.
Placing it in "qcom/msm8916/modem.mbn" suggests that it supports all
functionality for MSM and not just the reduced functionality for APQ.
Request the firmware from "qcom/apq8016/modem.mbn" instead to clarify this.
Do the same for "wcnss.mbn" for consistency (although the WCNSS firmware
works just fine on MSM8916).
Finally, add a "_sbc" suffix to the WCNSS_qcom_wlan_nv.bin firmware file.
It seems like the nv.bin firmware is somewhat board specific and can
therefore vary a bit from device to device. This makes it more clear
which board it is intended to be used for.
arm64: dts: qcom: sm6125: Improve indentation of multiline properties
Some multiline properties (spread out over multiple lines to keep length
in check) were not indented properly, leading to misalignment with the
items above. The DT file is still small enough to address this early in
the process.
Stephan Gerhold [Tue, 28 Sep 2021 11:29:45 +0000 (13:29 +0200)]
arm64: dts: qcom: msm8916-longcheer-l8150: Use &pm8916_usbin extcon
At the moment, longcheer-l8150 is using a dummy extcon-usb-gpio device
that permanently enables USB gadget mode. This workaround allows USB
to work but is actually wrong and confusing. The "vbus-gpio" used there
refers to an unused (floating) GPIO that is pulled up to make
extcon-usb-gpio report USB gadget mode permanently.
Replace this with the new &pm8916_usbin extcon device that actually
reports if an USB cable is attached or not. This allows the USB PHY
to be turned off when there is no USB cable attached and is much
cleaner overall.
Stephan Gerhold [Tue, 28 Sep 2021 11:29:44 +0000 (13:29 +0200)]
arm64: dts: qcom: pm8916: Add pm8941-misc extcon for USB detection
At the moment, USB gadget mode on MSM8916 works only with an extcon
device that reports the correct USB mode. This might be because the
USB PHY needs to be configured appropriately.
Unfortunately there is currently no simple approach to get such an
extcon device during early bring-up. The extcon device for USB VBUS
(i.e. gadget/peripheral mode) is typically provided by the charging
driver which is almost always very complex to port.
On pretty much all devices with PM8916, the USB VBUS is also connected
to the PM8916 "USB_IN" pad, no matter if they use the linear charger
integrated into PM8916 or not. The state of this pad can be checked
with the "USBIN_VALID" interrupt of PM8916.
The "qcom,pm8941-misc" binding exists to expose an "usb_vbus" and/or
"usb_id" interrupt from the PMIC as an extcon device.
Add a &pm8916_usbin node to pm8916.dtsi which can be used as simple
extcon device for devices that are currently lacking a proper charger
driver.
Stephan Gerhold [Tue, 28 Sep 2021 11:29:43 +0000 (13:29 +0200)]
arm64: dts: qcom: pm8916: Remove wrong reg-names for rtc@6000
While removing the size from the "reg" properties in pm8916.dtsi,
commit bd6429e81010 ("ARM64: dts: qcom: Remove size elements from
pmic reg properties") mistakenly also removed the second register
address for the rtc@6000 device. That one did not represent the size
of the register region but actually the address of the second "alarm"
register region of the rtc@6000 device.
Now there are "reg-names" for two "reg" elements, but there is actually
only one "reg" listed.
Since the DT schema for "qcom,pm8941-rtc" only expects one "reg"
element anyway, just drop the "reg-names" entirely to fix this.
Fixes: bd6429e81010 ("ARM64: dts: qcom: Remove size elements from pmic reg properties") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org> Link: https://lore.kernel.org/r/20210928112945.25310-1-stephan@gerhold.net
This device has a physical matrix keyboard, connected to a GPIO
expander, for which there's still no support yet.
Though, some of the keys are connected to the MSM8998 GPIOs and not
as a matrix, so these can be added.
Stephan Gerhold [Mon, 16 Aug 2021 18:18:10 +0000 (20:18 +0200)]
arm64: dts: qcom: msm8916: Fix Secondary MI2S bit clock
At the moment, playing audio on Secondary MI2S will just end up getting
stuck, without actually playing any audio. This happens because the wrong
bit clock is configured when playing audio on Secondary MI2S.
The PRI_I2S_CLK (better name: SPKR_I2S_CLK) is used by the SPKR audio mux
block that provides both Primary and Secondary MI2S.
The SEC_I2S_CLK (better name: MIC_I2S_CLK) is used by the MIC audio mux
block that provides Tertiary MI2S. Quaternary MI2S is also part of the
MIC audio mux but has its own clock (AUX_I2S_CLK).
This means that (quite confusingly) the SEC_I2S_CLK is not actually
used for Secondary MI2S as the name would suggest. Secondary MI2S
needs to have the same clock as Primary MI2S configured.
Fix the clock list for the lpass node in the device tree and add
a comment to clarify this confusing naming. With these changes,
audio can be played correctly on Secondary MI2S.
So far there were no interrupts set up for the BMC150 accelerometer
+ magnetometer combo because they were broken for some reason.
It turns out Longcheer L8150 actually has a BMC156 which is very similar
to BMC150, but only has an INT2 pin for the accelerometer part.
This requires some minor changes in the bmc150-accel driver which is now
supported by using the more correct bosch,bmc156_accel compatible.
Unfortunately it looks like even INT2 is not functional on most boards
because the interrupt line is not actually connected to the BMC156.
However, there are two pads next to the chip that can be shorted
to make it work if needed.
While at it, add the missing interrupts for the magnetometer part
and extra BMG160 gyroscope, those seem to work without any problems.
Also correct the magnetometer compatible to bosch,bmc156_magn for clarity
(no functional difference for the magnetometer part).
Konrad Dybcio [Thu, 23 Sep 2021 16:22:02 +0000 (18:22 +0200)]
arm64: dts: qcom: sm6350: Add device tree for Sony Xperia 10 III
Add initial SM6350 SoC and Sony Xperia 10 III (PDX213, Lena platform) device
trees. There is no sign of another Lena devices on the horizon, so a common
DTSI is not created for now. 10 III features a Full HD OLED display and 5G
support, among other nice things like USB3.
The bootloader is VERY unpleasant, to get a bootable setup you have to run:
// You have to either pull vbmeta{"","_system"} from
// /dev/block/bootdevice/by-name/ or build one as a part of AOSP build process
fastboot --disable-verity --disable-verification flash vbmeta vbmeta.img
fastboot --disable-verity --disable-verification flash vbmeta_system \
vbmeta_system.img
fastboot flash boot mainline.img
fastboot erase dtbo // This will take approx 70s...
fastboot reboot
projects / thirdparty / kernel / linux.git / log
