Hang on boot with older bootloader

Search This thread

Tasssadar

Inactive Recognized Developer
Dec 31, 2010
818
6,128
Brno
tasssadar.github.com
I've got reports when for some users, the device would freeze on boot when using older bootloader versions (3.41 I guess?) and custom kernel. This hang apparently disappears if the user upgrades to the newest bootloader.

Does anybody knows why this happens? I know Metallice has this issue with his kernel, so he tells users to upgrade to newest bootloader. Does anybody else have the same issue, maybe pinpointed the reason why this happens?

It doesn't cause any real problems because newest bootloader works okay, but I would still like to know why it happens.
 
Last edited:

zachf714

Senior Member
Jun 4, 2012
3,596
984
Mooresville
I've got reports when for some users, the device would freeze on boot when using older bootloader versions (3.41 I guess?) and custom kernel. This hang apparently disappears if the user upgrades to the newest bootloader.

Does anybody knows why this happens? I know Metallice has this issue with his kernel, so he tells users to upgrade to newest bootloader. Does anybody else have the same issue, maybe pinpointed the reason why this happens?

It doesn't cause any real problems because newest bootloader works okay, but I would still like to know why it happens.

I found after wondering the same question that it doens't actually hang but people are to impatient to wait and see. I also found that on a dead battery even on the newest bootloader even if there is enough charge that it can hang and a reboot is needed to be forced apon.
 

adfad666

Inactive Recognized Developer
Jul 29, 2011
763
4,302
Google made an announcement that they added some extra suppliers for certain components, I think some different storage chips, that required the new boot loader. That's probably the issue.
 

bftb0

Senior Member
Feb 5, 2010
2,594
1,041
[speculation]

There is no hardware reset/change which occurs when the bootloader transfers control to whatever comes next (recovery kernel, OS kernel, etc) other than what the kernel itself will attempt to do on it's own as it begins initializing, so beyond things which are explicitly passed to the kernel from the bootloader (e.g. the kernel boot command argument list), whatever hardware state - clocking configuration, rate, or a whole slew of other device initializations - that the bootloader sets up can be regarded as an implicit set of "hardware state" parameters for the kernel which follows. (It is impossible for the kernel to reset *everything* back to a known state via a hardware reset, as this would just re-launch the bootloader)

So, the scenario described certainly seems feasible enough if the kernel code makes inappropriate assumptions about inherited state, sequences initializations differently, etc.

I was poking through TWRP's kernel log the other day, and was somewhat shocked to see a message about failure to read the mmc device's (Flash Memory!) partition table - followed immediately by an indecipherable message about a clocking change .... and then normal sorts of messages about partitions found. :eek: Rather unnerving as that suggests something extremely fundamental for a recovery (partition layout) is being attempted initially in a sketchy fashion.

It does seem rather odd that some mismatch between the kernel's presumption of inherited hardware state would manifest itself in late boot behavior - the boot animation screen for the OS is in /system, no? Seems like if you are seeing things progress that far along the kernel probably has not failed in any dramatic way.

Anyhow - why not just put the question to the M-kernel dev in his thread, or give him the URL to this thread and ask him to comment?

[/speculation]

cheers

[ Edit ] I suppose I should have added that if you experience the problem yourself with a set of kernel mods, you might be able to come up with a hypothesis by bisecting backwards towards a reference commit that doesn't have the problem. Seems like a lot of work though, given that - for lack of Asus bootloader source code - the bootloader's behavior changes between releases are opaque.
 
Last edited:

Metallice

Senior Member
Jun 24, 2010
3,275
5,173
I spent a long time trying to figure it out before the bootloader update fixed it. Couldn't. The problem would just appear randomly. I tried reverting patches, resetting git, trying to find a cause, but there seemed to be no definite cause. One patch removal would seem to solve it, and then it would come back after adding another, dissapear when I added back the patch I thought was causing it, etc. etc.

I now don't see it as an issue since any bootloader beyond 4.1.x fixes this.
 

ngoralph

Senior Member
Apr 16, 2012
1,719
1,309
Xiaomi Mi Pad 5
Samsung Galaxy S22 Ultra
was on 3.34 when started to experience this the only way it gets fix for me is pressing the up/power button
and the hang was not just in boot even going to the recovery via fastboot also hangs
i think the only fix for this is updating bootloader