TL-DR:
No matter what medium is inserted, my PBP does not turn on.
Yesterday, when my PBP arrived, I was trying to install Manjaro on it. Because I only had an 8 GB microSD card around, I put the Manjaro installer on it, which contains an archive of an image of a working Manjaro install. That image is too big to fit on the microSD-card next to the archive. So while having booted the installer SD-card, I created a new partition table (GPT) on the eMMC-Disk (mmcblk2) and created one single ext4 partition, where I moved the archive, extracted it and copied the Image back to the microSD-card. To continue with the installation, I tried to reboot the PBP while still having the SD-card inserted, but sadly had to see, that my PBP would not turn on anymore.
What I have tried (and basically all combinations):
* Pulling the battery plug and putting it back in
* Pressing the reset button
* Booting it with a known-good microSD-card (and without one)
* Booting it with eMMC enabled / disabled
* Booting it with the eMMC-Module removed
* Booting it with and without the power adapter attached
What I noticed doing that:
* The Power LED does not turn on (which makes sense, because it's software controlled, as a user on the IRC pointed out)
* The Screen stays blank (backlight does not turn on)
* No Output on the serial console (Controlled by Linux)
* No Coil whine at all
* (I am not sure about this) the SoC felt slightly warmer than the rest of the device
I have asked in the IRC for help. Another user seems to have the same problem, their PBP was also in the same batch as mine (2019-12-24, ISO)
As I do not have much money (I am a student) and bought this laptop as my daily driver, I am very, very hesitant to do any hardware measurements / modifications as I am not especially talented doing that and can't risk this laptop.
Has anyone else seen this before or even recovered a PBP from this state?
I would be very glad to hear from that.
Greetings, Waweic
I'm sorry I don't have an immediate solution for you, but I highly suggest purchasing one of the eMMC to USB adapters, so next time you can burn the image directly. It takes way less time to ship, too.
Are you seeing the same behavior without the SD inserted? I would imagine that if the Manjaro installer wanted the PBP to reboot, it was probably to resume on the new install. (Idk for sure, my Manjaro install is from before the installer, and on an SD.)
Thanks for your fast answer, I do now have a little update. After like three times plugging the eMMC-module out and in again, selecting a random microSD-card praying, resetting and booting, I do now have an Android running. This makes the situation a whole lot less scary, although I still have to find another working microSD card that's big enough for Linux
01-02-2020, 12:19 AM
(This post was last modified: 01-02-2020, 01:35 AM by bcnaz.)
While I am not familiar with a lot of distro's, the ones I have installed have been between 600mb and 2.4 gb or 2.6gb
Of course that is the original install operating systems, and you can add a lot of software after the installation,
but it would seem that an 8gb should be more than large enough...
If you just do a quick glance around it does appear that the first bootable device is the sd card,
BUT .. That is a boot sequence that is loaded into the eMMC...
Actually the hard coded boot order starts with SPI, then eMMC, see the Wiki for more details.
.... So if the eMMC is corrupted this will not happen, these arm/cpu computers are not bios controlled like a AMD/Intel computer.
LINUX = CHOICES
**BCnAZ**
Donate to $upport
your favorite OS Team
Yes, I have read the same thing in the Wiki. I have also talked to people on the IRC. I am now as far as yesterday. Android boots, I have tried any image on the Wiki, have tried to boot them with eMMC enabled an disabled but none of them is starting. I am pretty desperate right now because this machine isn't of much use to me without linux and I do not have the capabilities to debug this device much further. I have tried basically anything that I can think of, but without further experience in mobile development and lacking equipment like a proper UART adapter, I am now pretty much out of options.
I would say that I can rule out the SD-cards, as I have probably flashed 20 different ones (yes, I do have a lot of 8GB *very* slow ones), some of them using Etcher which verified them as correct. Only android is booting reproducibly on different microSD cards.
I managed to get two snippets of useful data using the serial connection of my Raspberry Pi, I just got garbage the other times I have tried. I don't know what Image was on the SD-card at that time. When I have eMMC enabled, Serial output gives me this: https://pastebin.com/QKsgxc7y Without, I get this output: https://pastebin.com/asPs5Kgz
I really need some help here, I can't work without something that does at least a little bit more than my ancient Eeepc
(01-01-2020, 05:38 PM)tophneal Wrote: Are you seeing the same behavior without the SD inserted? I would imagine that if the Manjaro installer wanted the PBP to reboot, it was probably to resume on the new install. (Idk for sure, my Manjaro install is from before the installer, and on an SD.)
The installer did not work properly, so I just resorted to using it as a temporary linux
Hi
I've read you created a partition on eMMC with GPT
This is wrong
The SD card and/or eMMC images should be (almost ?) the same
eMMC is basically a SD card on steroids, i.e. with more pin
The stage0 bootloader in the SoC needs a special layout
http://opensource.rock-chips.com/wiki_Boot_option
As you can see at the above link
As simple
Code: xzcat $IMAGE | sudo dd of=$DEVICE bs=1M
should work
If you want to check the written image, zou have written with this method you must do some trickery
because dd reads by default the whole device and the image is compresses
Code: xzcat $IMAGE | md5sum
dd if=$DEVICE bs=1M count=$COUNT | md5sum
This should work (untested) with following assumtions
- you know/remember the block count number from the first command, this will show up at the end of copy
- the copied data from the decompression has an alignment of 1M blocksize, you will not see some 'copied 1000 blocks+500'
Use $DEVICE, $IMAGE, $COUNT as appropriate
Thank you for your answer. I only created that GPT layout temporarily, because I needed some disk space I could work on. I did not intend to use it as my boot drive and was expecting to be able to boot from a microSD card.
My situation now is:
* The only OS that boots from a microSD card is android
* It doesn't matter whether eMMC is plugged in or enabled
* Linux does not boot
So essentially, I have a bricked device. Everyone has told me that this shouldn't be possible. I know that. But somehow, it's still bricked. I have verified my Linux SD-cards, they are correctly flashed.
I do not have a UART adapter at hands, that works reliably at these speeds.
I find it just extraordinarily strange that just Android boots. At least that means that my SoC is somewhat ok
(01-03-2020, 07:03 AM)waweic Wrote: Thank you for your answer. I only created that GPT layout temporarily, because I needed some disk space I could work on. I did not intend to use it as my boot drive and was expecting to be able to boot from a microSD card.
My situation now is:
* The only OS that boots from a microSD card is android
* It doesn't matter whether eMMC is plugged in or enabled
* Linux does not boot
So essentially, I have a bricked device. Everyone has told me that this shouldn't be possible. I know that. But somehow, it's still bricked. I have verified my Linux SD-cards, they are correctly flashed.
I do not have a UART adapter at hands, that works reliably at these speeds.
I find it just extraordinarily strange that just Android boots. At least that means that my SoC is somewhat ok Don't despair. "Bricking" is a term for an unrecoverable item, without functioning firmware, at low enough a level, that repair must be done with physical replacement of components. It's unhelpful to your progress, adopting a "bricked" mindset!
I have done a lot of work with uBoot on other small devices, like routers and ShivaPlug. I understand the frustration.
You successfully verify the hardware by booting a functional Android! So SoC is more than "somewhat ok", it's fully functional!
I would ignore being distracted by SD card images at this point. You need first to return to "factory state" as your baseline.
https://forum.pine64.org/newreply.php?ti...lyto=55736
Then, if this is successful, begin experimenting with SD images. If you need "extra space", don't wipe the eMMC. This is your "safety net". A USB thumbdrive is probably the best for holding a blob of disk image, if you are short on SD space.
I hope this to be helpful and reassuring.
— Jeremiah Cornelius
"Be the first person not to do something, that no one has thought of not doing before’’
— Brian Eno, "Oblique Strategies"
Thanks for your answer, I was wrong here, the word "bricked" is wrong in this context. I have now managed to find a combination of image and SD-card with which I could reflash the eMMC correctly. Now I have a Manjaro working and can have a further look into the issue with SD-cards that fail to boot. In the IRC, one user mentioned that the daughterboard in their PBP was different than that of the first batch and introducing problems into the boot process, maybe that could be part of the problem. I will close this for now, as my problem is resolved, but I think this is something that should be looked upon a little more
|
Pinebook Pro not booting
