Xiaomi Mi Pad 5 Pro 5G (xiaomi-enuma)
|  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.0see Unixbench page on wiki | 
| Unixbench score Unixbench Whetstone/Dhrystone score. See Unixbench. | 0.0 | 
| 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]