Jump to content

Xiaomi Mi Pad 5 Pro 5G (xiaomi-enuma)

From postmarketOS Wiki
Xiaomi Mi Pad 5 Pro 5G
Xiaomi Pad 5 Pro running phosh ui with mainline kernel.
Xiaomi Pad 5 Pro running phosh ui with mainline kernel.
Manufacturer Xiaomi
Name Mi Pad 5 Pro 5G
Codename xiaomi-enuma
Released 2021
Type tablet
Hardware
Chipset Qualcomm Snapdragon 870 (SM8250-AC)
CPU Octa-core (1x3.2 GHz Kryo 585
3x2.42 GHz Kryo 585
4x1.80 GHz Kryo 585)
GPU Adreno 650
Display 2560x1600 120HZ IPS LCD
Storage 128/256 GiB
Memory 6/8 GiB
Architecture aarch64
Software
Original software
The software and version the device was shipped with.
Android 11 (MIUI 12.5)
Extended version
The most recent supported version from the manufacturer.
Android 13 (MIUI 14.0)
postmarketOS
Category community
Mainline
Instead of a Linux kernel fork, it is possible to run (Close to) Mainline.
yes
pmOS kernel
The kernel version that runs on the device's port.

6.17.0

see Unixbench page on wiki
Unixbench score
Unixbench Whetstone/Dhrystone score. See Unixbench.
0.0
Features
Flashing
Whether it is possible to flash the device with pmbootstrap flasher.
Works
USB Networking
After connecting the device with USB to your PC, you can connect to it via telnet (initramfs) or SSH (booted system).
Works
Internal storage
eMMC, SD cards, UFS...
Works
Battery
Whether charging and battery level reporting work.
Partial
Screen
Whether the display works; ideally with sleep mode and brightness control.
Works
Touchscreen
Works
Keyboard
Whether the built-in physical keyboard works.
Works
Stylus
Works
Multimedia
3D Acceleration
Works
Audio
Audio playback, microphone, headset and buttons.
Partial
Camera
Broken
Camera Flash
Works
Connectivity
WiFi
Works
Bluetooth
Works
GPS
Broken
Modem
Mobile data
Partial
Miscellaneous
FDE
Full disk encryption and unlocking with unl0kr.
Untested
USB OTG
USB On-The-Go or USB-C Role switching.
Works
Sensors
Accelerometer
Handles automatic screen rotation in many interfaces.
Works
Ambient Light
Measures the light level; used for automatic screen dimming in many interfaces.
Works
Hall Effect
Measures magnetic fields; usually used as a flip cover sensor
Broken

This is a 5G variant of the Xiaomi Mi Pad 5 Pro (xiaomi-elish) device.

Contributors

  • Wrobelda

Users owning this device

  • Wrobelda (Notes: mainlining in progress)


How to enter flash mode

Please see the instructions for Xiaomi Mi Pad 5 Pro (xiaomi-elish), the non-5G version of the same tablet.

Backup

Please see the instructions for Xiaomi Mi Pad 5 Pro (xiaomi-elish), the non-5G version of the same tablet.

Installation

Please see the instructions for Xiaomi Mi Pad 5 Pro (xiaomi-elish), the non-5G version of the same tablet.

Note: As opposed to the non-5G Elish version of the tabled, Enuma was only manufactured with a single type of the screen, so you can disregard any instructions on Elish wiki page regarding the panel type selection.

Issues

Please see the list of issues for Xiaomi Mi Pad 5 Pro (xiaomi-elish), the non-5G version of the same tablet, as they are virtually the same devices and any issue pertaining to Elish also applies here.

However, there are 5G modem issues specific to this device.

5G modem

Enuma has 5G modem, Qualcomm X55M, which sits on PCIe2 lane. Work is underway to get it working. The current issue is getting the modem to boot in PBL (Primary Boot Loader), which is what MHI expects.

With freshly booted enuma kernel, dmesg says:

[    9.407901] mhi-pci-generic 0002:01:00.0: MHI PCI device found: qcom-sdx55m
[    9.407923] mhi-pci-generic 0002:01:00.0: enabling device (0000 -> 0002)
[    9.470862] mhi mhi0: Requested to power ON
[    9.470891] mhi mhi0: Power on setup success
[    9.769004] mhi mhi0: Wait for device to enter SBL or Mission mode
[   17.633759] mhi-pci-generic 0002:01:00.0: failed to power up MHI controller
[   17.634512] mhi-pci-generic 0002:01:00.0: probe with driver mhi-pci-generic failed with error -110

Modem is visible over the PCI, but the X55's SoC (which is an ARM processor in itself) has not booted up yet. It needs to be brought up using the GPIOs, which control the state of the APU and the Modem chips on the X55 SoC, in a particular sequence. This is facilitated by the ESOC (External SoC) driver, which was backported from the Android downstream code.

[    0.376274] remoteproc remoteproc0: esoc0 is available

ESOC driver provides a character device (/dev/esoc-0), as well as DebugFS and an logging via IPC logging facility, all of which can help diagnose the status of the device.

