Messages

1

Astro Slide - Android / Re: Astro won't boot -- userdata corrupt?

« on: December 07, 2022, 05:36:22 pm »

Thanks @shymega, I'd love to get the original boot_a.img (if it's different than the one Noppe shared at https://www.oesf.org/forum/index.php?topic=36812.0 , which has  sha1sum 2d6f1d3948f28c0c4d460c4420f3111ad4604e78 )

2

Astro Slide - Android / Re: Screen momentarily going full brightness when going to sleep

« on: December 07, 2022, 11:26:57 am »

Yep, my device does this sometimes too. But not all the time! I've been trying to figure out what causes it, but no luck so far. I wonder if it has to do with the light sensor and automatic brightness control? (but I keep that disabled...)

3

Astro Slide - Android / Re: Astro won't boot -- userdata corrupt?

« on: December 06, 2022, 11:24:07 pm »

Thanks. I'm able to get into the stock recovery and mess around a bit in there, but no luck restoring functionality yet.

I seem to have lost the original boot.img from before I applied magisk, so I can't try getting my device back into the "green state". The "boot_b" partition seems to be empty (all 0x00). Does anybody have a copy of the stock boot.img that they'd be willing to share? You can email it to me with my username at gmail.com.

4

Astro Slide - Android / Astro won't boot -- userdata corrupt?

« on: December 04, 2022, 09:49:19 pm »

I dropped my Astro and busted the screen, so I had to pay the ebay premium for a replacement. When it showed up I rooted it the same way and everything seemed fine. Then I transferred over some userdata from my old handset, which ended up being about 30Gb. Afterwards I stopped/started the android runtime and it wouldn't come up, stuck on the pulsing "android" screen, with some NullPointerExceptions from system_server in the logcat. I noticed that all the directory names in /data/data and in /data/user/0 were random-looking base64 strings, and the same happened after a reboot of the device. I thought maybe I had screwed up my encryption keys somehow, so I tried "fastboot erase userdata". But now I still get stuck on the pulsing "android" screen and to make matters worse, I've lost adb.

I tried returning everything back to stock (restoring boot_a.img and vbmeta_a.img with mtkclient, then re-locking the bootloader) but then it won't get past the "red state" dm-verity boot-up screen, which claims my device is corrupt and will poweroff in 5 seconds unless I press the power button (and if I do, it just drops to fastboot).

My only guess is that maybe I put too much stress on the mmc flash with my data transfer, causing the part to fail.

Anyone have suggestions for debugging or proceeding? Anyone found a way to get a serial console? My only idea is to try to transplant th screen from the new device to the old one (or the mainboard from the old one to the new one), but I'm very scared to attempt it with no instructions.

5

Astro Slide - Hardware / Re: Planet USB-C to HDMI Video Cable

« on: October 30, 2022, 08:34:39 am »

I mentioned on the other thread that root can probe the lt8912b driver at runtime with `echo 14010000.dsi.2 > /sys/bus/mipi-dsi/drivers/panel-vt-lt8912b-vdo/bind` . This doesn't work because the panel index is mismatched from what the dts expects (and I don't understand why it works when the hdmi is plugged from boot--somehow the dts remote-port changes). I tried commenting out that check, but then the device just reboots. It seems, reading drivers/misc/mediatek/devapc, that the kernel worker thread that services the bind command isn't authorized to access the display subsystem, so the cpu generates a violation interrupt. Maybe I can disable this, or figure out some way to get the correct thread to do the probing.

6

Astro Slide - Android / Re: Kernel astro

« on: October 28, 2022, 11:08:49 pm »

Yep, it's real, it builds and it's what I've been running on my astro for months. In fact I'm recompiling it right now to see if I can unblock the hdmi module. I've discovered that you can reprobe at runtime by running this code as root:
 echo 14010000.dsi.2 > /sys/bus/mipi-dsi/drivers/panel-vt-lt8912b-vdo/bind
However, the driver refuses to load, seemnigly because it expects to be attached to panel1, not panel2. Somehow, when booting with the hdmi plug in, the value of  /sys/firmware/devicetree/base/dsi@14010000/ports/port/endpoint/remote-endpoint changes to point to panel2, even though the dts clearly points it to panel1. I've been trying to understand the OpenFirmware dts language but there's not much good documentation on it... 

7

Astro Slide - Hardware / Re: Planet USB-C to HDMI Video Cable

« on: October 16, 2022, 08:29:24 pm »

