Messages

1

Cosmo Communicator - Hardware / Re: Partitioning the Cosmo for multi-boot without losing your Android data

« on: July 31, 2020, 11:57:19 pm »

I have defined mine as follows, to keep userdata (44) starting at the same original position:
- 38: 126779328 - 126844863 (65536 sectors)
- 41: 126844864 - 126910399 (65536 sectors)
- 42: 126910400 - 126975935 (65536 sectors)
- 43: 126976000 - 244163436 (117187437 sectors / 55.87GB)
- 44: 10158080 - 126779327 (116621248 sectors / 55.6GB)

Sounds pretty boring actually.  I'm pondering something rather more adventurous:

Code: [Select]

- 44: 1228800 - 34783232
- 36: 235028480 - 241319936
- 42: 241319936 - 241385472
- 41: 241385472 - 241451008
- 38: 241451008 - 241516544
- 35: 241516544 - 243269632
- 37: 243269632 - 244154368

Theory being with a future LineageOS or other OS, system might be shrinkable (or need to expand).  As such userdata being the important one, place it first.

Now, in order to make the smaller userdata partition decrypt correctly, you'll need to modify the size inside the metadata partition. Run this on the Cosmo:

Code: [Select]

dd bs=512 count=32 if=/dev/block/by-name/metadata of=/tmp/meta.binUse adb pull /tmp/meta.bin to pull the metadata partition out and open it in a hex editor. The file will begin as follows...

Code: [Select]

C4 B1 B5 D0 01 00 03 00 30 09 00 00 00 00 00 00
10 00 00 00 01 00 00 00 C0 A7 F2 0D 00 00 00 00
                        ^^ ^^ ^^ ^^ ^^ ^^ ^^ ^^The eight bytes highlighted above, C0 A7 F2 0D 00 00 00 00, are what you need to change - these must match the little-endian encoding of the userdata size. For my size of 116621248, these are: C0 7F F3 06 00 00 00 00. Replace these and save the file. Then, use adb push meta.bin /tmp/ to send it back to the Cosmo, and run this on it:

Code: [Select]

dd if=/tmp/meta.bin of=/dev/block/by-name/metadataYou can now exit the shell and reboot your Cosmo. You should receive the bootloader menu and all your Android data should be there.

Noted.  This is a very important tidbit.

2

Cosmo Communicator - Hardware / Re: Compiling Cosmo Android kernel

« on: July 31, 2020, 10:42:07 pm »