$ cat /sys/kernel/debug/ipc_logging/esoc-mdm/log
[     0.375949583/         0x5fc8841] [mdm_disable_irqs]: Disabling the interrupts
[     0.376333073/         0x5fca4fa] [mdm_handle_clink_evt]: evt_state: ESOC_REQ_ENG_ON; Registered a req engine
[     0.376435938/         0x5fcacb0] [sdx55m_setup_hw]: Done configuring the GPIOs and esoc registration
[     0.376437969/         0x5fcacd6] [mdm_debug_gpio_ipc_log]: MDM2AP_ERRFATAL gpio = 547
[     0.376439271/         0x5fcacee] [mdm_debug_gpio_ipc_log]: AP2MDM_ERRFATAL gpio = 603
[     0.376440573/         0x5fcad08] [mdm_debug_gpio_ipc_log]: MDM2AP_STATUS gpio = 549
[     0.376441511/         0x5fcad1a] [mdm_debug_gpio_ipc_log]: AP2MDM_STATUS gpio = 602
[     0.376442292/         0x5fcad29] [mdm_debug_gpio_ipc_log]: AP2MDM_SOFT_RESET gpio = -1

(Note that the IPC log facility is a read-once circular buffer, i.e. the log buffer is emptied after retrieving its contents.)

Now, if you ask ESOC over the remoteproc to start the device:

$ printf 'start\0' > /sys/class/remoteproc/remoteproc0/state

Dmesg will show:

[16090.203679] remoteproc remoteproc0: powering up esoc0
[16090.213013] remoteproc remoteproc0: Booting fw image sdx55m/sbl1.mbn, size 548056
[16090.214097] ext-mdm soc@0:qcom,mdm0: SPMI warm reset failed

(assuming firmware file is present in /lib/firmware/sdx55m/sbl1.mbn)

and the IPC log reads:

[ 16090.214073112/      0x47f35847d0] [mdm_rproc_powerup]: Powerup request from SSR
[ 16090.214077122/      0x47f3584817] [mdm_rproc_powerup]: Boot trial: 0
[ 16090.214078633/      0x47f3584834] [mdm_rproc_powerup]: Req eng available
[ 16090.214080351/      0x47f3584855] [mdm_rproc_powerup]: In normal power-on mode
[ 16090.214081549/      0x47f358486c] [mdm_rproc_powerup]: Executing the ESOC_PWR_ON command
[ 16090.214083164/      0x47f358488b] [mdm_cmd_exe]: ESOC_PWR_ON: Setting AP2MDM_ERRFATAL = 0
[ 16090.214091758/      0x47f3584930] [mdm4x_do_first_power_on]: Powering on modem for the first time
[ 16090.214093216/      0x47f358494c] [sdx55m_toggle_soft_reset]: Doing a Warm reset using SPMI
[ 16090.214157955/      0x47f3584e27] [sdx55m_toggle_soft_reset]: SPMI warm reset failed
[ 16090.367950977/      0x47f3855ca3] [mdm4x_do_first_power_on]: Setting AP2MDM_STATUS = 1
[ 16090.367961289/      0x47f3855d67] [mdm4x_do_first_power_on]: Queueing the request: ESOC_REQ_IMG
[ 16090.367963529/      0x47f3855d92] [mdm_enable_irqs]: Enabling the interrupts
[ 16090.367979571/      0x47f3855ec6] [esoc_client_link_power_on]: Calling power_on hooks with flags: 0x0
[ 16090.367981654/      0x47f3855eee] [mdm_rproc_powerup]: Modem turned-on. Waiting for pon_done notification..

The modem is booted up using the SBL (Secondary Boot Loader) firmware provided. Now we need to manually tell MHI to initialize itself. This is normally done automatically in downstream, as the MHI driver there interfaces the ESOC driver directly (as evidenced by the esoc parameters present in /pcie2_rp-/mhi_0 node in downstream devicetree). However, ESOC driver has not been upstream (despite having been on Linaro's TODO in 2021 already: https://static.linaro.org/connect/lvc21/presentations/lvc21-123.pdf, p.21) and the upstream MHI driver does not know of ESOC, hence no communication here.

A simple rmmod mhi-pci-generic && modprobe mhi-pci-generic will result in:

[16670.865602] mhi-pci-generic 0002:01:00.0: MHI PCI device found: qcom-sdx55m
[16670.866616] mhi mhi0: Requested to power ON
[16670.866621] mhi mhi0: SECONDARY BOOTLOADER is not a valid EE for power on
[16670.866688] mhi-pci-generic 0002:01:00.0: failed to power up MHI controller
[16670.867182] mhi-pci-generic 0002:01:00.0: probe with driver mhi-pci-generic failed with error -5

My current understanding is that MHI expects the modem to be powered on into PBL (Primary Boot Loader) and is meant to take it into SBL stage from there. However, ESOC already puts the modem into SBL and there doesn't seem to be able to tell it stop at PBL only, giving MHI a chance to step in.

Note that putting the modem into PBL/SBL mode can technically be done without the ESOC driver's help, with a right sequence of PCIe RESET commands and/or control of the ap2mdm_active + mdm2ap_active GPIOs. ESOC driver is intended to help do this automatically and, together with the downstream 'mdm_helper', also automate the modem resetting whenever it fails for whatever reason and ends up errors state.

See also

Initial merge request: pmaports!7276

pmaports fork: [1]