Pmbootstrap: Tracking thread for compiling a working kernel for Samsung S7562

[cmdr2]

Hi,

Device: Samsung S7562 (suspected to be kyleopen)

First off, I apologize for filing an issue for this, since this isn't a problem with pmbootstrap. We can resolve this now and continue commenting, since I couldn't find a better way to publicly track progress on my phone's kernel compilation, which also supported comments. This issue is primarily for my own tracking in the open, and if anybody wants to comment. A wiki is sub-optimal for commenting, IMHO.

Problem:

My own kernel compiled for pmOS fails to boot - the Samsung logo is displayed, but no USB device is detected on my host OS.

Current state:

At the moment, pmOS boots up fine (without graphics though) using:
a) (attached) the factory pre-built kernel that it shipped with (extracted using dd and from unpacking the boot.img)
b) (attached) the kernels in 'boot.img' and 'boot.img-kyleV5' from the ROMS I found from XDA

It does not boot up from:
a) (attached) the kernel vmlinuz I've compiled using this, or this, or this
b) (attached) the kernel in the TWRP recovery for my phone. Interestingly, the TWRP recovery on the whole boots okay, but if I take its kernel and combine with pmOS initramfs, then it doesn't boot. Note: The TWRP pre-built kernel's uname -a indicates it is using KlinkOnE's kernel.

Here is the factory boot.img (4M zipped, 12.6M unzipped)

Sane things I've tried:

Initially, I chose to use this kernel source, with the kyle02_defconfig, since it says it is for S7562 (my phone), but that resulted in failure to boot.

extract-dtb says no dtbs were found in the factory zImage.

I also tried to rule out the compiled kernel size being an issue:

• [works] the factory kernel size (zImage) is 4118048 bytes
• [works] the XDA-built kernel size (zImage) is 4132656 bytes. this is larger than the original, but still works
• [fails] the compiled kernel size (vmlinuz) is 4121608 bytes. this is using the real lzop program (I compiled and installed that into chroot_native), to allow high (-9) compression.

Next, I tried the defconfig from /proc/config.gz in a running pmOS using the factory kernel, but the compiled kernel didn't boot. Then I tried the kernel source that the XDA link above claims to use to build those working kernel binaries, along with the defconfig, but that didn't work either. Then I tried KlinkOnE's fork of that github repo, since the TWRP image was apparently built using that, but that didn't work either.

Slightly desperate things I've tried:

I then tried enabling the kernel config related to ROM_CONSOLE and APANIC, in the hope that it would write some kernel panic or /proc/last_kmsg file, but I didn't find any such log when I booted subsequently using a working (pre-built) kernel.

Also, since ssh into pmOS using the factory kernel throws a PTY allocation request failed on channel 0 \n -ash: a: unknown operand error, I assume the factory kernel wasn't compiled with CONFIG_DEVTMPFS=y (as per Troubleshooting:kernel). So I tried compiling mine without that flag too, but that didn't boot either.

BTW, I noticed that when I compiled the kernel using LZMA compression config (I had added xz to the makedepends=), the phone would restart immediately after the Samsung logo, then restart again and so on. Using LZO (using either busybox's with a -6 patch, or by using the real lzop with -9) would hang at the Samsung logo and not show up as a USB device. The working factory or XDA kernels are LZO compressed (as per file after searching for the LZO magic and extracting the vmlinux using a hex-editor). Being a self-extracting kernel, I'd have thought the compression format wouldn't matter to the bootloader?

Another curious thing was that if I either randomly corrupted the zImage (using a hexeditor), or zeroed out the entire kernel image using dd if=/dev/zero, i.e. zImage was entirely zero (with the same file size), the phone would still get stuck at the Samsung logo and not proceed. So it is hard to tell why the phone restarts when there is an LZMA kernel, but doesn't when there's an obviously corrupt or zero kernel.

To take things further, I modified the main entry point of the kernel (start_kernel() in init/main.c) and added emergency_restart(); as the first line). That didn't cause the phone to restart either, but I'm skeptical anyway whether the emergency_restart() function can work before the kernel has called any of its initialization functions in start_kernel().

Next steps:

So at the moment, I see two options ahead - a) continue trying new variants of kernel source+defconfig, b) try to hook up a UART hardware setup to see if there are kernel error logs. I'm not sure whether my Samsung phone emits logs over UART by default, and what I'd need to do to coax it to do so. I have zero knowledge of UART, and it seems like this is one guide to do so.

Cheers

~cmdr2

[Decatf]

What about the compiler toolchain. Try the same (same version at least) as the factory kernel. I know postmarketOS uses its own bleeding edge one but you can cross compile a kernel the android way and then package the binary in your linux-$vendor_$device. In the experience with my device the gcc 4.6 compiler from AOSP is a safe fallback to rule out bugs due to compiler voodoo.

[cmdr2]

Good point, the version used while compiling for pmOS was armv6-alpine-linux-muslgnueabihf-gcc (Alpine 6.4.0) 6.4.0, while the factory kernel is gcc 4.4.3 (according to dmesg). I'll try this and report back, thanks!

[ollieparanoid]

Thanks for posting in such detail what you have done already, this is great for progressing futher. Here are some more ideas:

• Maybe the codename is visible on "odin mode"?

• Take one of the two working kernels (TWRP/XDA), get the build date of the kernel (uname -v), find the closes commit in the repo you think it used and compile that along with the config extracted from /proc/config.gz. Build it without changing anything in the config (not even DEVTMPFS or the compression).

• If that kernel does not boot, maybe binary diffing the kernel (extracted and also the beginnings of the compressed versions) will get you further. There is diffoscope, but it is not optimized for diffing kernels at all (on another note, it would be nice if we could extend diffoscope to be more useful for kernel diffing.)

• If you go down the serial path, it would be nice if you could extend the wiki with links you found and your new knowledge on that topic (especially from the point of view of someone who never did this before)

I find it impressive how much you have tried already and wish you best of luck, that you get it working now. You really deserve it. If it still does not work, we're here for further brainstorming.

[ollieparanoid]

Helpful comment from @br0ke in https://github.com/postmarketOS/pmbootstrap/issues/318#issuecomment-320175904:

GT-7568 is another model number for the same device (looks same to me) which does have the kernel source on Samsung's Open Source website.

[cmdr2]

Thanks, will try it out! There are some differences (one has FM radio, camera LED flash, dual SIM, is a bit thicker etc), but definitely worth a shot! :) I look forward to getting back to porting in the next week. These steps for a CM build of S7562 also contain a few more leads to pursue.

[mirh]

Uhm... Can be closed with #1361?

[cmdr2]

Yeah, this is great!