06-01-2025, 09:08 PM
Pinetab2 black screen of death seems to be a common problem.
I'd like to get some clarification on what causes this and what actions should be taken to resolve the issue or diagnose as dead the tablet. Specifically the details of the boot sequence , what the bootloader is up to, if it's a two part loader as well as what to expect and look for when using minicom or the like to communicate with the apparently dead tablet.
I'll be talking in terms of Danct Arch here, the current , June 2025, default
For starters, the boot order and uart bypass.
The wiki instructions here say that the pinetab2 will first look to boot from the micro sdcard, then if no bootable image is found, look to the emmc and that
If this fails, to use the uart to bypass the standard boot and force a boot from the micro sdcard. The reason for having to do this is said to be due to a corrupt or changed bootloader.
This begs the question: what bootloader is following the bypass and booting from the micro sdcard? It would seem that for the uart bypass to work there must be a boot loader that is not corrupted or overwritten that will make use of it. This would obviate the need for the uart bypass. The 2019-2020 discussion here would indicate this https://forum.pine64.org/showthread.php?tid=8439
So what gives?
Second, what exactly is the bootloader looking for? This question arises from the fact that the factory image /boot folder layout is different from that of the sdcard images , both the bare and plasma images. This may indicate that the bootloader may if it finds the device in a certain state, require the factory image. I'm not saying this is the case. Just that it's a possibility and one of the things that needs to be clarified in order to properly diagnose and solve the pinetab2 black screen of death issue.
Finally, when a minicom (or the like) session is started what are we to expect? What is the reply from the tablet ? What can prompt a reply or what command tests if the tablet is alive here?
As for what causes the black screen of death any insights from pine64 would be useful here. Though this is a developer tablet not for general public use booting the tablet and reinstalling the os are primordial. As is diagnosing if the unit is fried.
As a note on this mine died during a pacman update. However after opening the tablet up I found that the plastic near the right speaker (right side from front, near the board) was melted. I'm pretty sure that's enough heat to do a number on something on the motherboard but of course without knowing what the boot loader implementation is and what it's doing more precisely it's a guess as to if this is the case.
If other pinetab users have these same questions and interests or experience with this please chime in.
I'd like to get some clarification on what causes this and what actions should be taken to resolve the issue or diagnose as dead the tablet. Specifically the details of the boot sequence , what the bootloader is up to, if it's a two part loader as well as what to expect and look for when using minicom or the like to communicate with the apparently dead tablet.
I'll be talking in terms of Danct Arch here, the current , June 2025, default
For starters, the boot order and uart bypass.
The wiki instructions here say that the pinetab2 will first look to boot from the micro sdcard, then if no bootable image is found, look to the emmc and that
If this fails, to use the uart to bypass the standard boot and force a boot from the micro sdcard. The reason for having to do this is said to be due to a corrupt or changed bootloader.
This begs the question: what bootloader is following the bypass and booting from the micro sdcard? It would seem that for the uart bypass to work there must be a boot loader that is not corrupted or overwritten that will make use of it. This would obviate the need for the uart bypass. The 2019-2020 discussion here would indicate this https://forum.pine64.org/showthread.php?tid=8439
So what gives?
Second, what exactly is the bootloader looking for? This question arises from the fact that the factory image /boot folder layout is different from that of the sdcard images , both the bare and plasma images. This may indicate that the bootloader may if it finds the device in a certain state, require the factory image. I'm not saying this is the case. Just that it's a possibility and one of the things that needs to be clarified in order to properly diagnose and solve the pinetab2 black screen of death issue.
Finally, when a minicom (or the like) session is started what are we to expect? What is the reply from the tablet ? What can prompt a reply or what command tests if the tablet is alive here?
As for what causes the black screen of death any insights from pine64 would be useful here. Though this is a developer tablet not for general public use booting the tablet and reinstalling the os are primordial. As is diagnosing if the unit is fried.
As a note on this mine died during a pacman update. However after opening the tablet up I found that the plastic near the right speaker (right side from front, near the board) was melted. I'm pretty sure that's enough heat to do a number on something on the motherboard but of course without knowing what the boot loader implementation is and what it's doing more precisely it's a guess as to if this is the case.
If other pinetab users have these same questions and interests or experience with this please chime in.
