Hello dev community
I am currently trying to build my own kernel / zImage, but for some reason it doesn't work, when I flash my zImage the SGS2 crashs at the bootscreen with the yellow triangle.
Not even the battery animation when charging while off works anymore *lol*
Here is what I did so far:
extracted a stock initramfs from a samsung stock kernel
got the Samsung kernel sources and extracted on my PC
got the codesourcery toolchain and installed it
edited the path to the toolchain into kernel/Makefile
ran
make c1_rev02_defconfig (as stated in the readme.txt of the src download)
set the path to the extracted iniramfs files in the config
ran
make zImage
It eventually tells me "kernel zImage ready at ...."
padded with 0x00s to the 8MiB size, .tar'ed and flashed via Odin
But it doesn't boot.
When I throw my zImage at the initramfs extractor script, I get the proper initramfs files dumped, so they seem to be fine.
Searched around this forums for two days now, found a few "zImage repacker scripts" but none work or clear up any of my questions.
Any hints on what I missed or did wrong are appreciated
And while we're at it, another question:
At new FW builds, does the actual kernel itself change too, or is it only changes in the initramfs? Because there is only one set of sources from Samsung.... so I assume the actual kernel stays the same and using the initramfs of the targetted FW will suufice?
Why did you pad it up to 8mb?
also, when setting the initramfs source, did you set these to you uid you are compiling with?
CONFIG_INITRAMFS_ROOT_UID=1000
CONFIG_INITRAMFS_ROOT_GID=1000
Hm, padded to 8MB as all kernels are (padded to) 8MB, aren't they?
Tried flashing an unpadded version too, still no go.
And yes, UID and GID are set to the ones my user is running as....
Close to the end of the compiler run, I get a "found 14 module section missmatches" kind of message - could that have something to do with my zImage not working? And how would I fix that?
Oh c'mon, it can't be that hard, so many people are making their own zImages.... what am I missing here.... :-/
First of all, you cant just use a stock initramfs image, shove it into another kernel and expect it to work. There are kernel modules in there which need to be updated first before you do the last "make zImage".
Try this:
0. make sure your config is correct. you should copy c1_rev02_defconfig from inside arm/ to source_root/.config and do a "make oldconfig". Then adjust your configs as necessary ("make menuconfig" etc)
1. "make modules"
2. "INSTALL_MOD_PATH=~ make modules_install"
3. goto your home dir and pick out the modules and put them into the path of your initramfs files (/lib)
4. finally, make zImage.
5. theres no need to pad to 8mb. that is an urban legend
OK, did all that.... still no go.... :-/
Try this script:
Code:
#!/bin/bash
# Set Default Path
TOP_DIR=$PWD
KERNEL_PATH=/home/neophyte-x360/kernel/GALAXYS2/2.6.35.7
# TODO: Set toolchain and root filesystem path
TAR_NAME=zImage.tar
TOOLCHAIN="/home/neophyte-x360/android/system/prebuilt/linux-x86/toolchain/arm-eabi-4.4.3/bin/arm-eabi-"
# TOOLCHAIN="/home/neophyte-x360/toolchain/bin/arm-none-eabi-"
ROOTFS_PATH="/home/neophyte-x360/kernel/GALAXYS2/initramfs-SGS2"
echo "Cleaning latest build"
make ARCH=arm CROSS_COMPILE=$TOOLCHAIN -j`grep 'processor' /proc/cpuinfo | wc -l` clean
cp -f $KERNEL_PATH/arch/arm/configs/c1_rev02_defconfig $KERNEL_PATH/.config
make -j4 -C $KERNEL_PATH oldconfig || exit -1
make -j4 -C $KERNEL_PATH ARCH=arm CROSS_COMPILE=$TOOLCHAIN || exit -1
cp drivers/bluetooth/bthid/bthid.ko $ROOTFS_PATH/lib/modules/
cp drivers/net/wireless/bcm4330/dhd.ko $ROOTFS_PATH/lib/modules/
cp drivers/samsung/j4fs/j4fs.ko $ROOTFS_PATH/lib/modules/
cp drivers/samsung/fm_si4709/Si4709_driver.ko $ROOTFS_PATH/lib/modules/
cp drivers/scsi/scsi_wait_scan.ko $ROOTFS_PATH/lib/modules/
cp drivers/samsung/vibetonz/vibrator.ko $ROOTFS_PATH/lib/modules/
make -j4 -C $KERNEL_PATH ARCH=arm CROSS_COMPILE=$TOOLCHAIN || exit -1
# Copy Kernel Image
cp -f $KERNEL_PATH/arch/arm/boot/zImage .
cd arch/arm/boot
tar cf $KERNEL_PATH/arch/arm/boot/$TAR_NAME zImage && ls -lh $TAR_NAME
And try with other initramfs, maybe could be this.
PD: I forgot that with my script you have to select your initramfs inside .config
Very interesting thread!
Im about to study computer science and software engineering for 3 years in august.
Hoping/wishing/expecting to get into this eventually!
put this in your build script:-
export LOCALVERSION="-I9100XWKE7-CL215725"
this is just an example set its value to the same as the initramfs you used, e.g. the magicver in the modules.
sounds like your initramfs are incomplete...or more likely your toolchain is not quite right. even without recovery, your zimage should be 6-7mb...(no padding, and there is no need to)
OK, done a clean rebuild, taking care of everything you guys said:
made new initramfs dump from a stock zImage
make mrproper
make c1_rev02_defconfig
make menuconfig - set the paths/prefixes for toolchain, localversion and initramfs (also set my users UID and GID for mapping to UID/GUI 0) there, left everything else untouched and at defaults
make
copied the freshly built modules into my initramfs dir (checked with a hexeditor for the proper versionmagic, looks OK)
make zImage
resulting zImake size: ~5.7MB and no go, still doesn't boot.
I'll try now with another toolchain (using the last one available for d/l so far, just got the 2009-something one mentioned in the sources readme and going to try to use that one now) as well as different initramfs dumper....
I have not much hope this will change the outcome, but it's at least worth a try....
// EDIT (a few hours later xD)
SUCCESS
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
(anyone knows what the #9 is? where it comes from, what it says?)
I *finally* managed to get a completely self built kernel to boot \o/
So, what was it that played showstopper the whole time: THE TOOLCHAIN!
I had the latest (2011-something) version of the CodeSourcery toolchain installed - that does not seem to be a good idea.
Did exactely what I did before, but now with the 2009q3 version installed (like the readme of the source states) - and tadaa, it works!
// EDIT 2
Figured out the #9 as well, it's the build number / version; how many times I ran "make" since the last "make mrproper"
LET THE MODDING BEGIN (now the fun starts)
Glad to see someone's happy. I'm also trying to compile a kernel from source. However, mine's an I9100G. Managed to compile, flash and boot up my phone, but battery status and Wifi don't work. After looking through the dmesg log, apparently the battery driver is not being initialised. I wonder if anyone can help me? Maybe someone with knowledge of the OMAP platform?
aidfarh said:
Glad to see someone's happy. I'm also trying to compile a kernel from source. However, mine's an I9100G. Managed to compile, flash and boot up my phone, but battery status and Wifi don't work. After looking through the dmesg log, apparently the battery driver is not being initialised. I wonder if anyone can help me? Maybe someone with knowledge of the OMAP platform?
Click to expand...
Click to collapse
You can give me initramfs?
I cqn give it a try.
Sent from my GT-I9100
How to
HellcatDroid said:
Hello dev community
I am currently trying to build my own kernel / zImage, but for some reason it doesn't work, when I flash my zImage the SGS2 crashs at the bootscreen with the yellow triangle.
Not even the battery animation when charging while off works anymore *lol*
Click to expand...
Click to collapse
Could you please give a few mn to write a min How To? I would like to build my own, but as a noob, I am a litle lost in all the info I gathered.
It would be nice to profit from your experience.
Or maybe do you have any good links?
TY
netchip said:
You can give me initramfs?
I cqn give it a try.
Sent from my GT-I9100
Click to expand...
Click to collapse
Well, if you think it can help, here's the download link for my initramfs:
http://dl.dropbox.com/u/13796854/initramfs.zip
It's for an I9100G, though. Do you have one to test with?
aidfarh said:
Well, if you think it can help, here's the download link for my initramfs:
http://dl.dropbox.com/u/13796854/initramfs.zip
It's for an I9100G, though. Do you have one to test with?
Click to expand...
Click to collapse
I haven't one for testing.
I am a kernel developer here for SGS2, check the development part.
Related
Hello, everyone!
This is intended for everyone who want to modify kernels they are using. Since I could not find tutorials on how to repack kernels for our Novathor devices, I decided to write my own tutorial. Maybe there are other ways, but this is how I do it and it is 100% failsafe. I took transcendence CM 1.1.6 kernel as an example in this tutorial. So, let's start!
Requirements:
- Flashtool
- Linux (Ubuntu preferable), you can also use builduntu if you don't want to install linux to your hard drive
- Files provided in attachment
- Not to close terminal in linux at any price
- Brains
STEP 1: Unpacking
First of all, you want to unpack the kernel. This is the easiest one.
Fire up Flashtool, select tools/extractors/elf
Easy, right? Now, click on those three dots and find kernel you wish to modify. Kernel MUST have .elf extension for this to work, so if you have "boot.img" at you disposal, please rename it to "kernel.elf" (without quotes). Once you loaded your kernel, just click unpack. Do not close Flashtool yet. In it you will see logs that kernel is unpacked. Please take a screenshot of that window as we will need that report later. Screenshot should look like this:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
After you have saved screenshot somewhere, look in the folder where your kernel is, and you will find two or three files additional files, sometimes even four, depending on the kernel itself. They should be named this way:
kernel.elf.ramdisk.gz (very rarely, this file may be called kernel.elf.2)
kernel.elf.Image (sometimes this file may be called kernel.elf.1)
kernel.elf.3
kernel.elf.cmd
It depends on the kernel how much files you're going to have. Now, please rename them, so that you delete kernel.elf from names. Now they should be named like this:
ramdisk.gz
Image
3
cmd
Bolded files are needed for our modifications. Now to the next step!
STEP 2: Modifying
Now that we have needed files at our disposal, it's time to do the modifications.
Image file
This file is zImage of the kernel. This is the core of the kernel, where CPU frequencies, drivers, governors, etc. are stored. This file you cannot really modify but if you have built your own specific zImage, you can replace it. I don't recommend touching this file unless you know what you're doing (in other words, unless you're developer or programmer).
So, noobs: don't modify this file; pros: Go ahead
ramdisk.gz
You want to change that sweet boot image, that's why you want to unpack kernel in the first place? On how to create boot image, go here.
This file contains the rest of the tweaks developers apply to kernel. Here you will find CWM, bootsplash image, autoroot files, etc, all depending on kernel you are modifying. Now, hot to unpack this bloody file? some suggest to use 7zip, but this way you will break symlinks and your kernel will definitely not boot. Proper way of unpacking ramdisk.gz goes like this:
First of all, boot up linux (or load builduntu into virtual machine, your choice).
We want to set up working folders, right? Fire up terminal and enter following commands, one line at the time:
mkdir kernel-working
mkdir ramdisk-working
cd ramdisk-working
mkdir ramdisk-contents
cd ramdisk-contents
Click to expand...
Click to collapse
Don't close terminal, or I will break you fingers Now in your home folder you will find folders we've just created. Nice, isn't it? Remember those files we've unpacked earlier? copy them to these folders. ramdisk.gz goes to ramdisk-working folder, while the rest goes to kernel-working folder.
Download kernel_repack.zip from the attachment und unpack files which are in it to kernel-working folder.
Now we're all set up for modifying
Go back to the terminal. Copy and paste following command and run it:
gunzip -c ../ramdisk.gz | cpio -i
Click to expand...
Click to collapse
Again, don't close the terminal. This time I will break your legs if you do so Now ramdisk.gz is unpacked in ramdisk-contents folder (which is in ramdisk-working folder). There you will find bunch of files and folders. After you have done all your modifications, it's time to pack it up. To do so, run the following command in terminal:
find . | cpio -o -H newc | gzip > ../newramdisk.gz
Click to expand...
Click to collapse
In ramdisk-working folder you will find newramdisk.gz file, besides ramdisk.gz. Copy newramdisk.gz to kernel-working folder and rename it to ramdisk.gz.
Now all files for compiling new kernel are prepared. To the next and final step.
STEP 3: Packing kernel back
In terminal, run following commands (and yes, you run cd .. twice in a row):
cd ..
cd ..
cd kernel-working
Click to expand...
Click to collapse
Remember that screenshot we've took earlier? This is where we need it Told you so
And finally, here is the mother of all commands which neatly packs all of our files back into kernel, but don't use it just yet, I will explain why:
sudo python mkelf.py -o kernel.elf [email protected] [email protected],ramdisk [email protected],cmdline
Click to expand...
Click to collapse
Take a look at the my screenshot and you will see that each of the files have its own adress. For example Image is at the adress 0x00008000 and ramdisk.gz is at the adress 0x01000000,ramdisk and 3 is at the adress 0x00000000,cmdline. By writing proper names and adresses, I'm telling computer where to pack files inside the kernel. You will have to change adresses in this command according to your screenshot, because not all kernel have the same adresses for same files. This is the most important step because if you do this wrong, kernel will not properly compile!
If you did all the work correctly, in kernel-working folder you will find new kernel.elf file. If it was named boot.img before editing, rename it back, if it was named kernel.elf then leave as it is. If you want, you can test if you packed kernel properly by trying to unpack it in Flashtool. If flashtool reports that you have some files to unpack, than all is OK, if it reports nothing, then something went wrong.
Ta-da! Your kernel is finally packed and is ready to be flashed to your phone. Hopefully, if you didn't messed up something when you did your modifications and alterations to ramdisk.gz, it should properly boot.
You can flash kernel in your preffered way.
Final words:
I tried to make this tutorial as user-friendly as possible. It is pretty straightforward once you get into it.
I hope that I clarified some thing, and more importantly, that I helped you.
Cheers everyone, and happy, repacking/flashing/modifying
Not a bad guide! Keep it up!
Sent my Carbonised Xperia P
Nice! :good:
Another good reference for kernel unpacking is this: http://forum.xda-developers.com/xperia-u/general/tutorial-explaining-stock-boot-image-t2126924
Enviado desde mi ST25i mediante Tapatalk
great guide
I just have windows , so am i doomed ?? I just wanted to change my kernel to Candy instead of Sony
Johnt880 said:
I just have windows , so am i doomed ?? I just wanted to change my kernel to Candy instead of Sony
Click to expand...
Click to collapse
Run builduntu in virtualbox.
If i got a sony kernel that sorted with the word sony out that will do my phone ?Just a standard kernel
I didn't quite understand you, can you clarify a little?
kernel 4.4.2
is there a way to modify the kernel aosp 4.4.2. This method does not work
kosmos-2011 said:
is there a way to modify the kernel aosp 4.4.2. This method does not work
Click to expand...
Click to collapse
Try that > http://forum.xda-developers.com/showthread.php?t=2073775
Hey guys!
I finally did it and downloaded the liquid smooth's and device's repos. But now when I type 'make otapackage -j4 -i' after 4 hours(!) of compiling it stucks at a certain file and then I can't move the mouse, type someting or anything, Ubuntu 14.04 freezes and I have to press the power button to force the PC close.
Please anyone help? I'm posting a picture with my PC:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
lefterios said:
Please anyone help? I'm posting a picture with my PC:
Click to expand...
Click to collapse
You might have a corrupted gvfsd-metadata. Do pkill gvfsd-metadata, rm -rf ~/.local/share/gvfs-metadata.
And compiling time depends on the computer specs and can easily take more than 3 hours on an average core processor(i3).
MasterAwesome said:
You might have a corrupted gvfsd-metadata. Do pkill gvfsd-metadata, rm -rf ~/.local/share/gvfs-metadata.
And compiling time depends on the computer specs and can easily take more than 3 hours on an average core processor(i3).
Click to expand...
Click to collapse
Okay I'll try it today I'll report if this worked.
I have an Intel core i5 with 3GB Ram and I think that it's quite long...
But thanks anyway!
Okay so I compiled again and now no freezes. Unfortunately however when it was going to end an error occured:
The weird thing is that all folders like system, recovery etc are there
Can you help?
lefterios said:
Okay so I compiled again and now no freezes. Unfortunately however when it was going to end an error occured:
The weird thing is that all folders like system, recovery etc are there
Can you help?
Click to expand...
Click to collapse
Can you paste the error here? With screenshots I can really help you. Just paste the error like this:
Code:
Error
GeekyDroid said:
Can you paste the error here? With screenshots I can really help you. Just paste the error like this:
Code:
Error
Click to expand...
Click to collapse
Ok sure:
Code:
Traceback (most recent call last):
File "./build/tools/releasetools/ota_from_target_files",line 1123, in <module>
main(sys.argv[1:])
File "./build/tools/releasetools/ota_from_target_files",line 1091, in main
WriteFullOTAPackage(input_zip, output_zip)
File "./build/tools/releasetools/ota_from_target_files",line 539, in WriteFullOTAPackage(OPTIONS.input_tmp,"BOOT")
File "/home/lefteris/working/build/tools/releasetools/common.py", line 361, in GetBootableImage
info_dict))
File "/home/lefteris/working/build/tools/releasetools/common.py", line 836, in __init__
self.size = len(data)
TypeError: object of type 'NoneType' has no len()
make: [/home/lefteris/working/out/target/product/golden/liquid_golden-ota-userdebug.lefteris.zip] Error 1 (ignored)
Sorry I may have made a mistake because I copied from the image. If you want full changelog you can right-click the image and press 'open image in a new tab'
lefterios said:
Ok sure:
Code:
Traceback (most recent call last):
File "./build/tools/releasetools/ota_from_target_files",line 1123, in
main(sys.argv[1:])
File "./build/tools/releasetools/ota_from_target_files",line 1091, in main
WriteFullOTAPackage(input_zip, output_zip)
File "./build/tools/releasetools/ota_from_target_files",line 539, in WriteFullOTAPackage(OPTIONS.input_tmp,"BOOT")
File "/home/lefteris/working/build/tools/releasetools/common.py", line 361, in GetBootableImage
info_dict))
File "/home/lefteris/working/build/tools/releasetools/common.py", line 836, in __init__
self.size = len(data)
TypeError: object of type 'NoneType' has no len()
make: [/home/lefteris/working/out/target/product/golden/liquid_golden-ota-userdebug.lefteris.zip] Error 1 (ignored)
Sorry I may have made a mistake because I copied from the image. If you want full changelog you can right-click the image and press 'open image in a new tab'
Click to expand...
Click to collapse
Did you type make -i (ignoring the errors?) If you did that, the zImage might not have been built because of errors and the boot image is not built due to this. It might also be because of fs size constraints. In your out folder of your device, check if you have the kernel and the root directory.
And in the py file the typecasting might have been done wrong since it says "object of type 'NoneType' has no len()"
MasterAwesome said:
Did you type make -i (ignoring the errors?) If you did that, the zImage might not have been built because of errors and the boot image is not built due to this. It might also be because of fs size constraints. In your out folder of your device, check if you have the kernel and the root directory.
And in the py file the typecasting might have been done wrong since it says "object of type 'NoneType' has no len()"
Click to expand...
Click to collapse
Ιn the out folder I have the root directory but not the kernel... And yes I typed -i because there were many errors and I couldn't build the ROM. So what do I have to do now? Please note that I'm beginner and I don't know very much for ROM development...
lefterios said:
Ιn the out folder I have the root directory but not the kernel... And yes I typed -i because there were many errors and I couldn't build the ROM. So what do I have to do now? Please note that I'm beginner and I don't know very much for ROM development...
Click to expand...
Click to collapse
As I said the error must have been in the kernel and ignoring that will not build the kernel, you will have to fix it manually the errors you face in the kernel building stage, post it here.
MasterAwesome said:
As I said the error must have been in the kernel and ignoring that will not build the kernel, you will have to fix it manually the errors you face in the kernel building stage, post it here.
Click to expand...
Click to collapse
Sorry I don't know how to do that :crying:
A question: Can I build the ROM with existing kernel image(boot.img) from another ROM? I don't make changes to kernel...
lefterios said:
Sorry I don't know how to do that :crying:
A question: Can I build the ROM with existing kernel image(boot.img) from another ROM? I don't make changes to kernel...
Click to expand...
Click to collapse
Yes you can, in the boardconfig.mk add a flag
TARGET_PREBUILT_KERNEL := $(DEVICE_FOLDER)/prebuilt/kernel
Be sure to define the DEVICE_FOLDER at the top of the make file.
Although its deprecated. But it'll work in your case if the kernel is a kitkat kernel.
MasterAwesome said:
Yes you can, in the boardconfig.mk add a flag
TARGET_PREBUILT_KERNEL := $(DEVICE_FOLDER)/prebuilt/kernel
Be sure to define the DEVICE_FOLDER at the top of the make file.
Although its deprecated. But it'll work in your case if the kernel is a kitkat kernel.
Click to expand...
Click to collapse
I tried it but again no luck What am I doing wrong? It produces all files and folders except kernel!
lefterios said:
I tried it but again no luck What am I doing wrong? It produces all files and folders except kernel!
Click to expand...
Click to collapse
I believe you forgot to remove the kernel directory flags from the board config.mk. attach it here.
MasterAwesome said:
I believe you forgot to remove the kernel directory flags from the board config.mk. attach it here.
Click to expand...
Click to collapse
Ok I attached the file found under ~/working/device/samsung/golden. I hope you can help me. I created the folder prebuilt and I put there a zImage. Is that right?
lefterios said:
Ok I attached the file found under ~/working/device/samsung/golden. I hope you can help me. I created the folder prebuilt and I put there a zImage. Is that right?
Click to expand...
Click to collapse
You named it as zImage and specified it as prebuilt/kernel. It should be $(DEVICE_FOLDER)/prebuilt/zImage.
MasterAwesome said:
You named it as zImage and specified it as prebuilt/kernel. It should be $(DEVICE_FOLDER)/prebuilt/zImage.
Click to expand...
Click to collapse
Firtsly is everything alright with the boardconfig file? So should I rename the file to zImage and that's it? And also which difference there is between kernel and zImage and which should I use?
lefterios said:
Firtsly is everything alright with the boardconfig file? So should I rename the file to zImage and that's it? And also which difference there is between kernel and zImage and which should I use?
Click to expand...
Click to collapse
Everything else seems fine... The path must be the path to your kernel or what ever you renamed it as.
I'd recommend you try and compile the kernel alone to check if it work
MasterAwesome said:
Everything else seems fine... The path must be the path to your kernel or what ever you renamed it as.
I'd recommend you try and compile the kernel alone to check if it work
Click to expand...
Click to collapse
I compiled the kernel alone and it didn't show any error. It made a zImage file successfully. So where is the problem?
lefterios said:
I compiled the kernel alone and it didn't show any error. It made a zImage file successfully. So where is the problem?
Click to expand...
Click to collapse
Trying doing a "make" without the -i and see where the build stops.
Huawei have helpfully released the kernel source for the Huawei P9 Plus on their download site. Impressively, the version posted there (3.10.90) actually matches the current release build. However, the download itself is only part of the puzzle - it's important to then know how to compile it and use it. Hence this guide.
Some points to note first of all...
This guide refers to building on Linux. You can probably build on OSX or whatever too but seriously, it's less pain in the long run to spin up an Ubuntu VM.
In the download linked above, as well as the kernel, there are some other bits and pieces (some of which are quite bizarre). I've mirrored the kernel to Bitbucket, so you don't need to grab the whole download.
Got that? OK, so here's a step by step on how to build the kernel! I strongly recommend building stock first and testing that works for you, then you can start adding your tweaks in. I'm interested to hear what you add / change!
Open a terminal window on your Linux machine / in your Linux VM. No GUIs here. Change to the directory where you want the kernel / toolchain to live.
First of all, we're going to clone the toolchain from AOSP.
Code:
git clone https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9
Next we're going to clone the kernel source itself from my git repo on bitbucket.
Code:
git clone https://gitlab.com/paulobrien/android_kernel_huawei_p9plus.git kernel
We need to add the toolchain location to the path.
Code:
export PATH=$(pwd)/aarch64-linux-android-4.9/bin:$PATH
We need to specify that we are cross compiling for arm64.
Code:
export CROSS_COMPILE=$(pwd)/aarch64-linux-android-4.9/bin/aarch64-linux-android-
Let's create a directory for our output to go in to.
Code:
mkdir out
We've got the kernel downloaded, so let's change to that directory so we're ready to go.
Code:
cd kernel
A bit of cleaning up before we get started...
Code:
make ARCH=arm64 O=../out mrproper
Specify that we're building for the P9 (hisi3650 chipset)...
Code:
make ARCH=arm64 O=../out p9plus_extracted_defconfig
And build it!
Code:
make ARCH=arm64 O=../out -j8
When this process completes, we can check the '../out' directory and you should find the file arch/arm64/boot/Image. This is the kernel that you've just built! You can't flash it as is though, you need to put it into a boot image first.
Here's how you do it...
Change out of the kernel directory back to its parent.
Code:
cd ..
Download tools for manipulating the boot image.
Code:
git clone https://github.com/xiaolu/mkbootimg_tools.git
Download the stock boot image (actually we're using the root ready version for convenience).
Code:
wget -O boot.img http://nigella.modaco.com/files/boot.stock.huaweip9plus.b161.img
Extract the boot image.
Code:
mkbootimg_tools/mkboot boot.img boot.extracted
Copy the new kernel into the extracted boot folder.
Code:
cp out/arch/arm64/boot/Image.gz boot.extracted/kernel
Build a new boot image.
Code:
mkbootimg_tools/mkboot boot.extracted boot.newkernel.img
You now have a new boot image (boot.newkernel.img). All that's left is to flash it to your device! Reboot to bootloader (either using 'adb reboot bootloader' or by powering on with volume down held), flash using 'fastboot flash boot boot.newkernel.img' and then reboot using 'fastboot reboot'. Job done! In the About screen of settings you should see the date of the new kernel and details of your build machine.
Great work mate. You are rock
paulobrien said:
Huawei have helpfully released
will this work for the latest nougat?
Click to expand...
Click to collapse
Hi @paulobrien, does this guide works for Huawei P10 souce code downloaded from here?? http://consumer.huawei.com/en/opensource/detail/
I am trying to compile aosp for Huawei p10.
Thank you.
Update: How to build the kernel for your Huawei P9 Plus
Hello Fellows,
thank you @paulobrien for this nice and handy How To.
It didn't work for me so I've updated your How To a little to compile the P9 Plus kernel for the VIE-L09 Device.
The kernel source and config file comes from the Huawei Opensource Website.
https://consumer.huawei.com/en/opensource/
Filtered for P9 Plus
-> P9 Plus, VIE-AL10, Android 7.0, EMUI 5.0
The source is from the VIE-AL10 but works great with the VIE-L09 as well.
I've put the unmodified kernelsource to github.
The updated How To is also inspired by this [ULTIMATE GUIDE] and the View attachment README_Kernel.txt from the Huawei VIE_NG_EMUI5.0_opensource.tar.gz
Thanks and Credits to @paulobrien, @osm0sis and @Eliminator79
Preconditions:
An unlocked bootloader and rooted P9 Plus
A dump of the phones boot.img for ex. with DD if=/dev/block/mmcblk0p28 of=/...boot.img
A Linux System to compile the source
A working fastboot connection
optional: A working ADB connection (to pull the dumped boot.img)
optional: A working SSH connection (to pull the dumped boot.img)
install ubuntu-14.04.6-desktop-amd64.iso
user and machine name will be displayed in the kernel
update git:
Code:
sudo apt-get install git
git --version -> git version 1.9.1
sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update && sudo apt-get install git
git --version -> [B]git version 2.26.2[/B]
menuconfig classic:
Code:
sudo apt-get install build-essential libssl-dev libncurses5-dev bison flex
menuconfig modern GUI:
Code:
sudo apt-get install libqt4-dev pkg-config
get the ndk r16b toolchain aarch64-linux-android-4.9 from Google:
Code:
wget https://dl.google.com/android/repository/android-ndk-r16b-linux-x86_64.zip
extract the aarch64 folder:
Code:
unzip android-ndk-r16b-linux-x86_64.zip android-ndk-r16b/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64/*
mv android-ndk-r16b/toolchains/aarch64-linux-android-4.9/prebuilt/linux-x86_64 aarch64-linux-android-4.9 && rm -Rf android-ndk-r16b
export path and cross_compiler: (needs to be done every reboot)
Code:
export PATH=$PATH:$(pwd)/aarch64-linux-android-4.9/bin
export CROSS_COMPILE=$(pwd)/aarch64-linux-android-4.9/bin/aarch64-linux-android-
install fastboot
Code:
sudo apt-get install android-tools-fastboot
sudo apt-get install android-tools-adb
Clone the actually source or extract the downloaded one in a directory for ex. P9PLUSKERNELSRC
just compile it or make some changes as well.
clone the Huawei P9 Plus Nougat Stock Kernel Source 4.1.18:
Code:
git clone https://github.com/newbit1/HUAWEI_P9PLUS_VIENNA_NG_EMUI5.0_STOCK_KERNEL_4.1.18.git P9PLUSKERNELSRC
Update 30.04.2020: OREO repo added
alternative for OREO, clone the P9 Plus Oreo Stock Kernel Source 4.4.23:
The OREO Kernel will not boot the P9Plus with Nougat on it. But It has its config.gz already included.
Code:
git clone https://github.com/newbit1/HUAWEI_P9PLUS_VIENNA_OREO_EMUI8.0_STOCK_KERNEL_4.4.23.git P9PLUSKERNELSRC
the stock default kernel config file is in "kernel/arch/arm64/configs/merge_hi3650_defconfig":
Code:
cd P9PLUSKERNELSRC/kernel
make ARCH=arm64 distclean
rm ../out -Rf && make clean && make mrproper && mkdir ../out
make ARCH=arm64 O=../out merge_hi3650_defconfig
If you want to make changes, use the menu to config the kernel:
menuconfig classic:
Code:
make ARCH=arm64 O=../out menuconfig
menuconfig modern GUI:
Code:
make ARCH=arm64 O=../out xconfig
compile the kernel... and have a drink
Code:
make ARCH=arm64 O=../out -j8
If/when the kernel is compiled, pack it with AIK-Linux in the dumped and unpacked boot.img from your P9-Plus.
An unlocked bootloader and rooted P9 Plus is a precondition!
For example purposes in this How To I use the boot.img from my phone.
It has a init with magisk root 20.3
get the Android Image Kitchen from osm0sis xda:
Code:
wget https://forum.xda-developers.com/attachment.php?attachmentid=4825093 -O AIK-Linux-v3.6-ALL.tar.gz
tar -xvzf AIK-Linux-v3.6-ALL.tar.gz
cd AIK-Linux
wget https://github.com/newbit1/HUAWEI_P9PLUS_VIENNA_NG_EMUI5.0_STOCK_KERNEL_4.1.18/raw/master/HUAWEI_P9PLUS_NG_STOCK_BOOT_KERNEL_4.1.18.img -O boot.img
./unpackimg.sh
rm -f split_img/boot.img-zImage
put the just compiled kernel into the AIK and repack it:
Code:
mv ~/P9PLUSKERNELSRC/out/arch/arm64/boot/Image.gz ~/AIK-Linux/split_img/boot.img-zImage
./repackimg.sh
the repacked boot image-new.img is ready to be flashed into the P9 Plus
checking the ADB connection:
Enable USB Debugging and connect the P9 Plus via USB:
Code:
adb devices
List of devices attached
N9xxxxxxxxxxxxxx device
checking the Fastboot connection:
unplug the usb cable in
switch off the phone
hold the volume down button and keep holding it
plug the usb cable in
phone boots into fastboot mode
release the volume down button
check the fastboot connection with the P9 Plus
Code:
sudo fastboot devices
N9xxxxxxxxxxxxxx fastboot
flash image-new.img with the new kernel
Code:
sudo fastboot flash boot image-new.img
target reported max download size of 471859200 bytes
sending 'boot' (16238 KB)...
OKAY [ 0.844s]
writing 'boot'...
OKAY [ 0.121s]
finished. total time: 0.965s
reboot the phone and unplug the cable
Code:
sudo fastboot reboot
your phone is booting now...
Enjoy your new kernel
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
@newbit, you think nice, but its old and not useful anymore for newer android versions. 2nd i think, your cam is broken.
dkionline said:
@newbit, you think nice, but its old and not useful anymore for newer android versions. 2nd i think, your cam is broken.
Click to expand...
Click to collapse
Thank you @dkionline for your feedback.
I have to admit, you did put me in shock for like a half of heartbeat regarding the camera.
However, no, the Cams are working fine. So far everything else as well, and yes it is possible
That something is not working as it should. I did not do any special hardware test yet.
Any suggestions on how to do this?
I agree, the topic is relatively old, but it was very useful to me, even though it was not working as described.
In addition, I do not like to spam the forum with similar topics, so I have just updated it.
The main reason for the need to compile it was the outdated kernel version.
Unfortunately I don't make any progress yet to upgrade my kernel, but I will publish it If I am going to make
any progress.
If you have any idea on how to cherry-pick a stable-linux kernel version into an android Linux kernel? Please be my guest,
any support is very much appreciated.
Cheers
NewBit
Edit: 02.05.2020
Your comment didn't let me go after all... How does this "cam is broken" manifest in detail?
I've notices I can only take some fotos right after the phone booted, and then it says loading
and keeps deleting the just taken photos. Video recording works. A non stock camera app
also still works. When I put the stock kernel back, it doesn't delete the photos anymore.
Where does this come from? The stock camera app itself? What is the reason behind this?
I can remember I had a very similar issue some time ago, but this was solved with a simple reboot, this isn't.
Thanks again for your feedback!
newbit said:
Edit: 02.05.2020
Your comment didn't let me go after all... How does this "cam is broken" manifest in detail?
I've notices I can only take some fotos right after the phone booted, and then it says loading
and keeps deleting the just taken photos. Video recording works. A non stock camera app
also still works. When I put the stock kernel back, it doesn't delete the photos anymore.
Where does this come from? The stock camera app itself? What is the reason behind this?
I can remember I had a very similar issue some time ago, but this was solved with a simple reboot, this isn't.
Thanks again for your feedback!
Click to expand...
Click to collapse
In detail, the cam cant save pictures in Nougat, in all EMUI 5 sources we got. So, if you want, better update to EMUI 8 and build a kernel there. All works well, but just GCC4.9 toolchains.
If you're in a hurry and just want to know the latest news, follow this link:
https://forum.xda-developers.com/showpost.php?p=80393641&postcount=58
Keep reading for some background info.
Hi there!
So... I'm trying to port LineageOS (version 15.1) from OnePlus - OnePlus2 device to the LeEco LeMax 1 phone.
Why I've chosen this device to port from?
It has the MSM8994 (Qualcomm Snapdragon 810) SoC, which is the same as Max1, so (supposedly) a kernel compile would not be too much hassle. Besides it also has many similarities in terms of hardware.
What I did for device dir:
I took the tree from https://github.com/LineageOS/android_device_oneplus_oneplus2 and modified it to meet max1 requirements.
Current tree: https://github.com/alexsmithbr/android_device_letv_max1
What I did for vendor dir:
I compared the tree with Max1 tree, excluding everything that was not found in Max1. The plan is to add more vendor stuff if necessary.
Current tree: https://github.com/alexsmithbr/android_device_letv_max1
What I did for kernel dir:
I downloaded Le_Max_OpenSource.zip from opensource.le.com (in fact, as the site is down, I got a copy from http://web.archive.org/web/20180626053054/http://opensource.le.com:80/ and, from there, I found the file I needed was named Le_Max_OpenSource.zip. I got it from here.
The kernel config in this zip file is exactly the same I get from the device itself, with adb pull /proc/config.gz.
Current tree: https://github.com/alexsmithbr/android_kernel_letv_max1
Interesting related threads:
https://forum.xda-developers.com/showpost.php?p=78690008&postcount=7
https://forum.xda-developers.com/le.../cm-14-1-android-7-1-unofficial-letv-t3530173
Other possibly useful resources:
http://web.archive.org/web/20180626053054/http://opensource.le.com:80/
https://forum.xda-developers.com/showpost.php?p=78676206&postcount=2402
These are thanks to @rico69310, specifically this post:
https://www.mediafire.com/folder/ff7hbpa62ivsg/
https://yadi.sk/d/RPfdh3glmhzarw
https://cloud.mail.ru/public/GP9g/cWpyeYbuK/
Another useful resource, in case you brick your X900. This is thanks to @Phsh:
https://forum.xda-developers.com/showpost.php?p=75157516&postcount=2375
Current status
I can build LineageOS 15.1 completely, but, once flashed, the kernel doesn't boot and phone enters bootloader (the penguin screen) and stay there.
What I need
It's pretty obvious I need the ROM working...
But the focus now would be to have a working boot.img. I really don't know what I'm doing wrong.
I can't get any logs, as LeEco patched the kernel so that we don't have a last_kmsg. Instead, they apparently put last_kmsg into another partition in /dev/block/platform/soc.0/f9824900.sdhci/by-name/letvconfig2. You can check this in the kernel, file kernel/printk/last_kmsg.c, line 124:
Code:
#define DEFAULT_KERNELLOG_FILENAME "/dev/block/bootdevice/by-name/letvconfig2"
char *kernlog_file = DEFAULT_KERNELLOG_FILENAME;
Well, I tried to give an overview of all steps I took. Please feel free to ask anything or give hints.
Together we can make LeEco LeMax 1 live longer!
Thought it would be nice to describe my build process.
Basically I'm following these instructions: https://wiki.lineageos.org/devices/oneplus2/build
Of course these instructions are for oneplus2, but the step-by-step is pretty much the same for any device.
I'm using Ubuntu 18.04.1 LTS, in which I created a user specifically for building LineageOS.
I followed all steps on the above link until breakfast oneplus2, since, at this point, I had to create my own device/vendor/kernel tree, so that I can breakfast it.
To do this, I did:
Code:
# clone max1 device
cd ~/android/lineage/device
mkdir letv
cd letv
git clone https://github.com/alexsmithbr/android_device_letv_max1.git max1
# clone max1 vendor
cd ~/android/lineage/vendor
mkdir letv
cd letv
git clone https://github.com/alexsmithbr/android_vendor_letv_max1.git max1
# setup kernel
cd ~/android/lineage/kernel
mkdir letv
cd letv
# change <path_to_file> to the correct path to Le_Max_OpenSource.zip
# you downloaded from the link on the previous post.
unzip <path_to_file>/Le_Max_OpenSource.zip -d max1
# as the zip has unnecessary subfolders, I just moved them
# to their correct names and deleted other rubbish.
mv max1/LeMax_kernel/kernel/ max1/msm8994
rm max1/LeMax_kernel/ -R
In the end, you need a structure like this:
Code:
~/android/lineage/device/letv/max1
~/android/lineage/vendor/letv/max1
~/android/lineage/kernel/letv/msm8994
Finally, put config.gz in its dir:
Code:
adb pull /proc/config.gz /tmp
gunzip /tmp/config.gz -c > ~/android/lineage/kernel/letv/msm8994/arch/arm64/configs/msm8994-max1-perf_defconfig
Okay, now everything is set up for the build to start.
Code:
source build/envsetup.sh
breakfast max1
export USE_CCACHE=1
ccache -M 50G
export ANDROID_JACK_VM_ARGS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4G"
croot
Just before start building, I choose which kind of build I want:
Code:
choosecombo
Build type choices are:
1. release
2. debug
Which would you like? [1] 1
Which product would you like? [lineage_max1]
Variant choices are:
1. user
2. userdebug
3. eng
Which would you like? [eng]
Now, if you want a normal build, you can enter:
Code:
brunch max1
But, if you want a really verbose log (very useful to debug build errors), you can enter:
Code:
mka -j 4 showcommands
Note that -j 4 means 4 simultaneous jobs. You can specify another number. A rule of thumb is to use <number_of_cpus> * 2.
Now the system should build...
At this point:
https://github.com/alexsmithbr/andr...tree/0f9134dd09c269b2da9008c5598060b9d19ac2ef
https://github.com/alexsmithbr/andr...tree/9ece561a945867ab2af733c5ef890b6df5438a8b
The system builds and mka -j 4 showcommands bacon will build flashable lineage-15.1-20190128-UNOFFICIAL-max1.zip.
Unfortunately, when flashing this zip, and restarting the phone, it will vibrate twice when showing the LeEco first screen, then it vibrates twice again and shows me the penguin screen (bootloader).
No luck up to now.
Keep up with the good work... I hope you get the kernel working.
Spunkination said:
Keep up with the good work... I hope you get the kernel working.
Click to expand...
Click to collapse
Me too!
It's so hard to get any help... I've been to freenode as well and nobody wanted to help there. :/
So it feels like a very lonely path. But I'm still on to it.
Currently I'm recompiling everything, now getting "my" tree a bit closer to @ABM30 tree, adapted to LineageOS, instead of CyanogenMod.
Let's see what happens next.
No luck. Boots to penguin (bootloader) screen again.
---------- Post added at 09:37 AM ---------- Previous post was at 09:33 AM ----------
I'm cheering for you. I would very much like 8.1 Good luck ! Good work!
htimsxela said:
Me too!
It's so hard to get any help... I've been to freenode as well and nobody wanted to help there. :/
So it feels like a very lonely path. But I'm still on to it.
Currently I'm recompiling everything, now getting "my" tree a bit closer to @ABM30 tree, adapted to LineageOS, instead of CyanogenMod.
Let's see what happens next.
No luck. Boots to penguin (bootloader) screen again.
Click to expand...
Click to collapse
Hope you are good friend?
How is the build going?
I updated the git repositories. The current version compiles as well and I get a ROM at the end, but unfortunately it doesn't boot. I'm probably missing something in the kernel build. I'm still investigating, but I don't even get to the LineageOS logo. When I turn on the phone, it goes straight to bootloader (penguin) screen.
I'll keep trying. Since a build involves a lot (really!) of variables, there's always something new to try.
And it's good that we keep this thread active. Maybe someone with more knowledge shows up and is able to help.
My biggest issue is I can't find a way of seeing what's wrong, since LeEco patched the kernel in a way there is no /proc/last_kmsg file, nor /sys/fs/pstore/console-ramoops. LeEco implemented it in a way the logs would be written to a partition called letvconfig2, but even there I cannot see any logs.
I read another way of seeing kernel logs would be to use the phone's serial port, but then I'd have to reach its main board, which is not an option currently, since this is my only phone.
In other words, my options now resume to keep trying.
Tomorrow I expect to have some time to resume the work. Will give it some more tries. I'm even thinking about checking out a previous version of LineageOS (when it was still called CyanogenMod), then, once I get it working, try to make my way to newer versions.
Stay tuned!
And again: any hints are more than welcome!
I really believe this thread may become kind of a roadmap to compile android for any unsupported device.
Update: by looking at recovery.img and comparing to the recovery partition on device, I noticed the kernel being built by LineageOS doesn't contain any DTBs. Without DTBs, the kernel won't be able to identify the phone's hardware.
How I checked this:
Code:
$ mkdir /tmp/boot
$ cd /tmp/boot
$ unpackbootimg -i ~/android/lineage/out/target/product/max1/recovery.img -o .
BOARD_KERNEL_CMDLINE console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=qcom user_debug=31 msm_rtb.filter=0x37 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 boot_cpus=0-5 androidboot.selinux=permissive buildvariant=userdebug
BOARD_KERNEL_BASE 00000000
BOARD_PAGE_SIZE 4096
$ split-appended-dtb-master/split-appended-dtb recovery.img-zImage
ERROR: Appended Device Tree Blob not found!
I'll try to find out how to automatically add DTBs to the images.
I know there was a variable called TARGET_KERNEL_APPEND_DTB, which should be set to true on older (cyanogenmod) versions, but it is now deprecated. So deprecated that even the "deprecated" messages have been removed by now.
As far as I could figure out, now the action of appending/not appending DTBs to the kernel image is guessed by variable BOARD_KERNEL_IMAGE_NAME. For example:
To add dtb to kernel image, one would do:
Code:
BOARD_KERNEL_IMAGE_NAME := Image-dtb
To don't add dtb to kernel image, one would do:
Code:
BOARD_KERNEL_IMAGE_NAME := Image
I was hoping this would change something, as for me that variable was defined without the -dtb suffix, but I figured out I broke the kernel build:
Code:
make[1]: *** No rule to make target 'Image-dtb'. Stop.
I guess this is because the original kernel is too old (3.10.84) and it's AndroidKernel.mk still relies on TARGET_KERNEL_APPEND_DTB, as we can see on line 68:
Code:
ifeq ($(TARGET_KERNEL_APPEND_DTB), true)
$(info Using appended DTB)
TARGET_PREBUILT_INT_KERNEL := $(TARGET_PREBUILT_INT_KERNEL)-dtb
endif
Patch the kernel? Wow! This is going deep...
* unpackbootimg is part of the android_bootimg_tools. I got it from here: wget https://storage.googleapis.com/goog...d-serialport-api/android_bootimg_tools.tar.gz
* split-appended-dtb is this tool: https://github.com/dianlujitao/split-appended-dtb
Turns out there are two ways of adding DTBs.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
By checking my current recovery partition, I noticed DTBs are attached to partition, not to kernel. I also noticed it is not using a compressed kernel. So I'll configure BoardConfig.mk as:
Code:
BOARD_KERNEL_IMAGE_NAME := Image
If I wanted it gzipped, I'd make it Image.gz. If I wanted the DTBs attached to kernel (not to image), I'd do Image.gz-dtb.
Apparently no kernel patch will be needed... Anyway I created a git repository for it, just in case I need to change something.
Again, the build works, but it doesn't boot.
As I'm focusing on testing the kernel, I'm using the recovery partition.
I just dumped a copy of it with:
Code:
host$ adb shell
phone$ su
phone# cp /dev/block/bootdevice/by-name/recovery /sdcard
phone# exit
phone$ exit
host$ adb pull /sdcard/recovery
and I'm flashing it over and over to test.
To do this, I do
Code:
host$ adb reboot bootloader
# phone reboots
host$ fastboot flash recovery /path/to/recovery.img
# it flashes, then, holding volume-up, I type:
host$ fastboot reboot
Phone will reboot into recovery and test my image (up to now, I only get back to penguin screen (bootloader)).
To flash back my working recovery image, I do the same as above, just changing the path to recovery image.
Bless you and your work
Dude, I would definitely-definitely liked to help; I understand and root for your hard work. But unfortunately I don't possess any knowledge in this area. Yeah, I can flash using manual, but I'm lamer in terms of programming, not even close to IT.
htimsxela said:
Hi there!
Click to expand...
Click to collapse
I rarely meet such wonderful and persistent people like you. I sincerely hope you will succeed and achieve your goal! :good:
Santey Maas said:
Dude, I would definitely-definitely liked to help; I understand and root for your hard work. But unfortunately I don't possess any knowledge in this area. Yeah, I can flash using manual, but I'm lamer in terms of programming, not even close to IT.
Click to expand...
Click to collapse
Thanks, mate! I didn't give up yet. Each try brings more knowledge and I hope I'm able to share all I'm learning. Sort of paving the road for newcomers.
Tircon said:
I rarely meet such wonderful and persistent people like you. I sincerely hope you will succeed and achieve your goal! :good:
Click to expand...
Click to collapse
Thanks! My hope is that - if I succeed - more people can benefit from my work and give these phones a longer life.
LeEco Le Max (max1/x900) Secret Codes
A bit off-topic, but here it goes... While looking for a way to debug kernel boot, I came across those famous secret codes you can type on phone screen to access secret/test menus... This site, for example, says you can use code *#*#76937#*#* to have access to a menu where you can enable/disable some log, debug and AT commands options. I tested and it worked with my phone. Not happy enough, I did a
Code:
grep 76937 / -rl
on the phone and found out system/app/LetvDebugUtil/oat/arm64/LetvDebugUtil.odex was the only place where it occurred. Inspecting the file, I found, right next to the occurrence, the code 9439. Just to test, I entered *#*#9439#*#* on the phone and got to a Chinese menu (see attached picture). The translation of these Chinese stuff is "Launch China Telecom Network (CDMA)". I didn't check that box to see what happens.
Current known codes
*#*#76937#*#* - Menu where you can enable/disable some log, debug and AT commands options.
*#*#9439#*#* - Launch China Telecom Network (CDMA)
*#*#8888#*#* - Advanced settings. Here you can turn on logging of App, Modem, Net, Kernel, Bluetooth, GPS and WiFi. Logs are stored in /sdcard
*#0000# - About phone. Information about each card slot.
*#06# - MEID & IMEI numbers.
If you're having this error while trying to build LineageOS:
Code:
FAILED: /bin/bash -c "prebuilts/misc/linux-x86/flex/flex-2.5.39 -o/home/android_build/android/lineage/out/host/linux-x86/obj/STATIC_LIBRARIES/libaidl-common_intermediates/aidl_language_l.cpp system/tools/aidl/aidl_language_l.ll"
flex-2.5.39: loadlocale.c:130: _nl_intern_locale_data: Assertion `cnt < (sizeof (_nl_value_type_LC_TIME) / sizeof (_nl_value_type_LC_TIME[0]))' failed.
Aborted (core dumped)
ninja: build stopped: subcommand failed.
build/core/ninja.mk:151: recipe for target 'ninja_wrapper' failed
make: *** [ninja_wrapper] Error 1
make: Leaving directory '/home/android_build/android/lineage'
You're probably having the same issue I'm having with Flex. The easiest option is to recompile it. And it's easy.
Code:
$ cd prebuilts/misc/linux-x86/flex
$ mkdir flex-2.5.39-src
$ cd flex-2.5.39-src
$ tar zxvf ../flex-2.5.39.tar.gz
$ ./configure
$ make
$ cp flex ../flex-2.5.39
$ cd ..
$ rm flex-2.5.39-src -R
The above commands will recompile Flex for your architecture and everything should be fine (with Flex).
Some news regarding the overall progress with LineageOS.
I checked out the repo from cm-14.1 (cyanogenmod 14.1) and am now trying to build for it. If it builds, at least we'll have Android 7.1.x running on device. And - I believe - it could bring some light to start a port to a newer version (Lineage 15.1).
Up to now, I faced the same compile errors I got when compiling for 15.1, so it's being straight forward. I'm anxious to see if it'll boot. :fingers-crossed:
As usual, I'll keep you posted.
htimsxela said:
Some news regarding the overall progress with LineageOS.
I checked out the repo from cm-14.1 (cyanogenmod 14.1) and am now trying to build for it. If it builds, at least we'll have Android 7.0.1 running on device. And - I believe - it could bring some light to start a port to a newer version (Lineage 15.1).
Up to now, I faced the same compile errors I got when compiling for 15.1, so it's being straight forward. I'm anxious to see if it'll boot. :fingers-crossed:
As usual, I'll keep you posted.
Click to expand...
Click to collapse
Thanks for your effort!
This phone is great and it's pity that it was left without support..
htimsxela said:
Some news regarding the overall progress with LineageOS.
I checked out the repo from cm-14.1 (cyanogenmod 14.1) and am now trying to build for it. If it builds, at least we'll have Android 7.0.1 running on device. And - I believe - it could bring some light to start a port to a newer version (Lineage 15.1).
Up to now, I faced the same compile errors I got when compiling for 15.1, so it's being straight forward. I'm anxious to see if it'll boot. :fingers-crossed:
As usual, I'll keep you posted.
Click to expand...
Click to collapse
BTW if someone is curious out there, here's the CyanogenMod 14.1 branch I'm working on: https://github.com/alexsmithbr/android_device_letv_max1/tree/cm-14.1
It was based on CyanogenMod 12.1 and the code is almost three years old (last commit), so I'm spending some time updating obsolete code, etc.
Donnie2Darko said:
Thanks for your effort!
This phone is great and it's pity that it was left without support..
Click to expand...
Click to collapse
Yeah, let's see if I can help changing this scenario.
WARNING: This won't work currently for the SM-G9730. I need a recovery.img(.lz4) from the latest firmware.
Here's a not-so-widely-tested fix for the spontaneous reboot that occurs after rooting the SM-G9750 and other Snapdragon S10 models.
tulth located this patch. If you read the description of that patch, it mentions a NULL pointer getting dereferenced in find_get_entry (such a thing tends to cause crashes in your average program, so when this happens in the kernel, it's not surprising that a crash and reset is the response). If you look at tulth's last_kmsg, my last_kmsg and G-ThGraf's last_kmsg from a G9730, you'll notice they all have one thing in common: SHTF at smaps_pte_range+0x29c. What's at that location on those devices' kernel? Why it's only find_get_entry(vma->vm_file. So yeah, it's the same bug, already known to Google and it's been fixed in their kernel tree since January. The bug is triggered externally by reading /proc/<pid>/smaps_rollup under certain conditions. You might be able to workaround this by disabling programs to get more free RAM, but The Only Way To Fix the Underlying Kernel Bug Is To Fix the Kernel Itself™.
We're probably not going to see a new kernel update until (if?) we get an update for the next major version of Android. We Snapdragon S10* users already have an older kernel compared to Exynos S10 owners (our 4.14.78 vs. their 4.14.85) and it's probably because of that they don't see this bug. So I think the idea of Samsung fixing this is a non-starter. While I did manage to build an SM-G9750 kernel from source (their instructions leave a lot to be desired) with that patch applied, I could not get my phone to boot the result.
I am not a programmer, but I do know just slightly enough to get the ball rolling and provide the fix that that aforementioned patch does in the opcode form that can be applied onto the existing kernel on the phone.
While I've not half-arsed it in the sense I took the easy way out (always having mss->check_shmem_swap set to zero is an easy one-liner workaround; however, freeing of unneeded SHM pages wouldn't happen, eventually causing your phone to crawl to a halt), I am not familiar with assembly language for any platform at all and, as such, I could not find a way to free up enough space in the show_smap function. So I jump quite far out into a chunk of the .text section where it's full of zeroes. I don't know anything about the ELF format to be able to tell you why this section of zeroes exists - I make the probably-wrong assumption it's perhaps a requirement of the ELF format if a linker that's very good at producing optimised code still bothers to output that or it's optimisation by alignment - but it's there and it's a good place to add extra code to on account of, you know, being empty and marked executable.
As far as I can see, where I have placed the code isn't referenced by anything else at all in the kernel but I can't be 100% certain on that. Nevertheless, I've been testing this on and off (I've had to manually initiate reboots in between for various reasons) myself for the past seven days or so and I've not noticed any adverse effects.
EDIT: Saying that, I think I'll try and move the code into load_module() when I get time because this kernel can't actually load modules (see below) thus much of the code there is pointless.The risk is yours, should you choose to apply this fix.
I would've liked to wrote this as a kernel module, being far easier to maintain, and hooked the relevant smap functions (in a similar vein to flar2's wp_mod and AleksJ's ric_mod) but thanks to the geniuses at Samsung, load_module() will always return early and the compiler accordingly realises it can optimise the function by excising all the code needed to actually load a module - there's no point in keeping unreachable code. Why Samsung bothered turning on mandatory module signing is beyond me because modules will never load! You can see this for yourself: insmod /system/vendor/lib/modules/wil6210.ko will always fail with "Exec format error", and that's a signed module built and shipped by Samsung themselves for their kernel. Anyway.
As long as the kernel version remains the same, it's likely, but not guaranteed, the same patches will work for future software updates from Samsung and all I'll have to do is update the compatibility list. If you try this on any other kernel version, the chances of not being able to boot are very high. The task of maintaining this doesn't enthuse me, but I'll continue to do so out of necessity, for I like having a rooted phone but not one that restarts at the worst of times.
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
I know people have reported longer uptimes than that on their phone before having a forced restart, but in my case, my phone has AOD enabled, the latest stable Magisk version installed and is running EdXposed. Before this fix, I've never seen an uptime longer than about 16 hours (usually less), regardless of whether the phone was in use or not, as getting multiple restarts in a day tends to have that effect.
As long as you only write to the recovery partition (and that's the only block device that this guide tells you to write to ), you should always be able to use Odin to reflash it to reverse this, the process being somewhat similar to flashing Magisk in the first place but with the notable exception of not needing to factory reset anything. The following flashing routine was adapted from Magisk, so my thanks to topjohnwu.
If someone has the bright idea of sharing their already-patched recovery.img because typing copy and pasting commands is hard, I'll point out the following: anybody flashing such an image should really make sure they're running the same firmware and Magisk version the image was designed for. (And after reading ianmacd's posts, topjohnwu supposedly doesn't like pre-patched images with Magisk being shared. I'll respect that, and so should you.)
I won't take any responsibility if this damages your phone. Perform the following at your own risk. If you agree, then:
If you haven't already, root the phone with Magisk. Make sure to keep a copy of the magisk_patched.tar somewhere on your computer so you can reflash it with ODIN if something goes wrong here. Always make sure Magisk is installed before modifying the recovery partition yourself. If you have a pending software update, install that with Odin and root that first before doing the following.
Set up ADB on your phone and computer
From your computer, adb shell into the phone
Run
Code:
uname -r
Only attempt to apply these patches if you get 4.14.78-16509050 back. For an older version, the bottom of this post has previous patches that may or may not apply. Or just update your phone.
Run
Code:
su
and then
Code:
rm -rf /data/local/tmp/q12kpwrk ; mkdir /data/local/tmp/q12kpwrk && cd /data/local/tmp/q12kpwrk
Run
Code:
mkdir recovery && cd recovery
Find the recovery partition on your phone by running:
Code:
recovery_blk="`readlink -f /dev/block/by-name/recovery`" ; [ -b "$recovery_blk" ] || echo "Eh, something's off here. Don't continue"
Dump it to a file by running:
Code:
dd if="$recovery_blk" of=recovery.img
Extract the kernel by running:
Code:
/data/adb/magisk/magiskboot unpack recovery.img || echo "Stop! Do not continue!"
If you see the warning message again on a new line, then stop.
Otherwise, if all went well with the step above (the message "Kernel is uncompressed or not a supported compressed type!" can be safely disregarded), then note that for any of these patches, if you don't get any matches or get more than one, then do not continue any further. Don't selectively apply any of these patches; it's all or nothing.
Apply the first patch by running:
Code:
/data/adb/magisk/magiskboot hexpatch kernel F7030032895240F9F64F00F9 F7030032FD10F997F64F00F9
Run
Code:
/data/adb/magisk/magiskboot hexpatch kernel 02000014C02E00F9E1630191 02000014ED10F997E1630191
If you have an SM-G9750/Snapdragon S10+: run
Code:
/data/adb/magisk/magiskboot hexpatch kernel F30300AAA1010035F40313AA750640F9890E41F83F7500F103010054AA02098BC10501B0407100D121B83191 F30300AA0D000014895240F9DF420239C0035FD600000000D22E40F94E02008BCE2E00F9C0035FD621B83191
OR if you have an SM-G9730/Snapdragon S10: there is currently no patch. Feel free to send me a recovery.img from the latest firmware and I'll adapt it
OR if you have an SM-G9700/Snapdragon S10e (thanks to Laikar_ for the recovery.img and testing): run
Code:
/data/adb/magisk/magiskboot hexpatch kernel F30300AAA1010035F40313AA750640F9890E41F83F7500F103010054AA02098BA10501D0407100D121B81D91 F30300AA0D000014895240F9DF420239C0035FD600000000D22E40F94E02008BCE2E00F9C0035FD621B81D91
Have the patched kernel placed into a new recovery image, new-boot.img, by running:
Code:
/data/adb/magisk/magiskboot repack recovery.img || echo "Stop! Do not continue!"
Check to see if new-boot.img isn't somehow larger than the recovery partition itself by running
Code:
[ `stat -c '%s' "new-boot.img"` -gt `blockdev --getsize64 "$recovery_blk"` ] && echo "Do not continue!"
Flash the new recovery image by running
Code:
cat new-boot.img /dev/zero >"$recovery_blk" 2>/dev/null
Run
Code:
sync ; sync ; sync ; reboot recovery
If the phone boots again, great! If you're stuck at the Samsung-only logo that fades in and out for many minutes, just restart the phone again whilst holding the recovery button combo to boot into Android with Magisk activated like normal.
You can rm -rf the /data/local/tmp/q12kpwrk folder afterwards to get some space back.
If your phone keeps restarting, or you automatically get put into semi-bootloader flashing mode, hold the bootloader button combo to get to the blue-background downloading mode and reflash magisk_patched.tar (and HOME_CSC) with Odin. If you didn't keep said file or a Magisk-patched recovery.img you can tar up with 7-Zip and get Odin to flash as AP, you'll need to download the latest firmware for your SM-G9750 with Frija or similar, reflash that and then follow the instructions to root your phone again with Magisk.
If you do get a reboot after applying this, looking at /proc/last_kmsg will indicate if it's something to do with this patch or something else entirely.
Q&A:
Q: Will I have to reapply this if I update Magisk from Magisk Manager with a direct install?
A: No.
Q: Will I have to reapply this if I update the phone's firmware?
A: Yes, but check the new kernel's version first and see if it's listed in the compatibility section. If not, then you'll need to wait for an update to this fix. And remember to make sure that Magisk is installed first before modifying the recovery partition yourself.
Q: I don't want to wait hours to see if my phone will restart out of the blue. How can I test for this bug?
A: A variation on the steps to reproduce here, you can do this:
Code:
su
dd if=/data/media/0/AP_G9750ZHU1ASF1_CL16082828_QB24224470_REV00_user_low_ship_MULTI_CERT_meta_OS9.tar.md5 of=/dev/shm # or any very large file (3-4 GB, /dev/urandom might work). This fills up the allocated space for shared memory
cat /proc/*/smaps_rollup
If your kernel isn't patched, restart your phone certainly does. (Of course, you should probably run reboot recovery anyway if not because a full SHM isn't really conducive to a well-running Android session.)
Q: Do you have any other kernel patches?
A: Just the one, only tested on the SM-G9750, and it seems to not be needed at all - it has no bearing on this specific reboot issue anyway. This one disables one aspect of RKP. Again, I don't think this is actually needed on the S10+ , but Magisk still attempts to patch for this issue indiscriminately (probably for the benefit of older devices), although its patch will not apply to our kernel.
Code:
/data/adb/magisk/magiskboot hexpatch kernel 1FA50F7143010054491540B93FA50F71E30000544B0940B97FA50F71830000544A1940B95FA10F7168090054 1FA10F71810A0054491540B93FA10F71200A00544B0940B97FA10F71C00900544A1940B95FA10F7161090054
Q: Are you a dirty GPL violator, qwerty12?
A: No! What I am providing is the compiled form of the patch linked to in the beginning of this thread. If you want to understand what this does in lovely C, just look at that patch. Of course, I have to deal with this on the assembler level, so there is no source per se, just dump all the hex strings into an online disassembler. The first two magiskboot hexpatch invocations replace two existing instructions with jumps into the new code I add. The third hexpatch invocation adds the additional code implementing the patch - the original replaced instruction is executed, along with the code I added to set mss->check_shmem_swap to zero before vma->vm_file is checked for != NULL and for shmem_swapped to be added to mss->swap instead of replacing it.
Patches for older kernels:
4.14.78-16082828:
Use Magisk Manager to install the Busybox Magisk module. No, this is not optional. You can use a version of Busybox from another source, but note that this is the version I have personally tested all this with. Restart your phone anyway if you already have it installed; you want your phone's running state to be as fresh as possible to avoid the possibility of running into this bug while attempting to fix it.
Code:
/data/adb/magisk/magiskboot hexpatch kernel F7030032895240F9F64F00F9 F70300327ED15494F64F00F9
Code:
/data/adb/magisk/magiskboot hexpatch kernel 02000014C02E00F9E1630191 020000146ED15494E1630191
Code:
printf '\x89\x52\x40\xF9\xDF\x42\x02\x39\xC0\x03\x5F\xD6\x00\x00\x00\x00\xD2\x2E\x40\xF9\x4E\x02\x00\x8B\xCE\x2E\x00\xF9\xC0\x03\x5F\xD6' | busybox dd of=kernel bs=1 seek="$((0x017F9AAC + 20))" conv=notrunc
The magiskboot hexpatch equivalent of this was too large, so I settled for writing to a hard coded offset.
I have random reboot... will try this patch tomorrow.
Sent from my SM-G9750 using Tapatalk
Hi... already doing your patches... i thinks succesfully, because i dont have any error, and boot normally after last command.
So.... i have to wait if random reboot appear right ? *to test*
Thank you... will report in about 3 days
Hi,
Vuska said:
So.... i have to wait if random reboot appear right ? *to test*
Click to expand...
Click to collapse
You can run the commands under "Q: I don't want to wait hours to see if my phone will restart out of the blue. How can I test for this bug?" in the first post. If your phone restarts automatically when running cat, then your phone is still susceptible to restarting itself during use.
If it doesn't restart, then you need to run reboot recovery yourself immediately, but it means the fix was successfully applied.
PS D:\S10+\ADB platform-tools> ./adb devices
List of devices attached
R28M31K3DNZ device
PS D:\S10+\ADB platform-tools> ./adb shell
beyond2q:/ $ su
Permission denied
1|beyond2q:/ $
?????
N1ldo said:
PS D:\S10+\ADB platform-tools> ./adb devices
List of devices attached
R28M31K3DNZ device
PS D:\S10+\ADB platform-tools> ./adb shell
beyond2q:/ $ su
Permission denied
1|beyond2q:/ $
?????
Click to expand...
Click to collapse
do you already install busybox via magisk ? also there will be a pop up in your device to request access from computer. accept it
already enable usb debugging in developer menu ?
permission denied .... [emoji848] .. strange... already rooted right ?
Sent from my SM-G9750 using Tapatalk
Vuska said:
do you already install busybox via magisk ? also there will be a pop up in your device to request access from computer. accept it
already enable usb debugging in developer menu ?
permission denied .... [emoji848] .. strange... already rooted right ?
Sent from my SM-G9750 using Tapatalk
Click to expand...
Click to collapse
Yes.
As you can see in the prints below.
i try install another busybox to.
N1ldo said:
beyond2q:/ $ su
Permission denied
1|beyond2q:/ $
?????
Click to expand...
Click to collapse
Check your Magisk settings to see if you haven't turned off ADB superuser access and your apps list for a denied Shell entry.
qwerty12 said:
Check your Magisk settings to see if you haven't turned off ADB superuser access and your apps list for a denied Shell entry.
Click to expand...
Click to collapse
Thank you all ...:good::good:
Yes Shell was unauthorized root on Magisk application list :victory:
3 days now.... i can say it successfully fixed.... [emoji106][emoji106]
Thank you.
hope you will update too when new firmware arrives....
because i dont understand some code mean.... just follow and copy paste
Sent from my SM-G9750 using Tapatalk
*ASG7 firmware is out
I can provide a recovery.img from s10e (smg9700), also any way i can contact you for some help about building the kernel? I have been trying to do with s10e's one and i'm not having much success
FlatOutRU said:
*ASG7 firmware is out
Click to expand...
Click to collapse
Downloading...
is ASG7 can use this patches ?
Sent from my SM-G9750 using Tapatalk
FlatOutRU said:
*ASG7 firmware is out
Click to expand...
Click to collapse
Vuska said:
s ASG7 can use this patches ?
Click to expand...
Click to collapse
I'll download the update later and give it a once-over; however, I'll quote myself:
qwerty12 said:
As long as the kernel version remains the same, it's likely, but not guaranteed, the same patches will work for future software updates from Samsung and all I'll have to do is update the compatibility list.
Click to expand...
Click to collapse
Laikar_ said:
I can provide a recovery.img from s10e (smg9700), also any way i can contact you for some help about building the kernel? I have been trying to do with s10e's one and i'm not having much success
Click to expand...
Click to collapse
That would be appreciated, thanks. I can move the S10e into the "Patch not tested" section of the compatibility list.
I wish you'd have asked me this a few days ago, I deleted the kernel tree I had on my disk because I thought a new source ZIP from Samsung would be forthcoming for the new firmware. I'd've just attached a diff...
I did get the kernel to build but I could not get the result to boot. Some of the compiler warnings displayed during build didn't make it seem like I was going to get a working kernel image. I'll get back to you soon with some steps
qwerty12 said:
That would be appreciated, thanks. I can move the S10e into the "Patch not tested" section of the compatibility list.
I wish you'd have asked me this a few days ago, I deleted the kernel tree I had on my disk because I thought a new source ZIP from Samsung would be forthcoming for the new firmware. I'd've just attached a diff...
I did get the kernel to build but I could not get the result to boot. Some of the compiler warnings displayed during build didn't make it seem like I was going to get a working kernel image. I'll get back to you soon with some steps
Click to expand...
Click to collapse
I can't post links yet, tinyurl(dot)com/y537462u for the drive download link
Does EdXposed work for G9750?
qwerty12 said:
I'll download the update later and give it a once-over; however, I'll quote myself:
Click to expand...
Click to collapse
Its changed a bit
kakahoho said:
Does EdXposed work for G9750?
Click to expand...
Click to collapse
Yes.
FlatOutRU said:
Its changed a bit
Click to expand...
Click to collapse
Good call; there's now code at 0x017F9AAC + 20, probably not a good idea to overwrite that...
I was hoping the newer build date might have meant that Samsung applied the patch, meaning I could abandon this thread, but no such luck: I did the quick writing to /dev/shm test and my phone kernel panicked. Lovely.
I've updated the first thread with an updated patch. I followed through with my plan of moving my extra code into load_module() instead of the empty section of zeros as, thanks to Samsung's kernel developers' ineptness, that function will always fail - may as well make it early return and then use the extra space gained to store my code in.
Laikar_ said:
I can't post links yet, tinyurl(dot)com/y537462u for the drive download link
Click to expand...
Click to collapse
Thanks for the S10e recovery image, Laikar_. I've checked the recovery image's kernel and moved the S10e into the "Patch not tested" section. I'll write up some steps soon on building a kernel that won't boot
Anyway,
The S10 and S10e recovery images are not from ASG7, however, so I don't know if my newer patch applies to it but my old ones do. I think my newer one will do, too, but that's an educated guess.
Just like with the S10, anybody's welcome to try this on their S10e and let me know of the result.
qwerty12 said:
Yes.
Good call; there's now code at 0x017F9AAC + 20, probably not a good idea to overwrite that...
I was hoping the newer build date might have meant that Samsung applied the patch, meaning I could abandon this thread, but no such luck: I did the quick writing to /dev/shm test and my phone kernel panicked. Lovely.
I've updated the first thread with an updated patch. I followed through with my plan of moving my extra code into load_module() instead of the empty section of zeros as, thanks to Samsung's brainiac developers, that function will always fail - may as well make it early return and then use the extra space gained to store my code in.
Thanks for the S10e recovery image, Laikar_. I've checked the recovery image's kernel and moved the S10e into the "Patch not tested" section. I'll write up some steps soon on building a kernel that won't boot
Anyway,
The S10 and S10e recovery images are not from ASG7, however, so I don't know if my newer patch applies to it but my old ones do. I think my newer one will do, too, but that's an educated guess.
Just like with the S10, anybody's welcome to try this on their S10e and let me know of the result.
Click to expand...
Click to collapse
so the first post already update to 050 kernel right ?
mean after i updated my s10+ magisk etc.. i can do that all steps right ?
cool...
still not yet finished my download since yesterday... my internet down.. [emoji2357]
Sent from my SM-G9750 using Tapatalk
Vuska said:
so the first post already update to 050 kernel right ?
mean after i updated my s10+ magisk etc.. i can do that all steps right ?
Click to expand...
Click to collapse
Yep, the first post is updated for ASG7. Those steps are working on my SM-G9750 running it, anyway
Laikar_ said:
[...]any way i can contact you for some help about building the kernel? I have been trying to do with s10e's one and i'm not having much success
Click to expand...
Click to collapse
I'll mention again that I couldn't get the result to boot. If you work it out, please let me know. I hate loading kernel images into a disassembler
I did this on a Ubuntu 18.04.2 minimal installation. I figure that if you want to build a kernel then you, like me, have at least a working familiarity with GNU/Linux, so I won't go too in-depth.
First, install the packages needed to build:
Code:
sudo apt install git-core gnupg flex bison gperf build-essential zip zlib1g-dev libxml2-utils xsltproc unzip python bc libssl-dev
Download the toolchain mentioned in README_kernel.txt:
Code:
git clone --depth=1 https://android.googlesource.com/platform/prebuilts/gcc/linux-x86/aarch64/aarch64-linux-android-4.9
Download Snapdragon LLVM Compiler for Android v6.0.9 - Linux64 from https://developer.qualcomm.com/software/snapdragon-llvm-compiler-android/tools and untar it somewhere on your system. (This isn't actually the exact compiler Samsung use - if you look at /proc/version on your phone, you'll see it says 6.0.10 - but this is the closest we mere mortals will get.)
Download the source code zip from Samsung and untar Kernel.tar.gz into a newly-created folder. Inside said folder, run chmod 644 Makefile ; chmod 755 build_kernel.sh.
Open build_kernel.sh in your favourite editor. Make the following changes:
Set BUILD_CROSS_COMPILE to the folder where aarch64-linux-android-gcc, aarch64-linux-android-ld etc. are after cloning from git. Make sure to leave the aarch64-linux-android- suffix at the end. For me, this line looks like this:
Code:
BUILD_CROSS_COMPILE=/home/fp/x/aarch64-linux-android-4.9/bin/aarch64-linux-android-
KERNEL_LLVM_BIN needs to be set to the location of the Clang binary downloaded from Qualcomm. For me, this line looks like this:
Code:
KERNEL_LLVM_BIN=/home/fp/x/93270/toolchains/llvm-Snapdragon_LLVM_for_Android_6.0/prebuilt/linux-x86_64/bin/clang
After both REAL_CC=$KERNEL_LLVM_BIN instances add
Code:
CFP_CC=$KERNEL_LLVM_BIN
(although I think this is the wrong way to do it, consider just disabling CONFIG_RKP_CFP)
Open the Makefile in your favourite editor. Find the following line
Code:
@echo Cannot use CONFIG_CC_STACKPROTECTOR_$(stackp-name): \
$(stackp-flag) not supported by compiler >&2 && exit 1
Remove the "&& exit 1". The proper way to fix this would be to set CONFIG_CC_STACKPROTECTOR_STRONG to n in the config file; however if you run clang --help, you'll see that -fstack-protector-strong is actually supported. Why turn off a useful security feature?
Run build_kernel.sh and the kernel should build (albeit with a metric crap-ton of warnings, which is just one reason why it's not surprising the resulting kernel won't boot)