search

Halium / projectmanagement

143 stars 32 forks source link

[device-port] [klte] Samsung Galaxy S5 #96

Open minlexx opened 6 years ago

minlexx commented 6 years ago

Tree: halium-7.1

WIP

Links:

minlexx commented 6 years ago 
EGL_PLATFORM=hwcomposer test_hwcomposer 
width: 1080 height: 1920
library "/vendor/lib/egl/libGLESv2S3D_adreno.so" not found
OpenGL ES 2.0 (OpenGL ES 3.0 V@140.0 AU@ (GIT@I741a3d36ca))

photo_2018-09-16_02-03-37

minlexx commented 6 years ago

Plasma Mobile rootfs (touch / buttons not working yet):

pm-rootfs-1 pm-rootfs-2

spotlesscoder commented 6 years ago

Is there some way I can assist you here?

minlexx commented 6 years ago

Is there some way I can assist you here?

Dunno, do you have a device and can you build halium base yourself?

spotlesscoder commented 6 years ago

Yes

minlexx commented 6 years ago

@CodingSpiderFox well, you can at lesat try to compile hybris-boot and test with halium reference rootfs (hybris tests). Some people say kernel doesn't boot for them.

Note: my host system is Gentoo, so as official halium docs say to use ubuntu for building - I do everyting from Docker ubuntu 16.04 chroot image suitable for samsung device. Dockerfile, build and run scripts are there as example - https://github.com/minlexx/halium-build-env/ .

P.S. This is a prebuilt hybris-boot image - https://yadi.sk/d/3V48NUb7UYc_eQ (suitable for halium reference rootfs and Plasma Mobile rootfs). Ubports needs different kernel options.

spotlesscoder commented 6 years ago

Thanks, I'll look into it

drebrez commented 6 years ago

I've also got it working :tada:

klte-hwcomposer

