-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[4.19][12/13][bahamut] Stuck at bootloader logo #788
Comments
Probably, can you try that with the kernel that was previously working (rebuild kernel, reflash boot+dtbo, eventually vbmeta)? |
Hey Marijn, I can confirm that using the kernel at the previously working commit above makes 12.1 boot. Will bisect to find a little more about this. |
@bartcubbins Such as? It boots fine here. |
After bisecting it seems that 4.19.247 (sonyxperiadev/kernel@7354523) is the culprit of this. If anybody else with the same issue could confirm this, it would be great. |
I deleted my comment immediately after I posted it, I don't know how you managed to catch it;) |
🥷 (might have clicked the notification quickly, and GH isn't responsive enough to remove the message in time?) Feel free to edit/strikethrough/amend - or even hide - your comment in that case, deleting it outright makes things confusing ("I just read that, where has it gone to?"). |
Please post the contents of /sys/fs/pstore. |
Hello, I have I different phone, but the same kernel and the same symptoms. In a few hours I should be able to post /sys/fs/pstore |
@KingProNoob2 what phone do you have ? |
pdx-201 (Seine platform) |
Sooo... I mounted system.img and /sys was empty. Then I opened the ramdisk and it was empty too. Are those symlinks to somewhere? |
How would this be done? Should the broken kernel be booted and then the directory somehow pulled from recovery by flashing a working boot image? |
I can confirm the reported issue |
after a quick look the issue is caused by the clang commits from Sep 19, 2022 reverting those commits and rebuilding the kernel fixes the boot |
after a quick look the issue is caused by the clang commits from Sep 19,
2022
https://github.com/sonyxperiadev/kernel-sony-msm-4.19-common/commits/aosp/L
A.UM.9.12.r1
reverting those commits and rebuilding the kernel fixes the boot
Kernel panic?
|
stuck at Sony logo |
@bartcubbins resetting the git |
stuck at Sony logo
Ah before there kernel is loaded or so early that there's no pstore contents?
|
Building with the latest kernel-sony-msm-4.19-common (544e0e90768068fe2b5923960980d1ec721ff660) ends with build error in my test env:
Command line used: Though I haven't tried a clean build yet, there's another case of such fail here: OnePlusOSS/android_kernel_oneplus_sm8150#8 The advice was to use clang, which I believe the among script did? (Haven't had time for more thorough investigation, sorry:) |
Simonas Leleiva ***@***.***> writes:
Though I haven't tried a clean build yet, there's another case of such fail here: OnePlusOSS/android_kernel_oneplus_sm8150#8 The advice was to use clang, which I believe the among script did? (Haven't had time for more thorough investigation, sorry:)
Yes the script uses clang unless modified, you could test if it work
with a recent gcc.
I usually compile with Gcc 12.x locally (aarch64-linux-gnu-gcc
arm-none-eabi-gcc in Arch).
|
Just an FYI: while making my way up to the latest 4.14 kernel for kumano, 4.14.283 manifests the same behavior described here. Not coincidentally, the changes in both kernels are very much the same, so if the fix is found on one of them it can be carried over to the other. The AOSP base is 11 in this case, which means an older clang too. |
…is set" This reverts commit cb81ea9. It seems that some our Sony devices require tampering with the sysfs before the driver data is done being set, meaning that devices must be already registered before being touched. Fixes: 7354523 ("treewide: 4.19.247") Link: sonyxperiadev/bug_tracker#788 Signed-off-by: voidanix <voidanix@keyedlimepie.org>
@KingProNoob2 can you test on seine if this branch boots for you on 12.1? |
Yes, i can. I will build just the bootimage tho and use an older system.img (for speed reasons) |
Edit: I don't think I can now, because i kinda broke my OS on my pc ( I use arch linux btw) |
ping @KingProNoob2, any updates on this for seine? |
Just wondering which driver is behaving wrong. I was asking for logs but none have been provided. |
See the referenced commit above, from my investigation it seems to be extcon. As for the logs, I still have no idea how to pull them as pstore does not seem to work and it just cannot get past the logo. |
voidanix ***@***.***> writes:
As for the logs, I *still* have no idea how to pull them as pstore does not seem to work and it just cannot get past the logo.
Does boot-debug.img work?
|
Didn't try that as it was not present in |
Which buildtype? Try buildtype userdebug.
|
I have tried all of them so far (user, userdebug and user), but none of them boot nor have pstore. |
does your device boot with the precompiled kernel? |
No it does not, but I highly doubt it is related to the build script changes. |
this is strange since I built bahamut on Friday and it boots to UI |
@voidanix please flash your device with 55.0.A.11.25 then flash AOSP again (using the prebuilt kernel) |
Flashing both 55.0.xxx and 55.1.xxx before AOSP did not work in my case. Are you sure you are not using an old kernel checkout? |
@voidanix please use the prebuilt kernel to rule out any variation from my build |
@voidanix you should be able to build and boot the kernel for your device |
Can confirm that the latest prebuilt boots (tested on both 12.1 and 13), although is no modem at all now (unsure if related to T, but qcrilhook is kinda dead). Let me know if I should open an issue about this as well. |
do you have the sensors working? |
Adjusted commit e75b5ea ("mailbox: forward the hrtimer if not queued and under a lock") for downstream 831c430 ("drivers: mailbox: fix race resulting in multiple message submission"). Conflict with d221ce5 ("nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling") resolved. Skipped 67d5ad72940875dcc727 ("extcon: Modify extcon device to be created after driver data is set") due to it rendering our devices unbootable. Link: https://lore.kernel.org/r/20220613094908.257446132@linuxfoundation.org Link: sonyxperiadev/bug_tracker#788 Signed-off-by: voidanix <voidanix@keyedlimepie.org>
Adjusted commit e75b5ea2d6b15ba769d7 ("mailbox: forward the hrtimer if not queued and under a lock") for downstream 831c430 ("drivers: mailbox: fix race resulting in multiple message submission"). Conflict with d221ce54ce331c1a23be ("nfc: st21nfca: fix memory leaks in EVT_TRANSACTION handling") resolved. Skipped 67d5ad72940875dcc727 ("extcon: Modify extcon device to be created after driver data is set") due to it rendering our devices unbootable. Link: https://lore.kernel.org/r/20220613094908.257446132@linuxfoundation.org Link: sonyxperiadev/bug_tracker#788 Signed-off-by: voidanix <voidanix@keyedlimepie.org>
This reverts the changes introduced with upstream commit cb81ea9 ("extcon: Modify extcon device to be created after driver data is set"). It seems that some Sony devices (e.g. kumano) require tampering with the sysfs before dev_set_drvdata() finishes. Fixes: 7354523 ("treewide: 4.19.247") Link: sonyxperiadev/bug_tracker#788 Signed-off-by: voidanix <voidanix@keyedlimepie.org>
This reverts the changes introduced with upstream commit cb81ea9 ("extcon: Modify extcon device to be created after driver data is set"). It seems that some Sony devices (e.g. kumano) require tampering with the sysfs before dev_set_drvdata() finishes. Fixes: 7354523 ("treewide: 4.19.247") Link: sonyxperiadev/bug_tracker#788 Signed-off-by: voidanix <voidanix@keyedlimepie.org>
This reverts commit 0fe1902.
Platform: kumano
Device: bahamut
Kernel version: 4.19.248
Android version: 12.1 and 13
Software binaries version: SW_binaries_for_Xperia_Android_12_4.19_v3a_kumano.img
Previously working on
Last kernel checkout at sonyxperiadev/kernel@b162c36
Description
Device is stuck at bootloader logo (SONY) with a red notification LED, unable to boot into Android.
Not sure if 13 is supposed to boot at this time on kumano, but it does currently not: building 12.1 confirms that it does not boot there either.
Purely guessing, sonyxperiadev/kernel#2533 might have something to do with this.
How to reproduce
Build cleanly either T or S, both should not boot.
Additional context
No idea how to pull any logs from this state.
The text was updated successfully, but these errors were encountered: