Device htc vision

Hi,

This is a merge request to add support for the HTC Desire Z, aka HTC G2, aka HTC Vision. It's based on the device-htc-vision branch that cmdrwgls created around a year ago. I've added the following changes:

• make pmbootstrap kconfig check pass
• enable CONFIG_MSM_KSGL
• enable compilation with GCC 8
• add deviceinfo_flash_offset_base to deviceinfo as apparently that is required for HTC devices (#145 (closed))

Unfortunately it still won't boot. When I try (pmbootstap flasher boot), the device simply gets stuck displaying a green htc logo on a white background. I've tried the maximum-attention initramfs hook, but without success, it doesn't even seem to get that far. One possible person to contact might be milaq since he is providing current LineageOS builds for this device and is apparently able to produce a working kernel image from that source tree. And if anybody has an idea about how to make this thing boot I'm all ears! Or if you can give some hint on how to troubleshoot this, I'd also be very interested. Note that I've also tried building this tree with GCC 6 and ended up with the exact same result.

//EDIT: I managed to get the device to boot, this should now be ready to merge.

changed the description

By Matthias Berndt on 2019-01-05T01:01:27

added 1 commit

• bd328d7b - htc-vision: add postmarketos-base dependency to make CI pass

Compare with previous version

By Matthias Berndt on 2019-01-05T01:48:24

Have you ever tried to start a known working kernel with fastboot boot?
What about if you flash it into the device?

PS: added WIP to the title because it's not booting

By Daniele Debernardi on 2019-01-05T01:58:01

marked as a Work In Progress

By Daniele Debernardi on 2019-01-05T01:57:26

added 1 commit

• d3867d6f - htc-vision: change arch to armhf in device-htc-vision/APKBUILD

Compare with previous version

By Matthias Berndt on 2019-01-05T02:03:41

added 1 commit

• c1303402 - htc-vision: add !archcheck in device-htc-vision/APKBUILD

Compare with previous version

By Matthias Berndt on 2019-01-05T02:07:06

Hey @drebrez,

I can launch e. g. TWRP recovery through fastboot boot, so yeah, starting kernels does work. Flashing the kernel I built (using pmbootstrap flasher flash_kernel) leads to the exact same result as launching it through pmbootstrap flasher boot.

By Matthias Berndt on 2019-01-05T11:52:12

I've tried extracting the kernel zImage from a known-working ROM (https://milaq.net/downloads/android/vision/cm-11.0/lineage-11-20190101-NIGHTLY-MLQ-vision.zip) and booting it with the postmarketOS initramfs. This causes the screen to go black after a few seconds, unlike my own kernel images, where it would display the htc logo indefinitely. However the maximum-attention hook still won't do anything, so I'm not sure what to make of this.

By Matthias Berndt on 2019-01-05T13:45:39

EDIT: I was wrong with this, see below.

I fear that I have bad news for you. This reminded me a lot of the HTC wildfire port thread, in which the author feinerer figured out that postmarketOS won't boot on the device because it does not have an FPU. Reading it again, I found:

but pmbootstrap flasher boot shows after upload only a HTC Logo.

further down in the thread:

I think I have found out why the device does not (and cannot) boot:

The architecture armhf in pmOS is ARMv6 but has a strict requirement on an FPU (i.e., requires VFP). However, as it appears, the HTC Wildfire (with its MSM7225 SoC) does not have an FPU despite having an ARM11 (= ARMv6) processor.

So it looks like due to the lack of a matching architecture (in Alpine and pmOS) this device cannot be supported.

The HTC Desire Z has the similar MSM7230 SoC (gsmarena). To be honest, I don't know where one would look up if the FPU is present in that SoC or not, bot judging from the similar SoC name and the symptoms, it seems that your device does not have a FPU either, and therefore won't boot.

It's sad, because that little keyboard device looks really cool, and it would have made a good candidate for postmarketOS.

If you would like to put a lot of effort into this, you could compile Alpine for armv6 without FPU (at least the needed packages), then add this architecture to pmbootstrap as described here and then finally boot postmarketOS on your device. But I'm sure that Alpine wouldn't have a use for such an architecture, so you/we would need to maintain this port of Alpine on our own, and all in all it does not really seem feasible at this point, beyond a proof of concept for yourself.

Can somebody find a source stating that the SoC has no FPU? Then we could add this to the wiki page at least.

Thanks for all the effort you have put into this @mberndt!

By Oliver Smith on 2019-01-07T07:52:43

mentioned in commit wiki@909d29a0

By postmarketOS Wiki bot on 2019-01-06T11:42:40

@ollieparanoid: The device does have an FP unit. This wiki page links to this page where it says that hardware fp support is known as vfp on ARMv7 devices. So I checked:

shell@vision:/ $ cat /proc/cpuinfo
Processor       : ARMv7 Processor rev 1 (v7l)
BogoMIPS        : 163.57
Features        : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls 
CPU implementer : 0x51
CPU architecture: 7
CPU variant     : 0x1
CPU part        : 0x00f
CPU revision    : 1

Hardware        : vision
Revision        : 0080
EngineerID      : 0004
Serial          : 0000000000000000

So that doesn't seem to be the problem.

By Matthias Berndt on 2019-01-06T12:48:34

Ok, I'd like to summarize here what I've learned over the course of the last day or so, just so it's recorded somewhere – maybe it'll help somebody to get this guy running.

The first is that milaq's kernel source tree is very probably capable of producing a working kernel image. I know this because the LineageOS ROM that I linked to earlier is able to boot and contains an About screen that tells me the git sha of the kernel that is being used, and it matches the HEAD of milaq's htc-vision kernel git repo. Unfortunately milaq didn't respond to my email regarding this.

The second is that the kernel image contained in the LineageOS boot.img is able to run postmarketOS binaries. I checked this by modifying a postmarketOS initramfs (gunzip and un-cpio the initramfs, edit the init script and remove everything not strictly necessary to mount /sys, add a line to trigger the vibrator (echo 10000 > /sys/class/timed_output/vibrator/enable), cpio (with -c flag), gzip, build a boot.img with abootimg) and booting it with the LineageOS kernel image and lo and behold, it vibrated. Sadly it doesn't do that with the kernel image that I built.

The third is that a boot.img built from the LineageOS kernel image and the unmodified postmarketOS initramfs with the maximum-attention hook will not make the device vibrate or blink. What this tells me is that the maximum-attention hook is not run at the earliest time where that would be possible, which makes it less useful than it could be – after all, everything that is done before that hook is run is just one more thing that can go wrong and potentially prevent the hook from running.

Unfortunately, I haven't made any progress producing a working kernel image, and I have no more ideas on how to proceed, so I'm giving up for now. I suggest you merge my work into a feature branch in case somebody else wants to pick it up – it is a bit more up to date, compiles with gcc8 and the deviceinfo is more correct (e. g. it will now produce a boot.img).

By Matthias Berndt on 2019-01-06T19:30:22

Have you tried booting the kernel when compiled with gcc 6?

By Luca Weiss on 2019-01-06T21:56:02

@mberndt about executing the maximum-attention hook earlier, this can be the solution => pmbootstrap#1607 (closed)

By Daniele Debernardi on 2019-01-06T22:31:17

@z3ntu yes, that doesn't work.

By Matthias Berndt on 2019-01-06T22:58:14

The device does have an FP unit. This wiki page links to this page where it says that hardware fp support is known as vfp on ARMv7 devices.

Are you sure? This is not my field of expertise, but feinerer mentioned that the SoC, not the CPU, is lacking the FPU support. It would explain the symptoms you have described, too. I'll ask him via e-mail for clarification.

There's also a way of testing this theory: can you boot TWRP or Android, copy over the busybox-static armhf binary from Alpine and execute it on the device?

By Oliver Smith on 2019-01-07T07:00:00

@ollieparanoid, yes, I'm sure. /proc/cpuinfo doesn't lie and I have already run postmarketOS binaries with the LineageOS kernel for that device (as I mentioned earlier).

By Matthias Berndt on 2019-01-07T07:47:13

I see, sorry for the confusion.

By Oliver Smith on 2019-01-07T07:52:14

The third is that a boot.img built from the LineageOS kernel image and the unmodified postmarketOS initramfs with the maximum-attention hook will not make the device vibrate or blink. What this tells me is that the maximum-attention hook is not run at the earliest time where that would be possible, which makes it less useful than it could be – after all, everything that is done before that hook is run is just one more thing that can go wrong and potentially prevent the hook from running.

FWIW, one can easily change the init script linked below. Just change the file, and run pmbootstrap checksum postmarketos-mkinitfs, pmbootstrap build --arch=armhf --force postmarketos-mkinitfs, then pmbootstrap zap and when you do another pmbootstrap install, your version should be used (you can check this by entering the rootfs chroot with pmbootstrap chroot -r and reading the file with cat). You could move the hooks to the very top, or directly hardcode the code from the maximum-attention hook at the top.

https://gitlab.postmarketos.org/postmarketos/pmaports/blob/ffa2dad8ca790ee0f9fec0b1e3055ff7982cccd6/main/postmarketos-mkinitfs/init.sh.in#L21-24

Unfortunately, I haven't made any progress producing a working kernel image, and I have no more ideas on how to proceed, so I'm giving up for now. I suggest you merge my work into a feature branch in case somebody else wants to pick it up – it is a bit more up to date, compiles with gcc8 and the deviceinfo is more correct (e. g. it will now produce a boot.img).

We do have at least one kernel that boots when compiled with GCC-6, but not with GCC-8. Since this is an older device, I'm wondering if it would boot if we compiled the kernel with GCC-4.

By Oliver Smith on 2019-01-08T09:17:43

Not to disparage other people work, but for as much as that seems actually the most updated kernel for the device... the "platform" as a whole might have advanced quite further

https://github.com/OpenDesireProject/android_kernel_htc_msm7x30

https://github.com/shugaoye/android_kernel_htc_qsd8k/branches/all

https://github.com/rqmok/android_kernel_htc_msm7x30

By mirh on 2019-01-10T01:34:37

Hey @mirh, I've tried compiling the first of the source trees you've linked to and it also failed to produce a working kernel image. That's pretty much what I expected. As I said earlier, other people (milaq, flinny) managed to produce working Android kernels from the source tree I was using, meaning that apparently I'm building it wrong, and using a different source tree won't fix that.

We could try building it with gcc 4, but as far as I'm aware that compiler isn't packaged for postmarketOS and I don't want to spend time on packaging something as outdated as that, especially since I don't even know if that really is the issue here. At this point the only way I can get something to work here is if I get a hint from somebody – milaq, flinny or somebody else who's successfully built kernels for that device before or knows how to debug this sort of thing.

By Matthias Berndt on 2019-01-10T23:59:20

@mberndt what about compiling it without pmbootstrap at least to see if it boots correctly. You can probably easily find some docker image with the arm cross compiler and gcc4.

Edit: maybe this one? https://github.com/dockcross/dockcross/blob/master/linux-armv6/Dockerfile
line 30:

We are also using the 4.7 version of the toolchain, so that glibc=2.13

By Daniele Debernardi on 2019-01-11T01:31:44

I've now compiled a toolchain based on gcc-4.8.5 with crosstool-ng, that is the oldest supported version. I then compiled a kernel using this toolchain and it still wouldn't boot.

By Matthias Berndt on 2019-01-13T03:03:08

I've produced a kernel that boots by using my crosstool-ng-built compiler and the exact configuration that milaq's LineageOS kernel uses (copied from /proc/config.gz). I had previously adjusted the settings to adhere to postmarketOS's requirements (SysV IPC etc.) and apparently broke something in the process. So that's at least a starting point…

I'll work incrementally from here and try switching to a new compiler and enabling the options required by postmarketOS.

By Matthias Berndt on 2019-01-13T03:43:49

I've tried compiling the same kernel (with the with 02_gpu-msm-fix-gcc5-compile patch and the compiler-gcc.h file from downstreamkernel_prepare) with a gcc 5.4 toolchain and that didn't boot, so I'll stick with gcc-4.8.5 for now.

Also, I get an unbootable kernel when setting CONFIG_VT, so for now I'll leave that disabled – I hope it's not critical. The other options required for a postmarketOS kernel (disable CONFIG_ANDROID_PARANOID_NETWORK, enable CONFIG_DEVTMPFS, enable CONFIG_SYSVIPC) seem to be OK.

By Matthias Berndt on 2019-01-13T17:30:37

OK, I've tried combining my self-built kernel image with the postmarketOS initramfs and the maximum-attention hook and it works. The flashlight flashes, the hardware buttons light up, the LED on the front blinks and the phone vibrates. I've also tried installing the postmarketOS Android recovery zip, but that doesn't work yet, the display stays dark. Maybe I can get the debug-shell to work…

By Matthias Berndt on 2019-01-13T18:15:29

OK, I got the initramfs debug-shell working. I only had to add the same initramfs hook as for the HTC bravo and the USB networking stuff started working.

By Matthias Berndt on 2019-01-13T18:55:58

I copied over the VT-related configuration from the htc bravo and now the kernel boots with CONFIG_VT enabled and the display briefly flashes during boot. Getting closer and closer…

By Matthias Berndt on 2019-01-13T19:25:46

added 3 commits

• 7f5ba702 - add initramfs hook for USB networking
• a2007ea6 - remove CONFIG_VT as it results in an unbootable kernel
• ebd56c0f - re-enable CONFIG_VT, kinda sorta working this time

Compare with previous version

By Matthias Berndt on 2019-01-13T19:23:06

This is amazing, happy to read that you made so much progress \o/

I copied over the VT-related configuration from the htc bravo and now the kernel boots with CONFIG_VT enabled and the display briefly flashes during boot. Getting closer and closer…

Just to make sure, you have used something like make menuconfig and not edited the kernel configs by hand, right? Because when editing the files directly, it won't check/update dependencies when you change kernel config options.

For future reference, here's the latest GCC 4.x (4.9.2) packaged for Alpine, we can build a "gcc4" package for postmarketOS based on that. We could also use that specific 4.8.5 version if needed.

By Oliver Smith on 2019-01-14T08:09:58

Hey @ollieparanoid,

Just to make sure, you have used something like make menuconfig and not edited the kernel configs by hand, right?

Nah, Real Programmers use .

For future reference, here's the latest GCC 4.x (4.9.2) packaged for Alpine, we can build a "gcc4" package for postmarketOS based on that. We could also use that specific 4.8.5 version if needed.

Well, I haven't tried building the kernel with GCC 4.9, only with 4.8 (works) and 5.4 (doesn't). I'm building a gcc-4.9-based toolchain now and I'll let you know if that is capable of producing kernels that boot. It would be nice to get something more recent to boot on these guys, for instance the AOSP 3.18 kernel still includes support for the msm7x30 SoC. But I have no idea what else is needed for the device to boot, and debugging that sort of thing is likely to be a nightmare without some sort of serial console. So that's unlikely to ever happen…