I have a hunch about why the hdmi adapter only works if plugged in on boot. In the astro kernel tree, drivers/misc/mediatek/typec/fusb302 has code very much like the cosmo's hdmi plug detection code. It exports a symbol, hdmi_plug_in_flag, which gets changed to 1 when the port detects the adapter and 0 when the adapter is removed. However, unlike in the Cosmo tree, this variable is never used. It is however mentioned in commented-out code in drivers/gpu/drm/panel-vt-lt8912b-vdo.c . This driver is part of astro's device tree. In its .probe function, it calls FUSB300Read to check if the adapter is plugged in, and if so, sets the gpios necessary to send HDMI out. However, this probe function is only called once, at boot-up time.

Cosmo had a device at /dev/hdmitx and some userspace daemon for managing the hdmi output through ioctls on that device. Some similar code remains in the astro tree but it is not enabled in the device tree.

So, thanks to cam1965's discovery, I suspect we may be able to fix up Astro's proprietary left-side hdmi-output with some small changes. (I would be much happier if we could get standard displayport altmode working though!)

8

Astro Slide - Hardware / Re: Planet USB-C to HDMI Video Cable

« on: October 16, 2022, 08:16:29 pm »

Wow, thanks cam1965, excellent discovery! How did you figure that out?

I've been poking at the kernel source. It seems that there's some partial support for standard usb type c alternate-mode displayport. I tried 2 displays and 3 adapters/cables. In all cases, dmesg indicates a successful negotiation with the display and the astro adopts Downstream Facing Port mode. But nothing appears on the screen and no new device shows up in /sys/class/drm . (With a usb-c cable to a usb-c display, I was able to get the Astro charging over usb-pd and also using the screen's usb hub at the same time, which Cosmo was never able to do.) The code seems to suggest that a PI3DPX1205A chip is required to activate DisplayPort, but that driver isn't in the astro's device tree (k6873v1_64.dts). I wonder if the Astro indeed has this chip, and if so, how it's wired up.

9

Astro Slide - Hardware / Re: Planet USB-C to HDMI Video Cable

« on: October 06, 2022, 07:52:18 pm »

I looked at a dmesg dump from my Cosmo while plugging in the hdmi adapter:

[Thu Jan 16 15:19:08 2020]  (0)[24744:kworker/0:1]====fusb300_eint_work:zhaolong debug x600 USB1=====
[Thu Jan 16 15:19:08 2020]  (0)[24744:kworker/0:1]===USB1 is plug in===
[Thu Jan 16 15:19:08 2020]  (0)[24744:kworker/0:1]===hdmi plug in===
[Thu Jan 16 15:19:08 2020]  (0)[24744:kworker/0:1]=======CC2=======
[Thu Jan 16 15:19:09 2020]  (0)[162:hdmi_timer_kthr]i2c i2c-3: addr: 39, transfer ACK error
[Thu Jan 16 15:19:09 2020]  (0)[162:hdmi_timer_kthr]i2c_dump_info ++++++++++++++++++++++++++++++++++++++++++
[Thu Jan 16 15:19:09 2020]  (0)[162:hdmi_timer_kthr]I2C structure:
[Thu Jan 16 15:19:09 2020] [I2C]Clk=15600,Id=3,Op=1,Irq_stat=2,Total_len=2
[Thu Jan 16 15:19:09 2020] [I2C]Trans_len=2,Trans_num=1,Trans_auxlen=0,speed=400000
[Thu Jan 16 15:19:09 2020] [I2C]Trans_stop=1
[Thu Jan 16 15:19:09 2020]  (0)[162:hdmi_timer_kthr]base address 0xffffff8004e26000
[Thu Jan 16 15:19:09 2020]  (0)[162:hdmi_timer_kthr]I2C register:
[Thu Jan 16 15:19:09 2020] [I2C]SLAVE_ADDR=72,INTR_MASK=f8,INTR_STAT=1,CONTROL=28,TRANSFER_LEN=2
[Thu Jan 16 15:19:09 2020] [I2C]TRANSAC_LEN=1,DELAY_LEN=2,TIMING=13,START=2,FIFO_STAT=2201
[Thu Jan 16 15:19:09 2020] [I2C]IO_CONFIG=3,HS=0,DCM_EN=0,DEBUGSTAT=40,EXT_CONF=1800,TRANSFER_LEN_AUX=1
[Thu Jan 16 15:19:09 2020]  (0)[162:hdmi_timer_kthr]before enable DMA register(0x0):
[Thu Jan 16 15:19:09 2020] [I2C]INT_FLAG=0,INT_EN=0,EN=0,RST=0,
[Thu Jan 16 15:19:09 2020] [I2C]STOP=0,FLUSH=0,CON=0,TX_MEM_ADDR=0, RX_MEM_ADDR=0
[Thu Jan 16 15:19:09 2020] [I2C]TX_LEN=0,RX_LEN=0,INT_BUF_SIZE=0,DEBUG_STATUS=0
[Thu Jan 16 15:19:09 2020] [I2C]TX_MEM_ADDR2=0, RX_MEM_ADDR2=0
[Thu Jan 16 15:19:09 2020]  (0)[162:hdmi_timer_kthr]DMA register(0xffffff8004e28480):


When plugging into my astro, I get no such messages. So unless they quieted them (doubtful--the rest of dmesg is as noisy as ever), I suspect that HDMI output on astro may require kernel work that is not yet included in the released builds.


Edit to add: there's also this part in logcat:

10-07 20:40:11.444  1073  1283 I HdmiObserver: HdmiObserver: onUEvent: {SUBSYSTEM=switch, SEQNUM=5460, ACTION=change, SWITCH_NAME=otg_state, DEVPATH=/devices/virtual/switch/otg_state, SWITCH_STATE=1}
10-07 20:40:11.444  1073  1283 I HdmiObserver: HdmiObserver.onUEvent(), name=otg_state, state=1
10-07 20:40:11.444  1073  1283 I HdmiObserver: HDMIObserver.updateOtgState(), otgState=1
10-07 20:40:11.444  1073  1333 I HdmiObserver: HDMIObserver.handleOtgStateChanged(), otgState=1
10-07 20:40:11.445  1073  1333 E hdmi    : =====hdmi===== [HDMI] [hdmi_ioctl] open hdmitx. fd=207 cmd_code=-1073461215
10-07 20:40:11.445  1073  1333 I HdmiObserver: notifyOtgState: true
10-07 20:40:11.458  1073  1424 I UsbDescriptorParser: Unknown Descriptor len: 6 type:0x30

So, if it is indeed the same cable, the missing software could be kernel-side or userspace-side.

Another observation:  if I run "getevent" on the cosmo, when I plug the HDMI adapter in, I see the following from "mtk-kpd":

/dev/input/event1: 0001 00b8 00000001
/dev/input/event1: 0000 0000 00000000
/dev/input/event1: 0001 00b8 00000000
/dev/input/event1: 0000 0000 00000000

meanwhile I get nothing at all while plugging into the astro.

Astro's kernel tree has in drivers/misc/mediatek/typec/fusb302 some hdmi-plugging code that seems similar to what the cosmo had in drivers/misc/mediatek/usb_c/fusb302 , and the device shows up similarly in /sys/devices/platform/fusb301a... 

10

Astro Slide - Android / Re: Rooting the Astro Slide

« on: August 29, 2022, 08:21:59 pm »

To be perfectly clear: I only had to use the name "boot_a" when flashing with the mtkclient.

When using fastboot, I can use the name "boot".

11

Astro Slide - Hardware / Re: Keyboard ghosting

« on: August 26, 2022, 10:44:08 am »

The ghosting patch seems to work! I will try to clean it up and post it on Github this weekend.
Edit: here it is: https://github.com/planet-com/astro-kernel/pull/1

12

Astro Slide - Hardware / Keyboard ghosting

« on: August 25, 2022, 07:52:02 pm »

Alas, it seems that the Astro has the same keyboard ghosting problem that gemini/cosmo suffered from. Not a surprise, but was it too much to hope that Planet would shell out for some diodes in their third iteration?

I will be attempting to port the kernel patch that worked on gemini/cosmo, and will report back here whether it still works.

13

Astro Slide - Hardware / Re: Planet USB-C to HDMI Video Cable

« on: August 25, 2022, 07:45:36 pm »

I tried the PC USB-to-HDMI adapter from my Cosmo, and it doesn't seem to work on the Astro. I noticed that the indiegogo page claimed "USB to DisplayPort"  rather than HDMI, so maybe it'll be a new cable.

14

Astro Slide - Android / Re: Rooting the Astro Slide

« on: August 24, 2022, 09:00:20 pm »

I finally got my hands on a device. I was able to root it using the mtkclient tool here: https://github.com/bkerler/mtkclient with no scatterfile needed.

The only difference from those instructions are the partition names boot_a and vbmeta_a instead of boot and vbmeta. Possibly your patched boot image would work if you only flashed an empty vbmeta image to the vbmeta_a partition.

15

Cosmo Communicator - Hardware / Re: Compiling Cosmo Android kernel

« on: September 12, 2020, 07:26:29 pm »

I have managed to successfully build and flash a working android kernel following instructions on the sticky thread in the Android Forum. Since oesf links seem to often not work lately, here's an archival version:
https://archive.is/RClCX