search

AsteroidOS / asteroid

Build script for AsteroidOS, an open-source operating system for smartwatches
http://asteroidos.org
GNU General Public License v2.0
884 stars 64 forks source link

Huawei watch 2 support #101

Closed andreagubellini closed 2 years ago

andreagubellini commented 5 years ago

Hi everyone, I was thinking about this for quite some time. Is there any chance we could get Asteroid on huawei watch 2? I would be glad to help on the porting.

jrtberlin commented 5 years ago

Hi, we have the Huawei watch 2 on the list of possible ports. I don't think that we have made any progress on the watch. I would start by checking the porting guide (https://asteroidos.org/wiki/porting-guide/). If you have questions make sure to check our IRC.

Additional note: this is the repository of the sync client for Android.

nabeelmoeen commented 4 years ago

just saw support being added for the Huawei watch GT 2... hoping the huawei Watch 2 classic would be there soon as well

ajayjohn commented 4 years ago

Same here. +1 for the Huawei Watch 2 (LEO-DLXX)

jrtberlin commented 4 years ago

To get started on the Huawei Watch 2 we need the partition table of the device. If somebody has one we could use your help.

Steps to do:

  1. Boot TWRP with fastboot boot
  2. use adb to get the output of: ls -al /dev/block/platform/soc/7824900.sdhci/by-name
dave18 commented 4 years ago

Hi, I'm new to all this, but is this the right output?

~ # ls -al /dev/block/platform/soc/7824900.sdhci/by-name __bionic_open_tzdata: couldn't find any tzdata when looking for GMT! drwxr-xr-x 2 root root 740 Jan 1 04:29 . drwxr-xr-x 4 root root 820 Jan 1 04:29 .. lrwxrwxrwx 1 root root 21 Jan 1 04:29 DDR -> /dev/block/mmcblk0p21 lrwxrwxrwx 1 root root 20 Jan 1 04:29 aboot -> /dev/block/mmcblk0p7 lrwxrwxrwx 1 root root 20 Jan 1 04:29 abootbak -> /dev/block/mmcblk0p8 lrwxrwxrwx 1 root root 21 Jan 1 04:29 boot -> /dev/block/mmcblk0p29 lrwxrwxrwx 1 root root 21 Jan 1 04:29 cache -> /dev/block/mmcblk0p34 lrwxrwxrwx 1 root root 21 Jan 1 04:29 cmnlib -> /dev/block/mmcblk0p24 lrwxrwxrwx 1 root root 21 Jan 1 04:29 cmnlibbak -> /dev/block/mmcblk0p25 lrwxrwxrwx 1 root root 21 Jan 1 04:29 config -> /dev/block/mmcblk0p18 lrwxrwxrwx 1 root root 21 Jan 1 04:29 devinfo -> /dev/block/mmcblk0p23 lrwxrwxrwx 1 root root 21 Jan 1 04:29 fsc -> /dev/block/mmcblk0p13 lrwxrwxrwx 1 root root 21 Jan 1 04:29 fsg -> /dev/block/mmcblk0p22 lrwxrwxrwx 1 root root 21 Jan 1 04:29 keymaster -> /dev/block/mmcblk0p26 lrwxrwxrwx 1 root root 21 Jan 1 04:29 keymasterbak -> /dev/block/mmcblk0p27 lrwxrwxrwx 1 root root 21 Jan 1 04:29 keystore -> /dev/block/mmcblk0p17 lrwxrwxrwx 1 root root 21 Jan 1 04:29 misc -> /dev/block/mmcblk0p15 lrwxrwxrwx 1 root root 21 Jan 1 04:29 modem -> /dev/block/mmcblk0p32 lrwxrwxrwx 1 root root 21 Jan 1 04:29 modemst1 -> /dev/block/mmcblk0p11 lrwxrwxrwx 1 root root 21 Jan 1 04:29 modemst2 -> /dev/block/mmcblk0p12 lrwxrwxrwx 1 root root 21 Jan 1 04:29 nfc -> /dev/block/mmcblk0p19 lrwxrwxrwx 1 root root 21 Jan 1 04:29 nvbin -> /dev/block/mmcblk0p10 lrwxrwxrwx 1 root root 20 Jan 1 04:29 nvdata -> /dev/block/mmcblk0p9 lrwxrwxrwx 1 root root 21 Jan 1 04:29 oem -> /dev/block/mmcblk0p28 lrwxrwxrwx 1 root root 21 Jan 1 04:29 recovery -> /dev/block/mmcblk0p31 lrwxrwxrwx 1 root root 21 Jan 1 04:29 reserved -> /dev/block/mmcblk0p20 lrwxrwxrwx 1 root root 20 Jan 1 04:29 rpm -> /dev/block/mmcblk0p3 lrwxrwxrwx 1 root root 20 Jan 1 04:29 rpmbak -> /dev/block/mmcblk0p4 lrwxrwxrwx 1 root root 20 Jan 1 04:29 sbl1 -> /dev/block/mmcblk0p1 lrwxrwxrwx 1 root root 20 Jan 1 04:29 sbl1bak -> /dev/block/mmcblk0p2 lrwxrwxrwx 1 root root 21 Jan 1 04:29 sec -> /dev/block/mmcblk0p30 lrwxrwxrwx 1 root root 21 Jan 1 04:29 splash -> /dev/block/mmcblk0p16 lrwxrwxrwx 1 root root 21 Jan 1 04:29 ssd -> /dev/block/mmcblk0p14 lrwxrwxrwx 1 root root 21 Jan 1 04:29 system -> /dev/block/mmcblk0p33 lrwxrwxrwx 1 root root 20 Jan 1 04:29 tz -> /dev/block/mmcblk0p5 lrwxrwxrwx 1 root root 20 Jan 1 04:29 tzbak -> /dev/block/mmcblk0p6 lrwxrwxrwx 1 root root 21 Jan 1 04:29 userdata -> /dev/block/mmcblk0p35