By Matthias Berndt on 2019-01-14T18:10:01

I've now built a kernel with gcc 4.9.4, so now somebody will have to package that for postmarketOS for this MR to proceed.

By Matthias Berndt on 2019-01-14T19:55:51

Would #168 (closed) help?

By Grant Miller on 2019-01-14T20:15:21

Got the splash screen to work (needed msm-fb-refresh).

By Matthias Berndt on 2019-01-14T20:58:22

@GrantM11235 I tried building the kernel with that patch, but unfortunately that also didn't result in a bootable kernel image.

The question is: which part of the code do newer gcc releases miscompile? If we know, maybe we can fix it. I have a crazy idea: we could do a kind of binary search by compiling one half of the kernel source files with gcc 6 and the other half with gcc 4.9.4 and then linking it all together – I think the object files are supposed to be compatible. If that results in a working kernel, we know the error must be in the part of the code compiled with gcc 4.9.4, otherwise we know it must be in the other half.

The best way to implement that is probably to write a gcc wrapper that will look at its command line parameters (i. e. the files that need to be compiled) and then delegate to either gcc-4.9.4 or gcc-6. That way one doesn't need to change the kernel build system and it would be re-usable for different kernel trees.

By Matthias Berndt on 2019-01-14T22:09:00

That seems to be an insane effort for a downstream kernel, which we would ideally replace with mainline anyway - but I love that kind of crazy ideas

