New Cosmo Firmware Update

[mithrandir]

[Thanks Mith! I'll give that a shot tonight. Gotta go have dinner with the in-laws first. I had it apart at work, but that battery connector looked real odd to me. More like it was soldered on. Probably a mix of bad vision + light that are far too bright in my lab. I'm assuming it pulls up, not out? As in away from the keyboard, not towards the other end of the device. Oh! And to be clear, it doesnt make it to the rotating planets. Just the initial PC splash screen.

Thanks again!
-Prof (the NQ means "Not Quite")

Yes, for he Gemini it pulls up. Assuming the Cosmo uses the same battery you should be able to pull the connector upwards. Before one has to remove (for the Gemini, did not open the Cosmo, yet) the black plastic side cover on the connector's side and unscrew a small piece of metal that holds the connector in place. Bu most probably it is the same here.

Mith

[TheProfessorNQ]

Yes, for he Gemini it pulls up. Assuming the Cosmo uses the same battery you should be able to pull the connector upwards. Before one has to remove (for the Gemini, did not open the Cosmo, yet) the black plastic side cover on the connector's side and unscrew a small piece of metal that holds the connector in place. Bu most probably it is the same here.

Mith

I ended up pulling the battery last night. Let it all sit for a couple hours. Plugged it back in, and the problem continued. Tried using SP Flash tools to re-flash boot.img. Oh, right, to be clear, I'm fortunate enough that SP Flash Tool can still catch the phone during its cycle. The screen wont try coming on anymore, but windows still gives me the connect and disconnect sounds, so I can tell the cycle is still going on, and I can still connect with Flash Tool, so I reckon I'm probably stuck waiting until a full rom is released.

-Prof

[Ninji]

I ended up pulling the battery last night. Let it all sit for a couple hours. Plugged it back in, and the problem continued. Tried using SP Flash tools to re-flash boot.img. Oh, right, to be clear, I'm fortunate enough that SP Flash Tool can still catch the phone during its cycle. The screen wont try coming on anymore, but windows still gives me the connect and disconnect sounds, so I can tell the cycle is still going on, and I can still connect with Flash Tool, so I reckon I'm probably stuck waiting until a full rom is released.

-Prof

I'm wondering, can you successfully boot the Cosmo into the bootloader (Fastboot mode) or into recovery mode? If either of those work fine then that's probably a good sign that you just need to reflash a clean full ROM.

It's slightly frustrating that Planet haven't released factory images yet - I was able to put together images for some of the partitions by dumping them from my Cosmo and then using imgpatchtools to apply the patches from the OTA package, but I would much rather just have the original files available for download.

[TheProfessorNQ]

I'm wondering, can you successfully boot the Cosmo into the bootloader (Fastboot mode) or into recovery mode? If either of those work fine then that's probably a good sign that you just need to reflash a clean full ROM.

It's slightly frustrating that Planet haven't released factory images yet - I was able to put together images for some of the partitions by dumping them from my Cosmo and then using imgpatchtools to apply the patches from the OTA package, but I would much rather just have the original files available for download.

Unfortunately, neither of those are doable. I can connect with SP Flash Tool, however. TauPan has been helping me a bit. He uploaded his preloader rip for me. Using that, the screen now comes on again during the boot loop! No loop change, though.
Main point there is that I can flash individual partitions. I wonder, if you have an image of the recovery, if flashing that would allow me to boot into recovery. But I fully agree - they need to drop stock images.

Thanks for the help!
-Prof

[TauPan]

I have just looked at the OTA ZIPfile linked here.

The ZIPfile contains binary patches for the boot partition. Patching a binary that has already been modified results in garbage, most likely. This is why booting fails for people who tried to update their rooted Cosmo.

I don't know if the binary patching employed in google's `update-binary` command does any kind of safety checks, but apparently not, otherwise the update would just fail, I guess.

Flashing back the original boot image should work, but then you don't have an updated boot image, so the following leads to a working Cosmo:

Got the update installed on the rooted Cosmo..

1.  Flash the original boot image using SP flash tool (Gemini version is outdated and does not work for Cosmo)
2.  Perform the OTA update
3.  Flash the magisked boot image again

Images come from here: https://www.oesf.org/forum/index.php?showtopic=35879 (Thanks ZimbiX)

Mith

but the boot image will be outdated (but rooted).

Instead I suggest the following procedure (Step 1. and 2. unmodified):

3. Read back the updated, but unrooted boot image via SP
4. Patch it with magisk
5. SP flash the modified image to the Cosmo
6. Maybe upload it here for additional karma points.

[mithrandir]

I have just looked at the OTA ZIPfile linked here.

The ZIPfile contains binary patches for the boot partition. Patching a binary that has already been modified results in garbage, most likely. This is why booting fails for people who tried to update their rooted Cosmo.

I don't know if the binary patching employed in google's `update-binary` command does any kind of safety checks, but apparently not, otherwise the update would just fail, I guess.

Flashing back the original boot image should work, but then you don't have an updated boot image, so the following leads to a working Cosmo:

Got the update installed on the rooted Cosmo..

1.  Flash the original boot image using SP flash tool (Gemini version is outdated and does not work for Cosmo)
2.  Perform the OTA update
3.  Flash the magisked boot image again

Images come from here: https://www.oesf.org/forum/index.php?showtopic=35879 (Thanks ZimbiX)



Mith

but the boot image will be outdated (but rooted).

Instead I suggest the following procedure (Step 1. and 2. unmodified):

3. Read back the updated, but unrooted boot image via SP
4. Patch it with magisk
5. SP flash the modified image to the Cosmo
6. Maybe upload it here for additional karma points.

Right, the boot image would be outdated, but I on't think there have been changes to it. From the changelog all seems UI related. If there were a new kernel build, ok, but I don't think so.

[spook]

I went ahead and applied the update. The process was quite fast and uneventful. I did not notice any changes after starting post update either. So far so good

BTW, here's a shot of the launcher I use for anyone interested its called WinX Launcher. Gives the Cosmo a more of a laptop feel and navigates just like Windows.

Cheers

Do you have a Play Store link for that app? For some reason a search isn't bringing it up...

[TauPan]

I have just looked at the OTA ZIPfile linked here.

The ZIPfile contains binary patches for the boot partition. Patching a binary that has already been modified results in garbage, most likely. This is why booting fails for people who tried to update their rooted Cosmo.

Right, the boot image would be outdated, but I on't think there have been changes to it. From the changelog all seems UI related. If there were a new kernel build, ok, but I don't think so.

Excuse the repetition: I looked inside the zipfile, which you can do too and there is a binary patch to the boot image, which is the reason why people have been soft bricking their cosmos.

If there were no changes to the boot image, there would be no reason for it to be patched. So there are definitely changes to the boot image in the OTA, we just don't know which.

It could be changes that were too small to be mentioned in the changeloog, such as small bugfixes, or compatibility fixes, or even changes required by the following updates.

Also, if the next OTA update also patches the boot image, you won't be able to fix it by flashing your outdated boot image before, as the next patch will require the updated boot image to work!

[mithrandir]

I have just looked at the OTA ZIPfile linked here.

The ZIPfile contains binary patches for the boot partition. Patching a binary that has already been modified results in garbage, most likely. This is why booting fails for people who tried to update their rooted Cosmo.

Right, the boot image would be outdated, but I on't think there have been changes to it. From the changelog all seems UI related. If there were a new kernel build, ok, but I don't think so.

Excuse the repetition: I looked inside the zipfile, which you can do too and there is a binary patch to the boot image, which is the reason why people have been soft bricking their cosmos.

If there were no changes to the boot image, there would be no reason for it to be patched. So there are definitely changes to the boot image in the OTA, we just don't know which.

It could be changes that were too small to be mentioned in the changeloog, such as small bugfixes, or compatibility fixes, or even changes required by the following updates.

Also, if the next OTA update also patches the boot image, you won't be able to fix it by flashing your outdated boot image before, as the next patch will require the updated boot image to work!

Right, so we have to keep in mind there might be changes causing problems. Didn't expect changes to the boot image. Obviously it would be better to "magisk" the patched boot image an keep a backup of the non-magisked version for later updates. Well, I didn't backup this image before flashing the old magisked version again... Since for the time being it seems to work somehow I'll just wait for the flashable images from PC.

The next OTA will fail anyways in that case, no matter if we have the first or the second boot image patched with magisk. The only way to use OTA then would be to have the image patched by the first OTA (which I did not backup).

So the advice should be to at least keep a backup of the original OTA-patched version for later updates or to use the PC supplied images once available. We most probably will be getting a pre-rooted image, so this is the way to go, since we will then be able to lock the bootloader again and get rid of the 5 sec. boot delay.

[TauPan]

Right, so we have to keep in mind there might be changes causing problems. Didn't expect changes to the boot image. Obviously it would be better to "magisk" the patched boot image an keep a backup of the non-magisked version for later updates. Well, I didn't backup this image before flashing the old magisked version again... Since for the time being it seems to work somehow I'll just wait for the flashable images from PC.

The next OTA will fail anyways in that case, no matter if we have the first or the second boot image patched with magisk. The only way to use OTA then would be to have the image patched by the first OTA (which I did not backup).

So the advice should be to at least keep a backup of the original OTA-patched version for later updates or to use the PC supplied images once available. We most probably will be getting a pre-rooted image, so this is the way to go, since we will then be able to lock the bootloader again and get rid of the 5 sec. boot delay.

Completely agree!

There's a backup of the original boot image here: https://www.oesf.org/forum/index.php?s=&...st&p=292918

I also have one from my device, which I could share but I think that's not necessary.

Also I've learned that it's quite convenient to keep a backup of your seccfg partition before *and* after unlocking the bootloader, as you can just unlock and re-lock your bootloader by flashing either version. I haven't tested the unlocking version personally yet, but locking the bootloader by flashing a locked seccfg definitely works (and I do have a backup of the unlocked seccfg now, so I could test it).

[mithrandir]

Completely agree!

There's a backup of the original boot image here: https://www.oesf.org/forum/index.php?s=&...st&p=292918

I also have one from my device, which I could share but I think that's not necessary.

Also I've learned that it's quite convenient to keep a backup of your seccfg partition before *and* after unlocking the bootloader, as you can just unlock and re-lock your bootloader by flashing either version. I haven't tested the unlocking version personally yet, but locking the bootloader by flashing a locked seccfg definitely works (and I do have a backup of the unlocked seccfg now, so I could test it).

This is the original boot image backup (before 1st OTA). Unless I have a wrong understanding of the update process (mostly guessing) , for further updates we will need the one after the 1st  update.

[mithrandir]

This is the original boot image backup (before 1st OTA). Unless I have a wrong understanding of the update process (mostly guessing) , for further updates we will need the one after the 1st  update.

ZimbiX has published his boot images after the first OTA:
https://www.oesf.org/forum/index.php?s=&...st&p=293538

Thanks!