I've done some experimentation with this myself now.  I've determined what appears to be the official source (https://github.com/dguidipc/cosmo-android-kernel) is missing a number of files.  I believe those extra files were left out unintentionally, but that is clearly incomplete.

3

Cosmo Communicator - Hardware / Re: Keyboard Backlighting Set to On-Demand?

« on: July 31, 2020, 10:08:03 pm »

Why not have an option to have the keyboard backlighting automagically
turn on/off on the basis of ambient light?

Yes, this is a badly needed feature, though would need an interesting curve.  At daylight light levels you want the keyboard backlight off.  At dim room light levels you want the keyboard backlight full on.  In a full dark room, you want the keyboard backlight dim.

4

Cosmo Communicator - Hardware / Re: Unofficial TWRP build

« on: July 31, 2020, 09:59:19 pm »

Thank you so much! Yeah, I've tried the lk as well. All img files from he OTA zip, actually. It certainly seems that /data is being decrypted successfully. I haven't tried pulling any of the files with ADB, but I would think if file and folder names are looking right, that the decryption is working.

As near as I can tell, it appears this would require the use of FDE (Full Device Encryption) and not FBE (File-Based Encryption).  Yet so far I've only managed to get FBE and not managed to cause it to do FDE.  One of the dialogs during setup almost sounds like choosing between FBE/FDE, but I chose the one I would expect to generate FDE yet still ended up with FBE.



Then after some persistence I think I've figured out the answer to my own question.  I suspect @Ninji's TWRP build was based on TWRP's minimal OmniROM manifest:
https://github.com/minimal-manifest-twrp/pl...ifest_twrp_omni
Branch twrp-9.0.  Took a bit of adjustment to get my first build operational, but I have a successful build.  Now dealing with the above issue and working on building the kernel from source.

5

Cosmo Communicator - General Discussion / What should I do first?

« on: July 04, 2020, 10:18:41 pm »

- Freaked out some more as the box says 'Verizon version' yet I didn't select that option when placing my contribution - turns out it's irrelevant and works nicely on Voda NZ with 4G speed downloads of 20 Mbs+ where I am

I seem to recall thinking New Zealand would be either Japanese or Verizon frequencies.  We're finally to the point of most devices being able to get LTE world-wide (though NZ and JPN are interesting), which means it is time for carriers to start adding new frequencies.

First on my list, go into developer options and set "allow bootloader unlocking".  Then `adb reboot bootloader` then `fastboot flashing unlock`.  Also reboot into recovery and allocate space for Linux.  I'm planning to modify the setup further, but these are the two steps which wipe data.

6

Cosmo Communicator - Hardware / Microphone low gain / muddled voice on GSM phone calls:

« on: June 30, 2020, 11:10:18 pm »

- Both my Cosmo TWRP, ADB (recovery mode, su, whatever), and rooted Android just lie,lie,lie,lie,lie to me about mounting /dev/block/mmcblk0p35 to /vendor in read/write mode.  I even tried it from the linux side (with Pluma edits) just for kicks.  All changes get wiped on reboot (not remount).  Running e2fsck after edits gives a "modified" warning and manually reverts.  Probably has been going on in the background on all my reboots.

The situation with /vendor is rather more interesting than you were thinking.  Ever tried running the `mount` command or examining the contents of /proc/mounts?

Android isn't mounting /dev/block/mmcblk0p35 on /vendor.  Instead Android is mounting /dev/block/dm-0 on /vendor.  /sys/devices/virtual/block/dm-0 can tell you some about dm-0.  The virtual file which stands out is "fec/corrected" and on mine contains "0".  I'm pretty sure "fec" is shorthand for "Forward Error Correction".  Mainly Android has error-correction implemented on mmcblk0p35 to try to stop you from modifying /vendor.

A few approaches to this situation stand out.  First, you can figure out how to disable this.  This process may start by modifying the initial ramdisk or by modifying /system.  You'll need to find out where device-manager gets configured ("dm" is shorthand for "device-manager").  Alternatively inside Magisk, under "Advanced Settings" notice the option "Preserve AVB 2.0/dm-verity"?  I'm reasonably sure this is related, though note turning that off carries some risk.

Second, you can work within the system to figure out how to make dm-0 writeable.  Ever noticed the "androidboot.veritymode=enforcing" and "veritykeyid=id:<hex string>" values in /proc/cmdline?  I'm pretty sure that is part of this situation, but I haven't won the battle with the details.  Might be as simple as turning off the setting I mentioned in the last paragraph, modifying and then turning it back on.


Welcome to Android security.  They're trying to defend devices from malicious programs, but some of it is more aimed at thwarting owner modifications.

7

Cosmo Communicator - Android / V22 is out.

« on: June 30, 2020, 10:29:26 pm »

I might push my luck and ask if they can configure it with whatever the state of play is on the linux side if I ship it with a 256GB MicroSD card.

Or ask if I can pay for a suitably sized one to be implemented from their end since I think the SD card they shipped to Beta testers is still v19?

What is the largest SD card anyone is prepared to trust/recommend in the Cosmo?

Interesting issue that...  There is an issue V19 and V22 include vfat and ext4 support, but not exfat or udf.  As such the choice of filesystem on SD card is tricky.  Though I do note SD cards tend to have very large erase block sizes which isn't really suitable for anything besides pictures or video.  You would need to erase any SD card larger than 64GB (SD card association specifies exfat as the default, despite UDF being far superior).

I imagine kernels with exfat and/or udf will be showing up soon, but in the meantime larger than 64GB is a bit troublesome.  Though SD card performance is often questionable.

8

Cosmo Communicator - Linux / change boot priority debian and android and twrp

« on: June 27, 2020, 11:27:30 pm »

Is there a possibility in cosmo boot menu to change the boot priority, for example linux first , second android and 3rd twrp ?

This is more a general question than a Linux-specific one.  I'm basically certain this is possible, but somewhat troublesome.

There are a few potential mechanisms by which the bootloader finds boot areas.  It may be scanning through the GPT and looking at known entry numbers.  It may be scanning through the GPT and looking at type-UUIDs.  It may look at the headers of all areas and look for Android boot images.

The general strategy is to modify the GPT and reorder the entries.

This is hazardous, since depending upon the update mechanism you could cause updates to have weird behavior.  Notably depending upon whether the updater expects to update /dev/block/mmcblk0p30 versus /dev/block/by-name/boot, it could update the wrong area and suddenly booting for you becomes troublesome.

9

Cosmo Communicator - Android / TWRP on Cosmo w/ V22

« on: June 27, 2020, 10:56:57 pm »

I've had the exact same experience.  I tried Planet's TWRP image and got nowhere.  Selected TWRP boot option, then got dark screen and momentary vibration, wait for a bit and it is clear it went crunch.  I hope to rebuild TWRP myself as @Ninji's build doesn't meet my standards, then I can get onto further phases...

I didn't say Magisk is broken, I said *updating* Magisk is broken. So rooted boot works fine, but you cannot update Magisk. Although I have to admit that I haven't tried it with V22 yet, maybe Planet fixed the issue. Will give it another try in the next couple of days.

I'd been wondering about this.  I'd seen no complaints and was wondering if I was the only person who had run into this.

One big tidbit though:  Did you observe the messages during the attempt at upgrading Magisk?
Crucial one I noticed was "Installing in EMPTY_NORMAL_BOOT_4".

I'm pretty sure the problem is simply Magisk update is attempting to install to the wrong area.  Likely it is searching the MMC block devices in reverse order and so finds EMPTY_NORMAL_BOOT_4 before it finds ROOTED_ANDROID.  It might even be possible to boot using the extra entry...

Originally I was going to go and suggest copying boot to EMPTY_NORMAL_BOOT_4, installing and then copying back.  Unfortunately I kept reading the directions too many times and found what I had been looking for under "Boot Image Patching".  At which point I had the crucial bit of information I had been looking for.


Start a root shell and then run the command: `dd bs=2048 if=/dev/block/by-name/boot of=/storage/emulated/0/Download/magisk.img`
Go into Magisk Manager, select the "Update" option to the right of "Magisk".  Choose "Select Method", then "Select and Patch a File".  At this point you'll be in the file manager recent items list, go to "Downloads" and select "magisk.img".
Go back to the root shell (or start a new one) and run the command: `dd bs=2048 if=/storage/emulated/0/Download/magisk_patched.img of=/dev/block/by-name/boot`


You can change filenames/directories if you want, but that is the process.

10

Cosmo Communicator - CoDi / How to cancel codi checking update notification ?

« on: June 27, 2020, 09:57:55 pm »

I was wondering about this too.  Was on V19 CODI on 1.1.1.13, yet it kept trying to get the latest.  I'm pretty sure there is a bug somewhere, but luckily this hasn't caused too much trouble for me.

Now on V22, CODI on 1.1.1.14 and it hasn't cropped up again.  I've got an unfortunate suspicion it does this until you do your first CODI update.

11

Cosmo Communicator - Android / Manual Firmware Installation Files from Planet

« on: June 27, 2020, 09:31:30 pm »

Customer Support 1 (Planet Computers) Jun 26, 2020, 4:39 PM GMT+1 Dear Daniel, I'm actually not sure what happened here exactly, but I would like to rule out a possible hardware failure by asking you to perform a manual installation of the v22 firmware. You can install the latest v22 firmware by using this manual installation (http://support.planetcom.co.uk/index.php/Cosmo_Android_Firmware_Manual_Installation).

This is valuable information, but got corrupted in the process of you posting it.  I suspect you want this link: https://support.planetcom.co.uk/index.php/C...al_Installation

12

Cosmo Communicator - Hardware / screwed up

« on: June 27, 2020, 07:16:31 pm »

I've found it quite difficult to find things on Planet's support site.  There is some very valuable information there, but finding it is difficult.

V19 firmware
V22 firmware

The zip file can be unpacked and it includes full images of boot and system.


EDIT:  Grrf!  Finding these things can be tricky.  Let me give credit to @bolderz who provide a link on this thread, which once you've corrected the link you get this page which has the crucial links and instructions.

13

Cosmo Communicator - Hardware / Compiling Cosmo Android kernel

« on: June 27, 2020, 06:54:42 pm »

Thanks. I'd seen that repo, but assumed it to be Linux-specific and hadn't realised it had an android branch. That looks to have been updated more recently than the dguidipc repo: 2020-04-26 vs 2020-02-13
https://github.com/gemian/cosmo-linux-kerne...commits/android

This reminds me, the kernel source could be distinct due to differences in userspace.  The question of, "Is Android a Linux distribution?"  At times the answer seems "yes" and at times the answer seems "no".

Having reminded me of the situation, most likely you would want to use dguidipc/cosmo-android-kernel.  The reason being this should be what is in use on the Cosmo.  Issue is are there any differences between the kernel used in Cosmo release V1 and release V22?  It isn't certain, but there are often small tweaks between releases.  Yet with no tags nor branches that repository doesn't really satisfy the GPL.  I think I need to send e-mail to Planet about wanting more...

I haven't compiled a normal Linux kernel before. Maybe I should start there =P

The Linux kernel has some pretty good documentation.  The file "README" in the top directory is a good starting point.  There are a bunch of extra packages your build system may need before rebuilding a kernel for itself or a Cosmo.



EDIT: Partially note to self.  Grabbed /proc/config.gz.  The Cosmo configuration matches "k71v1_64_bsp_defconfig" the Cosmo may have an almost completely generic MediaTek kernel.

14

Cosmo Communicator - Hardware / Unofficial TWRP build

« on: June 27, 2020, 01:44:57 am »

Source code on GitHub: https://github.com/Treeki/unofficial-twrp-cosmo

They released a built blob which appears to be a build of TWRP, but didn't work for me.  Since I desire to do my own builds of TWRP, I'm trying to get this to build.  TWRP used to depend on the source trees of OmniROM, but apparently they're now supposed to work if used to replace LineageOS's recovery.  There are also minimized versions of OmniROM and LineageOS codebases which are supposed to work for builds.

Which repositories/branch did you use?

Minimal repo repositories are:
https://github.com/minimal-manifest-twrp/pl...ifest_twrp_omni
https://github.com/minimal-manifest-twrp/pl..._twrp_lineageos
(which and which branch?)


Personally I tend to include `fdisk` and `sfdisk` in builds.  `sgdisk` works okay for scripting, but `sfdisk` is much more powerful in a scripting environment.  Whereas `fdisk` is far more usable in interactive use.

15

Cosmo Communicator - Hardware / Partitioning the Cosmo for multi-boot without losing your Android data

« on: June 27, 2020, 12:48:51 am »

If you could find a static version of `sfdisk` that would likely work much better.  Give us a copy of `sfdisk -d /dev/block/mmcblk0` and then `sfdisk /dev/block/mmcblk0 < gpt_copy` installs it.  One thing I'm curious about is whether the UUIDs are the same from device to device.  They would start out identical, but they could be randomized before leaving the factory.

Planet's Android installation includes the `sgdisk` program which can be used for this.  The TWRP build I saw also had `sgdisk`.  Meanwhile I've found `sfdisk` much more powerful for scripted operations, while `fdisk` is better for interactive GPT work.