Regarding gcc4 packaging for postmarketOS, it should work roughly like this:

• copy main/gcc6 to main/gcc4
• change the pkgver, pkgrel=0, use the patches from Alpine's gcc4
• try to compile that
• if necessary, adjust the build instructions in the APKBUILD to match more what Alpine's gcc4 aport does
• make sure the new gcc4 builds for x86_64
• make sure you can compile simple x86_64 C programs with it (hello world)
• add gcc4 here in the pmbootstrap code
• pmbootstrap aportgen gcc4-armhf
• pmbootstrap build gcc4-armhf
• now try to use it in the linux APKBUILD
• see if your device boots with it

By Oliver Smith on 2019-01-17T08:21:16

*remembers why he had suggested "middle-of-the-road downstream landing kernels" to be shared by devices on first build/port attempt*

Anyway, the "linking mix" idea seems good (it was also used by some read hat guy, and for as much as crazy it sounds better than bisecting the ~7k commits between gcc 4.9.2 and 5.1, then rebuilding the whole kernel again, then trying to come up with an explanation)

Problem is: ABI also supposedly changed there. So there's that adding further spice into the issue.

on the other hand that seems like the kind of change that could be responsible for "magically disrupting" code

By mirh on 2019-01-17T18:00:31

If you can figure out a franken-kernel technique, it would also be useful for all the gcc6 kernels (#146 (closed))

By Grant Miller on 2019-01-17T18:08:23

Hey everybody,

@mirh, I didn't read the GCC 5 changelog in its entirety, but I think the ABI changes only affect C++, not C code, so I hope that it won't be an issue. We'll see.

But for now, I'd rather focus on actually getting the device to boot. It does run the initramfs and the telnet debug shell, but it doesn't boot correctly after that, and I'd like to get that to work before tackling the kernel/gcc problem.

By Matthias Berndt on 2019-01-17T18:21:06

mentioned in issue #171 (closed)

By Oliver Smith on 2019-01-18T08:42:10

Hm, I somehow got the device to boot. However I don't really know what I did differently. pmos_continue_boot has failed multiple times before, but today it somehow worked… Well, for a while. Then the screen turned completely red.

By Matthias Berndt on 2019-01-19T23:08:14

The touchscreen doesn't work yet, and I'm not sure, is it supposed to look so pink-ish? I suspect it's not working quite right just yet . It also has the problem that a lot of commands in the shell just hang indefinitely, e. g. sudo -s or ifconfig.

By Matthias Berndt on 2019-01-19T23:10:35

Oh, apparently to get the GUI working I need to mount /sysroot in read/write mode in the initramfs.

By Matthias Berndt on 2019-01-19T23:20:52

Got the touchscreen to work, just needed an udev rule :-)

