<div dir="ltr"><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Hello,</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I would like to share my successful bring-up of LLVM/clang-built Linux ARM(32-bit) hammerhead kernel for Android running on my Nexus 5 smartphone. After having successfully brought up LLVM/clang-built Linux kernel(since v4.15.7 to the most recent v4.17) on x86_64, I was interested in accomplishing the same on the ARM platform of my Nexus 5 - Android smartphone. So, here is the complete report of the same for the interested people.<span> </span></span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">The main advantage of the<span> </span></span><i style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b>clang-built Android ARM(32-bit) hammerhead kernel</b></i><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>for my Nexus 5 has been the<span> </span></span><i style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b>better battery usage</b></i><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>when compared to that of<span> </span></span><i style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b>gcc-built kernel,<span> </span></b></i><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">with the same kernel config and hardware(my Nexus 5 Android Smartphone). Details of the same can be found below.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font color="#ff0000" style="font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b>NOTE :<span> </span></b></font><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">By the way, I came across some reports of ARM64 clang-kernel for some Android Smartphones - but, the information over there did<span> </span></span><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font color="#ff0000">*not*</font></b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>help for my ARM32 clang-kernel case of Nexus 5(hammerhead). So, I started off this project from<span> </span></span><font color="#ff0000" style="font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b>*scratch*</b></font><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>and it has been<span> </span></span><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font color="#ff0000">lot of *entirely</font></b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span></span><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font color="#ff0000">my<span> </span></font><font color="#ff0000">own original work*<span> </span></font></b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">to first successfully<span> </span></span><font color="#ff0000" style="font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b>build</b></font><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>the ARM32 clang-kernel for Nexus 5(hammerhead) and second to make it<span> </span></span><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font color="#ff0000">*actually work*</font></b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>on the real hardware - Nexus 5.</span><div><br></div><div><span style="font-size:12.8px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">For easy reading with formatting, etc : <a href="https://ubuntuforums.org/showthread.php?t=2394035">https://ubuntuforums.org/showthread.php?t=2394035</a></span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Cheers.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><hr style="display:block;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><div style="margin:0px;padding:0px;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;text-align:center"><u><font size="4"><font color="#0000ff"><b>Android ARM(32-bit) clang-kernel bring-up for Nexus 5(hammerhead)</b></font></font></u></div><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font size="3" style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font color="#008000"><b><i><u>[Android Version Information]<span> </span></u></i></b></font><font color="#0000ff"><b><i><u>&</u></i></b></font><font color="#008000"><b><i><u><span> </span>[Battery Usage of a clang-built kernel ~ better than that of gcc-built kernel (shows one of the instances)</u>]</i></b></font></font><div style="margin:0px 0px 0px 40px;padding:0px;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><u><b><i><font color="#0000ff"><br></font></i></b></u><img src="https://i.imgur.com/k0UNicG.png" border="0" alt="" style="border: 0px; max-width: 100%;"><u><b><i><font color="#0000ff"><br></font></i></b></u><br></div><i style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b><font size="3"><font color="#0000ff"><u>[1]</u></font><font color="#008000"><u><span> </span>Android NDK r13b [LLVM/clang + binutils(as, ld, etc)]</u><span> </span></font></font><u><font size="3"><font color="#0000ff">[2]</font><font color="#008000"><span> </span>Android NDK r17 [LLVM/clang + binutils(as, ld, etc)]</font></font><br><br><br></u></b></i><img src="https://flic.kr/p/283b1Eh" border="0" alt="" style="border: 0px; max-width: 100%; color: rgb(0, 0, 0); font-family: Ubuntubeta, Ubuntu, "Bitstream Vera Sans", "DejaVu Sans", Tahoma, sans-serif; text-align: left; background-color: rgb(235, 236, 228); text-decoration-style: initial; text-decoration-color: initial;"><img src="https://photos.google.com/photo/AF1QipOl9ASeZerGWsZK69qo8nKx8Kc22jZIa4ssPWg" border="0" alt="" style="border: 0px; max-width: 100%; color: rgb(0, 0, 0); font-family: Ubuntubeta, Ubuntu, "Bitstream Vera Sans", "DejaVu Sans", Tahoma, sans-serif; text-align: left; background-color: rgb(235, 236, 228); text-decoration-style: initial; text-decoration-color: initial;"><img src="https://photos.google.com/share/AF1QipMKhiPOmPMm41ySte8QirR4ALeT-hM3TcCegmk_4mZ4-wRHjC00tEMHgC-IEqF1mQ?key=UzlwSTFTYnBTeEU1MWVPRVZBcnhJNkVTMlZYa1p3" border="0" alt="" style="border: 0px; max-width: 100%; color: rgb(0, 0, 0); font-family: Ubuntubeta, Ubuntu, "Bitstream Vera Sans", "DejaVu Sans", Tahoma, sans-serif; text-align: left; background-color: rgb(235, 236, 228); text-decoration-style: initial; text-decoration-color: initial;"><div style="margin:0px 0px 0px 40px;padding:0px;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><img src="https://i.imgur.com/8whisoz.png" border="0" alt="" style="border: 0px; max-width: 100%;"><br></div><font size="3" style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font color="#0000ff"><i><b><u>[3]</u></b></i></font><font color="#008000"><i><b><u><span> </span>Main LLVM/clang + Android NDK r13b binutils(as, ld, etc)</u><span> </span></b></i></font><font color="#0000ff"><i><b><u>[4]</u></b></i></font><font color="#008000"><i><b><u><span> </span>Main LLVM/clang + Android NDK r17 binutils(as, ld, etc)<br><br></u></b></i></font></font><img src="https://i.imgur.com/CN6yhMn.png" border="0" alt="" style="border: 0px; max-width: 100%; color: rgb(0, 0, 0); font-family: Ubuntubeta, Ubuntu, "Bitstream Vera Sans", "DejaVu Sans", Tahoma, sans-serif; text-align: left; background-color: rgb(235, 236, 228); text-decoration-style: initial; text-decoration-color: initial;"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font color="#0000ff" style="font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br></font><font color="#0000ff" style="font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><i><b><font size="3"><u>[5]</u></font></b></i></font><font color="#008000" style="font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><i><b><font size="3"><u><span> </span>Snapdragon Qualcomm LLVM/clang + NDK r13b binutils(as, etc)</u><span> </span></font></b></i></font><font color="#0000ff" style="font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><i><b><u><font size="3">[6]</font></u></b></i></font><font color="#008000" style="font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><i><b><u><font size="3"><span> </span>Snapdragon Qualcomm LLVM/clang + NDK r13b binutils(as, etc)<br></font></u></b></i></font><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><img src="https://i.imgur.com/9FH84ty.png" border="0" alt="" style="border: 0px; max-width: 100%; color: rgb(0, 0, 0); font-family: Ubuntubeta, Ubuntu, "Bitstream Vera Sans", "DejaVu Sans", Tahoma, sans-serif; text-align: left; background-color: rgb(235, 236, 228); text-decoration-style: initial; text-decoration-color: initial;"><div style="margin:0px 0px 0px 40px;padding:0px;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font size="3"><font color="#008000"><i><b><u>[Average Battery Usage]<br><br></u></b></i></font></font></div><img src="https://i.imgur.com/yWiXOVl.png" border="0" alt="" style="border: 0px; max-width: 100%; color: rgb(0, 0, 0); font-family: Ubuntubeta, Ubuntu, "Bitstream Vera Sans", "DejaVu Sans", Tahoma, sans-serif; text-align: left; background-color: rgb(235, 236, 228); text-decoration-style: initial; text-decoration-color: initial;"><div style="margin:0px 0px 0px 40px;padding:0px;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br></div><div style="margin:0px 0px 0px 40px;padding:0px;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font color="#008000"><u><b><font size="3"><i>BUILD SYSTEM INFORMATION<br></i></font><br></b></u></font><br><div class="gmail-bbcode_container" style="margin:5px 20px 20px;padding:0px;display:block"><div class="gmail-bbcode_description" style="margin:0px;padding:0px">Code:</div><pre class="gmail-bbcode_code" style="margin:0px;padding:6px;font-family:"Ubuntu Mono",monospace;line-height:14px;word-wrap:normal;font-style:normal;border:1px inset;text-align:left;overflow:auto;direction:ltr;background:none repeat-x rgb(239,239,239);font-size:14px;height:372px">#### Build system information ####

exp@exp:~$ 
exp@exp:~$ sudo dmidecode -t system | grep "Manufacturer:\|Version:"
    Manufacturer: LENOVO
    Version: Lenovo Y50-70 Touch
exp@exp:~$ 
exp@exp:~$

exp@exp:~$ 
exp@exp:~$ sudo dmidecode -t processor | grep "Version\|Family:"
    Family: Core i7
    Version: Intel(R) Core(TM) i7-4710HQ CPU @ 2.50GHz
exp@exp:~$ 
exp@exp:~$

exp@exp:~$ 
exp@exp:~$ cat /proc/meminfo | grep MemTotal
MemTotal:       16332968 kB
exp@exp:~$ 
exp@exp:~$ 

