Can I copy them from PureOS?
…and dozens of different ICs connected with each other in a unique configuration, very much unlike the set of ICs used by the board the image you flashed was meant for.
What, if anything, did you do for uboot
? What does Android even expect?
Probably the safest thing by far would be to attempt to reflash PureOS and chalk it up to experience either way.
The NXP Android image included uboot in there
Okay, so, the saga continues. I tried using the Librem 5 flashing script to flash PureOS, but after going through the loading process where the light turns yellow and the laptop lists it as copying over, and then says “Successes 1 Failures 0”, after I removed the cable from the Librem 5 and tried booting it, it didn’t boot or do anything.
I noticed that unlike last night when trying to flash the goober ROM and unlike the PureOS tutorial, when I attach the Librem 5 to the computer while holding Volume Up, now it is flashing green as if trying to boot something and failing, instead of not doing that, prior to uuu stuff beginning. Is that a sign of something we can fix? It’s interesting that that’s the only time I’ve seen it flash green since mucking about with this.
From LED Indicator Colors - Purism - Librem products documentation “Green (flashing)” means “A boot-loop in the bootloader.” with further advice on that page. I would at least try a long reset.
Can you boot Jumpdrive and examine the state of the eMMC drive? (both from outside and from inside)
I searched the same official docs you linked for “jumpdrive” and nothing came up. Do you have a link to jumpdrive and what it is and where to get it? My Librem 14 running byzantium says:
$ sudo apt install jumpdrive
[sudo] password for <me>:
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package jumpdrive
$ sudo apt search jumpdrive
Sorting... Done
Full Text Search... Done
I really appreciate your help. I was partially skeptical of running something from a github instead of PureOS repo on my Librem 14, but the contents of their shell script was 1 line, to run uuu thing
for their bootable thing.
Then, this thing put words and graphics on the Librem 5 screen, even though previously indications were that I had possibly destroyed the Librem 5. So, now it seems that I did not destroy it, at least not totally.
Jumpdrive seems to have mounted and is showing two partitions. One is big with 4 GB and has a /home/purism
folder, and the other is 488 MB and has some files in it with librem5
in their name. So, it seems that at least partially, the eMMC was indeed overwritten with PureOS.
But where do I go from there? So, the device itself won’t boot anything but jumpdrive, but we know that uuu
did actually overwrite what is on the eMMC at least in some form and to some extent?
(NOTE: The wacky image I tried to flash yesterday had 13+ partitions and is nothing like any of this, so it definitely seems gone.)
When you put your phone in Serial Download mode, your host computer effectively controls what happens on the phone, using uuu
.
When you reflash, that is fairly straightforward, the host computer sends the disk image over to the phone and the phone writes the disk image to the eMMC drive.
When you use Jumpdrive, the host computer sends a whole (maybe slightly abridged) kernel over to the phone, for storage in memory, not on the disk, and the phone boots that kernel, and the phone then exposes its eMMC drive (and µSD drive if there’s a card inserted) to the host computer via USB, and you can telnet into the phone, again via USB.
Okay but if the eMMC drive already has PureOS Byzantium for Librem 5, where should I look to understand why the Jumpdrive “maybe slightly abridged” kernel can boot on the Librem 5 but the PureOS Byzantium for all that I can tell does not?
As you should be.
You can download a pre-built Jumpdrive image from Purism if you prefer but I would have to hunt up the URL.
To clarify … at this stage … it will boot over USB but not boot from the eMMC drive.
There are some promising signs that the phone is not completely borked.
Here’s approximately what your /boot
partition should contain: L5 USA blocked due to an update! - #14 by irvinewade
I would say next step would be to telnet in to the phone.
Ah yeah sorry I didn’t say. Along with jumpdrive the telnet
was already working, and can ls
inside of the telnet console and see files in the jumpdrive mount. I didn’t mount anything there via any manual jumpdive mount command (inside of the L5 itself?) so I was only looking at the eMMC contents from the Librem 14 USB mount, wherein I entered the 123456 luks password based on the assumption that the reason it asked for a password would have been successful eMMC overwrite with PureOS Byzantium for Librem 5 image tonight.
But when I look in the mounted stuff, for example /var/log
(inside the mounted LUKS encrypted part) at where I loosely recall system logs might be, everything is last modified in 2023. Definitely seems like it never booted the main eMMC partition.
Unlike the example that you have linked, the boot partition on the eMMC appears to have kernel version 6.2.0-1-librem5 because I got the “stable” image when I ran the flash script.
Aside from that, the example that you linked has a grub
folder, but I do not find that same folder on my current boot partition. Would it be worth me imagining this phone with the 6.5 or 6.6 or whatever kernel is current, by way of trying to image onto it the exact contents of what was on it before I messed around with it last night?
Yesterday before mucking about with it, I booted into an SD card and then used dd
to try to image the entire eMMC onto an external drive. However, if it cannot boot stable Byzantium default image, I do not know why it would successfully be able to boot something I created with dd
last night. Plus I would imagine I probably couldn’t boot that SD card anymore.
As an aside, it should be either/or. You either mount the disks on the host computer or you telnet in and mount them on the phone itself. You must not mount on both. And if you intend to telnet in and mount them on the phone itself but they are already mounted on the host computer then you should unmount them on the host computer before telnetting in.
I more imagined that you would telnet in because there are things that you can check from within the phone that you won’t be able to check from the host computer. The host computer can only really check the contents of the disks.
I think you are probably right - although PureOS on the Librem 5 does not use syslog
by default so looking for that specifically might not be the best thing to look for. However I would have to look up the exact pathname used by journald
as I don’t seem to have it to hand.
I’m still pondering on what you should check next. Possibly solving this will depend on how much interest @dos has in this challenge.
Maybe uboot
didn’t get rewritten correctly but I don’t know how to check that.
Once you have finished with Jumpdrive,
- with the whole thing powered down completely, does the battery charge normally? i.e. red LED on until battery is ‘full’ (do you know what the battery state was before you started this exercise? what it should be now?)
- did you try the long reset?
- you should try to boot from µSD card if you have a known good previously bootable card
I would guess that whatever comes with “stable” is perfectly adequate, if somewhat out of date. So I would stick with what you have.
Great questions. The battery that I was trying to use appears to have been drained/empty, or near-empty, based on the rough status light on my external chargers. I had been thinking it was full or mostly full earlier, so maybe the escapades with the weird image drained it.
Whether with the battery I had been using, or a new different battery that is at or near 100%, there is not a buzz/green light boot behavior in this Librem 5 anymore. However the red light seems to work as expected. So, when I plug it into a charger without a battery, the red light blinks, and when I plug it into a charger with a battery, the red remains solid red indicating charging.
But the light is never green. So, normally when I put a battery into a Librem 5, it boots before I can tell it to boot, from the moment it has power. But presently this device is not doing that. It also does not seem to respond to the power button to make it boot. Also, when plugged into power without a battery, the power button does not seem to make it boot.
But that is also why I am somewhat surprised that Jumpdrive lights up the screen and lets me connect over telnet. Other signs would indicate that the device was just dead, but that suggests that the screen hardware and the CPUs are still functional.
Edit:
Because the device will never show the green light (except when connecting to uuu
), and does not boot, I was not able to boot the previously-known-good SD card.
Edit 2:
What counts as a ‘long reset’ ?
Remove the USB C cable and hold down the power button for 15-18 seconds to reset the phone.
You probably did that as part of reflashing but it doesn’t hurt to try it again.
… and the memory (of course)
… and the USB port.
Yes, I tried this with each reflash. I used date
command on the Librem 14 to watch for the passage of truly 15-18 seconds.
I tried re-running the default Librem 5 flash script again, this time with the full battery instead of the empty one. Wondered if flashing on a battery that I thought was mostly full, but that wasn’t, might have been the issue.
This did not seem to fix anything.
But, again, I am “flashing” in a way that does not match the tutorial. It bootloops the green light even when holding volume up. Then if I ignore that and insert the battery, it acts as if the flashing process has begun and the light goes to yellow and it shows the progress bar for uuu
doing the flashing. But is that actually working as expected?
This sounds like u-boot uploaded via uuu attempting to start but failing because of not enough power being provided over USB. I initially understood that green blinking light showed up when attempting to boot from reflashed eMMC, but it seems you were already uploading the bootloader from your host computer.
Technically there’s no “yellow light”, it’s just the charging indicator (red LED) shining up together with boot indicator (green LED). Charging gets enabled late in the process.
There’s Librem 5-specific code in u-boot that makes it light the green LED up and do a short vibra pulse as soon as it launches, it’s not a hardware-defined behavior (unlike the red LED).