By Matthias Berndt on 2021-08-13T10:28:13

Well, for a while. Then the screen turned completely red.

That is the black "lockscreen" of weston. tap the screen to unlock :)

Regarding the colors, see: https://wiki.postmarketos.org/wiki/Troubleshooting:display#My_screen_is_red.21

By Oliver Smith on 2019-01-20T00:30:57

Yes, now that the touch screen works I was able to figure that out :-). Somebody else pointed out that wiki page to me earlier and I'm trying to fix the “red display” thing right now, but so far it's not working. Unfortunately my kernel tree is quite different from those mentioned on that wiki page, so making the required change is not trivial.

If I enable CONFIG_FB_MSM_DEFAULT_DEPTH_ARGB8888=y in the kernel configuration, the graphics output isn't so red, but the postmarketOS logo is suddenly blue. Go figure…

By Matthias Berndt on 2019-01-20T01:06:37

I also found this kernel tree:

https://github.com/msm7x30/android_kernel_qcom_msm7x30

I wonder where it came from. Maybe I can get it to boot on the device. It is the correct SoC and it's based on a much newer kernel than the one I've been using so far.

By Matthias Berndt on 2019-01-20T01:09:13

I've set the default framebuffer colour depth to 16 bits per pixel and that fixes the red screen issue. Not an ideal solution, but hey, better than nothing! The HTC Ace seems to suffer from the same problem actually, 16 bits per pixel is enabled with an initramfs hook there.

By Matthias Berndt on 2021-08-13T10:24:55

@ollieparanoid, I'm having a strange problem, maybe you have an idea. The /etc/init.d/root script, which is supposed to remount / in read-write mode during boot, doesn't appear to work. /etc/fstab contains these lines

LABEL=pmOS_root                /       ext4    relatime,data=ordered   0       1
LABEL=pmOS_boot                /boot   auto    defaults                0       2

but mount seems to have a problem finding the partitions, both by LABEL and by UUID. Using the actual device files like this seems to work:

/dev/dm-1               /       ext4    relatime,data=ordered   0       1
/dev/dm-0               /boot   auto    defaults                0       2

Any ideas on how to fix this?

By Matthias Berndt on 2019-01-20T02:47:43

I would try to figure out, which labels can be detected at this point, and try to get the kernel/mount to detect all of them. Maybe you can write an initfs hook that triggers the kernel to read the partition labels again, and then detects them properly or something along the lines of that. (try partprobe?)

By Oliver Smith on 2019-01-20T03:10:19