LK doesn't boot on /most/ 64-bit devices

npjohnson commented 7 years ago

As the title states.

We believe it may be due to the stock bootloaders forcing 64-bit boot modes, but have no definitive proof yet.

So far, it doesn't boot on:

HTC One M9 (msm8994, FDT): Stuck on aboot splash screen
Huawei Nexus 6P (msm8994, FDT): Stuck on aboot splash screen
LG Nexus 5X (msm8992, FDT): Stuck on aboot splash screen
Google (HTC) Pixel/Pixel XL (msm8996, FDT): Stuck on aboot splash screen
LG G5 (msm8994, FDT): someone in the chat tried it iirc, and they said stuck on aboot splash screen
LeEco Le Max 2 (msm8996, FDT): reboot
ZTE Axon 7 (msm8996, FDT): reboot/powerdown
Oneplus 3/3t (msm8996, FDT): stuck
Lenovo ZUK Z2(msm8996, FDT): 900E diag mode
Xperia X Compact (msm8956, FDT): stuck

M1cha commented 7 years ago

do what I suggested in the 6p issue:

"what you can try on all your devices with this problem is changing the LK loading addr to the same as used by the stock bootloader(and rm -Rf out after doing so). Many devices don't like booting LK from the initial linux loading addr."

CodingMarco commented 7 years ago

How exactly can we do that?

M1cha commented 7 years ago

dump the 'aboot' partition and run binwalk on the resulting file

CodingMarco commented 7 years ago

Where can I change the LK loading addr? In config.ini under LK_BASE or BOOTIMG_BASE? And should I use the kernel addr or the ramdisk addr?

Thanks for your help!

M1cha commented 7 years ago

LK_BASE. kernel/ramdisk address? sounds like you're looking in the wrong place because these have nothing to do with this.

Maybe u dumped the boot partition by accident? 'aboot' is not a typo.

CodingMarco commented 7 years ago

What is it then? Sorry that I don't understand so much…

CodingMarco commented 7 years ago

I dumped /dev/block/bootdevice/by-name/aboot

M1cha commented 7 years ago

that's correct but there are no kernel or ramdisk addresses. if you're unsure, just upload the binary and I'll take a look.

CodingMarco commented 7 years ago

Here is it: https://drive.google.com/open?id=0B1kUxbPpOiT9TE9NVlE4WU1CTm8

Thank you!

M1cha commented 7 years ago

@Glove007 0x91800000

M1cha commented 7 years ago

I've added LeEco Le Max 2 (msm8996) to the list. changing the loading addr didn't help and the device force reboots which usually is a sign of the hypervisor forcing a reboot.

twoeye commented 7 years ago

ZTE/Axon 7 (msm8996)

With adjusted LK_BASE from aboot: fastboot lk reboots phone. Without adjusted base: fastboot lk turns off phone.

M1cha commented 7 years ago

ok two more ideas/information requests:

does lk_origdtb.img work on these devices?
do these devices use dt.img or appended fdt?

npjohnson commented 7 years ago

@M1cha

No, lk_origdtb makes no difference, still hangs at the aboot splash screen of most the respective devices.
According to EFI Droid, they use appended FDT, but I might have had an idea that may be the root of this whole issue... I am almost certain the Nexus 6P, Pixel XL, and HTC One M9 all use DT (and not FDT). Is there a simple way to check this? I was wondering if maybe some mis-handling by EFI Droid's unmkbootimg of the device tree creation.

M1cha commented 7 years ago

@npjohnson if unpackbootimg said there is an fdt, then that should be true. Otherwise the dtb patching would fail due to invalid contents. Also Nexus devices used appended fdt's long before qcom so I'm pretty sure the 6p does too. You can double-check if EFIDroid is right by looking at your ROM's BoardConfig.mk but if BOOTIMG_FDT is defined in EFIDroid and there's a valid fdt in the device directory your device is certainly using fdt.

npjohnson commented 7 years ago

@M1cha That FDT define (nor any other FDT define) is made anywhere in these devices device trees (in AOSP). The output image type is however, defined as zImage-dtb, does that give you any clues? How do I tell if the EFI Droid unpacked FDT images are valid?

M1cha commented 7 years ago

@npjohnson the define I've mentioned is an EFIDroid define, not an Android one. https://github.com/LineageOS/android_device_huawei_angler/blob/cm-14.1/BoardConfig.mk#L35 Image.gz-dtb is means: 'cat Image.gz dtb1.dtb dtb2.dtb ...' with Image.gz being a NON-self decompressable Image. the 32bit equivalent of this is zImage-dtb which means 'cat zImage dtb1.dtb dtb2.dtb ...' with zImage being a self-decompressable Image.

with that being said, the following possible causes come to my mind:

the stock bootloader doesn't like 32bit kernels for some reason
the stockbl doesn't like this header(but it should since linux uses the same): https://github.com/efidroid/build/blob/master/core/tasks/lk.sh#L134