but since the new systemd version doesn't want to start automatically with the old kernel version I had to start it manually like this:

  1. After installing the rootfs (halium-rootfs-20170630-151006.tar.gz), the system.img and configured the root password as explained here, before leaving the chroot also create the init_enter_debug file (empty)

  2. After booting the device you will be able to connect with telnet (see http://docs.halium.org/en/latest/porting/debug-build/early-init.html#debugging-via-telnet)

  3. Once connected we have to configure to debug the initramfs script but inside the real rootfs, run these commands on the telnet:

    $ touch /target/init_enter_debug2
$ cp /init /target/init-debug
$ cp /bin/busybox /target/bin/busybox-static
$ echo "continue" >/init-ctl/stdin

    I had to copy the busybox executable because it wasn't present and it's used here

  4. You should now be able to connect again to the device using telnet, but this time using the port 2323

  5. now that we are inside the rootfs I've disabled the networking service in order to keep the connection to the device: 

    $ systemctl disable networking.service
$ systemctl mask networking.service

  6. Starting systemd manually complains that is not able to determine the cgroup, so let's create it:

    mount -t tmpfs tmpfs /sys/fs/cgroup
mkdir /sys/fs/cgroup/systemd
mount -t cgroup cgroup -o none,name=systemd /sys/fs/cgroup/systemd

  7. Start systemd with the following command:

    $ echo "/lib/systemd/systemd --system --crash-reboot=0 --dump-core=0 --show-status=0 --log-target=kmsg --log-level=debug --log-color=1 --log-location=1" >/init-ctl/stdin

  8. Since the networking service is disabled, you should now be able to connect to the device also through ssh with:

    $ ssh root@192.168.2.15

I hope these steps will help you too :wink:

minlexx commented 6 years ago

Interesting detail about networking.service, why? To keep IP address the same as it was for telnet?

What about other hybris tests? lights, vibrator, gps? Did you get Wi-Fi working? lxc container running? Even without lxc you can get wlan0 to appear with cat /proc/deferred_initcalls - it calls all deferred driver initialization functions (normally it is done by android init in lxc). Then run nmtui and go choose Wi-Fi network.

If that goes OK, go try plasma-mobile rootfs. But before booting, (optionally) chroot into it from telnet and disable/mask simplelogin.service. Verify that systemctl start simplelogin sends phone to reboot (probably another systemd crash)

P.S. Picture is different from mine, because much older rootfs? :thinking:

minlexx commented 6 years ago

Problematic code (chase_symlinks() in src/basic/fs-util.c, src/basic/mount-util.c), that prevents systemd from booting on our 3.4 kernel was added in systmd-233. So probably systemd-229 has all chances to boot... But for me it also sent device to reboot by systemctl start simplelogin.service in pm-rootfs.

Meanwhile I got systemd-216 running on edge 18.04 neon rootfs but test_hwcomposer fails with Segmentation fault (core dumped) :disappointed:

minlexx commented 6 years ago

@drebrez also do you have repeated errors in dmesg about vold crashing and restarting all the time? If so you need also this fix to system/vold: vold: do no abort on selinux failure. After that android container is fully running.

drebrez commented 6 years ago

Interesting detail about networking.service, why? To keep IP address the same as it was for telnet?

With the networking.service enabled I've never managed to configure and connect with the other IP, so I decided to bypass the problem instead of spending hours trying to identify the issue.

What about other hybris tests? lights, vibrator, gps? Did you get Wi-Fi working? lxc container running?

I tried all the tests and I got pretty much the same result as in the first post. lxc container running and logcat works. Wifi works without any issue, connected successfully to my network with WPA2 security using nmtui. For EGL_PLATFORM=hwcomposer test_hwcomposer I had to upgrade the system because it was complaining about a missing function in libgui.so, solved with:

echo "deb http://repo.halium.org/caf xenial main" >> /etc/apt/sources.list.d/halium-caf.list
apt-get update
apt-get dist-upgrade

also do you have repeated errors in dmesg about vold crashing and restarting all the time?

I didn't noticed about vold but I had a lot of repeated errors about Service 'adsprpcd' (pid 388) exited with status 255 and restarting the service. Don't even know what that service is

minlexx commented 6 years ago

I was able to execute test_hwcomposer in neon 18.04 rootfs with libandroid-properties1 libhybris libhybris-test libhybris-utils upgraded from caf repository and by modifying LD_LIBRARY_PATH:

export LD_LIBRARY_PATH=/usr/lib/arm-linux-gnueabihf/libhybris-egl
export EGL_PLATFORM=hwcomposer
test_hwcomposer

if libEGL gets loaded from /usr/lib/arm-linux-gnueabihf/libhybris-egl, then it works. logcat, photo

If it loads from /usr/lib/arm-linux-gnueabihf/libEGL.so.1, then it doesn't.

Audio works (paplay /usr/share/sounds/sitter/ohits.ogg)

minlexx commented 6 years ago

@drebrez adsprpcd works in my case, this is probably audio HAL driver... Does it output any errors in dmesg/logcat? Just checked audio works in pm rootfs by paplay /usr/share/sounds/sitter/ohits.ogg

Can you show /system/bin/logcat | grep AudioDaemon ? logcat

Strange that you don't have errors about vold, do you have audit=0 selinux=0 androidboot.selinux=disabled in kernel cmdline, e.g. this commit - https://github.com/minlexx/android_device_samsung_klte-common/commit/b6bb438a361e90270c8648625de5cff0db6a0558 ?

minlexx commented 5 years ago

Since the very beginning I was curious why can't we just write to framebuffer device or read from it as on any usual Linux in guides about framebuffer. (cat /dev/urandom > /dev/fb0 etc) So I wanted to solve this problem.

First step was to change boot logo, and with commit Enable penguin logo on boot I had a nice Linux penguin logo after the Samsung one (and no more that annoying red text saying about modified kernel and warranty bit) - Linux Bootlogo

It turned out that logo is disabled on device tree level ("qcom,mdss-fb-splash-logo-enabled") so I decided to forcefully enable it in source code, and used existing CONFIG_FB_MSM_LOGO for that purpose (both source code, AND device tree are compiled, so I thought no difference at which level to change it - dts file or kernel source directly).

So, thus I proved that framebuffer is working from kernel space, and some example how to work with it is in file drivers/video/msm/mdss/mdss_mdp_splash_logo.c.

Interesting fact, logo image itself is hardcoded in kernel in file drivers/video/msm/mdss/splash.h as an array of BGR data that is written directly into mapped framebuffer memory.

I wrote a small program with Qt, to verify the contents of image (splash.h is directly included in that source): default

minlexx commented 5 years ago

The next step was to be able to draw into framebuffer from a user-space executable.

After reading a source code of framebuffer image displayer program, fbida, especially that file - https://git.kraxel.org/cgit/fbida/tree/fbtools.c , I started to understand what steps are needed to draw something using framebuffer, in two words:

To test framebuffer further, I made a simple program inspired by fbida - https://github.com/minlexx/test_framebuffer . But originally it was failing at step after mmap(), error was EINVAL and it was because memory region size reported in fb_fix_screeninfo was zero, and mmap() cannot map zero-length memory.

After some time digging in mdss_fb kernel code, I found that user's mmap() is handled by mdss_fb_mmap there - mdss_fb.c line 1619 (and in general, all operations on framebuffer device are specified in the same file, a bit below in static struct fb_ops mdss_fb_ops = {...)

I wanted to find out where fb_fix.smem_len is filled, and it was of course in function mdss_fb_register() here, in code block:

    /*
     * Populate smem length here for uspace to get the
     * Framebuffer size when FBIO_FSCREENINFO ioctl is
     * called.
     */
    fix->smem_len = PAGE_ALIGN(fix->line_length * var->yres) * mfd->fb_page;

But after a few lines below, it is zeroed in call to mdss_fb_alloc_fbmem() here. mdss_fb_alloc_fbmem() in turn calls mdss_fb_alloc_fbmem_iommu() , which tries to read memory size from device tree in code block here

of_property_read_u32(pdev->dev.of_node, "qcom,memory-reservation-size", &size);

But it is zero, not specified in DTS. And after that, if device is not in low_power/recovery mode, it just zeroes all memory related fields and returns:

    if ((!boot_mode_lpm) && (!boot_mode_recovery)) { */  /* Normal Booting */
        mfd->fbi->screen_base = NULL;
        mfd->fbi->fix.smem_start = 0;
        mfd->fbi->fix.smem_len = size;
        return 0;
    } else {

That's the problem. Device tree does not have a memory-reservation-size value and that's why we cannot map framebuffer in user space to draw on it.

With commit Always allow to allocate/map framebuffer iommu memory I made the code above go to else branch, where memory size is read from device tree from other tag, qcom,memory-alt-reservation-size, which is specified in DT, and not zero. This way mmap() from userspace does not fail, it maps memory region and you can write pixels!

But you still cannot see anything on the screen.

P.S. For some reason the line below virt = dma_alloc_coherent(&pdev->dev, size, &phys, GFP_KERNEL); fails during the early startup, but later it succeeds (there are several framebuffer registered, and maybe several times, so...) Later, when testing with test program, after boot - it works despite that error message early in dmesg. I don't know why

minlexx commented 5 years ago

Step 3: Additional step needed to display something on Samsung Galaxy S5 screen using framebuffer

First, you need to always activate framebuffer like here, whatever it means: 

fb_var.activate = FB_ACTIVATE_NOW | FB_ACTIVATE_ALL | FB_ACTIVATE_FORCE;
ioctl(fb, FBIOPUT_VSCREENINFO, &fb_var);

Then you need to commit changes using specific ioctl as here. Line where this ioctl is handled. I don't remember (!) how I guessed it, probably just a blind shot, but it worked.

P.S. as @drebrez told, it may be more appropriate to use FBIOPAN_DISPLAY ioctl instead of that MSMFB_DISPLAY_COMMIT, as done in https://github.com/AsteroidOS/msm-fb-refresher/blob/master/refresher.c#L47

With all this, my test program can display Plasma logo: Plasma Logo on framebuffer photo

And its console out output is:

root@klte:/projects/test_framebuffer/build# mount -t devtmpfs none /dev
root@klte:/projects/test_framebuffer/build# ./test_framebuffer 
trying fbdev: /dev/fb0 ...
OK
Fix: id = mdssfb_90000
Fix: smem_start = 00000000, len = 16711680
Fix: type = 0
Fix: visual = 2
Fix: accel = 0
Fix: cap = 0
Fix: pan steps: x, y: 1, 1
Fix: ywrap step: 0
Fix: line_length, bytes: 4352
Var: resolution: 1080 x 1920
Var: virt. resolution: 1080 x 3840
Var: offsets x, y: 0, 0
Var: vmode = 0
Var: bpp = 32
var: RGBA lengths: r, g, b, a: 8, 8, 8, 8
var: RGBA offsets: r, g, b, a: 24, 16, 8, 0
page_mask = 00000FFF
fb_mem_offset = 00000000
Mapped framebuffer mem to B54E6000
activateDisplay OK
Sleeping for 10s...
unmapped framebuffer mem

Testing was done in debug telnet session, no systemd, no lxc, no android running, so it is theoretically possible to run some graphics using framebuffer backend, without GPU (no HW acceleration).

drebrez commented 5 years ago

@minlexx nice investigation :+1:

I can add that the problem about the framebuffer could also be resolved by simply adding androidboot.boot_recovery=1 to the kernel cmdline.

And the failure you get during the early startup about the memory allocation for the framebuffer can be resolved by increasing the contiguous memory area size (I've used 64 instead of 16, maybe works with less) with the kernel config option CONFIG_CMA_SIZE_MBYTES=64

Merith-TK commented 5 years ago

Uh... Is this still alive? Is like to test builds.

bobpoekert commented 5 years ago

I tried installing this on a G900T. when I flash hybris-boot.img I get a boot loop of a black screen with the tux logo on it. when I flash hybris-recovery.img it hangs at the samsung logo bootloader screen. when I flash @minlexx's prebuilt hybris-boot.img I also get a boot loop (though this time with no tux logo).

this is in /proc/kmesg when I boot the prebuilt image:

[ 4.493388] [0: switch_root: 1] Kernel panic - not syncing: Attempted to kill the idle task! or init task [ 4.493506] [0: switch_root: 1] [] (unwind_backtrace+0x0/0xec) from [] (panic+0xe8/0x284) [ 4.493616] [0: switch_root: 1] [] (panic+0xe8/0x284) from [] (do_exit+0x90/0x808) [ 4.493721] [0: switch_root: 1] [] (do_exit+0x90/0x808) from [] (do_group_exit+0x4c/0xb0) [ 4.493826] [0: switch_root: 1] [] (do_group_exit+0x4c/0xb0) from [] (sys_exit_group+0x10/0x18) [ 4.493934] [0: switch_root: 1] [] (sys_exit_group+0x10/0x18) from [] (ret_fast_syscall+0x0/0x30) [ 4.494046]I[2: swapper/2: 0] CPU2: stopping [ 4.494109]I[2: swapper/2: 0] [] (unwind_backtrace+0x0/0xec) from [] (handle_IPI+0x144/0x240) [ 4.494214]I[2: swapper/2: 0] [] (handle_IPI+0x144/0x240) from [] (gic_handle_irq+0xec/0x124) [ 4.494320]I[2: swapper/2: 0] [] (gic_handle_irq+0xec/0x124) from [] (irq_svc+0x40/0x74) [ 4.494423]I[2: swapper/2: 0] Exception stack(0xea48bf28 to 0xea48bf70) [ 4.494527]I[2: swapper/2: 0] bf20: 0b7fa36e 00000000 00001136 00000000 00000000 c310b770 [ 4.494632]I[2: swapper/2: 0] bf40: 00433bea 00000000 8d4fdf3b 83126e97 ea48a000 00000002 00000008 ea48bf70 [ 4.494691]I[2: swapper/2: 0] bf60: c01e8c24 c01890d4 00000013 ffffffff [ 4.494802]I[2: swapper/2: 0] [] (irq_svc+0x40/0x74) from [] (lpm_cpuidle_enter+0x11c/0x138) [ 4.494916]I[2: swapper/2: 0] [] (lpm_cpuidle_enter+0x11c/0x138) from [] (cpuidle_enter_state+0x18/0x60) [ 4.495029]I[2: swapper/2: 0] [] (cpuidle_enter_state+0x18/0x60) from [] (cpuidle_idle_call+0x144/0x324) [ 4.495139]I[2: swapper/2: 0] [] (cpuidle_idle_call+0x144/0x324) from [] (cpu_idle+0x6c/0x100) [ 4.495248]I[2: swapper/2: 0] [] (cpu_idle+0x6c/0x100) from [<00b06254>] (0xb06254) [ 4.495356]I[1: swapper/1: 0] CPU1: stopping [ 4.495517]I[1: swapper/1: 0] [] (unwind_backtrace+0x0/0xec) from [] (handle_IPI+0x144/0x240) [ 4.495729]I[1: swapper/1: 0] [] (handle_IPI+0x144/0x240) from [] (gic_handle_irq+0xec/0x124) [ 4.495842]I[1: swapper/1: 0] [] (gic_handle_irq+0xec/0x124) from [] (irq_svc+0x40/0x74) [ 4.495948]I[1: swapper/1: 0] Exception stack(0xea481f28 to 0xea481f70) [ 4.496056]I[1: swapper/1: 0] 1f20: 0b7fa717 00000000 0000042e 00000000 00000000 c3102770 [ 4.496162]I[1: swapper/1: 0] 1f40: 00105418 00000000 8d4fdf3b 83126e97 ea480000 00000001 00000008 ea481f70 [ 4.496266]I[1: swapper/1: 0] 1f60: c01e8c24 c01890d4 00000013 ffffffff [ 4.496377]I[1: swapper/1: 0] [] (irq_svc+0x40/0x74) from [] (lpm_cpuidle_enter+0x11c/0x138) [ 4.496488]I[1: swapper/1: 0] [] (lpm_cpuidle_enter+0x11c/0x138) from [] (cpuidle_enter_state+0x18/0x60) [ 4.496597]I[1: swapper/1: 0] [] (cpuidle_enter_state+0x18/0x60) from [] (cpuidle_idle_call+0x144/0x324) [ 4.496707]I[1: swapper/1: 0] [] (cpuidle_idle_call+0x144/0x324) from [] (cpu_idle+0x6c/0x100) [ 4.496813]I[1: swapper/1: 0] [] (cpu_idle+0x6c/0x100) from [<00b06254>] (0xb06254) [ 4.496873]I[3: swapper/3: 0] CPU3: stopping [ 4.497002]I[3: swapper/3: 0] [] (unwind_backtrace+0x0/0xec) from [] (handle_IPI+0x144/0x240) [ 4.497116]I[3: swapper/3: 0] [] (handle_IPI+0x144/0x240) from [] (gic_handle_irq+0xec/0x124) [ 4.497228]I[3: swapper/3: 0] [] (gic_handle_irq+0xec/0x124) from [] (__irq_svc+0x40/0x74) [ 4.497333]I[3: swapper/3: 0] Exception stack(0xea495f28 to 0xea495f70) [ 4.497395]I[3: swapper/3: 0] 5f20: 0b7fa5df 00000000 00000460 00000000 00000000 c3114770 [ 4.497504]I[3: swapper/3: 0] 5f40: 00111a0d 00000000 8d4fdf3b 83126e97 ea494000 00000003 00000008 ea495f70 [ 4.497613]I[3: swapper/3: 0] 5f60: c01e8c24 c01890d4 00000013 ffffffff [ 4.497728]I[3: swapper/3: 0] [] (__irq_svc+0x40/0x74) from [] (lpm_cpuidle_enter+0x11c/0x138) [ 4.497842]I[3: swapper/3: 0] [] (lpm_cpuidle_enter+0x11c/0x138) from [] (cpuidle_enter_state+0x18/0x60) [ 4.497951]I[3: swapper/3: 0] [] (cpuidle_enter_state+0x18/0x60) from [] (cpuidle_idle_call+0x144/0x324) [ 4.498059]I[3: swapper/3: 0] [] (cpuidle_idle_call+0x144/0x324) from [] (cpu_idle+0x6c/0x100) [ 4.498165]I[3: swapper/3: 0] [] (cpu_idle+0x6c/0x100) from [<00b06254>] (0xb06254)

minlexx commented 5 years ago

@bobpoekert so you have successguly built hybris-boot and systemimage yourself? Then you don't need old prebuilt...

Which rootfs did you use? Rootfs type and version matters here.

bobpoekert commented 5 years ago

@minlexx the one that's linked to from the halium docs (http://bshah.in/halium/halium-rootfs-20170630-151006.tar.gz). Is there a rootfs that's known to work that I should be using?

knifemeido commented 5 years ago

I would love to help with this project, I followed the documentation and built for my s5, the normal halium-install gave me storage errors, I used the standalone one and it proceeded to entering a unix password. My s5 now says at the corner of my screen "KERNEL IS NOT SEANDROID ENFORCING" and "Set Warranty Bit : kernel ." It boots to the samsung logo and charging logo but bootloops from there. Any help would be appreciated, thanks. I used the halium-rootfs provided by the docs and used both the hybris-image provided here and my built one, none of them worked. No serial output was given.

bobpoekert commented 5 years ago

booting the recovery image with the phone plugged into a raspi (running raspian) I don't see the debug interface (referenced here) showing up in lsusb. @skydoescoding, if you flash the recovery image do you get the same result?

Tofee commented 5 years ago

Problematic code (chase_symlinks() in src/basic/fs-util.c, src/basic/mount-util.c), that prevents systemd from booting on our 3.4 kernel was added in systmd-233. So probably systemd-229 has all chances to boot... But for me it also sent device to reboot by systemctl start simplelogin.service in pm-rootfs.

Meanwhile I got systemd-216 running on edge 18.04 neon rootfs but test_hwcomposer fails with Segmentation fault (core dumped) disappointed

If you're still interested, you can try a rough patch I'm trying on LuneOS: https://github.com/Tofee/meta-webos-ports/commit/da27859c08661183ce84612f18bd93a27ca41eec . Not sure how well it'll work, though.

minlexx commented 5 years ago

If you're still interested, you can try a rough patch I'm trying on LuneOS: Tofee/meta-webos-ports@da27859 . Not sure how well it'll work, though.

@Tofee thanks for the info! I was trying similar things when I was initially investigating boot problems with systemd, I found out that fstat was returning error, traced that down to fs/stat.c in kernel (vfs_stat) and gave up :smile: I decided to refuse from systemd completely for now, and to replace it with openrc. So, now I'm trying postmarketOS rootfs, which already has samsung-klte device packaged thanks to @drebrez 's amazing work. I also got it booting to weston framebuffer GUI as on photo there (but with red screen bug).

I'm afraid that there may be other kernel <=> systemd incompatibilities, even if this particular patch helps, god knows what else will appear. Dunno. But postmarketOS is already booting fine, so I'm now in the process of figuring out how to customize its build system to continue my efforts.

Given that now postmarketOS has libhybris packaged (yay! thanks @NotKit , so many talented people around :heart: ) it may be worth a try to create a working OS with downstream kernel and android blobs in lxc container.

P.S. pmOS samsung-klte weston framebuffer red screen bug:

image

minlexx commented 5 years ago

Also I'm thinking about mainline kernel; I followed this guide - https://forum.xda-developers.com/galaxy-s7/how-to/guide-samsung-galaxy-s7-uart-t3743895 and successfully crafted USB-UART adapter:

image

The guide for S7 worked almost 100% accurately, except that I used CP2102 instead of FT232 and MUIC driver is located in S5 kernel in other place than in S7:

drivers/misc/max77804k-muic.c:103: ADC_JIG_UART_ON = 0x1d, /* 0x11101 619K ohm */
drivers/misc/max77804k-muic.c:104: ADC_CARDOCK = 0x1d, /* 0x11101 619K ohm */

So I can confirm that resistance value should also be 619k ohm.

And lineageOS's BOARD_KERNEL_CMDLINE should be modified from console=null to console=ttyHSL0 in device/samsung/klte-common/BoardConfigCommon.mk to see bootloader and kernel startup output.

Maybe some day we can run systemd succesfully on 5.x kernel :wink:

Merith-TK commented 5 years ago

Guess I shall try postmarket today... I mean. If I only use basic services, I should be good to go...

Are all of these TWRP compatible?

On Wed, Mar 6, 2019, 2:46 PM Alexey Min notifications@github.com wrote:

Also I'm thinking about mainline kernel; I followed this guide - https://forum.xda-developers.com/galaxy-s7/how-to/guide-samsung-galaxy-s7-uart-t3743895 and successfully crafted USB-UART adapter:

[image: image] https://user-images.githubusercontent.com/13084776/53918886-5dc62d00-4079-11e9-9df6-1310f9105ef7.png

The guide for S7 worked almost 100% accurately, except that I used CP2102 instead of FT232 and MUIC driver is located in S5 kernel in other place than in S7:

drivers/misc/max77804k-muic.c:103: ADC_JIG_UART_ON = 0x1d, / 0x11101 619K ohm /

drivers/misc/max77804k-muic.c:104: ADC_CARDOCK = 0x1d, / 0x11101 619K ohm /

So I can confirm that resistance value should also be 619k ohm.

And lineageOS's BOARD_KERNEL_CMDLINE should be modified from console=null to console=ttyHSL0 in device/samsung/klte-common/BoardConfigCommon.mk to see bootloader and kernel startup output.

Maybe some day we can run systemd succesfully on 5.x kernel 😉

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Halium/projectmanagement/issues/96#issuecomment-470308191, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ8HXjsKfisJP7iEQmCp4ZHHVF5KR9nyks5vUEVIgaJpZM4WQ_8K .

Merith-TK commented 5 years ago

So... Postmarket have moved their repo to gitlab

minlexx commented 5 years ago

Guess I shall try postmarket today... I mean. If I only use basic services, I should be good to go... Are all of these TWRP compatible?

What do you mean? TWRP is not needed to flash pmOS, just put device in download mode before pmbootstrap flasher flash_kernel and pmbootstrap flasher flash_rootfs.

Merith-TK commented 5 years ago

Will it mess with TWRP is specifically what I was asking,

On Wed, Mar 6, 2019, 3:29 PM Alexey Min notifications@github.com wrote:

Guess I shall try postmarket today... I mean. If I only use basic services, I should be good to go... Are all of these TWRP compatible?

What do you mean? TWRP is not needed to flash pmOS, just put device in download mode before pmbootstrap flasher flash_kernel and pmbootstrap flasher flash_rootfs.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Halium/projectmanagement/issues/96#issuecomment-470319389, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ8HXvSispQcZJZuK91UGspQTFDSPCjBks5vUE9ggaJpZM4WQ_8K .

minlexx commented 5 years ago

No, why would it touch recovery? It will only overwrite /system partition.

Merith-TK commented 5 years ago

I was worried it would install its own. Because I like keeping my backups.

On Wed, Mar 6, 2019, 3:56 PM Alexey Min notifications@github.com wrote:

No, why would it touch recovery? It will only overwrite /system partition.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Halium/projectmanagement/issues/96#issuecomment-470325506, or mute the thread https://github.com/notifications/unsubscribe-auth/AJ8HXsEitLNvIKDC3vaavUW0RxZXgf5Eks5vUFW3gaJpZM4WQ_8K .

Tofee commented 5 years ago

@minlexx That was probably my last patch to support kernels that old; I would prefer spending time on making hammerhead mainline work, instead of keeping a 3.4 kernel on life support.

Herrie82 commented 5 years ago

@minlexx We found a simple kernel patch that did the trick too: https://github.com/Herrie82/android_kernel_lge_hammerhead/commit/b5e4c523b4fa9c54ef43fa34d07f282258138c3b

drebrez commented 5 years ago

@minlexx for mainline kernel I suggest you start from this branch https://gitlab.com/postmarketOS/linux-postmarketos/tree/qcom which, if you look at the last commits, it already has working regulators, gpio-keys, sd-card and USB. Feel free to take my patches and upstream them (initial dts file for S5: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/qcom-msm8974-samsung-klte.dts)

minlexx commented 5 years ago

@minlexx We found a simple kernel patch that did the trick too: Herrie82/android_kernel_lge_hammerhead@b5e4c52

You are replacing fget to fget_raw, but samsung_msm8974 kernel source already has fget_light, so I probably should try to replace fget_light to fget_raw_light, as was done originally in https://github.com/torvalds/linux/commit/55815f70147dcfa3ead5738fd56d3574e2e3c1c2 ? Should it help? And more interestingly, will it break anything .. :thinking:

Herrie82 commented 5 years ago

@minlexx Yes we've seen some variants too. It was more that fstat was broken and needed fixing. This will do for the required purposes. We don't care much about the performance of this particular operation. That's what the newer iteration with fget_light achieves. Anyway it might be worth to try. We prefer to go mainline at some point, but for now it at least keeps our 3.4 based targets alive.

Kaffeine commented 5 years ago

@minlexx We found a simple kernel patch that did the trick too: Herrie82/android_kernel_lge_hammerhead@b5e4c52

You are replacing fget to fget_raw, but samsung_msm8974 kernel source already has fget_light, so I probably should try to replace fget_light to fget_raw_light, as was done originally in torvalds/linux@55815f7 ? Should it help? And more interestingly, will it break anything .. thinking

Sounds interesting not in terms of optimization, but in terms of less deviation from the upstream. IIUC any kind of _raw will do the trick.

minlexx commented 5 years ago

Audio and sensors marked as working.

Also nasty infinite recursion bug in kernel was fixed after my complaints in https://github.com/LineageOS/android_kernel_samsung_msm8974/commit/64a824fabec531f414a92241882668feef10aeb1 (see also https://gitlab.com/postmarketOS/pmaports/issues/274#note_179827141 ). If that was the problem for running elogind, maybe that was also the problem for systemd, too. But I haven't cehcked yet, so far I'm happy enough with openrc.

AndroidDeals commented 4 years ago

so how can we have the flashable zips? I made it several times but failed.

minlexx commented 4 years ago

Wait for pmaports!1572 to be merged and you can try to use klte on postmarketOS with the mainline kernel without any Android/Halium parts (see screens here )

There is only one serious issue with it..

AndroidDeals commented 4 years ago

Thank you, but I still have the interest in utouch. Do you know why it prompts no such file or directory when I breakfast halium boot and system image

AndroidDeals commented 4 years ago

Wait for pmaports!1572 to be merged and you can try to use klte on postmarketOS with the mainline kernel without any Android/Halium parts (see screens here )

There is only one serious issue with it..

Thank you, but I still have the interest in utouch. Do you know why it prompts no such file or directory when I breakfast halium boot and system image

minlexx commented 4 years ago

No idea

Pretuer commented 3 years ago

Is this project still up?

leviesper commented 3 years ago

what is the progress on this? how can i test it out for my device?