exp@exp:~$ 
exp@exp:~$  lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 17.10
Release:    17.10
Codename:    artful
exp@exp:~$ 
exp@exp:~$</pre></div><br><u><b><font size="3"><i><font color="#008000">BUILD SUMMARY</font><br></i></font><br></b></u><div class="gmail-bbcode_container" style="margin:5px 20px 20px;padding:0px;display:block"><div class="gmail-bbcode_description" style="margin:0px;padding:0px">Code:</div><pre class="gmail-bbcode_code" style="margin:0px;padding:6px;font-family:"Ubuntu Mono",monospace;line-height:14px;word-wrap:normal;font-style:normal;border:1px inset;text-align:left;overflow:auto;direction:ltr;background:none repeat-x rgb(239,239,239);font-size:14px;height:216px">#### Total build time ####


38m6.816s

#### Build times ####


[GCC NDK r13b] : 4m15.596s
[GCC NDK r17] : 4m13.983s
[Android NDK r13b : LLVM/clang + binutils(ld and as)] : 4m3.665s
[Android NDK r17 : LLVM/clang + binutils(ld and as)] : 4m4.683s
[Main LLVM/clang + Android NDK r13b binutils(ld and as)] : 6m8.064s
[Main LLVM/clang + Android NDK r17 binutils(ld and as)] : 6m3.457s
[Qualcomm Snapdragon LLVM/clang + Android NDK r13b binutils(ld and as)] : 4m32.581s
[Qualcomm Snapdragon LLVM/clang + Android NDK r17 binutils(ld and as)] : 4m44.779s</pre></div><i><font size="3"><font color="#008000"><u><b>LONGEST AND SHORTEST BUILD</b></u></font><br></font></i><br><div class="gmail-bbcode_container" style="margin:5px 20px 20px;padding:0px;display:block"><div class="gmail-bbcode_description" style="margin:0px;padding:0px">Code:</div><pre class="gmail-bbcode_code" style="margin:0px;padding:6px;font-family:"Ubuntu Mono",monospace;line-height:14px;word-wrap:normal;font-style:normal;border:1px inset;text-align:left;overflow:auto;direction:ltr;background:none repeat-x rgb(239,239,239);font-size:14px;height:168px">##### Longest build ####
Name : Main LLVM/clang + Android NDK r13b binutils(ld and as)
Time : 6m8.064s
boot.img : boot-main-llvm-clang-ndk-r13b-binutils-ld-as.img
zImage-dtb : zImage-dtb-main-llvm-clang-ndk-r13b-binutils-ld-as


##### Shortest build ####
Name : Android NDK r13b : LLVM/clang + binutils(ld and as)
Time : 4m3.665s
boot.img : boot-ndk-r13b-clang-llvm-binutils-ld-as.img
zImage-dtb : zImage-dtb-ndk-r13b-clang-llvm-binutils-ld-as</pre></div><br><font size="3"><i><font color="#008000"><u><b>LARGEST AND SMALLEST IMAGES</b></u></font><br></i></font><br><div class="gmail-bbcode_container" style="margin:5px 20px 20px;padding:0px;display:block"><div class="gmail-bbcode_description" style="margin:0px;padding:0px">Code:</div><pre class="gmail-bbcode_code" style="margin:0px;padding:6px;font-family:"Ubuntu Mono",monospace;line-height:14px;word-wrap:normal;font-style:normal;border:1px inset;text-align:left;overflow:auto;direction:ltr;background:none repeat-x rgb(239,239,239);font-size:14px;height:108px">     ◈ Largest boot img : boot-ndk-r17-gcc.img ❏ Size : 13M (12984320 bytes)
     ◈ Smallest boot img 1 : boot-main-llvm-clang-ndk-r17-binutils-ld-as.img ❏ Size : 11M (11272192 bytes)
     ◈ Smallest boot img 2 : boot-main-llvm-clang-ndk-r13b-binutils-ld-as.img ❏ Size : 11M (11272192 bytes)


     ◈ Largest zImage-dtb : zImage-dtb-ndk-r17-gcc ❏ Size : 12M (11844904 bytes)
     ◈ Smallest zImage-dtb : zImage-dtb-main-llvm-clang-ndk-r13b-binutils-ld-as ❏ Size : 9.7M (10132600 bytes)</pre></div><font size="3"><i><font color="#008000"><u><b>BOOT IMAGES SUMMARY<br></b></u></font></i></font><br><div class="gmail-bbcode_container" style="margin:5px 20px 20px;padding:0px;display:block"><div class="gmail-bbcode_description" style="margin:0px;padding:0px">Code:</div><pre class="gmail-bbcode_code" style="margin:0px;padding:6px;font-family:"Ubuntu Mono",monospace;line-height:14px;word-wrap:normal;font-style:normal;border:1px inset;text-align:left;overflow:auto;direction:ltr;background:none repeat-x rgb(239,239,239);font-size:14px;height:120px">     ◈ boot-ndk-r17-gcc.img ❏ Size ~ 13M (12984320 bytes)
     ◈ boot-ndk-r13b-gcc.img ❏ Size ~ 13M (12978176 bytes)
     ◈ boot-ndk-r13b-clang-llvm-binutils-ld-as.img ❏ Size ~ 13M (12625920 bytes)
     ◈ boot-qualcomm-snapdragon-llvm-clang-ndk-r13b-binutils-ld-as.img ❏ Size ~ 12M (11610112 bytes)
     ◈ boot-qualcomm-snapdragon-llvm-clang-ndk-r17-binutils-ld-as.img ❏ Size ~ 12M (11610112 bytes)
     ◈ boot-ndk-r17-clang-llvm-binutils-ld-as.img ❏ Size ~ 11M (11476992 bytes)
     ◈ boot-main-llvm-clang-ndk-r13b-binutils-ld-as.img ❏ Size ~ 11M (11272192 bytes)
     ◈ boot-main-llvm-clang-ndk-r17-binutils-ld-as.img ❏ Size ~ 11M (11272192 bytes)</pre></div><br><font size="3"><i><font color="#008000"><u><b>ZIMAGE-DTB SUMMARY</b></u></font><br></i></font><br><div class="gmail-bbcode_container" style="margin:5px 20px 20px;padding:0px;display:block"><div class="gmail-bbcode_description" style="margin:0px;padding:0px">Code:</div><pre class="gmail-bbcode_code" style="margin:0px;padding:6px;font-family:"Ubuntu Mono",monospace;line-height:14px;word-wrap:normal;font-style:normal;border:1px inset;text-align:left;overflow:auto;direction:ltr;background:none repeat-x rgb(239,239,239);font-size:14px;height:120px">     ◈ zImage-dtb-ndk-r17-gcc ❏ Size ~ 12M (11844904 bytes)
     ◈ zImage-dtb-ndk-r13b-gcc ❏ Size ~ 12M (11837640 bytes)
     ◈ zImage-dtb-ndk-r13b-clang-llvm-binutils-ld-as ❏ Size ~ 11M (11487176 bytes)
     ◈ zImage-dtb-qualcomm-snapdragon-llvm-clang-ndk-r13b-binutils-ld-as ❏ Size ~ 10M (10469728 bytes)
     ◈ zImage-dtb-qualcomm-snapdragon-llvm-clang-ndk-r17-binutils-ld-as ❏ Size ~ 10M (10469680 bytes)
     ◈ zImage-dtb-ndk-r17-clang-llvm-binutils-ld-as ❏ Size ~ 10M (10336624 bytes)
     ◈ zImage-dtb-main-llvm-clang-ndk-r17-binutils-ld-as ❏ Size ~ 10M (10132608 bytes)
     ◈ zImage-dtb-main-llvm-clang-ndk-r13b-binutils-ld-as ❏ Size ~ 10M (10132600 bytes)</pre></div><br><font size="3"><i><font color="#008000"><u><b>RAMDISK INFORMATION</b></u></font><br></i></font><br><div class="gmail-bbcode_container" style="margin:5px 20px 20px;padding:0px;display:block"><div class="gmail-bbcode_description" style="margin:0px;padding:0px">Code:</div><pre class="gmail-bbcode_code" style="margin:0px;padding:6px;font-family:"Ubuntu Mono",monospace;line-height:14px;word-wrap:normal;font-style:normal;border:1px inset;text-align:left;overflow:auto;direction:ltr;background:none repeat-x rgb(239,239,239);font-size:14px;height:72px">Ramdisk(pre-built - from RR) : 


     ◈ boot.img-ramdisk.gz ❏ Size ~ 1M (1136400 bytes)</pre></div><br><font color="#008000"><u><b><font size="3"><i>Clang-KERNEL INFORMATION(from each of the zImage-dtb images)</i></font></b></u></font><br><br><div class="gmail-bbcode_container" style="margin:5px 20px 20px;padding:0px;display:block"><div class="gmail-bbcode_description" style="margin:0px;padding:0px">Code:</div><pre class="gmail-bbcode_code" style="margin:0px;padding:6px;font-family:"Ubuntu Mono",monospace;line-height:14px;word-wrap:normal;font-style:normal;border:1px inset;text-align:left;overflow:auto;direction:ltr;background:none repeat-x rgb(239,239,239);font-size:14px;height:372px">exp@exp:~$ 
