在 Kindle Fire HDX 上得到了希望的验证结果后，对于在后续的工作中是否要长时间占用这个还有其他实际用途的设备是很犹豫的。巧的是，双人安同学退下来一款老掉牙的平板，Samsung Galaxy Tab 10.1，落到了我的手上。到 XDA 论坛上翻腾看了下，没想到这个老古董还有人给适配出了 Android 7.1.1 的 ROM，经过一番折腾（主要是帖子里推荐的 TWRP Recovery 3.x 的版本不能正常工作，换成 2.8.7 才好），刷机成功。

有了这个家伙，老夫的 Kindle Fire HDX 就可以休息了。第一件事情，当然还是试着编译适配这台设备的模块。把 https://github.com/Decatf/android_kernel_samsung_p4 的代码用 git clone 到本地，根据平台 Tegra 选择了先 make samsung_p4wifi_defconfig 的配置（要查看 arm 平台的所有配置可以去 arch/arm/configs 下），工具链么，就直接使用了为 Kindle Fire HDX 下载的那一套，接下来又轻车熟路地 make prepare 和 make scripts，准备工作的最后一步就是 Module.symvers 了。

从本系列的前文都知道，这块没什么技术含量，可偏偏这块今天出现了情况：在 zImage 里找不到压缩过的内核了！extract-symvers.py 脚本执行出错，手工用十六进制编辑器打开，发现搜索 gzip 的标识符根本就没有。搜索良久，发现了另外一个据说也可以处理 zImage 文件的脚本（https://github.com/xiaolu/galaxys2_kernel_repack），试用之下，也并没有改观。但是阅读其实现代码的过程中，发现了 zImage 内核的压缩方式有多种可能的事实。返回头到十六进制编辑器中审视，终于可以确定 Galaxy Tab 的这个 zImage 是使用 LZMA 算法压缩的（其特征可能是首先出现 5D 00 这两个字节，其后不远处有若干个 FF；脚本里有一处使用 grep 查找类似模式字串的地方，只可惜并不能匹配成功，经手工验证发现 grep 匹配 FF 这个字节总是失败，而且其模式字串中的有个 \x.. 也没看明白其用途，留待之后研究吧）。

有了之前处理 gzip 的经验，这次依葫芦画瓢。把 5D 00 之前的所有数据去除，另存为 kernel.lzma，然后用 unlzma -dqc kernel.lzma > kernel.raw 即可得到解压缩的内核。由于 extract-symvers.py 是直接处理 zImage 里的 gzip 格式的数据的，让它处理 unlzma 的这个输出文件的话要进行个小改造。编辑源文件，把 KernelImage 的初始化函数 __init__ 里含有 index 的三行代码注释掉即可。自此 Module.symvers 文件顺利生成，模块编译也顺利通过，单等明日验证加载效果。

有时间的话考虑把这些脚本工具改进、整合一下，造福自己和大家。