jrtberlin commented 4 years ago

Thanks @dave18, this is what we are looking for!

dave18 commented 4 years ago

Glad I could help. happy to test any builds on my Watch 2 if needed.

MagneFire commented 4 years ago

@jrtberlin and I are working on a port for the Huawei Watch 2(sawshark/sawfish). We don't own this watch so this is a unique opportunity for the community to help :wink:

We both own the regular Huawei Watch (sturgeon) of which I did the port.

At first glance the two seem very similar. The (probably) biggest challenge is to port the Android base from Marshmallow to Nougat. It turns out that some people are/were already working on this (https://github.com/iuncuim/android_manifest/commits/ng and https://github.com/asteroid-platy/android_manifest)

The current road map we will use to get a working port will be as follows:

A repository for the Huawei Watch 2 has already bee setup: https://github.com/MagneFire/meta-sawshark-hybris

Of course, when we have something to test we will publish that here. Though, keep in mind that porting the Android base is a time consuming task, meaning that it'll probably take sometime before we have anything to test for you.

flocke commented 4 years ago

@jrtberlin @MagneFire Thank you for working on this. I own a Huawei Watch 2 (sawfish) and am pretty well versed in both the Linux and Android ecosystems as well as development for both (I'm the author of andOTP). So if you need any specific information or testing feel free to contact me.

MagneFire commented 4 years ago

Sorry for not getting back at this sooner. But I have successfully ported the Android base to 7.1.1 on sturgeon (the Huawei Watch Classic).

And I have just built a version for the Huawei Watch 2. This one has the system base from a sawfish build. Which is apparently the Bluetooth variant. So in any case I am not sure if it will work for sawshark LTE variant.

Download: https://www.dropbox.com/sh/h0kzcky4qls3v60/AAC7nBfhSoPpStSQ6Gx4h769a?dl=0

First of all, I don't expect it to boot fully. So depending on how far it gets in the boot process there are different things to debug.

To flash

Just follow the general instructions on the install page (pick for example sturgeon). I recommend using the temporary installation as this makes things easier to debug.

It reboots

The first thing to try is to boot AsteroidOS with --cmdline debug-ramdisk parameter. Keep an eye on device manager/dmesg to see if an ADB device comes available. It is still possible that it reboots. In that case I need to do a little more debugging :wink:

EDIT: Just a heads up, I have updated the version linked. It has the following changes integrated from sturgeon:

Things that could work

Of course I couldn't test this so this is a list of things that may work:

Things that are likely broken

Some bugs are general on all platforms sawshark will be no different :smile:

Things that won't work

Some of these are bugs and some aren't actually finished yet:

FlorentBrianFoxcorner commented 3 years ago

@MagneFire thank you.

Tried booting the BT variant, following https://asteroidos.org/install/sturgeon/

The watch is unlocked now. Followed -> 2 b. Temporary installation:

adb push -p /home/fv/Downloads/asteroid-image-sawshark.ext4 /sdcard/asteroidos.ext4 adb reboot bootloader fastboot boot /home/fv/Downloads/zImage-dtb-sawshark.fastboot

=> The watch then boots again into Wear OS.

Then tried:

fastboot --cmdline "debug-ramdisk" boot /home/fv/Downloads/zImage-dtb-sawshark.fastboot fastboot: unrecognized option '--cmdline' fastboot -c "debug-ramdisk" boot /home/fv/Downloads/zImage-dtb-sawshark.fastboot downloading 'boot.img'... OKAY [ 0.448s] booting... OKAY [ 0.162s] finished. total time: 0.609s

=> watch hangs in fastboot and does not react on anything except holding both buttons until reset... then again booting into Wear OS

fastboot --version fastboot version 1:8.1.0+r23-5ubuntu2 Installed as /usr/lib/android-sdk/platform-tools/fastboot

MagneFire commented 3 years ago

@FlorentBrianFoxcorner Thanks for testing! :smile: It is actually great to see that the watch hangs when you boot it with fastboot -c "debug-ramdisk" boot /home/fv/Downloads/zImage-dtb-sawshark.fastboot. Can you verify whether or not you can connect to the watch using adb when it is frozen in this mode? If adb shell works, can you send the logs for dmesg? And try to find the asteroidos.ext4 file using the commands (in adb shell):

. /machine.conf
mkdir /sdcard
mount /dev/$sdcard_partition /sdcard
ls /sdcard

Also, does it show the AsteroidOS boot logo at this point?

Another thing, can you also send the output of dmesg on WearOS?

For reference sake, this may also be helpful: https://asteroidos.org/wiki/boot-process/

FlorentBrianFoxcorner commented 3 years ago

@MagneFire, YES, I was able to connect!

dmesg-asteroid.txt

It does not show the logo but is stuck at the frozen fastboot menu.

The kernel seems to lack CONFIG_QUOTA, I was NOT able to mount sdcard, mind dmesg. The partition layout and the image do seem to be ok. I checked with:

adb pull /dev/mmcblk0p35 ./ sudo mkdir /media/debug sudo mount -o loop ./mmcblk0p35 /media/debug

-> My Ubuntu box was able to mount the resulting image RW alright.

For dmesg on Wear Os I need root or is there a shortcut?

127|sawfish:/ $ dmesg dmesg: /dev/kmsg: Permission denied

MagneFire commented 3 years ago

Thanks so much for that info! I have adjusted the kernel config to include the CONFIG_QUOTA. Can you retry a normal boot first to see if it progresses any further? Otherwise try the steps before again?

Only the fastboot image has changed, you do not need to push the ext4 file again. https://www.dropbox.com/sh/h0kzcky4qls3v60/AAC7nBfhSoPpStSQ6Gx4h769a?dl=0

FlorentBrianFoxcorner commented 3 years ago

The kernel still does not seem to fully support required ext4 features:

[..] [ 7.722561] msm_otg 78d9000.usb: Avail curr from USB = 500 [ 7.780107] android_work: android_work: sent uevent USB_STATE=CONFIGURED [ 34.014561] mmc0: mmc_partial_init: tuning execution failed (-22) [ 34.016290] EXT3-fs (mmcblk0p35): error: couldn't mount because of unsupported optional features (40) [ 34.017878] EXT4-fs (mmcblk0p35): couldn't mount as ext2 due to feature incompatibilities [ 34.029527] EXT4-fs warning (device mmcblk0p35): ext4_enable_quotas:5274: Failed to enable quota tracking (type=0, err=-3). Please run e2fsck to fix. [ 34.029634] EXT4-fs (mmcblk0p35): mount failed [..]

Tried to build myself, did not succeed...

git clone https://github.com/AsteroidOS/asteroid.git cd asteroid/src git clone https://github.com/MagneFire/meta-sawshark-hybris.git # your latest changes are not yet pushed, right? cd ..

added line to asteroid/build/conf/bblayers.conf:

${SRCDIR}/meta-sawshark-hybris \

then did:

sudo docker rm -f asteroidos-toolchain ; sudo docker run --name asteroidos-toolchain -it -v /etc/passwd:/etc/passwd -u id -u:id -g -v "$HOME/.gitconfig:/$HOME/.gitconfig" -v "$(pwd):/asteroid" asteroidos-toolchain bash -c "source ./prepare-build.sh sawshark && bitbake asteroid-image"

got:

'void ( glGetProgramBinary)(GLuint, GLsizei, GLsizei, GLenum, void)' redeclared as different kind of symbol

FlorentBrianFoxcorner commented 3 years ago

Tried

e2fsck -f /dev/mmcblk0p35

Filesystem is ok.

MagneFire commented 3 years ago

A new fastboot version should be downloadable now. It has some other quota related functions enabled. Does this fix the mounting issues?

As for the bitbake issue, I think this is caused by libhybris using newer GLES3 based headers. The reason as to why I am not getting this issue is likely due to a dependency not recompiling after the libhybris change(i.e. lipstick, asteroid-launcher, etc are using older headers and compile fine.). Anyway, I have downgraded the libhybris used, to a version that might fix the issue.

FlorentBrianFoxcorner commented 3 years ago

That did the trick for mounting /sdcard!

Without debug: IMG_20201229_121750

New dmesg: dmesg-sawshark-2020-12-29.txt

sh-4.4# ls -l /sdcard drwx------ 2 root root 4096 Oct 21 04:39 adb -rw------- 1 1000 1000 6640 Dec 29 2020 alm.agnss drwxrwxr-x 2 1000 1000 4096 Jan 1 2009 anr drwxrwx--x 8 1000 1000 4096 Dec 28 2020 app drwx------ 2 root root 4096 Oct 21 04:39 app-asec drwxrwx--x 2 1000 1000 4096 Oct 21 04:39 app-ephemeral drwxrwx--x 2 1000 1000 4096 Oct 21 04:39 app-lib drwxrwx--x 2 1000 1000 4096 Oct 21 04:39 app-private drwx------ 2 1000 1000 4096 Oct 21 04:39 backup drwxr-xr-x 2 2000 2000 4096 Oct 21 04:39 bootchart drwxrwx--- 5 1000 2001 4096 Oct 21 04:39 cache drwxrwx--x 3 root root 4096 Oct 22 18:32 dalvik-cache drwxrwx--x 69 1000 1000 4096 Dec 27 2020 data drwxrwx--- 2 1019 1019 4096 Oct 21 04:39 drm lrwxrwxrwx 1 1000 1000 30 Oct 21 04:39 firmware -> /system/vendor/firmware/murata drwxr-x--x 3 root root 4096 Oct 21 04:39 local drwx------ 3 1000 1000 4096 Jan 1 2009 logdata drwxrwx--- 2 root root 4096 Jan 1 1970 lost+found drwxrwx--- 4 1023 1023 4096 Jan 1 2009 media drwxrwx--- 2 1031 1031 4096 Oct 21 04:39 mediadrm drwxrwx--t 35 1000 9998 4096 Oct 21 04:39 misc drwxrwx--t 3 1000 9998 4096 Jan 1 2009 misc_ce drwxrwx--t 3 1000 9998 4096 Oct 21 04:39 misc_de drwxr-xr-x 2 1027 1027 4096 Jan 1 2009 nfc drwxrwx--x 2 root root 4096 Oct 21 04:39 ota drwxrwx--- 2 1000 2001 4096 Oct 21 04:39 ota_package -rw------- 1 1000 1000 143638 Dec 29 2020 persistence.agnss drwx------ 2 root root 4096 Dec 29 2020 property drwxrwx--x 2 1000 1000 4096 Dec 28 2020 resource-cache drwx------ 2 1000 1000 4096 Oct 21 04:39 ss drwxrwxr-x 17 1000 1000 4096 Dec 29 2020 system drwxrwx--- 3 1000 1000 4096 Jan 1 2009 system_ce drwxrwx--- 3 1000 1000 4096 Oct 21 04:39 system_de drwx------ 2 1000 1000 4096 Dec 25 2020 time drwxrwx--x 2 1000 1000 4096 Oct 21 04:39 tombstones drwx--x--x 2 1000 1000 4096 Oct 21 04:39 user drwx--x--x 3 1000 1000 4096 Oct 21 04:39 user_de drwxrwx--x 4 root root 4096 Oct 21 04:39 vendor

Also started new build now...

MagneFire commented 3 years ago

Very interesting! Can you check if /system/bin/logcat also outputs information? It should help with the display issue.

FlorentBrianFoxcorner commented 3 years ago

There is no adb connection possible when booted without debug.

And in debug mode there is no /system mounted.

Followed https://asteroidos.org/wiki/boot-process/ and logcat is in /rfs/system/bin. But it seems to be dynamically linked and libs are missing as well as ldd -> I am lost.

sh-4.4# /rfs/system/bin/logcat sh: /rfs/system/bin/logcat: No such file or directory sh-4.4# ldd /rfs/system/bin/logcat sh: ldd: command not found

The build passed yesterday's error, now stuck at

collect2: error: ld returned 1 exit status Makefile.AccountsHelperTest:161: recipe for target 'AccountsHelperTest' failed make[4]: [AccountsHelperTest] Error 1 make[4]: Leaving directory '/asteroid/build/tmp-glibc/work/armv7vehf-neon-oe-linux-gnueabi/buteo-syncfw/+gitAUTOINC+dc14838480-r1/build/unittests/tests/msyncd tests' Makefile:57: recipe for target 'sub-AccountsHelperTest-pro-make_first' failed make[3]: [sub-AccountsHelperTest-pro-make_first] Error 2

I there a way to skip tests during build?

MagneFire commented 3 years ago

Is a ssh connection possible without debug mode? (ssh ceres@192.168.2.15) (https://asteroidos.org/wiki/ssh/) I don't think we need the debug mode for now, as it no longer crashes/reboots.

As for the build, disabling tests require some manual patches as well. Can you try to clean the package first?

bitbake -ccleanall buteo-syncfw

And try to rebuild.

Also, I have uploaded a new ext4 image that should have adb mode as the default. Just in case the ssh thing doesn't work.

FlorentBrianFoxcorner commented 3 years ago

Sorry I did not notice this earlier: When that screen content I sent earlier is displayed, actually no USB connection can be made to the watch. Tried different USB ports at my PC without success. Also tried with new ext4 image. Ubuntu dmesg shows endlessly:

[..] [ 4303.939954] usb 1-2.3: new high-speed USB device number 43 using xhci_hcd [ 4304.072975] usb 1-2.3: New USB device found, idVendor=12d1, idProduct=1c2c, bcdDevice= 3.18 [ 4304.072978] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4304.072979] usb 1-2.3: Product: LEO-BX9 [ 4304.072980] usb 1-2.3: Manufacturer: HUAWEI [ 4304.072981] usb 1-2.3: SerialNumber: TKQ7N18B06001286 [ 4846.446522] usb 1-2.3: USB disconnect, device number 43 [ 4846.446762] xhci_hcd 0000:02:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state. [ 4851.471366] usb 1-2.3: new high-speed USB device number 44 using xhci_hcd [ 4851.607115] usb 1-2.3: New USB device found, idVendor=18d1, idProduct=d00d, bcdDevice= 1.00 [ 4851.607117] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 4851.607119] usb 1-2.3: Product: Android [ 4851.607120] usb 1-2.3: Manufacturer: Google [ 4851.607121] usb 1-2.3: SerialNumber: TKQ7N18B06001286 [ 4876.909970] usb 1-2.3: USB disconnect, device number 44 [ 4890.739454] usb 1-2.3: new high-speed USB device number 45 using xhci_hcd [ 4890.850385] usb 1-2.3: no configurations [ 4890.850390] usb 1-2.3: can't read configurations, error -22 [ 4890.943980] usb 1-2.3: new high-speed USB device number 46 using xhci_hcd [ 4891.054389] usb 1-2.3: no configurations [ 4891.054393] usb 1-2.3: can't read configurations, error -22 [ 4891.058403] usb 1-2-port3: attempt power cycle [ 4892.307485] usb 1-2.3: new high-speed USB device number 47 using xhci_hcd [ 4892.333378] usb 1-2.3: no configurations [ 4892.333383] usb 1-2.3: can't read configurations, error -22 [ 4892.427993] usb 1-2.3: new high-speed USB device number 48 using xhci_hcd [ 4892.453381] usb 1-2.3: no configurations [ 4892.453385] usb 1-2.3: can't read configurations, error -22 [ 4892.457403] usb 1-2-port3: unable to enumerate USB device [ 4892.752003] usb 1-2.3: new high-speed USB device number 49 using xhci_hcd [ 4892.862406] usb 1-2.3: no configurations [ 4892.862410] usb 1-2.3: can't read configurations, error -22 [ 4892.955995] usb 1-2.3: new high-speed USB device number 50 using xhci_hcd [ 4893.070021] usb 1-2.3: no configurations [ 4893.070027] usb 1-2.3: can't read configurations, error -22 [ 4893.074426] usb 1-2-port3: attempt power cycle [ 4893.692010] usb 1-2.3: new high-speed USB device number 51 using xhci_hcd [ 4893.717061] usb 1-2.3: no configurations [ 4893.717065] usb 1-2.3: can't read configurations, error -22 [ 4893.812015] usb 1-2.3: new high-speed USB device number 52 using xhci_hcd [ 4893.837421] usb 1-2.3: no configurations [ 4893.837426] usb 1-2.3: can't read configurations, error -22 [ 4893.840995] usb 1-2-port3: unable to enumerate USB device [..]

These line occurs after fastboot boot [..] zImage-dtb-sawshark.fastboot:

[ 4846.446522] usb 1-2.3: USB disconnect, device number 43 [ 4846.446762] xhci_hcd 0000:02:00.0: WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.

Then the device becomes "Google Android" and USB connect is no longer possible.

Trying rebuild as well.

FlorentBrianFoxcorner commented 3 years ago

Build succeeded, I get the same result when using resulting ext4 and kernel.

MagneFire commented 3 years ago

ok, thanks for confirming. I am currently not sure why this issue occurs. And good to see the same behavior, it's at least reproducible :wink:

Meanwhile, I will create a new layer specific for the Bluetooth version of this watch. So there will, for now be, two repos:

I will let you know when the builds are done. The files will be published here: https://www.dropbox.com/sh/lefbpbjwqsmhfm2/AABSEF33uHH119JV38Ri1OYna?dl=0

On sturgeon usb did also not work, but this was partly solved by reverting a commit: https://github.com/MagneFire/meta-sturgeon-hybris/blob/nougat-mr1.8-release/recipes-kernel/linux/linux-sturgeon/0001-Revert-KEYS-Fix-crash-when-attempt-to-garbage-collec.patch. Something similar might also be needed here, though this commit does not appear for sawshark... Otherwise, we could also disable usb-moded completely and use adbd directly, similar to: https://github.com/AsteroidOS/meta-asteroid/pull/15. I can test these changes for sturgeon too, so I don't suspect this to be a difficult thing to do.

edit: New files have been published to the Dropbox folder. Also I have updated the kernel to the latest version for Nougat.

Edit 2: I have updated the binaries one more time On sturgeon we also pull the /firmware files, this was needed for the adsp to work. Instead of pulling these files on sawfish the partition is mounted to /firmware (https://github.com/MagneFire/meta-sawfish-hybris/commit/53b91225881adf8e257b096f0ad02eea16332d98) and then firmwared is adjusted to look there for files too (https://github.com/MagneFire/meta-sawfish-hybris/commit/0877206cca73c19c0b804b22685123496ffc5c31). The binaries for this version is located in the firmware_test folder. Can you test if either behaves any differently from the previous builds?

fosspill commented 3 years ago

I'm not very well versed in this but I did try to flash both versions referenced in your last post @MagneFire to my Watch 2.

No luck: Both end up with the screen shown here https://github.com/AsteroidOS/asteroid/issues/101#issuecomment-752044885

To make the device discoverable with adb -c "debug-ramdisk" is still needed but the screen is frozen on the bootloader screen while debug is active.

I'd gladly extract any logs I can (from debug) if needed!

MagneFire commented 3 years ago

@fosspill Thanks for testing! Maybe something else we can do is make the journal log persistent. To get the logs from the mode where something is shown on the screen.

1. Boot to debug-ramdisk

Boot to this mode to change the configuration of journalctl.

Then start a adb shell session. Execute the following commands:

. /machine.conf
mkdir /sdcard
mount /dev/$sdcard_partition /sdcard
mount -o loop /sdcard/media/0/asteroidos.ext4 /mnt
chroot /mnt
vi /etc/fstab

Change the contents of /etc/fstab to disable the /var/volatile entry, like this:

...
#tmpfs                /var/volatile        tmpfs      defaults              0  0
...

Then make adjust the journald config:

vi /etc/systemd/journald.conf

Adjust the #Storage=auto to Storage=persistent

...
[Journal]
Storage=persistent
#Compress=yes
#Seal=yes
#SplitMode=uid
#SyncIntervalSec=5m
...

Lastly, remove the symlink and create a new folder:

rm /var/log
mkdir /var/log/

Now exit chroot:

exit

And reboot to normal mode.

2. Reboot to normal mode.

Now just reboot to the mode where adb is broken, but where something is displayed on the screen. Wait for a ~5 minutes, just to be sure.

3. Reboot to debug mode.

Now boot to debug mode to fetch the journalctl logs from the normal mode:

. /machine.conf
mkdir /sdcard
mount /dev/$sdcard_partition /sdcard
mount -o loop /sdcard/media/0/asteroidos.ext4 /mnt
chroot /mnt
journalctl --no-pager

Now you should see the log of the previous boot. Can you send me this?

On a side node, I have updated the images once more with an updated adb daemon and small changes to the usb-moded package. Can you test this too. I don't really expect it to be any different, but you never know :wink:

edit: Adjusted instructions for temporary installation.

fosspill commented 3 years ago

First: The new images has the exact same issue.

Further: I think I may have done something wrong (or missed a step here).

I ran (in order):

$ fastboot -c "debug-ramdisk" boot zImage-dtb-sawfish.fastboot
Downloading 'boot.img'
OKAY [  0.438s]
booting
OKAY [  0.161s]
Finished. Total time: 0.829s

$ adb shell
sh-4.4# . /machine.conf
sh-4.4# mkdir /sdcard
sh-4.4# mount /dev/$sdcard_partition /sdcard
sh-4.4# mount -o loop /sdcard/media/0/asteroidos.ext4 /mnt
mount: mounting /sdcard/media/0/asteroidos.ext4 on /mnt failed: No such file or directory

There is indeed no /0/ or anything alike in /sdcard/media, it is empty.

MagneFire commented 3 years ago

Huh!? That's really strange, can you try this: https://github.com/AsteroidOS/asteroid/issues/101#issuecomment-665335544, is the output the same? Just to confirm that your watch isn't doing anything weird. Are there any contents in the /sdcard/ when you mount it?

fosspill commented 3 years ago 
$ ls -al /sdcard/
drwxr-xr-x   22 root     root          4096 Oct 26  2020 .
drwxr-xr-x   19 root     root           480 Jan  1 10:51 ..
drwxr-xr-x    3 root     root          4096 Oct 26  2020 .config
drwxr-xr-x    2 root     root          4096 Jan  5  2021 bin
drwxr-xr-x    2 root     root          4096 Dec 29  2020 boot
drwxr-xr-x    2 root     root          4096 Dec 29  2020 dev
drwxr-xr-x   51 root     root          4096 Oct 25  2020 etc
drwxr-xr-x    2 root     root          4096 Jan  1 09:53 firmware
drwxr-xr-x    4 root     root          4096 Jan  5  2021 home
-rw-r--r--    1 root     root           772 Jan  5  2021 init.rc
drwxr-xr-x    8 root     root          4096 Jan  5  2021 lib
drwx------    2 root     root         16384 Jan  5  2021 lost+found
drwxr-xr-x    2 root     root          4096 Dec 29  2020 media
drwxr-xr-x    2 root     root          4096 Dec 29  2020 mnt
drwxr-xr-x    2 root     root          4096 Jan  1 09:53 nvdata
dr-xr-xr-x    2 root     root          4096 Dec 29  2020 proc
-rw-r--r--    1 root     root          5578 Dec 30  2020 property_contexts
drwxr-xr-x    2 root     root          4096 Jan  5  2021 run
drwxr-xr-x    3 root     root          4096 Jan  5  2021 sbin
dr-xr-xr-x    2 root     root          4096 Dec 29  2020 sys
drwxr-xr-x    9 root     root          4096 Dec 30  2020 system
drwxrwxrwt    2 root     root          4096 Dec 29  2020 tmp
drwxr-xr-x   10 root     root          4096 Jan  5  2021 usr
drwxr-xr-x    8 root     root          4096 Oct 25  2020 var
lrwxrwxrwx    1 root     root            13 Dec 30  2020 vendor -> system/vendor

When it comes to https://github.com/AsteroidOS/asteroid/issues/101#issuecomment-665335544 I guess I'd have to reflash the stock ROM?

MagneFire commented 3 years ago

Ow, this looks like a real installation, i.e. fastboot flash userdata asteroid-image-sawfish.ext4.

In that case use the following:

. /machine.conf
mkdir /sdcard
mount /dev/$sdcard_partition /mnt

Instead of:

. /machine.conf
mkdir /sdcard
mount /dev/$sdcard_partition /sdcard
mount -o loop /sdcard/media/0/asteroidos.ext4 /mnt

Also, a reflash of the stock ROM isn't needed, TWRP provides the necessary information.

fosspill commented 3 years ago

Yeah, I should have told you that. Replaced the standard rom the moment I had the chance as the watch hasn't been in use for a year, if not more, anyways.

First try at the logs: Journal: https://gist.github.com/fosspill/64d3de01afbc2e39b977379c31bb0be6 To what I can see this seems weird (the date is all wrong, for instance) so I guess this is wrong. I have however tried a few times now and everything seem to be correct.

Second try at the logs (this is the same, but much more data. Did all of the most recent day: https://gist.github.com/fosspill/8ba3e25fbd80c4f16636ef9a19eece40

Output from the partition table:

~ # ls -al /dev/block/platform/soc/7824900.sdhci/by-name
__bionic_open_tzdata: couldn't find any tzdata when looking for GMT!
drwxr-xr-x    2 root         root               740 Jan  1 11:52 .
drwxr-xr-x    4 root         root               820 Jan  1 11:52 ..
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 DDR -> /dev/block/mmcblk0p21
lrwxrwxrwx    1 root         root                20 Jan  1 11:52 aboot -> /dev/block/mmcblk0p7
lrwxrwxrwx    1 root         root                20 Jan  1 11:52 abootbak -> /dev/block/mmcblk0p8
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 boot -> /dev/block/mmcblk0p29
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 cache -> /dev/block/mmcblk0p34
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 cmnlib -> /dev/block/mmcblk0p24
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 cmnlibbak -> /dev/block/mmcblk0p25
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 config -> /dev/block/mmcblk0p18
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 devinfo -> /dev/block/mmcblk0p23
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 fsc -> /dev/block/mmcblk0p13
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 fsg -> /dev/block/mmcblk0p22
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 keymaster -> /dev/block/mmcblk0p26
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 keymasterbak -> /dev/block/mmcblk0p27
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 keystore -> /dev/block/mmcblk0p17
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 misc -> /dev/block/mmcblk0p15
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 modem -> /dev/block/mmcblk0p32
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 modemst1 -> /dev/block/mmcblk0p11
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 modemst2 -> /dev/block/mmcblk0p12
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 nfc -> /dev/block/mmcblk0p19
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 nvbin -> /dev/block/mmcblk0p10
lrwxrwxrwx    1 root         root                20 Jan  1 11:52 nvdata -> /dev/block/mmcblk0p9
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 oem -> /dev/block/mmcblk0p28
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 recovery -> /dev/block/mmcblk0p31
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 reserved -> /dev/block/mmcblk0p20
lrwxrwxrwx    1 root         root                20 Jan  1 11:52 rpm -> /dev/block/mmcblk0p3
lrwxrwxrwx    1 root         root                20 Jan  1 11:52 rpmbak -> /dev/block/mmcblk0p4
lrwxrwxrwx    1 root         root                20 Jan  1 11:52 sbl1 -> /dev/block/mmcblk0p1
lrwxrwxrwx    1 root         root                20 Jan  1 11:52 sbl1bak -> /dev/block/mmcblk0p2
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 sec -> /dev/block/mmcblk0p30
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 splash -> /dev/block/mmcblk0p16
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 ssd -> /dev/block/mmcblk0p14
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 system -> /dev/block/mmcblk0p33
lrwxrwxrwx    1 root         root                20 Jan  1 11:52 tz -> /dev/block/mmcblk0p5
lrwxrwxrwx    1 root         root                20 Jan  1 11:52 tzbak -> /dev/block/mmcblk0p6
lrwxrwxrwx    1 root         root                21 Jan  1 11:52 userdata -> /dev/block/mmcblk0p35
MagneFire commented 3 years ago

This looks very interesting actually. Few things to note:

Can you maybe send the full log of the journalctl? It seems that some parts are missing from the beginning. You can also just pipe the output to a file and pull that from the watch:

journalctl --no-pager > /journal.log

And use adb pull to fetch it:

adb pull /journal.log
fosspill commented 3 years ago

Had to give up on the adb pull. Couldn't find the file but I just marked it all and pasted it: https://gist.github.com/fosspill/f70a86bb6a8e52b71fa9ff29d8c82810

MagneFire commented 3 years ago

@fosspill Thanks for that log! It actually provides some interesting debug information! The following log output actually makes me think that this is the reason for the display not functioning.

init: Failed to initialize property area

It might have something to do with me not disabling SELinux :fearful:

Anyway, you'll find new images on the Dropbox (https://www.dropbox.com/sh/lefbpbjwqsmhfm2/AABSEF33uHH119JV38Ri1OYna?dl=0), that properly disables SELinux and also some work on Bluetooth. Can you test again, to see if it progresses any further.

fosspill commented 3 years ago

No change to what I can see, but here are the new debug logs.

https://gist.github.com/fosspill/66bd6bb04df245f5075bc954727b5a86

The init error you spoke of seems to have vanished though:

Oct 25 19:37:48 sawfish init: init first stage started!
Oct 25 19:37:48 sawfish init: init second stage started!
Oct 25 19:37:48 sawfish init: Running restorecon...
Oct 25 19:37:48 sawfish init: waitpid failed: No child processes
Oct 25 19:37:48 sawfish init: (Loading properties from /default.prop took 0.00s.)
Oct 25 19:37:48 sawfish init: (Parsing /init.rc took 0.02s.)
Oct 25 19:37:48 sawfish init: Waiting for /dev/.coldboot_done...
Oct 25 19:37:48 sawfish init: Waiting for /dev/.coldboot_done took 0.00s.
Oct 25 19:37:48 sawfish init: /dev/hw_random not found

I ran a quick diff between the logs too and it seems like things are generally going better now, even if it doesn't seem better on the watch itself

MagneFire commented 3 years ago

Thanks again! It seems to progress nicely. I think the following cause it to not display anything:

Oct 26 18:21:45 sawfish kernel: mdss_fb_handle_buf_sync_ioctl: mdp-fence: get_unused_fd_flags failed error:0xffffffe8
Oct 26 18:21:45 sawfish kernel: kgsl kgsl-3d0: |kgsl_add_fence_event| Unable to get a file descriptor: -24

Can you try to disable msm-fb-refresher?

. /machine.conf
mkdir /sdcard
mount /dev/$sdcard_partition /mnt
chroot /mnt
/etc/systemd/system/msm-fb-refresher.service

Does that change anything? Otherwise we may want to mess with some environment variables: https://github.com/MagneFire/qt5-qpa-hwcomposer-plugin/blob/master/hwcomposer/hwcomposer_backend.cpp#L70

fosspill commented 3 years ago

After running systemctl disable msm-fb-refresher.service the screen no longer looks like a mess (like the earlier picture) but is instead now frozen on the bootloader screen.

journal.log This is still a thing as well:

Oct 26 18:21:45 sawfish kernel: mdss_fb_handle_buf_sync_ioctl: mdp-fence: get_unused_fd_flags failed error:0xffffffe8
Oct 26 18:21:45 sawfish kernel: kgsl kgsl-3d0: |kgsl_add_fence_event| Unable to get a file descriptor: -24
fosspill commented 3 years ago

I've read up on some of the documentation (not quite enough yet) but I haven't figured out if there are any easy ways to mess with the environment variables. Which file gets read first and should therefore have them set?

MagneFire commented 3 years ago

I really hoped that disabling that service would magically solve this issue :cry:

Anyway, You should be able to set the environment variables by changing the file /var/lib/environment/compositor/default.conf, so:

. /machine.conf
mkdir /sdcard
mount /dev/$sdcard_partition /mnt
chroot /mnt
vi /var/lib/environment/compositor/default.conf

And then just add: QT_QPA_NO_FRAMEBUFFER_FIRST=1 Follow this by a reboot

fosspill commented 3 years ago

Heh, yes, magical simple solutions are always the best!

Thanks for mentioning that file though, I see there are many possibly interesting variables there.

That variable though didn't seem to do much, but here is the logs: journal.log

The logs are interesting because there seems to be many changes from earlier? Did I change something else? Comparing the previous log and this one I find changes like:

(This is new on the newest logs)
sawfish kernel: Booting Linux on physical CPU 0x0
sawfish kernel: Initializing cgroup subsys cpu
sawfish kernel: platform 1de0000.qcom,venus: assigned reserved memory node venus_qseecom_region@0
sawfish kernel: Initializing cgroup subsys cpuacct
sawfish kernel: Linux version 3.18.24 (oe-user@oe-host) (gcc version 8.3.0 (GCC) ) AsteroidOS/meta-smelt-hybris#1 SMP PREEMPT Wed Jan 6 12:12:31 UTC 2021
sawfish kernel: CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
sawfish kernel: CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
sawfish kernel: Machine model: Qualcomm Technologies, Inc. APQ8009W-PM8916 MTP
sawfish kernel: Reserved memory: reserved region for node 'external_image__region@0': base 0x87a00000, size 6 MiB
sawfish kernel: Reserved memory: reserved region for node 'modem_adsp_region@0': base 0x88000000, size 85 MiB
sawfish kernel: Reserved memory: reserved region for node 'pheripheral_region@0': base 0x8d500000, size 5 MiB
sawfish kernel: Reserved memory: reserved region for node 'splash_region@83000000': base 0x83000000, size 12 MiB

It also seems like I may have failed at disabling the service!?

sawfish systemd[1]: msm-fb-refresher.service: Succeeded.
sawfish audit: CONFIG_CHANGE audit_pid=426 old=0 auid=4294967295 ses=4294967295 res=1
sawfish systemd[1]: Started msm-fb-refresher updates the framebuffer on qualcomm devices.

Edit: I even deleted the service now, logs still shows it starting. I'm doing something wrong.

MagneFire commented 3 years ago

The log is now persistent on every boot, so this may be from previous boots. You could just remove the /var/log/journal/ folder to clear the complete log.

Also, I have uploaded a new version under the hybris_update folder. Can you give that a try?

Some background on this build: The error related to get_unused_fd_flags seems to indicate that QCOM_BSP and QTI_BSP aren't set.

The error indicates that probably something related to graphics has already been opened. So disabling msm-fb-refresher would have been the obvious fix (worked for smelt: AsteroidOS/meta-smartwatch#1) Also change the input device for touch to event1.

Next up would really be fixing/finding a better solution for adb not working properly. As this will allow for getting more debug information using /system/bin/logcat.

fosspill commented 3 years ago

Oh right, I feel a bit silly now.. I guess at least the bottoms of the logs I've uploaded would be somewhat useful regardless. I'll make sure to wipe it between boots now though, at least I'll be less confused myself :sweat_smile:

Thanks for bearing with me here!

First boot with the _hubrisupdate image resulted in a completely black screen! Sadly still no adb responsiveness though. Booting again made it just show the bootloader screen permanently though.

This is the logs. Completely clean this time (I believe), so this is only the last boot: journal.log

EDIT: Getting some sleep, but booted it again now and it's frozen on the Huawei logo. Seems to graphically freeze on whatever it saw last.

MagneFire commented 3 years ago

No worries :smile: Looking at the log actually reveals that the:

Oct 26 18:21:45 sawfish kernel: mdss_fb_handle_buf_sync_ioctl: mdp-fence: get_unused_fd_flags failed error:0xffffffe8
Oct 26 18:21:45 sawfish kernel: kgsl kgsl-3d0: |kgsl_add_fence_event| Unable to get a file descriptor: -24

Are actually gone!

I have uploaded new images that should solve the following:

Oct 26 18:26:42 sawfish asteroid-launcher[501]: ../../git/src/semaphore_p.cpp: 57 - Unable to get semaphore /home/ceres/.local/share/system/privileged/Calendar/mkcal/db: Function not implemented (38)
Oct 26 18:26:42 sawfish asteroid-launcher[501]: ../../git/src/semaphore_p.cpp: 214 - Unable to create semaphore array!
Oct 26 18:26:42 sawfish asteroid-launcher[501]: ../../git/src/semaphore_p.cpp: 57 - Unable to decrement semaphore /home/ceres/.local/share/system/privileged/Calendar/mkcal/db: Success (0)
Oct 26 18:26:42 sawfish asteroid-launcher[501]: ../../git/src/sqlitestorage.cpp: 180 - cannot lock "/home/ceres/.local/share/system/privileged/Calendar/mkcal/db" error "Success"

Also, I have applied the check-config script on the Linux defconfig, that should also fix some permission issues, hopefully this one:

Oct 26 18:26:47 sawfish /usr/libexec/mapplauncherd/booster-qtcomponents-qt5[558]: SocketManager: Failed to unlink existing socket file '/run/user/1000/mapplauncherd/qtcomponents-qt5': No such file or directory
fosspill commented 3 years ago

New image, new logs: journal.log

To what I can see both the errors you mentioned are indeed resolved, but there is still this one, which seems related to your last point: Oct 26 18:44:37 sawfish /usr/libexec/mapplauncherd/booster-generic[508]: SocketManager: Failed to unlink existing socket file '/run/user/1000/mapplauncherd/generic': No such file or directory

MagneFire commented 3 years ago

The kgsl kgsl-3d0: |kgsl_add_fence_event| Unable to get a file descriptor: -24 is still a thing in that log, which wasn't in the previous one, that's a bit strange.

The error I mentioned in the previous /usr/libexec/mapplauncherd/booster-generic is actually a non-error. The same line exists in the journal on sturgeon.

It is great to see that some issues with regards to the semaphore issues are resolved.

Anyway, there is another image on the Dropbox, that should™ have a workaround for adb not working (disables usb-moded). Also I have recreated the system tarball, it took me some time to do it properly this time, modified repos are:

fosspill commented 3 years ago

There is a mismatch between the boot and userdata creation time on dropbox, but I presume that's just because you made changes to one later.

Sadly adb still doesn't work without debug for me, but I still haven't seen the "garbled output" that there was a picture of.

journal.log

MagneFire commented 3 years ago

The mismatch is because only changes were made to the root image not the kernel and initramfs.

Can you check/enable the android-tools-adbd service to see if that fixes adb on the watch? Strangely it runs on my watch even though I haven't enabled it.

The 'garbled output' is produced by the msm-fb-refresher I think. I could add that again to see if that works now. Given that android init was broken before we removed the msm-fb-refresher.

fosspill commented 3 years ago

I chrooted and ran systemctl enable android-tools-adbd and rebooted. Still no adb, sadly. I'll try again a bit tomorrow morning and give you the logs!

fosspill commented 3 years ago

journal.log

To what I can see running "systemctl enable android-tools-adbd" does not actually make android-tools-adbd start. I didn't find any mentions of it in the logs.

How I tried to enable it. Please tell me if I'm doing something wrong:

. /machine.conf
mkdir /sdcard
mount /dev/$sdcard_partition /mnt
chroot /mnt

systemctl enable android-tools-adbd
MagneFire commented 3 years ago

You are correct that enabling doesn't start it in debug mode(which is also not needed.). It does however look like it does run in normal mode:

sawfish android-gadget-setup[409]: mount: /dev/usb-ffs/adb: adb already mounted or mount point busy.

The android-gadget-setup service is a dependency for the android-tools-adbd service.

Interestingly, this log does not have the other error:

kgsl kgsl-3d0: |kgsl_add_fence_event| Unable to get a file descriptor: -24

Which, I think, is rather odd. Also, another build is on the Dropbox (msm-fb-refresher folder). This should have the android-tools-adbd service enabled and once again adds and enables msm-fb-refresher.

I will do some further tests with adb on my sturgeon. Even though it works fine on that.