exp@exp:~$ ../show_kernel_compiler_all.sh 
#### Kernel compiler information ####

NOTE : Analyzing the images by decompressing them based on lz4 magic (\x02\x21\x4c\x18) . . .

Image metadata(zImage-dtb-main-llvm-clang-ndk-r13b-binutils-ld-as) : 
+++ grep -P -a -b --only-matching '\x02\x21\x4c\x18' zImage-dtb-main-llvm-clang-ndk-r13b-binutils-ld-as
+++ tail -1
+++ cut -d: -f 1
++ pos1=5381
++ dd if=zImage-dtb-main-llvm-clang-ndk-r13b-binutils-ld-as bs=5381 skip=1
++ lz4 -d
++ eclang
++ head -1
+++ strings -a
+++ grep 'clang version'
Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Flash clang version 7.0.332826 (<a href="https://git.llvm.org/git/clang">https://git.llvm.org/git/clang</a> 4029c7ddda99ecbfa144f0afec44a192c442b6e5) (<a href="https://git.llvm.org/git/llvm">https://git.llvm.org/git/llvm</a> 1181c40e0e24e0cca32e2609686db1f14151fc1a) (based on LLVM 7.0.332826) - android-ndk-r13b) #1 SMP PREEMPT Mon Jun 4 00:33:21 PDT 2018
++ set +x

Image metadata(zImage-dtb-main-llvm-clang-ndk-r17-binutils-ld-as) : 
+++ grep -P -a -b --only-matching '\x02\x21\x4c\x18' zImage-dtb-main-llvm-clang-ndk-r17-binutils-ld-as
+++ cut -d: -f 1
+++ tail -1
++ pos1=5373
++ dd if=zImage-dtb-main-llvm-clang-ndk-r17-binutils-ld-as bs=5373 skip=1
++ lz4 -d
++ eclang
++ head -1
+++ strings -a
+++ grep 'clang version'
Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Flash clang version 7.0.332826 (<a href="https://git.llvm.org/git/clang">https://git.llvm.org/git/clang</a> 4029c7ddda99ecbfa144f0afec44a192c442b6e5) (<a href="https://git.llvm.org/git/llvm">https://git.llvm.org/git/llvm</a> 1181c40e0e24e0cca32e2609686db1f14151fc1a) (based on LLVM 7.0.332826) - android-ndk-r17) #1 SMP PREEMPT Mon Jun 4 00:39:25 PDT 2018
++ set +x

Image metadata(zImage-dtb-ndk-r13b-clang-llvm-binutils-ld-as) : 
+++ grep -P -a -b --only-matching '\x02\x21\x4c\x18' zImage-dtb-ndk-r13b-clang-llvm-binutils-ld-as
+++ tail -1
+++ cut -d: -f 1
++ pos1=5509
++ dd if=zImage-dtb-ndk-r13b-clang-llvm-binutils-ld-as bs=5509 skip=1
++ lz4 -d
++ eclang
++ head -1
+++ grep 'clang version'
+++ strings -a
Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Android clang version 3.8.256229 (based on LLVM 3.8.256229) - android-ndk-r13b) #1 SMP PREEMPT Mon Jun 4 00:23:08 PDT 2018
++ set +x

Image metadata(zImage-dtb-ndk-r17-clang-llvm-binutils-ld-as) : 
+++ grep -P -a -b --only-matching '\x02\x21\x4c\x18' zImage-dtb-ndk-r17-clang-llvm-binutils-ld-as
+++ tail -1
+++ cut -d: -f 1
++ pos1=5449
++ dd if=zImage-dtb-ndk-r17-clang-llvm-binutils-ld-as bs=5449 skip=1
++ lz4 -d
++ eclang
++ head -1
+++ strings -a
+++ grep 'clang version'
Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Android (4691093 based on r316199) clang version 6.0.2 (<a href="https://android.googlesource.com/toolchain/clang">https://android.googlesource.com/toolchain/clang</a> 183abd29fc496f55536e7d904e0abae47888fc7f) (<a href="https://android.googlesource.com/toolchain/llvm">https://android.googlesource.com/toolchain/llvm</a> 34361f192e41ed6e4e8f9aca80a4ea7e9856f327) (based on LLVM 6.0.2svn) - android-ndk-r17) #1 SMP PREEMPT Mon Jun 4 00:27:14 PDT 2018
++ set +x

Image metadata(zImage-dtb-qualcomm-snapdragon-llvm-clang-ndk-r13b-binutils-ld-as) : 
+++ grep -P -a -b --only-matching '\x02\x21\x4c\x18' zImage-dtb-qualcomm-snapdragon-llvm-clang-ndk-r13b-binutils-ld-as
+++ tail -1
+++ cut -d: -f 1
++ pos1=5417
++ dd if=zImage-dtb-qualcomm-snapdragon-llvm-clang-ndk-r13b-binutils-ld-as bs=5417 skip=1
++ lz4 -d
++ eclang
++ head -1
+++ strings -a
+++ grep 'clang version'
Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Snapdragon LLVM ARM Compiler 4.0.2 for Android NDK (based on <a href="http://llvm.org">llvm.org</a> 4.0+) - clang version 4.0.2 for Android NDK - android-ndk-r13b) #1 SMP PREEMPT Mon Jun 4 00:43:58 PDT 2018
++ set +x

Image metadata(zImage-dtb-qualcomm-snapdragon-llvm-clang-ndk-r17-binutils-ld-as) : 
+++ grep -P -a -b --only-matching '\x02\x21\x4c\x18' zImage-dtb-qualcomm-snapdragon-llvm-clang-ndk-r17-binutils-ld-as
+++ tail -1
+++ cut -d: -f 1
++ pos1=5409
++ dd if=zImage-dtb-qualcomm-snapdragon-llvm-clang-ndk-r17-binutils-ld-as bs=5409 skip=1
++ lz4 -d
++ eclang
++ head -1
+++ strings -a
+++ grep 'clang version'
Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Snapdragon LLVM ARM Compiler 4.0.2 for Android NDK (based on <a href="http://llvm.org">llvm.org</a> 4.0+) - clang version 4.0.2 for Android NDK - android-ndk-r17) #1 SMP PREEMPT Mon Jun 4 00:48:42 PDT 2018
++ set +x

