note pro 国际版
Back in November 2019, Xiaomi sent some of us the Redmi Note 8 Pro through XDA, to play with and mod. The Redmi Note 8 Pro is powered by the MediaTek G90T (mt6785), a platform most of us in the custom ROM world aren’t used to.
早在2019年11月， 小米就通过XDA向我们中的一些人发送了Redmi Note 8 Pro ，以与and mod一起玩。 Redmi Note 8 Pro由联发科G90T(mt6785)驱动，在定制ROM世界中我们大多数人都不习惯使用该平台。
I personally enjoy tinkering with anything and everything that can boot Linux and Android, and this device was no exception. After all, we have the OEM’s proprietary firmware, and given the recent developments of Project Treble, it shouldn’t be too hard to reverse and stitch things together right? Let’s find out.
我个人喜欢修改可以启动Linux和Android的所有内容，并且该设备也不例外。 毕竟，我们拥有OEM专有的固件，并且考虑到Project Treble的最新发展，将这些东西反向组合在一起应该不是很难吗？ 让我们找出答案。
Before anything, let’s take a moment to appreciate how pretty the device is. Sure, there are better looking devices, but I haven’t seen a white phone look this good in different lighting conditions.
在开始之前，让我们花一点时间欣赏一下设备的美观程度。 当然，有更好看的设备，但我还没有看到白色手机在不同的照明条件下看起来如此好。
联发科技与Custom ROM世界 (MediaTek and the Custom ROM world)
Over the last decade, MediaTek devices have earned an awful reputation where many believe that the devices run hot, waste battery, are slow and are not “developer-friendly”. You see, since 2010, many manufacturers have been creating “budget” smartphones using MediaTek platforms that are often rebrands of generic cheap Chinese phones. In addition to this, MediaTek does not opensource it’s BSP (Board Support Package) at all, unlike Qualcomm (in the form of CodeAurora Forums, or CAF for short). This often compels people buying cheap devices today, to opt for a Qualcomm equivalent. In the last few years however, commercial MTK devices have been getting better and the Redmi Note 8 Pro is no exception. Xiaomi was nice enough to opensource the Kernel (and Kernel modules), which makes a crucial part of development in the later stages. Let’s find out how such a strange machine can be so unique, yet so familiar.
在过去的十年中，联发科技的设备赢得了极高的声誉，许多人认为这些设备运行温度高，电池浪费，运行缓慢且对开发人员不友好。 您会看到，自2010年以来，许多制造商一直在使用联发科技平台创建“预算”智能手机，这些平台通常是通用廉价中国手机的品牌。 除此之外，与高通公司不同( 联通科技不以CODEAurora论坛或简称CAF形式)，联发科根本不开源其BSP(董事会支持软件包)。 这通常迫使人们今天购买廉价设备，而选择与之类似的高通公司。 然而，在过去几年中，商用MTK设备已经变得越来越好，Redmi Note 8 Pro也不例外。 小米足以将内核 (和内核模块 ) 开源 ，这在以后的开发中至关重要。 让我们找出这样一台奇怪的机器如何如此独特却又如此熟悉。
入门 (Getting Started)
So, our first step would be to unlock the bootloader (of course), identify the product and figure out what code and firmware we already have. Xiaomi has a fancy unlock process in place, which involves binding the device to a Mi Account and applying for an unlock. It normally takes a week to unlock the bootloader. During this week, I started looking into the kernel sources and MIUI dumps to see how we could get the device to run cool stuff. The Redmi Note 8 Pro has 2 variants, namely “begonia” and “begoniain”. “begoniain” is simply the Indian variant and lacks NFC hardware. This wasn’t a big deal, given they used the same kernel and their software was mostly interchangeable.
因此，我们的第一步将是解锁引导加载程序(当然)，确定产品并弄清楚我们已经拥有的代码和固件。 小米有一个不错的解锁流程，其中涉及将设备绑定到Mi帐户并申请解锁。 解锁引导加载程序通常需要一周的时间。 在本周中，我开始研究内核源代码和MIUI转储，以了解如何使设备运行出色的东西。 Redmi Note 8 Pro有2个变体，分别是“秋海棠”和“秋海棠”。 “ begoniain”仅仅是印度的变体， 缺少NFC硬件 。 考虑到他们使用相同的内核并且他们的软件大部分是可互换的，所以这没什么大不了的。
初步发展 (Initial developments)
Now, as per tradition, I decided to work on getting TWRP up and running first. Team Win Recovery Project (or TWRP for short) is a Custom Android Recovery that provides for a friendly touch interface and allows users to install OTA packages, make and restore full device backups (famously known as “nandroid” backups). These OTA packages give us the ability to run scripts before and after writing partitions as necessary, making the user’s life a lot easier. An Android Recovery contains it’s own kernel, thus killing two birds with one stone. Though the kernel didn’t compile out of the box, it was by no means “incomplete”. It was missing a few things, but it was pretty simple to figure it out and patch up. Within 2–3 days of unlocking my device’s bootloader, I had the kernel compiling and TWRP booting!
现在，按照传统，我决定首先启动并运行TWRP。 Team Win Recovery项目(或简称TWRP)是一个自定义Android恢复程序，它提供了友好的触摸界面，并允许用户安装OTA软件包，进行和还原完整的设备备份(众所周知的“ nandroid”备份)。 这些OTA软件包使我们能够根据需要在编写分区之前和之后运行脚本，从而使用户的工作变得更加轻松。 Android Recovery包含其自己的内核，因此用一块石头杀死了两只鸟。 尽管内核不是开箱即用的，但绝不是“不完整”的。 它遗漏了一些东西，但是弄清楚并修补它非常简单。 在解锁设备的引导加载程序的两到三天内，我进行了内核编译和TWRP引导！
Fast-forward a few days, I start working on getting POSP (an AOSP derivative) to boot. Why POSP? Why not Lineage or something more conventional? I happen to be the Founder and Lead of POSP and let’s be real, there is pretty much no difference when it comes to device porting; Everything is AOSP and proprietary vendor services take care of most issues thanks to Treble. Within no time, I managed to reach the boot animation.
几天后，我开始着手启动POSP (一种AOSP衍生产品)启动。 为什么选择POSP？ 为什么不沿袭或更传统的东西呢？ 我恰好是POSP的创始人和负责人，让我们成为现实，在设备移植方面几乎没有什么区别。 一切都是AOSP，并且得益于Treble ，专有的供应商服务可以解决大多数问题。 我很快就找到了启动动画。
Buuuut, that’s where the fun ends. For now.
Buuuut，那就是乐趣的尽头。 目前。
A few days later, I encounter multiple hard-bricks while experimenting. A “hard-brick” is slang used to indicate a catastrophic software failure that, more often than not, cannot be fixed with conventional tools. While the reason for the bricks were probably stupid, it helps us understand how the device’s download mode (aka EDL) work and will be of great help at a later point.
几天后，我在进行实验时遇到了很多难题。 “硬砖”是一种lang语，用于表示灾难性的软件故障，而该故障通常是无法用常规工具修复的。 尽管造成砖块的原因可能是愚蠢的，但它可以帮助我们了解设备的下载模式(又名EDL)如何工作，并且在以后会有所帮助。
卡在BootROM下载 (Stuck in BootROM download)
To understand what’s happening here, let us understand a conventional MediaTek platform boot sequence and partition layout on the Redmi Note 8 Pro.
要了解此处发生的情况，请让我们了解Redmi Note 8 Pro上常规的MediaTek平台启动顺序和分区布局。
Checking /dev/block/platform/bootdevice/by-name, we can see what we’re working with:
检查/ dev / block / platform / bootdevice / by-name ，我们可以看到我们正在使用什么：
We can see, sda and sdb contain the preloader(s) and sdc contains pretty much everything else. The boot sequence is rather straightforward. While some specifics may not be completely correct (remember, all this is proprietary and the following were determined by observing behavior, logs and from other blogs):
我们可以看到，sda和sdb包含预加载器，而sdc包含几乎所有其他内容。 引导顺序非常简单。 尽管某些细节可能并不完全正确(请记住，所有这些都是专有的，并且以下内容是通过观察行为，日志和其他博客确定的)：
BootROM (BROM) — At the beginning of SoC init, once the CPU has initialized itself, the internal SRAM controller pushes a jump instruction to the address of BootROM, which is a small program that will initialize the flash storage and do some basic UART setup. The UART interface is still not ready yet. BootROM will check storage and try to load a working Preloader from the flash storage. BootROM may also implement security to prevent unauthorized alteration to the storage.
BootROM(BROM) —在SoC初始化开始时，一旦CPU自身初始化，内部SRAM控制器便将跳转指令压入BootROM的地址，这是一个小程序，它将初始化闪存并进行一些基本的UART设置。 UART接口仍未准备好。 BootROM将检查存储，并尝试从闪存中加载可用的Preloader。 BootROM还可以实现安全性，以防止对存储进行未经授权的更改。
Preloader (PL) — This program resides at the start of the emmc/ufs flash device. It relies on various things including but not limited to timers, clocks, watchdogs, UART, GPIO, USB, etc and will setup these in it’s init instructions. Preloader executes after BootROM has initialized the storage and validated security, meaning it does not need to perform security checks and has full access to the flash (Note: this information will come handy at a later point). PL also initializes SecureLib which is responsible for Secure Boot setup. After it is done bringing up the platform, it will select a boot mode (usually NORMAL_BOOT) and will load the Android BootLoader.
Preloader(PL) -该程序位于emmc / ufs闪存设备的开始。 它依赖于各种事物，包括但不限于定时器，时钟，看门狗，UART，GPIO，USB等，并将在其init指令中进行设置。 预加载器在BootROM初始化存储并验证安全性之后执行，这意味着它不需要执行安全性检查并具有对闪存的完全访问权限(注意：此信息稍后会派上用场)。 PL还初始化负责安全启动设置的SecureLib。 完成启动平台后，它将选择启动模式(通常为NORMAL_BOOT)并加载Android BootLoader。
If during PL init, the Volume Up (+) button is held, Preloader will abort loading and hand control back to BROM, signaling it to load a low-level “Emergency Download” (EDL) mode. This interrupt is only listened for before SecureLib is setup.
如果在PL初始化过程中按住“调高音量”(+)按钮，则预加载器将中止加载，并将控制权交还给BROM，表示已加载低级别的“紧急下载”(EDL)模式。 仅在设置SecureLib之前侦听此中断。
Android BootLoader, the LittleKernel (LK) — Now, a minimized kernel (LK) and an OEM customized version of ABOOT (Android BootLoader) will spin up to start the traditional Android boot process. This stage also loads the logo data and displays the boot-logo, before a full boot-image starts booting Linux and takes over control. The LK is responsible for verifying several partitions to make sure they are signed with a particular key. If it fails to verify a partition, it will not continue. ABOOT will check Android Verified Boot (AVB) as necessary and conditionally continue bootup. LK also listens to the device keys to load recovery or fastboot download. On MIUI LK images, Volume Up (+) loads recovery, while Volume Down (-) loads fastboot.
Android BootLoader，LittleKernel(LK) —现在，最小化的内核(LK)和OEM定制版本的ABOOT(Android BootLoader)将启动传统的Android启动过程。 在完整的启动映像开始启动Linux并接管控制之前，此阶段还将加载徽标数据并显示启动徽标。 LK负责验证多个分区，以确保它们已使用特定密钥签名。 如果无法验证分区，它将不会继续。 ABOOT将根据需要检查Android验证启动(AVB)，并有条件地继续启动。 LK还监听设备密钥以进行负载恢复或快速启动下载。 在MIUI LK映像上，提高音量(+)加载恢复，而降低音量(-)加载快速启动。
Linux boot — Now Android can continue booting like any other device! The selected boot image (boot/recovery/equivalent) is loaded, DTOs are merged and Linux begins to boot :D
Linux引导 -现在Android可以像其他任何设备一样继续引导！ 加载所选的引导映像(引导/恢复/等效)，合并DTO，Linux开始引导：D
Okay, so how did you get stuck in BROM Download? What next?
好的，您是如何陷入BROM下载的呢？ 接下来是什么？
Glad you asked!You see, if LK fails to find a working boot-image, it will not continue and reboot the device. Effectively giving you no display output and a blinking LED. Often, draining the battery (equivalent of unplugging the battery) and booting the device with Volume Up (+) helped boot into recovery (given the kernel image itself was at fault).There was one more problem. A bigger problem. Before moving forward, you may wanna check out this article about DTOs (Device Tree Overlays):
很高兴您询问！您看到，如果LK无法找到有效的启动映像，它将无法继续并重新启动设备。 有效地使您没有显示输出，并且LED闪烁。 通常，排干电池(相当于拔下电池)并使用Volume Up(+)引导设备有助于引导进入恢复状态(假设内核映像本身有故障)。 还有一个问题。 一个更大的问题。 在继续之前，您可能想阅读一下有关DTO(设备树覆盖图)的文章：
If DTOs failed to merge, LK could not even init. For whatever reason on this device, LK tries to use boot’s DTB (Device Tree Blob) and DTBO image (Device Tree Blob Overlay) for itself*. Meaning, if you were to break DTB and DTBO merging or their compatibility with this proprietary LK, you would be left with a broken device. A device in such a non-functional state is commonly referred to as a “hard-brick” (The device is no better than a brick! Cannot be fixed with conventional software). Oh and, tripping AVB would hard-brick you too!
如果DTO合并失败，LK甚至无法初始化。 无论出于何种原因，LK都会尝试使用引导程序的DTB(设备树Blob)和DTBO映像(设备树Blob覆盖图)*。 意思是，如果您要破坏DTB和DTBO合并或它们与该专有LK的兼容性，则会留下损坏的设备。 处于这种非功能状态的设备通常称为“硬砖” (该设备并不比实体砖好！无法使用常规软件进行固定)。 哦，绊倒AVB也会让您难过！
Over time, a hard-bricked Redmi Note 8 Pro would run out it’s battery pretty quickly, since the device would attempt to boot, fail and reboot. You would also notice the device being a little warm while it does this. There is no other indication of life other than a bright LED that blinks every few seconds when plugged into a charger or USB, and a UART connection when Volume Up (+) is held long enough.
随着时间的流逝，坚固的Redmi Note 8 Pro会很快耗尽电池电量，因为设备会尝试启动，失败并重新启动。 您还会注意到设备在执行此操作时有点发热。 除了亮起的LED指示灯(插入充电器或USB时每隔几秒钟闪烁一次)，以及在音量调高(+)时保持足够长的时间进行UART连接之外，没有其他寿命指示。
* From observations, this should have been fixed in MIUI A10 (Android 10). We however diverged from official firmware, as you will see below. LK images on MIUI A10 seem to contain the kernel dtb too.
*根据观察，这应该已经在MIUI A10(Android 10)中修复。 但是，我们与官方固件有所不同，如下所示。 MIUI A10上的LK图像似乎也包含内核dtb。
有什么大不了的？ 只需在BROM下载中使用SP Flash Tools，对吗？ (Whats the big deal? Just use SP Flash Tools in BROM download, right?)
Wrong. For those unaware, SP Flash Tools, short for SmartPhone Flash Tool is a tool that MediaTek distributes that allows flashing the OEM firmware back onto a MediaTek device, in case something goes wrong. Now, in this “hard-brick” condition, the device is able to enter the BROM “emergency-download” mode (EDL, for short). If you remember, BROM may implement security to prevent unauthorized modification to the device.Most manufacturers implement very basic security; there are 2 main BROM security implementations:
错误。 对于那些不知道的SP闪存工具， SmartPhone闪存工具的缩写，是联发科分发的工具，万一出问题了，该工具可以将OEM固件刷回到联发科设备上。 现在，在这种“硬块”状态下，设备能够进入BROM“紧急下载”模式(简称EDL)。 如果您还记得，BROM可能会实施安全措施以防止对设备进行未经授权的修改。 BROM安全实现主要有2种：
- SLA (Serial Link Authorization) SLA(串行链接授权)
- DAA (Download Agent Authorization) DAA(下载代理授权)
A MediaTek device can have none, either or both. Usually a slightly modified version of the flash tool which contains a few secrets is enough to let anyone re-flash the device. Let’s quickly understand what these implementations are like and how they differ.BROM exposes UART to communicate. In both cases, the device will generate a few random bytes which must be “decrypted” or simply processed to create a new string. If BROM validates the string, it’ll allow the host to issue many more instructions without errors, such as jumping to addresses or writing partitions. The difference between the two is, in SLA, BootROM performs the checks and in DAA, Download Agent (DA) performs the check. Download Agent is loaded by SP Flash Tool. On devices that implement SLA, you cannot load a DA file without completing the SLA challenge. On devices that implement DAA, the challenge is done by DA and a modified DA file is enough to bypass security (That is, assuming you manage to reverse things or have the BSP).
MediaTek设备可以没有任何一个，也可以没有。 通常，稍稍修改版本的Flash工具(其中包含一些秘密)就足以让任何人重新刷新设备。 让我们快速了解一下这些实现的方式以及它们之间的区别.BROM公开了UART进行通信。 在这两种情况下，设备都会生成一些随机字节，必须对其进行“解密”或对其进行简单处理以创建新的字符串。 如果BROM验证了字符串，它将允许主机发出更多的指令而不会出错，例如跳转到地址或写入分区。 两者之间的区别在于，在SLA中，BootROM执行检查，而在DAA中，下载代理(DA)执行检查。 下载代理由SP Flash Tool加载。 在实现SLA的设备上，您必须先完成SLA质询才能加载DA文件。 在实现DAA的设备上，挑战由DA完成，修改后的DA文件足以绕过安全性(也就是说，假设您设法扭转局面或拥有BSP)。
This device had SLA. What’s worse? Server side SLA.Xiaomi has special accounts (called Mi Authorized Accounts) that are given to service centers for repairing devices. These accounts are capable of requesting Authorization tokens to unlock BROM download on MediaTek devices (and other EDL equivalents for Qualcomm devices). Something that can be very easily fixed by a consumer and/or developer, is locked to service centers.
该设备具有SLA。 更糟糕的是？ 服务器端SLA。 小米拥有专门的帐户(称为Mi授权帐户)，该帐户已分配给服务中心以维修设备。 这些帐户能够请求授权令牌来解锁MediaTek设备(以及Qualcomm设备的其他EDL等效文件)上的BROM下载。 消费者和/或开发人员可以很容易地将其固定的东西锁定在服务中心。
It gets worse. Many service centers do not know how to properly EDL and end up doing full motherboard replacements. While I understand this is for security of their devices, it would be nice to allow a user to fix his own device. After all, they tie your device to your Mi Account, which should help making sure that you are flashing things on your own device.
情况变得更糟。 许多服务中心不知道如何正确进行EDL处理并最终完成主板的全部更换。 虽然我了解这是出于他们设备的安全性考虑，但允许用户修复自己的设备会很好。 毕竟，他们将您的设备绑定到您的Mi帐户，这应该有助于确保您在自己的设备上闪烁内容。
I did manage to flash the device once on my machine by paying some shady person on the Internet to TeamViewer into my system and authorize the flash process. It was a well controlled and Wireshark monitored session, but it yielded no usable data unfortunately.The device generates 16 bytes of data (red) and sends it to the server. The server checks if your account has authorization and returns 256 bytes of data. If the data is correct, BROM continues. Else it traps itself in an infinite loop, until it times-out due to no-command and reboots.
我确实通过向互联网上的一些可疑人员付钱给TeamViewer进入我的系统并授权了刷新过程，从而设法在机器上刷新了设备一次。 这是一个受良好控制且受Wireshark监视的会话，但不幸的是它没有产生可用数据。设备生成16字节数据(红色)并将其发送到服务器。 服务器检查您的帐户是否具有授权，并返回256字节的数据。 如果数据正确，则BROM继续。 否则，它会陷入无限循环，直到由于无命令而超时并重新启动。
For completeness sake, I tried to make a Python Script that basically simulates the exact same serial communication between the host and device as SP Flash Tools, and tried to ignore the entire SLA (qualify_host) part, but BROM simply rejected any further commands. You can find the script here:
为了完整起见，我尝试制作一个Python脚本，该脚本基本上模拟主机和设备之间与SP Flash Tools完全相同的串行通信，并尝试忽略整个SLA(qualify_host)部分，但是BROM只是拒绝了任何其他命令。 您可以在此处找到脚本：
https://github.com/AgentFabulous/xiaomi_mtk_brom_experiments
https://github.com/AgentFabulous/xiaomi_mtk_brom_experiments
After going through multiple shady services with variable level of success and countless service center visits, teaching them how to enter BROM download so they can fix it using their special accounts, I was able to get my device running again.
在经历了成功程度不一的多次幕后服务以及无数次服务中心访问之后，教他们如何输入BROM下载，以便他们可以使用其特殊帐户对其进行修复，我得以使我的设备再次运行。
You can read my entire rant here. Xiaomi refused to comment about the situation. I recommend you to give this XDA article a read, too!
您可以 在这里 阅读我的全部言论 。 小米拒绝对此事发表评论。 我建议您也阅读本XDA文章 ！
回到发展！ (Back to development!)
I would never let these petty roadblocks keep me from running my own code on this shiny device. Coming back to development, remember how I mentioned LK verifies signed images? Well, turns out DTBO was signed too. My compiled DTBO images yielded a brick-like situation. This was luckily not a hard-brick, since the DTO was still valid and LK was able to load. After close inspection, we can see that the the DTBO contains 2 certificates:
我永远不会让这些琐碎的障碍阻止我在这个闪亮的设备上运行自己的代码。 回到开发阶段，还记得我提到过LK如何验证签名的图像吗？ 好吧，事实证明DTBO也已签署。 我编译的DTBO图像产生了类似砖的情况。 幸运的是，这并不是硬性规定，因为DTO仍然有效并且LK能够加载。 经过仔细检查，我们可以看到DTBO包含2个证书：
My earlier builds reached the animation since I was using MIUI dtbo, which was identical to the opensource kernel DTO sources. DTO however changed on later MIUI A9 (Android 9) images, which could potentially be catastrophic. So first, we had to compile our own working DTBO images.After some magic with dd, I extracted the 2 certs that were appended.
自从我使用MIUI dtbo以来，我的早期版本就达到了动画效果，它与开源内核DTO源代码相同。 但是，DTO在后来的MIUI A9(Android 9)图像上进行了更改，这可能会造成灾难性的后果。 因此，首先，我们必须编译自己的工作DTBO映像。在对dd进行了一些魔术之后，我提取了附加的2个证书。
A simple Python Script and a few hex-diffs later, we had a dtbo image that looked more like the one on MIUI. Let’s see if it runs.(What’s the worse that could happen right? Another service center visit, perhaps! Those guys must be sick of me, by now :P)
一个简单的Python脚本和一些十六进制的差异，之后，我们得到了一个dtbo图像，看起来更像是MIUI上的图像。 让我们看看它是否运行。(可能发生的最糟糕的情况是什么？也许是另一次服务中心访问！这些人现在一定已经讨厌我了：P)
This point on, getting the device to boot was fairly straightforward. It was a matter of reading logs and figuring out why something doesn’t work. However, it was still pretty dangerous to develop and modify the device, given the risk that one little mistake could cost a lot of time and money to fix.
至此，启动设备非常简单。 这是阅读日志并弄清为什么某事不起作用的问题。 但是，由于存在一个小错误可能花费大量时间和金钱来修复的风险，因此开发和修改设备仍然非常危险。
希望之光 (A Ray Of Hope)
Back in (late) November 2019, a firmware surfaced that was labelled to be begonia’s “factory firmware”. You see, every OEM receives a BSP for their platform of choice from the SoC manufacturer. Usually, the OEM will boot a clean version of this BSP on their hardware to get everything working, before the product team can start porting out the “skin” of Android that they advertise and ship their products with. This clean-version of the BSP build is often referred to as the “final factory firmware”. This happened to be just that. It was a userdebug build (you can read more about build types here), with lots of fun options enabled, that you would never see on a production device. You know, the kind of stuff that lets you run pretty much anything, dump memory and registers, have a debug console connection, and the kind of stuff that makes your device invincible. On closer inspection of strings and unix-paths in preloader, bootloader and kernel, it was clear that this build was compiled on the very same system as the newest MIUI A9 builds.Remember the “Note” in the Preloader part of the boot sequence? No? Well, here it is again:
回到2019年11月下旬，出现了一个固件，该固件被标记为秋海棠的“工厂固件”。 您会看到，每个OEM都会从SoC制造商那里获得针对其所选平台的BSP。 通常，OEM将在其硬件上启动此BSP的全新版本，以使一切正常工作，然后产品团队才能开始移植其广告和产品所用的Android“外观”。 BSP版本的这种纯净版本通常称为“最终工厂固件”。 碰巧就是这样。 这是一个userdebug构建(您可以在此处阅读有关构建类型的更多信息)，并启用了许多有趣的选项，而这些是您在生产设备上从未见过的。 您知道，这类东西可以让您运行几乎所有内容，转储内存和寄存器，建立调试控制台连接以及使您的设备立于不败之地。 在仔细检查预加载器，引导加载器和内核中的字符串和unix路径时，很明显此构建是在与最新MIUI A9构建相同的系统上编译的。还记得启动顺序的预加载器部分中的“注”吗？ 没有？ 好吧，这又是：
P
P
Well, this Preloader was compiled with download.c and was setting up UART on bootup, without any key-presses/interrupts.
好吧，这个预加载器是用download.c编译的，并且在启动时设置了UART，没有任何按键/中断。
To verify, I used a slightly modified version of my BROM script to see if it really was a download connection, by trying to perform a handshake.
为了进行验证，我通过尝试执行握手来对BROM脚本进行了稍微修改，以查看它是否确实是下载连接。
Credit where due, a man by the name of “Nikolay Molev” from 4PDA was brave enough to try out the entire firmware, and observed that he was able to use SP Flash Tool without any fancy Mi Account. I simply tried the Preloader and LK from that build as suggested by him to confirm this was in fact real.
值得一提的是，一个来自4PDA的名叫“ Nikolay Molev”的人很勇敢地尝试了整个固件，并观察到他能够使用SP Flash Tool而没有任何花哨的Mi帐户。 我只是按照他的建议尝试了该版本中的Preloader和LK，以确认这确实是真实的。
现状 (Current State of Things)
With a Preloader that has a working UART download connection, we have to make sure that we’re able to run newer software from Xiaomi on this old leaked Preloader. The thing is, the newer Android 10 BootLoaders (LK images) do not run on this PL. We are stuck with Factory and MIUI Android 9 bootloaders. And, the new kernel sources do not run on the old BootLoader for some odd reason (possibly due to DTO differences). For newer software to run, we need the new kernel running, or at least it’s new drivers.
对于具有有效UART下载连接的预加载器，我们必须确保能够在此旧的泄漏的预加载器上运行小米的较新软件。 事实是，较新的Android 10 BootLoader(LK图像)无法在此PL上运行。 我们受制于Factory和MIUI Android 9引导程序。 而且，由于某些奇怪的原因(可能是由于DTO差异)，新的内核源代码无法在旧的BootLoader上运行。 为了运行更新的软件，我们需要运行新的内核， 或者至少是新的驱动程序。
So, I sat down and started tinkering with the existing working kernel to boot the new Android 10 vendor. You can see the result of my first few attempts here :D
因此，我坐下来，开始修改现有的工作内核，以启动新的Android 10供应商。 您可以在这里查看我的前几次尝试的结果 ：D
Sitting and debugging through porting of drivers, one at a time, took about a week but was well worth it! I needed a mixed combination of Android 9 and Android 10 firmware images, which is now commonly referred to as the Begonia CFW Project. This allows us to ship unified builds for begonia and begoniain while still being completely functional!The kernel source and device configurations for the same can be found here:
通过一次移植驱动程序进行安装和调试，一次大约花了一个星期，但值得！ 我需要Android 9和Android 10固件映像的混合组合，现在通常将其称为Begonia CFW Project 。 这使我们能够在仍完全功能正常的情况下为海棠和海棠素提供统一的构建版本，其内核源代码和设备配置可在此处找到：
https://github.com/AgentFabulous/begoniahttps://github.com/PotatoDevices/device_redmi_begoniahttps://github.com/PotatoDevices/vendor_redmi_begonia
https://github.com/AgentFabulous/begonia https://github.com/PotatoDevices/device_redmi_begonia https://github.com/PotatoDevices/vendor_redmi_begonia
修复，修复和修复！ (Fix, fix and fix!)
Camera caused me the most trouble, since it failed to auto-focus no matter what. Turns out, that many services on the device were failing to properly read and write NV, and this trickled down to the camera services failing to use the AF driver. This however made me read through countless leaked technical documents that were in Chinese to understand how to properly enable logging, MediaTek’s camera-twin architecture and it’s dependencies.
相机给我带来了最大的麻烦，因为无论如何它都无法自动对焦。 事实证明，设备上的许多服务都无法正确读取和写入NV，这最终导致相机服务无法使用AF驱动程序。 但是，这使我通读了无数泄漏的中文技术文档，以了解如何正确启用日志记录，联发科的双摄架构及其依赖关系。
The Audio stack also was pretty interesting, which was the main motivation of the CFW. On first few boots, audio was broken and the device would reboot itself due to a WDT in the audio drivers. For audio to work and the device to stop rebooting, I had to port the new audio drivers, and for the new audio drivers to work, I had to use the MIUI Android 10 audio_dsp.img. Further, I had to use scp.img from the newer firmwares too, to fix a few sensors. (scp.img is supposedly the data struct for the MediaTek sensorHub driver)The CFW also contains the Factory Preloader and LK to make sure the user is safe when installing such Frankenstein firmwares.
音频堆栈也非常有趣，这是CFW的主要动机。 在最初的几次启动中，音频被破坏，并且由于音频驱动程序中的WDT，设备将自行重启。 为了使音频正常工作，并使设备停止重新引导，我必须移植新的音频驱动程序，并且要使新的音频驱动程序正常工作，我必须使用MIUI Android 10 audio_dsp.img 。 此外，我还必须使用较新固件中的scp.img来修复一些传感器。 (scp.img应该是联发科技sensorHub驱动程序的数据结构)CFW还包含Factory Preloader和LK，以确保在安装此类科学怪人固件时用户安全。
Other fun fixing experiences include fixing of IMS (Known popularly for VoLTE). What was deemed impossible by many actually turned out to be very very easy. Properly porting the prebuilt MediaTek ImsService and it’s dependencies managed to fix the IMS stack too! I did need to reverse out a few changes so WiFi StaState callbacks could be registered by the service. This would fix random crashes of the ImsService app. You can find the patches here.
其他有趣的修复体验包括IMS修复(VoLTE广为人知)。 实际上许多人认为不可能的事情非常非常容易。 正确移植预构建的联发科技ImsService及其依赖项也可以修复IMS堆栈！ 我确实需要撤消一些更改，以便该服务可以注册WiFi StaState回调。 这将修复ImsService应用程序的随机崩溃。 您可以在此处找到补丁。
外卖 (Takeaways)
We finally have a happy device which we have (almost) full control over, running an AOSP/AOSP-derivative build. It’s safe to play with software and everything works! Without Xiaomi’s kernel source release, this would never have been possible. This device has been quite a roller-coaster for me and has taught me a lot about MediaTek internals, security and architecture. But, the development doesn’t stop there. Who knows what else this device can run? 😉
我们终于有了一个可以(几乎)完全控制，运行AOSP / AOSP派生版本的快乐设备。 使用软件安全，一切正常！ 没有小米的内核源代码发行，这将永远不可能。 该设备对我来说是过山车，并且教会了我很多有关联发科技内部，安全性和体系结构的知识。 但是，发展并不仅限于此。 谁知道该设备还能运行什么？ 😉
This device is now my daily-driver and I absolutely love using it! All the code is linked above.
现在，该设备已成为我的日常司机，我绝对喜欢使用它！ 所有代码都在上面链接。
学分和感谢 (Credits and Thanks)
I’d like to thank everyone who contributed in the development, testing and debugging of this project. Here’s them in no particular order:
我要感谢在此项目的开发，测试和调试中做出贡献的每个人。 以下是它们的排列顺序：
- Zinadin Zidan (ZIDAN44)- Elias (TheMalachite)- Aayush Gupta (theimpulsion1)- Harshit Jain (dev_harsh1998)- Mashopy- Sagar Sorathiya - Sahil Sonar- Juan- Martin- Shanike- THEMAXIMUMPOWER
-Zinadin Zidan(ZIDAN44)-Elias(TheMalachite)-Aayush Gupta(theimpulsion1)-Harshit Jain(dev_harsh1998)-Mashopy- Sagar Sorathiya-Sahil Sonar- Juan- Martin- Shanike- THEMAXIMUMPOWER
Special thanks to the GSI community, who had been working on innovative fixes on their project, way before we even had usable builds :D
特别感谢GSI社区，他们一直在为项目进行创新性修复，甚至在我们没有可用的构建版本之前就已开始：D
Most importantly, thanks to Xiaomi India and XDA for sending us the devices!
最重要的是，感谢小米印度和XDA向我们发送了设备！
- Glossary -ABOOT = AndroidBoot (or, Android BootLoader)ARB = Anti-RollBack ProtectionAVB = Android Verified BootBROM = BootROMBSP = Board Support Package (usually proprietary)DT = Device TreeDTB = Device Tree BlobDTBO = Device Tree Blob OverlayDTO = Device Tree OverlayDTS = Device Tree SourceEDL = Emergency DownloadLK = LittleKernelPL = PreloaderUART = Universal Asynchronous Receiver-TransmitterWDT = WatchDog Timer
-术语 -ABOOT = AndroidBoot(或Android BootLoader) ARB =防回滚保护 AVB = Android验证的启动 BROM = BootROMBSP =电路板支持包(通常是专有的) DT =设备树DTB =设备树BlobDTBO =设备树Blob覆盖DTO =设备树覆盖DTS =设备树源 EDL =紧急下载LK = LittleKernelPL =预加载器UART =通用异步接收器-发送器WDT =看门狗定时器
翻译自: https://medium.com/swlh/modding-the-redmi-note-8-pro-an-adventure-e473e84d4d14
note pro 国际版
414
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