if 32bit is the reason we're screwed because I don't know if we can pull off coding a stable 64bit lk and UEFI that easily.

EDIT for "How do I tell if the EFI Droid unpacked FDT images are valid?": run binwalk, file or dtc on them or use a hex editor.

npjohnson commented 7 years ago

@M1cha Ah. I see your point.

A way I could test this quickly is to build a 32 bit kernel off the devices kernel source and see if I could boot it right?

M1cha commented 7 years ago

@npjohnson if that's supported yes, I dunno if you can easily build one or if it requires some more porting efforts.

Also keep in mind that if it works and you boot TWRP or so you need a 32bit TWRP ramdisk.

npjohnson commented 7 years ago

@M1cha I know offhand that none of Angler's firmware's are 64-bit, and it /shouldn't/ be too much effort. I'll see what I can do tomorrow.

M1cha commented 7 years ago

@npjohnson I've started editing the OP to add info about what happens after booting lk(reboot/shutdown/stuck). can you do that for your devices too?

npjohnson commented 7 years ago

@M1cha done

M1cha commented 7 years ago

@npjohnson thx. did you ever check if the device is really stuck or if it enters qcom download mode(lsusb)?

npjohnson commented 7 years ago

@M1cha Stuck, no USB interface.

M1cha commented 7 years ago

@npjohnson can you extend the list with FDT/DT information like I did with ZUK Z2? If all of them use FDT then we have our reason. my xiaomi mi4c has an msm8992 and works, but uses a DT.

npjohnson commented 7 years ago

@M1cha Updated. They're all FDT :)

Think we found the problem then.

drsn0w commented 7 years ago

Stuck at Google splash screen on Nexus 5X (bullhead)

npjohnson commented 7 years ago

@drsn0w added to the list

M1cha commented 7 years ago

try to do this (after compiling):

cat out/device/?/?/lk_kernel/build-?/lk.bin | gzip -n -f -9 > out/lk.bin.gz
cat out/lk.bin.gz device/?/?/fdt.img > out/Image.gz-dtb

then, repack lk.img with out/Image.gz-dtb as the kernel. Since the build system prints the mkbootimg command at the end you just have to copy and edit it. Pleas not that even if this works it's not a permanent solution for many devices because fdt and/or gzip-compressed kernel were not supported on the bootloader which the device was shipped with.

oshmoun commented 7 years ago

Xperia X Compact (kugo) also seems to have the same issue. i.e, booting lk.img or lk_origdtb.img results in a stuck device with no usb connection

EDIT: @M1cha using your method with appended dtb, device now reboots to system and does not get stuck anymore.

drsn0w commented 7 years ago

@M1cha I tried your suggested fix on Nexus 5X (bullhead) I was able to boot into the first LK step, and run finalize_device. Currently doing more testing, will update.

npjohnson commented 7 years ago

@M1cha using that repack method on the Nexus 6P results in being able to boot LK!!! I was able to finalize_device and all.

It still visually hangs at the Google logo, but now we have fastboot access behind it!

I figured I'd try 2NDSTAGE_DTB, and that resulted in the display briefly firing on, and then running a ton of text in front of tux then rebooting. I'll move that to the 6P issue though. Looks like we found the root of this issue!

EDIT: Even the 6P's display is fixed, but this appended FDT method only works for LK as of now, and not for UEFI.

drsn0w commented 7 years ago

@npjohnson take a look in #porting on Slack, we're working through some display issues on the 5X, might be similar for 6P

drsn0w commented 7 years ago

5X LK boots with working display, but when I did the same to the UEFI kernel it simply reboots into system

ghost commented 7 years ago

Same bug causing device to boot to the system instead of staying in lk.img . Looking for a resolve soon

Trying to port to Moto G 2014 (msm8226)

npjohnson commented 7 years ago

@titanlts That'd be incorrect. 8226 is not 64 bit. Plus, the Moto G 2014 already has a fully functional port (only thea officially, but just switching the name gets titan to work, and merlin requires a few tiny edits).

ghost commented 7 years ago

Yes ! I already know that titan is a arm not arm64 . But guys on XDA , told me to just drop the info about my device if it had something related to this issue .Thanks for that info ! I will look into that and change it ;)

On 14-Mar-2017 7:22 AM, "Nolen Johnson" notifications@github.com wrote:

@titanlts https://github.com/titanlts That'd be incorrect. 8226 is not 64 bit. Plus, the Moto G 2014 already has a fully functional port (only thea officially, but just switching the name gets titan to work, and merlin requires a few tiny edits).

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/efidroid/projectmanagement/issues/89#issuecomment-286297992, or mute the thread https://github.com/notifications/unsubscribe-auth/AZCSKaBMNwyZLlBa0G-WAjy1TePo8kTdks5rlfLYgaJpZM4MXim5 .

ghost commented 7 years ago

@npjohnson Can you help guiding me to the lk.img and uefi_boot.img of thea . So that i can modify it to make it work on titan