exp@exp:~$ 
exp@exp:~$</pre></div><br><br><font color="#008000"><u><b><font size="3"><i>Clang-KERNEL INFORMATION(from dmesg extracted from each of the boot instances)<br></i></font><br></b></u></font><div class="gmail-bbcode_container" style="margin:5px 20px 20px;padding:0px;display:block"><div class="gmail-bbcode_description" style="margin:0px;padding:0px">Code:</div><pre class="gmail-bbcode_code" style="margin:0px;padding:6px;font-family:"Ubuntu Mono",monospace;line-height:14px;word-wrap:normal;font-style:normal;border:1px inset;text-align:left;overflow:auto;direction:ltr;background:none repeat-x rgb(239,239,239);font-size:14px;height:372px">exp@exp:~$ 
exp@exp:~$ cat android1/android1_dmesg.txt | grep "clang\|Machine"
[    0.000000] Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Android clang version 3.8.256229 (based on LLVM 3.8.256229) - android-ndk-r13b) #1 SMP PREEMPT Mon Jun 4 00:23:08 PDT 2018
[    0.000000] Machine: Qualcomm MSM 8974 HAMMERHEAD (Flattened Device Tree), model: LGE MSM 8974 HAMMERHEAD
exp@exp:~$ 
exp@exp:~$ 
exp@exp:~$ cat android2/android2_dmesg.txt | grep "clang\|Machine"
[    0.000000] Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Android (4691093 based on r316199) clang version 6.0.2 (<a href="https://android.googlesource.com/toolchain/clang">https://android.googlesource.com/toolchain/clang</a> 183abd29fc496f55536e7d904e0abae47888fc7f) (<a href="https://android.googlesource.com/toolchain/llvm">https://android.googlesource.com/toolchain/llvm</a> 34361f192e41ed6e4e8f9aca80a4ea7e9856f327) (based on LLVM 6.0.2svn) - android-ndk-r17) #1 SMP PREEMPT Mon Jun 4 00:27:14 PDT 2018
[    0.000000] Machine: Qualcomm MSM 8974 HAMMERHEAD (Flattened Device Tree), model: LGE MSM 8974 HAMMERHEAD
exp@exp:~$ 
exp@exp:~$ 
exp@exp:~$ cat main1/main1_dmesg.txt | grep "clang\|Machine"
[    0.000000] Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Flash clang version 7.0.332826 (<a href="https://git.llvm.org/git/clang">https://git.llvm.org/git/clang</a> 4029c7ddda99ecbfa144f0afec44a192c442b6e5) (<a href="https://git.llvm.org/git/llvm">https://git.llvm.org/git/llvm</a> 1181c40e0e24e0cca32e2609686db1f14151fc1a) (based on LLVM 7.0.332826) - android-ndk-r13b) #1 SMP PREEMPT Mon Jun 4 00:33:21 PDT 2018
[    0.000000] Machine: Qualcomm MSM 8974 HAMMERHEAD (Flattened Device Tree), model: LGE MSM 8974 HAMMERHEAD
exp@exp:~$ 
exp@exp:~$ 
exp@exp:~$ cat main2/main2_dmesg.txt | grep "clang\|Machine"
[    0.000000] Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Flash clang version 7.0.332826 (<a href="https://git.llvm.org/git/clang">https://git.llvm.org/git/clang</a> 4029c7ddda99ecbfa144f0afec44a192c442b6e5) (<a href="https://git.llvm.org/git/llvm">https://git.llvm.org/git/llvm</a> 1181c40e0e24e0cca32e2609686db1f14151fc1a) (based on LLVM 7.0.332826) - android-ndk-r17) #1 SMP PREEMPT Mon Jun 4 00:39:25 PDT 2018
[    0.000000] Machine: Qualcomm MSM 8974 HAMMERHEAD (Flattened Device Tree), model: LGE MSM 8974 HAMMERHEAD
exp@exp:~$ 
exp@exp:~$ 
exp@exp:~$ 
exp@exp:~$ cat qualcomm1/qualcomm1_dmesg.txt | grep "clang\|Machine"
[    0.000000] Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Snapdragon LLVM ARM Compiler 4.0.2 for Android NDK (based on <a href="http://llvm.org">llvm.org</a> 4.0+) - clang version 4.0.2 for Android NDK - android-ndk-r13b) #1 SMP PREEMPT Mon Jun 4 00:43:58 PDT 2018
[    0.000000] Machine: Qualcomm MSM 8974 HAMMERHEAD (Flattened Device Tree), model: LGE MSM 8974 HAMMERHEAD
exp@exp:~$ 
exp@exp:~$ 
exp@exp:~$ cat qualcomm2/qualcomm2_dmesg.txt | grep "clang\|Machine"
[    0.000000] Linux version 3.4.113-unicornblood-hammerhead-o+ (exp@exp) (Snapdragon LLVM ARM Compiler 4.0.2 for Android NDK (based on <a href="http://llvm.org">llvm.org</a> 4.0+) - clang version 4.0.2 for Android NDK - android-ndk-r17) #1 SMP PREEMPT Mon Jun 4 00:48:42 PDT 2018
[    0.000000] Machine: Qualcomm MSM 8974 HAMMERHEAD (Flattened Device Tree), model: LGE MSM 8974 HAMMERHEAD
exp@exp:~$</pre></div></div><div style="margin:0px 0px 0px 40px;padding:0px;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br><font color="#008000"><u><b><i><font size="3">[ANDROID ARM LLVM/CLANG-KERNEL ~ RESEARCH PROJECT OVERVIEW]</font></i><br><br></b></u></font></div><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><ol class="gmail-decimal" style="margin:0px 40px;padding:0px;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding the right kernel source and kernel config that works with the Android version I had on my Nexus 5.</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Android(version) on my Nexus 5 is Resurrection Remix(RR) oreo with 3.4.13 hammerhead kernel(unicornblood config)</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Experimenting with different kernel source and hammerhead kernel config including that of AOSP</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding the most compact and quickest way to just build the kernel out of tree but using the tree's build tools</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Syncing the Resurrection Remix's source from its repo onto my machine</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding the make targets for building just the ramdisk instead of building the whole RR ROM which was not the goal</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding the tool and the arguments for that to build the boot.img that can be fastboot-ed</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Building a working kernel from source for my RR on Nexus 5, first with Android NDK r13b gcc</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding the DirtyUnicorn kernel source, building it with gcc in the first place, generating the boot.img</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding the right kernel config for the hammerhead kernel - unicornblood that's used by DirtyUnicorn repo</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Using the pre-built ramdisk from RR zip instead of self-built one</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Disabling SELinux for allowing the kernel to be fastboot-ed</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Debugging the ADB-over-USB not working with the DirtyUnicorn kernel image built</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Discussing on the Resurrection Remix forum and with the kernel developer(uname:voidz) to know the actual kernel source used in RR.</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Successfully booting the gcc-built kernel for RR on my Nexus 5</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Working kernel confimed in the first place for my ultimate Android ARM clang-kernel goal</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Setting up the clang-kernel build</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding the right LLVM/clang toolchain to begin with - Android NDK r13b LLVM/clang</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Using the binutils - assembler, linker, etc that's in Android NDK r13b</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Launching the clang-kernel build</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Disabling the options that clang doesn't recognize</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Examining the initial compilation erros - invalid instruction error(thrown actually by x86_64 GNU as)</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Fixing the assembler path to the ARM assembler</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Making sure it uses the right external assembler(Android EABI GNU assembler)</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Fixing the subsequent build errors</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">RCU header had some static code check which had to be disabled since in clang case alone it was an error not in gcc</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">VLAIS in various kernel components had to be changed to non-VLAIS to work with clang</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Updating VLAIS to non-VLAIS in various kernel components</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Disk encryption</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">USB Gadget/Function Filesystem</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">CRC32</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Netfilter</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Fixing linker errors for duplicate exception sections that clang generates</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Instructing the linker to leave the exceptions out while generating the final kernel image</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Fixing more linker errors</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Added missing ARM EABI memory manipulation implementations that some of the kernel code needed that the toolchain didn't provide</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Building successfully the kernel image with clang for the first time</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Booting the clang-built kernel image for the first time</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Booting gets stuck at "Google" logo</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Checking whether there was any kernel panic by booting to recovery mode and checking /proc/last_kmsg</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Not finding anything relevant to clang-kernel boot in /proc/last_kmsg</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Running over a plethora of possibilities for the stuck-at-google-logo case</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Kernel might have not been loaded at all by bootloader for some reason</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Generated boot.img might have incorrect offsets for kernel, ramdisk, etc</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Generated kernel image might be corrupt</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Bootloader might be expecting gcc-specific compiler metadata instead of LLVM/clang, in kernel image header</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Fastboot might have some way of logging the overall boot sequence which might have give some hint</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Attempting to boot the clang-kernel and ramdisk with QEMU/ARM to debug like I did for x86_64 clang-kernel</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Booting on QEMU/ARM with both kernel and ramdisk, next with just the kernel, with GUI and without GUI</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Booting the kernel and ramdisk built with Android emulator, specifically QEMU/ARMel that's part of the SDK</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Cross-compiling Android LittleKernel bootloader for ARM and using that to boot the clang-kernel on QEMU/ARM</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Not seeing anything happening at all in any of the above scenarios</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Carrying out more debugging</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Turning off the Nexus 5 and doing a fastboot to get fresh /proc/last_kmsg if possible</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Adding various debug parameters on kernel command-line</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Trying out different options that fastboot has for specifying offsets, etc</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Researching on external hardware-based debugging like adding UART interface to get early boot logs</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Researching on the very first code that runs when the kernel is loaded - kernel entry point</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding start_kernel() inside init/main.c</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Adding some debug statements over there and not seeing them for obvious console-not-yet-initialized reason</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Then finding the actual kernel entry point in head.S assembly source</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Researching on ways to print anything at all in the ARM assembly code within head.S</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding printascii that's used for the above case but realizing it's for a serial console(UART)</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Understanding the ARM assembly code within head.S and its siblings and the inline documentation therein</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Getting to know the prerequisites of prior entering the kernel entry point in head.S</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Exploring the methods to confirm whether the control is indeed reaching head.S or not</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Checking if the LED on the bottom of Nexus 5 can be turned on/off with different colors as an indication</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Researching on doing something with ARM CPU like raising an exception, or a reset event as an indication</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Researching on different ways of restarting Nexus 5 - checking how a "reboot" command works at kernel level</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Looking into machine restart logic - translating that to a reset logic to be used within head.S</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Using reset logic for more fine-grained debugging instruction by instrucion within head.S and its siblings</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Noticing PC write was problematic</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding ways to branch off to destination instead of modifying PC which is not recommended as per the docs</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Understanding the end-to-end control flow since the kernel entry point till start_kernel() of init/main.c</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Following the inter-working of head.S and processor-specific assembly code during the setup</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Locating some control register access being problematic like that with PC</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Researching on other available clang/LLVM toolchains to see if they work</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Using Android NDK r17's LLVM/clang - not helpful - same outcome - stuck-at-google-logo case</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding main LLVM/clang source and building it to use with kernel source - not helpful - same outcome</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finding Snapdragon Qualcomm LLVM/clang toolchain and using it - not helpful - same outcome</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Using different diff-tools to compare two binaries : clang-built kernel and gcc-built kernel</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">hexdiff - saw some differences</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">vimdiff - some other differenes</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Using different binary analysis tools to examine the differences between the gcc-built and clang-built kernels => Android EABI readelf - saw some ELF header information differences</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Android EABI objdump - compared disassembly, symbols, sections and their flags, etc</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Adding mechanism to use the same assembly code settings as that of gcc</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Using same assembler options that gcc uses while invoking the assembler for intermediate assembly code</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Using same assembly code setup as that of gcc for data, target architecture, etc for intermediates</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Automating the above so that it works for every intermediate assembly file that clang generates</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Reducing the optimization level of kernel build</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Keeping the oversmart optimization aside - O1 and Os - didn't change the stuck-at-google-logo case</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Disabling optimization completely - O0 - didn't work - kernel doesn't support based on what I read online</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Disabling the caches in kernel config as needed by head.S</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Updating kernel config to disable I-cache and D-cache - didn't help</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Trying out different assembler options</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Experimenting with different SP sizes, EABI versions - didn't help</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Trying out different clang options</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Using different possible stack alignments to address any incorrect assumptions around that - didn't help</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Correcting the SP access</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Updating access to SP in one of the thread access kernel code as per one of the online notes</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Researching more on the lines on what does clang do that's not gcc doesn't</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Disabling all the optimizations and clang-only features if any</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Disabling all the intrinsic features that clang uses internally - device rebooted after a failed boot!</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">No more stuck-at-google-logo case with the above change</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Witnessing the device auto-reboot with the above change - must be a kernel panic!</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Checking /proc/last_kmsg within recovery mode - yes, it was the clang-kernel that panic'ed - good sign!</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Finally, the clang-kernel has started executing after an exhaustive set of attempts - breakthrough!</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Locating the source of kernel panic</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Looking at the stacktrace revealed one of the audio codec had a buffer overrun - fixed it</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Rebuilding the kernel with the fix and retrying</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Seeing some more kernel panics - another audio codec source which had similar issue - fixed it</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Booting to the Android GUI with clang-kernel for the first time</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Fixing the kernel panics mentioned above allowed boot to move on</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Seeing Android animation(RR logo in my case) for the first time!</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Getting to the Android home screen after few seconds of wait - mission accomplished!</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Verifying all the system information</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Checking kernel version to be showing LLVM/clang toolchain version, etc</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Examining kernel dmesg for clang specific information</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Checking /proc/version for the same</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Checking Settings/About for the same</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Verifying all the features work</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Checking Camera, Bluetooth, ADB over USB, etc</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Cheking WiFi - didn't work - "connected, no internet"</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Noticing WiFi symbol had a cross(x) symbol on it</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Browsing failed as expected due to no internet availability</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Disabling WiFi to check if cellular(LTE) network works for internet - didn't</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Noticing mobile network also had a cross(x) symbol on it after disabling WiFi as above</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Browsing with mobile network as well failed as expected due to no internet availability</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Verifying phone calls work - yes, they worked!</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Checking logcat, dmesg for any network error</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Noticing SELinux denials for some of the network related actions</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Locating the error stating bandwidth module not loaded</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Narrowing down to the kernel code where the possible issue is present</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Fixing the netfilter code for the above issue</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Updating one of the netfilter code with the latest code from that of the mainline kernel</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Rebuilt the kernel - WiFi and mobile network - both worked!</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Realizing all the features are now working with a clang-built ARM kernel for Android!</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Planning to repeat the same with the all ther remaining LLVM/clang toolchains</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Using Android NDK r13b's LLVM/clang in place of main LLVM/clang used so far for building the kernel</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Noticing Kernel panic</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Tracking down the kernel panic to one of the Camera MSM driver code</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Fixing the Camera MSM driver code in terms of device id specification</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Comparing with other Camera MSM driver source code and finding the difference if any</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Completing the device/driver id specification with the missing item - fixed the panic</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Booting to Android home screen this time with even the Android NDK r13's LLVM/clang-built kernel!</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Picking the next remaining LLVM/clang toolchains</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Android NDK r17's LLVM/clang - no issues in booting thus far updated kernel</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Qualcomm Snapdragon LLVM/clang - no issues in booting thus far updated kernel</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Performing round up of all the toolchains and combinations of NDK binutils</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Verifying all the combinations(total 8) :</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Android NDK r13b [gcc + binutils(as, ld, etc)]</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Android NDK r17 [gcc + binutils(as, ld, etc)]</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Android NDK r13b [LLVM/clang + binutils(as, ld, etc)]</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Android NDK r17 [LLVM/clang + binutils(as, ld, etc)]</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Main LLVM/clang + Android NDK r13b binutils(as, ld, etc)</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Main LLVM/clang + Android NDK r17 binutils(as, ld, etc)</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Snapdragon Qualcomm LLVM/clang + Android NDK r13b binutils(as, ld, etc)</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Snapdragon Qualcomm LLVM/clang + Android NDK r17 binutils(as, ld, etc)</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Confirming all of the above work - yes, worked!</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Automating all of the above builds and the testing of the images</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Facilitating automation of all the 8 combination builds</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Collecting the statistics - build time, image sizes, etc</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Summarizing the longest/shortest builds, largest/smallest zImage-dtb, largest/smallest boot.img</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Testing all of the images one by one for the final time</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Consolidating the data from the above automation</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Collecting the complete kernel boot(dmesg) log from each build</div></li><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Taking snapshots of the kernel version, Android version, build number from each build - About/System info</div></li></ul><br></li><li style="margin:0px;padding:0px;list-style:decimal outside"><div style="margin:0px 0px 0px 40px;padding:0px">Wrapping my Android clang-kernel research project!</div><br><ul style="margin:0px 40px;padding:0px"><li style="margin:0px;padding:0px;list-style:disc outside"><div style="margin:0px 0px 0px 40px;padding:0px">Done and dusted. Period.</div></li></ul></li></ol><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><hr style="display:block;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><i style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><font color="#008000"><u><b>[</b></u><u><b>ANDROID ARM LLVM/CLANG-KERNEL ~ RESEARCH<span> </span></b></u></font></i><u style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228)"><b><i><font color="#008000">WALK-THROUGH]</font></i><br><br></b></u><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 1:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>First of all, finding the right kernel source for the hammerhead kernel installed as part of Resurrection Remix(RR) on my Nexus 5 was a challenge. Initially, based on the kernel version information, I took dirtyunicorn kernel source from its repo and built it with unicornblood hammerhead kernel config using Android r13b gcc toolchain. Then I also built the ramdisk needed from the Resurrection Remix Android source base. With that created boot.img and tried that with fastboot - this didn't boot - the usual google logo appeared and looped back to bootloader. After examining the logs in recovery mode, I noticed SELinux specific denials. So, tried to fastboot again with SELinux mode set to permissive. This also didn't boot. After some research, found that the boot.img that I had was smaller than the one that came with Resurrection Remix zip. In that ramdisk was much smaller than the one in the zip. So, after realizing that ramdisk needs other rootfs utils to be part of it which required some more building from RR source, and since I was only keen on the kernel part, I took the ramdisk from the zip and generated the boot.img with that along with my kernel. This booted. Prior arriving at this, I had also experimented with AOSP kernel source, and other kernel sources for hammerhead - some of them didn't even boot so had to go back to dirtyunicorn.<span> </span></span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 2:<span> </span></b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">The booted kernel had almost everything working except for the ADB over USB feature. Though ADB over network worked, when I enabled ADB over USB, I noticed on my host PC, dmesg showed "USB disconnect" event and would reconnect if I disabled ADB over USB. Tried every other stuff to get this working including USB driver debugging, etc - nothing consistenly gave the ADB over USB access. I noticed there were some missing sysfs entries for Android USB function filesystem. So, I debugged around that code and added extra logic to make sure the USB won't get disconnected, etc when ADB over USB was enabled - none helped. After a lot more researching and experimenting, noticed that the kernel that came with RR zip was built with username(voidz) and based on that got an update from RR fourm that there's an updated dirtyunicorn kernel branch which that person had and I took that and tried to build as I built above. The kernel got built with the same unicornblood hammerhead kernel config. Generated the boot.img with this kernel and the ramdisk from the RR zip file, fastboot-ed it, image booted, and ADB over USB worked as needed.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 3:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>With the above prerequisite of a working kernel(source) for my Nexus 5 running RR(oreo), I was motivated to build the Android kernel with LLVM/clang as I had already been successful in building and bringing up x86_64 Linux kernel(4.15.7 onwards - latest 4.17) for my host system running Ubuntu 17.10 x86_64 whose reports are available at the end of this post for the interested people. To begin with, I chose the LLVM/clang toolchain that was present in Android NDK r13b and started to build the same kernel I used with Android NDK r13b gcc above. Similar to that of x86_64 kernel clang-build, there weres some build/compilation errors involving unknown options, etc.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 4:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>To get the Android kernel clang-build further, I disabled the integrated assembler, removed the unsuppored compiler option/flags across kernel components. This allowed clang-build to proceed further. But, there were some still issues in recognizing the inline ARM assembly code correctly since the assembler being picked up was still wrong. Setting CLANG_TRIPLE to arm-linux-gnu and the like in separate attempts, didn't help in any way. After much research, I found out that I can use "-target" option to specify the androideabi target and by that clang was made to search for the assembler with that target as prefix which actually was not present under /usr/bin by default. Hence, it took the host x86_64 GNU assembler and was complaining about unknown assembly instrucitons. So, I created the necessary symlinks over there pointing to that of Android NDK r13b binutils binaries - this fixed the issue of picking the right assembler. By the way, I saw some reports on successful ARM64/AARCH64 clang-kernel for Google Pixel* but the steps therein didn't work for my ARM(32) clang-kernel case, so had to continue with my independent efforts.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 5:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Progressing further, there was an RCU specific static code check which failed - after looking around disabled it as it was harmless. The build progressed further. Next the build failed due to VLAIS used in several of the kernel components including disk encryption, USB Gadget/Function Filesystem, CRC32, netfilter, etc. These addressed compilation errors.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 6:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Next was to address the linker errors - clang generated duplicate exception sections across kernel components which resulted in failure while the linker tried to link all of them together. To address this, I researched a lot in the internet to understand what are these and why are they getting added by clang but not gcc, how to get rid of them if not needed and possible, and so on. So, experimented with options to disable exceptions, unwind-tables, etc - none helped. There were also warnings of unwinding not expected to work for some of the kernel components. Tried to enable the stack unwinding in kernel config - this addressed the linker error but wanted to make sure that this additional change to be not present for only clang-build as gcc didn't need it.<span> </span></span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 7:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>To address the duplicate the exception sections linker error mentioned above, after realizing that gcc doesn't generate this error due to not generating them in the first place, I researched more to finds ways to exclude them. Found the way to inform the linker to leave these exception sections in generating the final kernel image - that solved the issue.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 8:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>After fixing the above linker error of duplicate exception sections, there were some some more linker complaints about missing implementations of ARM eabi versions of memory manipulation functions. Researched on these and found that these are usually available as part of the toolchain but if absent, they need to be implemented by self. So, I wrote my own implementations for them and restarted the build - did't see those linker errors, as expected.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 9:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>With the so far changes, the kernel image got successfully built with clang for the first time. The zImage-dtb was ready to be combined with the pre-built ramdisk used above to generate the quintessential boot.img that I can "fastboot" on my Nexus 5 for the first time.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 10:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Tried to fastboot with boot.img thus built - the image appeared to boot but got stuck with the "Google" logo with the unlocked symbol underneath. Having seen this a lot many times even with gcc, expected the boot to proceed with Android logo animation(RR logo in this case) after some time since I thought booting time might differ between gcc/clang-built kernel. But, it didn't proceed. Having seen a similar thing with x86_64 clang-built kernel for my host system running Ubuntu 17.10 x86_64, my immediate interpretation was that the kernel "panic-ed" somewhere along the boot assuming that kernel at least got loaded and started to boot to some extent. So, I rebooted to recovery mode to retrieve the kernel logs of this unsuccessful boot. But, the /proc/last_ksmg didn't have any logs pertaining to the clang-built Android ARM kernel I fastboot-ed. Instead, it was having some logs from previous gcc-built kernel boot.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 11:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>The above absence of clang-kernel logs itself in /proc/last_kmsg gave rise to numerous questions :</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><ul style="margin:0px 40px;padding:0px;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><li style="margin:0px;padding:0px;list-style:disc outside">Is the kernel getting loaded in the very first place?</li><li style="margin:0px;padding:0px;list-style:disc outside">Is the kernel offset, ramdisk offset wrong or off by some bytes for the clang-built kernel and not the gcc-built kernel?</li><li style="margin:0px;padding:0px;list-style:disc outside">Is the mkbootimg command having the base address right, does it have to be relative or absolute?</li><li style="margin:0px;padding:0px;list-style:disc outside">Is there some incorrect zImage-dtb header(wrong version magic, etc) for some reason, that Android bootloader was considering erroneous, and hence bailing out and sitting idle after displaying the "Google" logo?</li><li style="margin:0px;padding:0px;list-style:disc outside">Is there a way to get the fastboot logs, bootloader logs, where's the bootloader code of Android?</li><li style="margin:0px;padding:0px;list-style:disc outside">How does the Android bootloader(found out that LittleKernel was the bootloader) source locate and load the kernel with offsets, etc?</li><li style="margin:0px;padding:0px;list-style:disc outside">Is there some boot signature that's wrong and hence bootloader isn't able to load kernel?</li></ul><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 12:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>With no clue of whether kernel was getting loaded at all as explained above, I wanted to see if it's possible to boot the clang-built Android ARM kernel and ramdisk used, using QEMU/ARM - just like the debugging method I had employed for that of x86_64 when I saw the Linux kernel booting had stopped as I saw "Loading ..." on my host system with Ubuntu 17.10 x86_64. However, the none of the attempts to boot Android ARM kernel and ramdisk succeeded - nothing was seen at all either on QEMU GUI or on the console in no-GUI mode. Tried different ARM machine types in QEMU options, tried to boot even just the kernel to see if panics by not finding the rootfs/ramdisk as expected - nothing helped.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 13:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>As an additional effort in bringing up Android ARM clang-kernel on QEMU/ARM, I thought if I could cross-compile the LittleKernel bootloader source for ARM and use it as the bootloader with QEMU/ARM, I could see some action - didn't work. Also, I tried to use an UEFI firmware cross-compiled for ARM to boot the same - didn't help. Then I tried to use standard Android emulator(via Android Studio, AVD, etc) to see if I can mention my Android ARM clang-kernel as the kernel to boot the emulator with the necessary arguments - didn't help though it took considerable effort to locate how to load custom kernel in the command-line of Android emulator as the script/bianary "emulator" loads eventuallly the QEMU/ARMel whose command-line invocation I finally figured out and used it for my debugging in this stage.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 14:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>In order to confirm whether ther kernel is at least starting to execute, I retried fastboot-ing some more times in different modes :</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><ul style="margin:0px 40px;padding:0px;color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><li style="margin:0px;padding:0px;list-style:disc outside">Powering off the Nexus 5 and powering it on to bootloader mode, so that old /proc/last_kmsg won't be present and hence no confusion of whether the kernel logs therein is of my clang-kernel boot or of some other previous gcc-kernel boot.</li><li style="margin:0px;padding:0px;list-style:disc outside">Booting into gcc-kernel after failed clang-kernel boot to see if I can get the /proc/last_kmsg from this valid Android boot mode instead of in recovery mode.</li><li style="margin:0px;padding:0px;list-style:disc outside">Enabled earlyprintk and UART debugging in kernel config for the clang-kernel being built and added those parameters in the kernel cmdline.</li><li style="margin:0px;padding:0px;list-style:disc outside">Increased kernel log buffer size to 4M.</li><li style="margin:0px;padding:0px;list-style:disc outside">Increased the kernel log-level to maximum.</li><li style="margin:0px;padding:0px;list-style:disc outside">Researched on who actually renders the "Google" logo if kernel is not even starting to execute - is it then the bootloader which renders that?</li><li style="margin:0px;padding:0px;list-style:disc outside">Why is that with some kernel versions, booting fails and it actually loops back to bootloader and not in this clang-kernel case?</li><li style="margin:0px;padding:0px;list-style:disc outside">Is the DTB appended correctly and TAGS offset correct for the kernel to find it - if DTB is not present, fastboot itself fails saying the DTB can't be found in the given boot.img.</li><li style="margin:0px;padding:0px;list-style:disc outside">Tried to give the kernel(zImage-dtb) and ramdisk separately in fastboot command with offsets, etc - fastboot creates the boot.img on the fly and tries to boot it.</li><li style="margin:0px;padding:0px;list-style:disc outside">Checked if fastboot has some useful options to debug more - like some logging over USB back to host(my PC).</li><li style="margin:0px;padding:0px;list-style:disc outside">Researched around to see if I can add some UART module over USB to get the bootloader/kernel logs before the console(tty) even gets initialized and I can see the kernel logs - I actually found some article of someone having added an external UART module some Android smartphone - but after sometime, I thought it's an overkill for my project - so, dropped that idea of buying something like that and got back to debugging with whatever I had - just my Nexus 5!</li><li style="margin:0px;padding:0px;list-style:disc outside">Reattempted to boot with QEMU/ARM with different TTY*s, etc</li></ul><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">None of the above worked though they helped me in understanding better of how the Android booting works and its internals.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 15:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Then came the point of finding what actually runs first when kernel is made to run - like some low-level kernel code that runs to get the actual high-level code up and running to start dumping some kernel logs? At first I found the C kernel entry-point to be start_kernel() in init/main.c. Tried to put some extra printk() statements at the beginning of it only to find the console gets somewhere down later after a whole bunch of other initializations. So, all the printk would get buffered until then - no use. So, is this the very function that gets called from the Android bootloader or is there some other low-level code that gets entered into?</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 16:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>After some research, found the architecture specific head.S(ARM specific kernel entry point from the bootloader!). So, time to dive into the assembly world - one step closer to the hardware - excited! I spent some time understanding the instructions over there and the inline comments over there to see what actually happens where - by that I also looked around in head-common.S, etc. Finally, realized that this *is* the code to debug in the first place before the start_kernel() even gets called ultimately. But, what to debug, where to print some logs, how to debug - no UART/serial console, no way of finding whether this entry point is even getting hit - all I was seeing was the "Google" log(which I found out in some way that it's not rendered by kernel but the bootloader/some-other-early-code) and nothing else.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 17:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Upon reading the documentation over there in head.S, I doubted whether the hardware is setup properly before entering the head.S : it says certain things about MMU, I-cache, D-cache, etc - are these rightly setup? At the same time, I also thought, if there was something wrong in that, how did the gcc-built kernel boot up without any issue - same bootloader, so same hardware pre-initializations before head.S is entered, same head*.S code and the same kernel except the compiler being gcc instead of clang - so, is clang screwing something up in generating the final binary so that this head.S is not even entered from bootloader?</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 18:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Next was to determine a way to check if the very instruction of head.S was executed or not. With no external debugging aid, this took a lot of brainstorming and researching on the internet - can I place some code in head.S to turn on the small LED on the Android Smartphone in some way to indicate the head.S was indeed getting hit or is there some other way to know the same? All of the available debugging methods involved some external hardware-aid which I didn't have.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 19:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>There came a thought of doing with the ARM CPU itself - can it be made to raise an exception, interrupt, etc through some ARM instruction? Can it be reset? Can it made to jump to reset vector? Yes, that was the "bang on" moment! I researched on the method, rather the instruction to reset ARM CPU - some articles said some of the registers need to be written into to enable/disable something so that ARM CPU gets reset but none of them worked for the ARM environment(Cortex-a15 of Nexus 5) had.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 20:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>After a fair amount of research into how to reset ARM CPU in bare-metal/assembly mode, I realized that there must piece of low-level code which resets/reboots the ARM CPU when the user issues a "reboot" command on console/terminal - where is it? After tracing down the reboot=>..=>sys_reboot()=>...some level-code to restart machine, I located the logic which could restart the system. Using that as a reference for my implementation of ARM CPU reset, wrote a reset logic in ARM assembly and placed it in head.S. After experimenting substantially, came up with a reset logic that seemed to work and called it from the kernel entry point within head.S. With this, rebuilt the clang-kernel, regenerated the boot.img, tried to fastboot it as usual on my Nexus 5 - the "Google" logo appeared as anticipated, then after few seconds as I hoped, the boot process looped back to bootloader! Delighted! My reset logoic worked which meant the kernel entry point in head.S was indeed getting hit! Great find after lot of struggle and what not!</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 21:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>With the above confirmation of the control coming to kernel entry point in head.S from bootloader, I moved the reset logic to few instructions down and repeated the above process of rebuilding-regnerating-fastbooting and again, I could see the Nexus 5 getting reset to bootloader - proved again that the control was fine so far good within head.S. Eventually, there was a place where the program counter was getting updated directly to branch off to a different assembly procedure - I placed my reset logic just after that one - control didn't reach this time - there was no reset - booting process got stuck at "Google" logo like many of the earlier times. This made me think what's wrong with updating the program counter - is it not accessible/modifiable directly? how was it not an issue for gcc-kernel?</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 22:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>After finding the issue with direct update of program counter above, I tried a branch off to the destination using the branch instruction - it worked to my surprise as I moved the reset logic to destination and got the Nexus 5 reset to bootloader this time! So, there was some issue with the underlying binary generated by clang with direct update of PC instead of branching to it like I did. This made me acutally think, since there were some unsupported ABI specfic options for clang that were removed, is there something with the way program counter is interpreted? Hence, I tried experimenting with different program counter sizes, stack-alignment, and all that to the assembler in addition to the given arguments from the clang for generating the object code for the intermediate assembly code generated by clang - none helped, same behavior. Did more of watching the arguments that are being given by clang to the assembler and compared with that of the gcc - what were the differences? Whatever were missing like EABI version, DWARF2 debugging information, little endian flag, etc, I added them manually along with the arguments given by clang so as to run the assembler with the same set of options that gcc was doing - no change.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 23:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Since I had found a way to move the control forward using branch instruction, I studied the control flow and replaced all the program counter updates to corresponding branch instructions - entry point => processor initialization => getting MMU ready => turning MMU on => enabling MMU => starting the kernel where the C code in init/main.c starts executing. This took a lot of time since the above control transfers were across assembly files and carefully going through them and understanding them demanded certain level of effort as I was dealing with entirely ARM assembly code for the first time on my own with no one to ask any questions I had - ARM reference manuals, online documentation, open source discussions were handy in understanding which instructions(in different *.S) do what. Also, I had to combine several of the assembly code spread across files together to be able to branch off by name instead of addresses of the procedures stored in registers.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 24:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>With the replaced assembly code as above, there were some still issues with respect to the assembly instructions modifying the control registers - control wouldn't go beyond them for some reason. Just to if that's really required, had commented it out, and the control would move on but the same issue would occur in another place with some access to the control registers. So, I was not sure whether it's okay to leave out all those control registers read/write - so reverted them to their originals.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 25:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>With additional corrected changes to branching, etc, control eventually reached the start_kernel() of init/main.c - for confirming this I implemented the reset logic I wrote in ARM assembly for use in head*.S and other assembly code, in C and called it within main.c - though the same kind of reset to bootloader didn't happen right away, with some more corrections to my C implementation of reset logic, I saw the same reset behavior - start_kernel() is getting hit for sure as I checked it multiple times with and without my C-reset logic(all of the earlier reset calls were disabled, of course).</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 26:<span> </span></b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">After confirming that start_kernel() was being entered into, I tried moving the reset logic down one function call at a time - reset didn't happen after few of function calls - went inside the function after which the reset was not happening - it turned out to be accessing CPUID(again some sort of control register access which posed as an issue as earlier) and the control seemed not returning from it to the start_kernel().</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 27:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Tried to change the linkage of the first few functions being called to be ASM linkage to see if it makes any difference as start_kernel() was being called(rather branched into) without any issue but not the subsequent functions - didn't make any difference. The goal was to find the underlying issue in any possible way - so methods employed though seemed not so relevant many a times, I have tried them anyway so that I rule them out from further considerations confidently if they didn't work out or didn't help.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 28:<span> </span></b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Tried to move the console initializations over other initializations to be able to see printk messages as early as possible - didn't work anyway.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 29:<span> </span></b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">After all the above, somewhere I thought what if there are some fixes in the newer Android NDK LLVM/clang that were absent in the one I was using(NDK r13b) - downloaded the latest NDK r17 and rebuilt the kernel using the LLVM/clang that was in NDK r17, regenerated boot.img as usual, fastboot-ed it - didn't boot - same result as earlier - got stuck in "Google" logo.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 30:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Looked around on the internet for any reports on how to use clang for Android kernel - found ARM64/AARCH64 report which mentioned using main LLVM for building the LLVM/clang on our own. So, followed the steps there, got the LLVM source, built it as needed, got the toolchain binaries ready : clang, clang++, etc. Used it for rebuilding the kernel, repeated the rest of process - didn't boot - same result as earlier.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 31:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Researched some more to see if there's any other LLVM toolchain for Android that people have used. Found Qualcomm Snapdragon LLVM toolchain. Downloaded it from Qualcomm site. Used the clang within it to rebuild the kernel and repeated the rest of the process - did *not* boot - same result as earlier. So, decided to continue rest of the effort with main LLVM/clang download and built in the above stage instead of Android NDK r13b's LLVM/clang.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 32:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>As the next resort, tried to see differences between the kernel images built by clang and gcc using hexdiff, vimdiff, etc - saw some differences but couldn't find out anything useful.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 33:<span> </span></b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Similarly did a hexdiff between boot.img(s) with clang and gcc kernel - is the kernel offset same in both the cases and so on?</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 34:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Used Android NDK's readelf to examine the kernel images from both clang and gcc builds(vmlinux - both compressed and uncompressed) in terms of the ELF header. Saw some metadata differences - analyzed them to understand if they affected the kernel executions in any way.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 35:<span> </span></b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">Used Android NDK's objdump to determine differences in the sections within the kernel images built using clang and gcc - compared the disassembled code from both cases - saw the differences - went back to assembler invocation - checked the arguments being passed - added manually whatever were missing from the clang invocation of assembler when compared to the gcc invocation of the same assembler. Even then theere were differences in terms of number of sections(text, etc) and their flags, symbols, and so on - spent considerable amount of time to understand if they matter with respect to the reason behind the clang-kernel not booting.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 36:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Going one step further, added a mechanism to save the intermediate assembly file that clang generateed for each source(*.S and *.c), and compared that with that of gcc - there were some differences in terms of optimizations, instruction uses, etc - this made me think there could be some optimizations(over) that might be resulting in unexpected behavior that I am seeing when booting clang-kernel?</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 37:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Based on the above, added a mechanism to replace the assembler directives that were placed by clang with that of gcc, for all of the intermediate assembler code generated - this was to make sure that the ELF generated by clang for the kernel has exactly same ELF header specifics as that of the kernel generated by gcc - automating the whole thing took a lot of work and rework. There was also some unamed intermediate assembly file with architecture set to ARMv5 instead of ARMv7 - so did that replacement as well to make sure I get the exact assembly code specifics as that with gcc.<span> </span></span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 38:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>To keep the differences between the code generated by clang and gcc at minimum, reduced the optimization level of kernel from O2 to O1 - rebuilt the kernel and redid the rest of the process - didn't help in booting the kernel - same outcome as earlier</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 39:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Totally disabled optimization with O0 - this didn't even compile - failed with some errors - researched on the internet and came to know that the Linux kernel code is meant to be built with optimization at least of O1.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 40:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Changed the optimization criteria to be for size(Os) - repeated the whole process of building, etc - didn't help</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 41:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Based on what I read in the documentation at the entry point in head.S, disabled the D-cache, I-cache, etc in kernel config to see if they bring any change - didn't affect.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 42:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Revisited the changes I had made including the memory manipulation functions I had implemented - Are they right? Is there any alignment considerations I need to do? What does a standard implementation looks like? Researched more along these lines, found the actual signatures of these functions, corrected my implementations accordingly - rebuilt the kernel, repeated the rest of the process - didn't change anything.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 43:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Looked around on the internet again why these memory manipulations aren't present by default - can this be because of the optimization level chosen? Is there a way to enable these instead of implementing it myself? - didn't find anything of that sort.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 44:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Meanwhile, came across some report on the stack pointer access for thread local storage needing some explicit assembly-level access. Included that as well, redid the whole thing - no change in the kernel booting behavior though.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 45:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Eventually, I came to the thought there is something extra that's being done by clang that's resulting in some unneeded optimization that's leading to some misinterpretation of given assembly and/or C code - so disabled every other optimization including the intrinsic ones that's built into the compiler code generation after exploring the relevant discussions and clang documentation. Rebuilt the kernel and repeated the rest of the process - to my great satisfaction, this time it didn't get stuck in "Google" logo but it rebooted to boot with the existing kernel(installed on my Nexus 5) - I knew this happens only if there was some kernel panic for any legitimate reason and as I had already disabled all the "reset logic" everywhere, I was pretty sure about I could get the dump of this kernel panic or oops in the recovery mode via /proc/last_kmsg.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 46:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>With the above first milestone of finally achieving the loading and running of the clang-built kernel on Nexus 5 though it looped back to reboot with the installed kernel because it encountered some kernel panic, I was immensely happy and overall project gained incredible momentum since I had to go through tons of research, attempts, experiments, documentation and articles day and night just to get the kernel started and see some logs from it. And yes, I went to recovery mode, and had a look at the /proc/last_kmsg which showed kernel panic - having started from zeroth level in this project seeing my Nexus 5 getting stuck at "Google" logo for hundreds of time since the start of project across numerous attemps spread across day and night amidst so many things, it was a great indication of eventually having a working clang-built Android kernel on my Nexus 5 since I at least saw my clang-built Android kernel alive for some time for the first time ever!</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 47:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Just to confirm, I reverted the most recent changes mentioned above to see if they were "actually" the reason to get the clang-kernel up and running - they were indeed the reason - confirmed it couple of times - great!</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 48:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Focusing on the kernel panic, it was from one of the audio codecs with resepct to buffer overrun - fixed it, rebuilt the kernel, re-fastboot-ed it - there was another audio codec with the same failure - fixed that as well, repeated the process and there were some more of these and fixed all of them - kernel moved forward, saw the RR logo animaton(Andriod logo in case of AOSP)! Android is finally booting!</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 49:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>After a plethora of attempts above, finally I got the Android successfully booted up on the clang-built ARM kernel on my Nexus 5 - confirmed the system information from "adb shell - dmesg - proc-version, etc" and also from "About/System" section of Android settings which showed the clang-built kernel version information in terms of the clang compiler version used to build the kernel, etc. Immensely happy!</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 50:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Noticed the WiFi got connected but had a cross(x) symbol on it - "connected, no internet" was the status. Checked if data over LTE works if not WiFi - didn't - same cross mark if I disabled WiFi and tried to use Cellular data(LTE) - phone calls would work but no internet - checked logcat/dmesg - showed some issue with SELinux denials - spent some time on whether it's the kernel or ramdisk issue, etc.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 51:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Tracked down the above WiFi issue to be some bandwidth module being not loaded - checked for different entries for WiFi/wlan under sysfs and their status and so on - found out a particular piece of netfilter code had some VLAIS in use which I had fixed as per clang requirements - later on figured out that the latest mainline kernel had an updated code for that piece - incorporated that, rebuilt and retried - WiFi worked - no more cross symbol - same case with cellular data. Also, verified that ADB over USB, etc work - so far so good.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 52:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>With everything working so far, I had used main LLVM/clang so far as the clang compiler, so wanted to try the same with all the other clang toolchains I had earlier experimented with, for the sake of universality. So, at first, picked Android NDK r13b's clang/LLVM - rebuilt the kernel and repeated the rest of the process - didn't boot - looped back to boot with the existing kernel - sign of some kernel panic.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 53:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Examined the /proc/last_ksmg as usual to debug the above issue - saw some kernel panic in Camera MSM driver code - tracked down to the actual function as per the stack-trace - after substantial debugging without finding the actual reason for the panic, I decided to move on to the other remaining LLVM/clang toolchains as this was only seeming to happen with Android NDK r13b's clang(which is not the latest as well) - so why waste any more time?</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 54:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Took Android NDK r17's LLVM/clang for rebuilding the kernel and tried bringing it up - worked without any issue(no panic, etc) - Android came up - WiFi, etc all were working - verified the kernel version information, compiler version, etc - all good.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 55:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Next was to use Qualcomm Snapdragon's LLVM/clang to rebuild the kernel and verify everything works - did that - everything worked.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 56:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>With all verified except with the Android NDK r13b's LLVM/clang with which there was a kernel panic from Camera MSM driver code, I decided to go back to it and fix it once for all as I didn't have anything else pending before wrapping this project up!</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 57:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Examined the Camera MSM driver code across different files and compared them with each other, added printk-logs. Surprisingly, I noticed that there was a incorrect driver's code being called back for the device id table registered - there were some string manipulation usage within these functions - suspected them to be overrunning the stack or so and corrupting something up causing such a behavior - dumped various flags, data, numbers, names, etc for the driver, device and its parameters to find out who is calling the wrong driver - found the init code was calling this as a call back after the driver got registered.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 58:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>For one moment, had to check the device tree source for this device for which wrong driver was called back - didn't find anything incorrect as the same works for every other clang-toolchain and even gcc.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 59:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Tried to debug the init code which was calling this based on the device id matching the driver, went through different device driver bare-bone code to understand how a device-and-driver gets mapped onto and the driver's file operations are called - found a difference between the suspected driver and the actual driver which should have been called for the wrongly mapped device, in terms of device id specification.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 60:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Added the missing item in the suspected driver to have the device id specification as expected by the device driver bare-bone framework - rebuilt the kernel, repeated the rest of the process - worked! Android booted even with Android NDK r13b's LLVM/clang!</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 61:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>With that, everything was done and dusted. For the sake of completeness, I redid the whole thing with different combinations of LLVM/clang and NDK's binutils.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 62:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Repeated the process with Android NDK r13b's gcc - all good - no regressions because of changes done for clang.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 63:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Repeated the process with Android NDK r17s gcc - all good - no regressions because of changes done for clang.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 63:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Repeated the process with Android NDK r13b's (LLVM/clang + binutils(as, ld, etc)) - no issues</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 64:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Repeated the process with Android NDK r17's (LLVM/clang + binutils(as, ld, etc)) - no issues</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 65:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Repeated the process with (Main LLVM/clang) + (Android NDK r13b's binutils(as, ld, etc)) - no issues</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 66:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Repeated the process with (Main LLVM/clang) + (Android NDK r17's binutils(as, ld, etc)) - no issues</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 67:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Repeated the process with (Snapdragon Qualcomm LLVM/clang) + (Android NDK r13b's binutils(as, ld, etc)) - no issues</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 68:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>For the sake of completeness and compactness, silenced the various noisy warnings for clang case. Despite that Snapdargon Qualcomm LLVM/clang's instance was showing unavailability of vectorization because of missing needed options to enable them - tried to add the missing ones - didn't silence the warning - researched on that - came to know that there were little benefits of it - ignored those warnings and didn't silence them.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 69:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Repeated the process with (Snapdragon Qualcomm LLVM/clang) + (Android NDK r17's binutils(as, ld, etc)) - no issues</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 70:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Added clang-specific build-level changes under clang-only category to not mess with gcc-builds</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 71:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Reverified that everything is fine with all the toolchains with thus far set of changes</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 72:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Automated the whole of the above combinations, generated the boot.imgs, compared the build-times, zImage-sizes, boot.img's size - listed out the shortest/longest builds, smallest/largest zImage, smallest/largest boot.img.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 73:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Ran the overall automation several times with any activity on my system and with the activity to see the difference in build times, etc. Note down the results.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><b style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial">Stage 74:</b><span style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline"><span> </span>Wrote test automation to fastboot all of the images one by one and checked the sanity of all the images - all good - all done. Period.</span><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br style="color:rgb(0,0,0);font-family:Ubuntubeta,Ubuntu,"Bitstream Vera Sans","DejaVu Sans",Tahoma,sans-serif;text-align:left;background-color:rgb(235,236,228);text-decoration-style:initial;text-decoration-color:initial"><br></div></div>