npjohnson commented 7 years ago

@titanlts

It's a tad more complicated.

Send me your boot.img and I'll remake the device tree and submit for official support through @M1cha.

ghost commented 7 years ago

@npjohnson No need :) . I managed to build it successfully . It's working now

ghost commented 7 years ago

Except for the uefi_boot.img . it is freezed in the Splashscreen

twoeye commented 7 years ago

ZTE Axon 7

lk_origdtb.img: Reboots device Image.gz-dtb/repacked lk.img: Reboots device

I'm fairly confident in my results, however this is at a technical level which is a bit unfamiliar.

npjohnson commented 7 years ago

@titanlts Offer still stands. Email your boot image to the email on my GitHub profile and I'll submit for official support, as I had finished it, but just forgot to submit, super easy to recreate though.

ashdkv commented 7 years ago

Hello! Any progress with msm8996?

M1cha commented 7 years ago

msm8996 has another GIC(v3) maybe that's the problem?

Nobiscum commented 7 years ago

Does anybody knows which branch from codeaurora for LK is actual? I need to compile LK for OnePlus3

adipatiarya commented 7 years ago

how to dump adress base aboot

SplicedNZ commented 7 years ago

I tried to disassemble the aboot image from my OnePlus3t in IDA, my goal was to check if ABOOT_FORCE_KERNEL64_ADDRis set, my assumption is that stops loading of efidroids 32bit LK.

The "aboot" image is in qualcomm MBN format, normally aboot's first 40 btyes are a ELF header containing aboots sizes and addresses, but isnt the case here.

So, in addition to the above question, does anyone know how to obtain the "ImgBase" value from these MBN files? without it, aboot cannot be disassembled correctly.

M1cha commented 7 years ago

@JTRealms this is the format of the header: https://github.com/efidroid/modules_libboot/blob/master/loaders/qcmbn.c#L31

Also, there are plugins for IDAPro to load mbn files. Also, this option does NOT mean that the kernel will be booted in 64bit mode.

fxsheep commented 4 years ago

@M1cha @npjohnson I have the same problem on Readmi 3S (land) , both lk and uefi stuck at aboot screen.I'm not very familiar with ARM or Qualcomm, but here are some of my ideas:

Ater some investigations I think it isn't because stock LK forces AArch64 boot mode.All of these devices shares a similar lk codebase, some even have arm32 kernel, so why should it do? So I did some experiments: 1.Boot an arm32 kernel (my device has arm64 stock kernel and rom).I didn't try to port my own, instead I tried a kernel from a very similar device with arm32 kernel, Redmi S2.(Ignore the fact that it has msm8953 while mine is msm8937). It rebooted immmediately (of course), but from pstore kmesg I have seen it booting (but crashed because 8937 and 8953 difference, ofc). This has proved that my LK in fact has the ability to boot arm32 images. 2.Some facts: I found that the difference between arm32 and arm64 boot.img is that arm32 has a zImage with a special header while arm64 is Image.gz+dtbs.Stock LK probably uses this fact to determine 32/64 bootmodes, and EFIDroid matches arm32 perfectly. 3.Later I had a good idea: Maybe the LK has been running but just crashed before fastboot?Why not get some UART logs?However it isn't convenient for me to get the UART connection to the SoC so I went another way: https://github.com/efidroid/bootloader_lk/blob/91bd0e0878af6b6731986519387d17c411482d34/platform/msm_shared/debug.c#L67 LK has put the UART log buffer to memory.Although it isnt hardcoded but it looks quite static.Based on the fact that my device has a pretty open EDL, I went to dump the buffer directly in EDL mode: https://github.com/alephsecurity/firehorse This is a great tool for hacking the EDL (yay). With this tool I dumped randomly starting from 0x80008000 which is the default NOUEFI LK loadaddr. Soon I found the buffer is located at 0x80073E58.(since it has RLOG magic it is quite outstanding)

PS H:\下载\firehorse-master\host> C:\python27-x64\python.exe firehorse.py -c COM3 -t nokia6 fw peek 80073E58 400 INFO: 80073e58 52 4c 4f 47 00 40 00 00 2b 00 00 00 2b 00 00 00 RLOG.@..+...+... 80073e68 44 2f 5b 30 5d 20 73 6d 65 6d 20 72 61 6d 20 70 D/[0] smem ram p 80073e78 74 61 62 6c 65 20 66 6f 75 6e 64 3a 20 76 65 72 table found: ver 80073e88 3a 20 31 20 6c 65 6e 3a 20 35 0a 00 00 00 00 00 : 1 len: 5...... 80073e98 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80073ea8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80073eb8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80073ec8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 80073ed8 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ Whoops! It printed only one line about smem ,and dies after that? At least the LK is really booting and "the reboot" isn't really caused by HYP.I'm looking into LK boot sequnce to find out why.

efidroid / projectmanagement

LK doesn't boot on /most/ 64-bit devices #89